fix logrotate (#2201)

vesoft-inc · Jul 31, 2023 · 1358504 · 1358504
1 parent 3839cd5
commit 1358504
Show file tree

Hide file tree

Showing 3 changed files with 85 additions and 43 deletions.
diff --git a/docs-2.0/3.ngql-guide/7.general-query-statements/3.go.md b/docs-2.0/3.ngql-guide/7.general-query-statements/3.go.md
@@ -1,6 +1,6 @@
 # GO
 
-`GO` traverses in a graph with specified filters and returns results.
+The `GO` statement is used in the NebulaGraph database to traverse the graph starting from a given starting vertex with specified filters and return results.
 
 ## OpenCypher compatibility
 
@@ -37,11 +37,11 @@ YIELD [DISTINCT] <return_list>
 
 - `M TO N {STEP|STEPS}`: traverses `from M to N` hops. When `M` is `zero`, the output is the same as that of `M` is `one`. That is, the output of `GO 0 TO 2` and `GO 1 TO 2` are the same.
 
-- `<vertex_list>`: represents a list of vertex IDs separated by commas, or a special place holder `$-.id`. For more information, see [Pipe](../5.operators/4.pipe.md).
+- `<vertex_list>`: represents a list of vertex IDs separated by commas.
 
 - `<edge_type_list>`: represents a list of edge types which the traversal can go through.
 
-- `REVERSELY | BIDIRECT`: defines the direction of the query. By default, the `GO` statement searches for outgoing edges of `<vertex_list>`. If `REVERSELY` is set, `GO` searches for incoming edges. If `BIDIRECT` is set, `GO` searches for edges of both directions.
+- `REVERSELY | BIDIRECT`: defines the direction of the query. By default, the `GO` statement searches for outgoing edges of `<vertex_list>`. If `REVERSELY` is set, `GO` searches for incoming edges. If `BIDIRECT` is set, `GO` searches for edges of both directions. The direction of the query can be checked by returning the `<edge_type>._type` field using `YIELD`. A positive value indicates an outgoing edge, while a negative value indicates an incoming edge.
 
 - `WHERE <expression>`: specifies the traversal filters. You can use the `WHERE` clause for the source vertices, the edges, and the destination vertices. You can use it together with `AND`, `OR`, `NOT`, and `XOR`. For more information, see [WHERE](../8.clauses-and-options/where.md).
 
@@ -66,10 +66,22 @@ YIELD [DISTINCT] <return_list>
 
 - `LIMIT  [<offset>,] <number_rows>]`: limits the number of rows of the output. For more information, see [LIMIT](../8.clauses-and-options/limit.md).
 
-## Examples
+
+## Notes
+
+- The `WHERE` and `YIELD` clauses in `GO` statements usually utilize property reference symbols (`$^` and `$$`) or the `properties($^)` and `properties($$)` functions to specify the properties of a vertex; use the `properties(edge)` function to specify the properties of an edge. For details, see [Property Reference Symbols](../4.variable-and-composite-queries/3.property-reference.md) and [Schema-related Functions](../6.functions-and-expressions/4.schema.md).
+
+- When referring to the result of a subquery in a compound `GO` statement, you need to set a name for the result and pass it to the next subquery using the pipe symbol `|`, and reference the name of the result in the next subquery using `$-`. See the [Pipe Operator](../5.operators/4.pipe.md) for details.
+
+- When the queried property has no value, the returned result displays `NULL`.
+
+## Cases and examples
+
+### To query the immediate neighbors of a vertex
+
+For example, to query the team that a person belongs to, assuming that the person is connected to the team by the `serve` edge and the person's ID is `player102`.
 
 ```ngql
-# The following example returns the teams that player 102 serves.
 nebula> GO FROM "player102" OVER serve YIELD dst(edge);
 +-----------+
 | dst(EDGE) |
@@ -79,8 +91,12 @@ nebula> GO FROM "player102" OVER serve YIELD dst(edge);
 +-----------+
 ```
 
+### To query all vertices within a specified number of hops from a starting vertex
+
+For example, to query all vertices within two hops of a person vertex, assuming that the person is connected to other people by the `follow` edge and the person's ID is `player102`.
+
 ```ngql
-# The following example returns the friends of player 102 with 2 hops.
+# Return all vertices that are 2 hops away from the player102 vertex.
 nebula> GO 2 STEPS FROM "player102" OVER follow YIELD dst(edge);
 +-------------+
 | dst(EDGE)   |
@@ -94,7 +110,35 @@ nebula> GO 2 STEPS FROM "player102" OVER follow YIELD dst(edge);
 ```
 
 ```ngql
-# The following example adds a filter for the traversal.
+# Return all vertices within 1 or 2 hops away from the player102 vertex.
+nebula> GO 1 TO 2 STEPS FROM "player100" OVER follow \
+        YIELD dst(edge) AS destination;
++-------------+
+| destination |
++-------------+
+| "player101" |
+| "player125" |
+...
+
+# The following MATCH query has the same semantics as the previous GO query.
+nebula> MATCH (v) -[e:follow*1..2]->(v2) \
+        WHERE id(v) == "player100" \
+        RETURN id(v2) AS destination;
++-------------+
+| destination |
++-------------+
+| "player100" |
+| "player102" |
+...
+```
+
+### To add filtering conditions
+
+Case: To query the vertices and edges that meet specific conditions.
+
+For example, use the `WHERE` clause to query the edges with specific properties between the starting vertex and the destination vertex.
+
+```ngql
 nebula> GO FROM "player100", "player102" OVER serve \
         WHERE properties(edge).start_year > 1995 \
         YIELD DISTINCT properties($$).name AS team_name, properties(edge).start_year AS start_year, properties($^).name AS player_name;
@@ -108,8 +152,13 @@ nebula> GO FROM "player100", "player102" OVER serve \
 +-----------------+------------+---------------------+
 ```
 
+### To query multiple edge types
+
+Case: To query multiple edge types that are connected to the starting vertex. You can specify multiple edge types or the `*` symbol to query multiple edge types.
+
+For example, to query the `follow` and `serve` edges that are connected to the starting vertex.
+
 ```ngql
-# The following example traverses along with multiple edge types. If there is no value for a property, the output is `NULL`.
 nebula> GO FROM "player100" OVER follow, serve \
         YIELD properties(edge).degree, properties(edge).start_year;
 +-------------------------+-----------------------------+
@@ -121,8 +170,10 @@ nebula> GO FROM "player100" OVER follow, serve \
 +-------------------------+-----------------------------+
 ```
 
+### To query incoming vertices using the REVERSELY keyword
+
 ```ngql
-# The following example returns the neighbor vertices in the incoming direction of player 100.
+# Return the vertices that follow the player100 vertex.
 nebula> GO FROM "player100" OVER follow REVERSELY \
         YIELD src(edge) AS destination;
 +-------------+
@@ -132,20 +183,21 @@ nebula> GO FROM "player100" OVER follow REVERSELY \
 | "player102" |
 ...
 
-# This MATCH query shares the same semantics with the preceding GO query.
+# The following MATCH query has the same semantics as the previous GO query.
 nebula> MATCH (v)<-[e:follow]- (v2) WHERE id(v) == 'player100' \
         RETURN id(v2) AS destination;
 +-------------+
 | destination |
 +-------------+
 | "player101" |
 | "player102" |
-+-------------+
 ...
 ```
 
+### To use subqueries as the starting vertice of a graph traversal
+
 ```ngql
-# The following example retrieves the friends of player 100 and the teams that they serve.
+# Return the friends of the player100 vertex and the teams that the friends belong to.
 nebula> GO FROM "player100" OVER follow REVERSELY \
         YIELD src(edge) AS id | \
         GO FROM $-.id OVER serve \
@@ -159,7 +211,7 @@ nebula> GO FROM "player100" OVER follow REVERSELY \
 | "Boris Diaw"        | "Suns"          |
 ...
 
-# This MATCH query shares the same semantics with the preceding GO query.
+# The following MATCH query has the same semantics as the previous GO query.
 nebula> MATCH (v)<-[e:follow]- (v2)-[e2:serve]->(v3)  \
         WHERE id(v) == 'player100' \
         RETURN v2.player.name AS FriendOf, v3.team.name AS Team;
@@ -172,65 +224,50 @@ nebula> MATCH (v)<-[e:follow]- (v2)-[e2:serve]->(v3)  \
 ...
 ```
 
-```ngql
-# The following example retrieves the friends of player 100 within 1 or 2 hops.
-nebula> GO 1 TO 2 STEPS FROM "player100" OVER follow \
-        YIELD dst(edge) AS destination;
-+-------------+
-| destination |
-+-------------+
-| "player101" |
-| "player125" |
-...
+### To use `GROUP BY` to group the output
 
-# This MATCH query shares the same semantics with the preceding GO query.
-nebula> MATCH (v) -[e:follow*1..2]->(v2) \
-        WHERE id(v) == "player100" \
-        RETURN id(v2) AS destination;
-+-------------+
-| destination |
-+-------------+
-| "player100" |
-| "player102" |
-...
-```
+You need to use `YIELD` to define the output that needs to be returned after grouping.
 
 ```ngql
-# The following example the outputs according to age.
+# The following example collects the outputs according to age.
 nebula> GO 2 STEPS FROM "player100" OVER follow \
         YIELD src(edge) AS src, dst(edge) AS dst, properties($$).age AS age \
         | GROUP BY $-.dst \
         YIELD $-.dst AS dst, collect_set($-.src) AS src, collect($-.age) AS age;
 +-------------+----------------------------+----------+
 | dst         | src                        | age      |
 +-------------+----------------------------+----------+
-| "player125" | ["player101"]              | [41]     |
-| "player100" | ["player125", "player101"] | [42, 42] |
-| "player102" | ["player101"]              | [33]     |
+| "player125" | {"player101"}              | [41]     |
+| "player100" | {"player125", "player101"} | [42, 42] |
+| "player102" | {"player101"}              | [33]     |
 +-------------+----------------------------+----------+
 ```
 
+###  To use `ORDER BY` and `LIMIT` to sort and limit the output
+
 ```ngql
 # The following example groups the outputs and restricts the number of rows of the outputs.
 nebula> $a = GO FROM "player100" OVER follow YIELD src(edge) AS src, dst(edge) AS dst; \
         GO 2 STEPS FROM $a.dst OVER follow \
         YIELD $a.src AS src, $a.dst, src(edge), dst(edge) \
         | ORDER BY $-.src | OFFSET 1 LIMIT 2;
 +-------------+-------------+-------------+-------------+
-| src         | $a.dst      | follow._src | follow._dst |
+| src         | $a.dst      | src(EDGE)   | dst(EDGE)   |
 +-------------+-------------+-------------+-------------+
 | "player100" | "player101" | "player100" | "player101" |
 | "player100" | "player125" | "player100" | "player125" |
 +-------------+-------------+-------------+-------------+
 ```
 
+### Other examples
+
 ```ngql
 # The following example determines if $$.player.name IS NOT EMPTY.
 nebula> GO FROM "player100" OVER follow WHERE properties($$).name IS NOT EMPTY YIELD dst(edge);
 +-------------+
-| follow._dst |
+| dst(EDGE)   |
 +-------------+
 | "player125" |
 | "player101" |
 +-------------+
-```
+```
diff --git a/docs-2.0/nebula-operator/2.deploy-nebula-operator.md b/docs-2.0/nebula-operator/2.deploy-nebula-operator.md
@@ -266,3 +266,8 @@ For more information about `helm install`, see [Helm Install](https://helm.sh/do
 ## What's next
 
 Automate the deployment of NebulaGraph clusters with NebulaGraph Operator. For more information, see [Deploy NebulaGraph Clusters with Kubectl](3.deploy-nebula-graph-cluster/3.1create-cluster-with-kubectl.md) or [Deploy NebulaGraph Clusters with Helm](3.deploy-nebula-graph-cluster/3.2create-cluster-with-helm.md).
+
+{{ent.ent_begin}}
+For the NebulaGraph Enterprise Edition deployment, you need first to deploy the License Manager and have the license key loaded. For more information, see [Deploy LM](3.deploy-nebula-graph-cluster/3.0.deploy-lm.md).
+{{ent.ent_end}}
+
diff --git a/...-2.0/nebula-operator/8.custom-cluster-configurations/8.4.manage-running-logs.md b/...-2.0/nebula-operator/8.custom-cluster-configurations/8.4.manage-running-logs.md
@@ -28,14 +28,14 @@ Running logs generated by cluster services during runtime will occupy disk space
 
 To facilitate log collection and management, each NebulaGraph service deploys a sidecar container responsible for collecting logs generated by the service container and sending them to the specified log disk. The sidecar container automatically cleans and archives logs using the [logrotate](https://linux.die.net/man/8/logrotate) tool.
 
-In the YAML configuration file of the cluster instance, you can configure log rotation to automatically clean and archive logs through the `spec.logRotate` field. By default, the log rotation feature is turned off. Here is an example of enabling log rotation:
+In the YAML configuration file of the cluster instance, set `spec.logRotate` to enable log rotation and set `timestamp_in_logfile_name` to `false` to disable the timestamp in the log file name to implement log rotation for the target service. The `timestamp_in_logfile_name` parameter is configured under the `spec.<graphd|metad|storaged>.config` field. By default, the log rotation feature is turned off. Here is an example of enabling log rotation for all services:
 
 ```yaml
 ...
 spec:
   graphd:
     config:
-      # Whether to include a timestamp in the log file name. "true" means yes, "false" means no. It is "true" by default.
+      # Whether to include a timestamp in the log file name. You must set this parameter to false to enable log rotation. It is set to true by default.
       "timestamp_in_logfile_name": "false"
   metad:
     config: