From 13585045a02a9a13ccff8e5a6e189b3e179dfba5 Mon Sep 17 00:00:00 2001 From: "abby.huang" <78209557+abby-cyber@users.noreply.github.com> Date: Mon, 31 Jul 2023 15:40:59 +0800 Subject: [PATCH] fix logrotate (#2201) --- .../7.general-query-statements/3.go.md | 119 ++++++++++++------ .../2.deploy-nebula-operator.md | 5 + .../8.4.manage-running-logs.md | 4 +- 3 files changed, 85 insertions(+), 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 index 1e05dc556c4..e915cd09425 100644 --- 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] - `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. -- ``: 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). +- ``: represents a list of vertex IDs separated by commas. - ``: 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 ``. 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 ``. 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 `._type` field using `YIELD`. A positive value indicates an outgoing edge, while a negative value indicates an incoming edge. - `WHERE `: 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] - `LIMIT [,] ]`: 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,7 +183,7 @@ 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; +-------------+ @@ -140,12 +191,13 @@ nebula> MATCH (v)<-[e:follow]- (v2) WHERE id(v) == 'player100' \ +-------------+ | "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,31 +224,12 @@ 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 \ @@ -204,12 +237,14 @@ nebula> GO 2 STEPS FROM "player100" OVER follow \ +-------------+----------------------------+----------+ | 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; \ @@ -217,20 +252,22 @@ nebula> $a = GO FROM "player100" OVER follow YIELD src(edge) AS src, dst(edge) A 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" | +-------------+ -``` +``` \ No newline at end of file diff --git a/docs-2.0/nebula-operator/2.deploy-nebula-operator.md b/docs-2.0/nebula-operator/2.deploy-nebula-operator.md index 1bca982b2f9..7ef7ed7729d 100644 --- 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/docs-2.0/nebula-operator/8.custom-cluster-configurations/8.4.manage-running-logs.md b/docs-2.0/nebula-operator/8.custom-cluster-configurations/8.4.manage-running-logs.md index 78a117acd8c..601d4dedb8b 100644 --- a/docs-2.0/nebula-operator/8.custom-cluster-configurations/8.4.manage-running-logs.md +++ b/docs-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..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: