diff --git a/docs-2.0/1.introduction/3.nebula-graph-architecture/3.graph-service.md b/docs-2.0/1.introduction/3.nebula-graph-architecture/3.graph-service.md index 144817d32d9..c1bfe970acb 100644 --- a/docs-2.0/1.introduction/3.nebula-graph-architecture/3.graph-service.md +++ b/docs-2.0/1.introduction/3.nebula-graph-architecture/3.graph-service.md @@ -82,11 +82,11 @@ In the `nebula-graphd.conf` file, when `enable_optimizer` is set to be `true`, P RBO is a “bottom-up” exploration process. For each rule, the root node of the execution plan (in this case, the `Project` node) is the entry point, and step by step along with the node dependencies, it reaches the node at the bottom to see if it matches the rule. - As shown in the preceding figure, when the `Filter` node is explored, it is found that its children node is `GetNeighbors`, which matches successfully with the pre-defined rules, so a transformation is initiated to integrate the `Filter` node into the `GetNeighbors` node, the `Filter` node is removed, and then the process continues to the next rule. Therefore, when the `GetNeighbor` operator calls interfaces of the Storage layer to get the neighboring edges of a vertex during the execution stage, the Storage layer will directly filter out the unqualified edges internally. Such optimization greatly reduces the amount of data transfer, which is commonly known as filter push down. + As shown in the preceding figure, when the `Filter` node is explored, it is found that its children node is `GetNeighbors`, which matches successfully with the pre-defined rules, so a transformation is initiated to integrate the `Filter` node into the `GetNeighbors` node, the `Filter` node is removed, and then the process continues to the next rule. Therefore, when the `GetNeighbor` operator calls interfaces of the Storage layer to get the neighboring edges of a vertex during the execution stage, the Storage layer will directly filter out the unqualified edges internally. Such optimization greatly reduces the amount of data transfer, which is commonly known as filter pushdown. !!! Note - Nebula Graph {{ nebula.release }} will not run optimization at default settings. + Nebula Graph {{ nebula.release }} will not run optimization by default. ## Executor @@ -98,7 +98,7 @@ Each node of the execution plan has one execution operator node, whose input and ## Source code hierarchy -The source code hierarchy under the nebula-graph repository is as follows： +The source code hierarchy under the nebula-graph repository is as follows. ```bash |--src diff --git a/docs-2.0/1.introduction/3.nebula-graph-architecture/4.storage-service.md b/docs-2.0/1.introduction/3.nebula-graph-architecture/4.storage-service.md index 9aa60bb7e46..92de3a4e154 100644 --- a/docs-2.0/1.introduction/3.nebula-graph-architecture/4.storage-service.md +++ b/docs-2.0/1.introduction/3.nebula-graph-architecture/4.storage-service.md @@ -2,7 +2,7 @@ The persistent data of Nebula Graph have two parts. One is the [Meta Service](2.meta-service.md) that stores the meta-related data. -The other is Storage Service that stores the data, which is run by the nebula-storaged process. This topic will describe the architecture of Storage Service. +The other is the Storage Service that stores the data, which is run by the nebula-storaged process. This topic will describe the architecture of Storage Service. ## Advantages @@ -30,15 +30,15 @@ All the nebula-storaged processes consist of a Raft-based cluster. There are thr - `getNeighbors`: query the in-edge or out-edge of a set of vertices, return the edges and the corresponding properties, and support conditional filtering. - - `insert vertex/edge`：insert a vertex or edge and its properties. + - `insert vertex/edge`: insert a vertex or edge and its properties. - - `getProps`：get the properties of a vertex or an edge. + - `getProps`: get the properties of a vertex or an edge. It is this layer that makes the Storage Service a real graph storage. Otherwise, it is just a KV storage. - Consensus - Below the storage interface is the consensus layer that implements [Multi Group Raft](#multi_group_raft), which ensures the strong consistency and high availability of Storage Service. + Below the storage interface is the consensus layer that implements [Multi Group Raft](#multi_group_raft), which ensures the strong consistency and high availability of the Storage Service. - Store engine @@ -48,7 +48,7 @@ The following will describe some features of Storage Service based on the above ## KVStore -Nebula Graph develops and customizes its built-in KVStore because: +Nebula Graph develops and customizes its built-in KVStore for the following reasons. - It is a high-performance KVStore. @@ -56,7 +56,7 @@ Nebula Graph develops and customizes its built-in KVStore because: - It has strong data consistency. -Therefore, Nebula Graph develops its own KVStore with RocksDB as the local storage engine. The advantages are as follows: +Therefore, Nebula Graph develops its own KVStore with RocksDB as the local storage engine. The advantages are as follows. - For multiple local hard disks, Nebula Graph can make full use of its concurrent capacities through deploying multiple data directories. @@ -76,7 +76,7 @@ Nebula Graph stores vertices and edges. Efficient property filtering is critical Nebula Graph {{ nebula.base20 }} has changed a lot over its releases. The following will introduce the old and new data storage formats and cover their differences. -- Vertex key format +- Vertex format ![The vertex format of storage service](https://docs-cdn.nebula-graph.com.cn/docs-2.0/1.introduction/2.nebula-graph-architecture/storage-vertex-format.png) @@ -84,7 +84,7 @@ Nebula Graph {{ nebula.base20 }} has changed a lot over its releases. The follow |:---|:---| |`Type`|One byte, used to indicate the key type.| |`PartID`|Three bytes, used to indicate the sharding partition and to scan the partition data based on the prefix when re-balancing the partition.| - |`VertexID`|Used to indicate vertex ID. For an integer VertexID, it occupies eight bytes. However, for a string VertexID, it is changed to `fixed_string` of a fixed length which needs to be specified by users when they create space.| + |`VertexID`|Used to indicate vertex ID. For an integer VertexID, it occupies eight bytes. However, for a string VertexID, it is changed to `fixed_string` of a fixed length which needs to be specified by users when they create the space.| |`TagID`|Four bytes, used to indicate the tags that vertex relate with.| - Edge Format @@ -244,7 +244,7 @@ When a transfer leadership command is committed, the leader will abandon its lea ### Peer changes -To avoid split-brain, when members in a Raft Group change, an intermediate state is required. In such a state, the quorum of the old group and new group always have an overlap. Thus it prevents the old or new group from making decisions unilaterally. To make it even simpler, in his doctoral thesis Diego Ongaro suggests adding or removing a peer once to ensure the overlap between the quorum of the new group and the old group. Nebula Graph‘s implementation also uses this approach, except that the way to add or remove a member is different. For details, please refer to addPeer/removePeer in the Raft Part class. +To avoid split-brain, when members in a Raft Group change, an intermediate state is required. In such a state, the quorum of the old group and new group always have an overlap. Thus it prevents the old or new group from making decisions unilaterally. To make it even simpler, in his doctoral thesis Diego Ongaro suggests adding or removing a peer once to ensure the overlap between the quorum of the new group and the old group. Nebula Graph also uses this approach, except that the way to add or remove a member is different. For details, please refer to addPeer/removePeer in the Raft Part class. ## Differences with HDFS diff --git a/docs-2.0/2.quick-start/3.connect-to-nebula-graph.md b/docs-2.0/2.quick-start/3.connect-to-nebula-graph.md index 4a13092ca46..ee817b197fe 100644 --- a/docs-2.0/2.quick-start/3.connect-to-nebula-graph.md +++ b/docs-2.0/2.quick-start/3.connect-to-nebula-graph.md @@ -6,17 +6,17 @@ Nebula Graph supports multiple types of clients, including a CLI client, a GUI c You can use supported [clients or console](../20.appendix/6.eco-tool-version.md) to connect to Nebula Graph database. - ## Use Nebula Console to connect to Nebula Graph ### Prerequisites -* You have started the Nebula Graph services. For how to start the services, see [Start and Stop Nebula Graph](./5.start-stop-service.md). +* Nebula Graph services are started. For how to start services, see [Start and Stop Nebula Graph](./5.start-stop-service.md). -* The machine you plan to run Nebula Console on has network access to the Nebula Graph services. +* The machines that run Nebula Console and Nebula Graph services have network access to each other. ### Steps @@ -26,11 +26,11 @@ If you don't have a Nebula Graph database yet, we recommend that you try the clo We recommend that you select the **latest** release. - ![Select a Nebula Graph version and click **Assets**](https://docs-cdn.nebula-graph.com.cn/docs-2.0/2.quick-start/nebula-console-releases-1.png "Click Assets to show the available Nebula Graph binary files") + ![Select a Nebula Graph version and click **Assets**](../2.quick-start/console.png "Click Assets to show the available Nebula Graph binary files") 2. In the **Assets** area, find the correct binary file for the machine where you want to run Nebula Console and download the file to the machine. - ![Click to download the package according to your hardware architecture](https://docs-cdn.nebula-graph.com.cn/docs-2.0/2.quick-start/nebula-console-releases-2-1.png "Click the package name to download it") + ![Click to download the package according to your hardware architecture](../2.quick-start/assets.png "Click the package name to download it") 3. (Optional) Rename the binary file to `nebula-console` for convenience. @@ -52,21 +52,21 @@ If you don't have a Nebula Graph database yet, we recommend that you try the clo 6. Run the following command to connect to Nebula Graph. - * For Linux or macOS: + * For Linux or macOS: - ```bash - $ ./nebula-console -addr -port -u -p - [-t 120] [-e "nGQL_statement" | -f filename.nGQL] - ``` + ```bash + $ ./nebula-console -addr -port -u -p + [-t 120] [-e "nGQL_statement" | -f filename.nGQL] + ``` - * For Windows: + * For Windows: - ```powershell - > nebula-console.exe -addr -port -u -p - [-t 120] [-e "nGQL_statement" | -f filename.nGQL] - ``` + ```powershell + > nebula-console.exe -addr -port -u -p + [-t 120] [-e "nGQL_statement" | -f filename.nGQL] + ``` - The description of the parameters is as follows. + The descriptions are as follows. | Parameter | Description | | - | - | @@ -75,36 +75,129 @@ If you don't have a Nebula Graph database yet, we recommend that you try the clo | `-port` | Sets the port number of the graphd service. The default port number is 9669. | | `-u/-user` | Sets the username of your Nebula Graph account. Before enabling authentication, you can use any existing username (The default username is `root`). | | `-p/-password` | Sets the password of your Nebula Graph account. Before enabling authentication, you can use any characters as the password. | - | `-t/-timeout` | Sets an integer-type timeout threshold of the connection. The unit is second. The default value is 120. | + | `-t/-timeout` | Sets an integer-type timeout threshold of the connection. The unit is second. The default value is 120. | | `-e/-eval` | Sets a string-type nGQL statement. The nGQL statement will be executed once the connection succeeds. The connection stops after the result is returned. | | `-f/-file` | Sets the path of an nGQL file. The nGQL statements in the file are executed once the connection succeeds. The connection stops after the result is returned. | Users can use the command of `./nebula-console --help` to get the details of all the parameters and can also find more details in the [Nebula Console Repository](https://github.com/vesoft-inc/nebula-console/tree/v2.0.0-ga). -## Nebula Console export mode +## Nebula Console commands -When the export mode is enabled, Nebula Console will export all the query results into a CSV file. When the export mode is disabled, the export stops. The syntax is as follows. +Nebula Console supports some commands. Users can export all the query results into a CSV file or a DOT file, and import test datasets. !!! Note - * The following commands are case insensitive. - * The CSV file is stored in the working directory. Run the Linux command `pwd` to show the working directory. + * The commands are case-insensitive. + +### Export CSV files + +!!! note + + - The CSV file is stored in the working directory. Run the Linux command `pwd` to show the working directory. + + - This command only takes effect on the next query statement. + +The command is as follows. + +```ngql +nebula> :CSV +``` + +### Export DOT files + +!!! Note + + - The DOT file is stored in the working directory. Run the Linux command `pwd` to show the working directory. + + - The content of the DOT file can be copied and pasted in the [GraphvizOnline](https://dreampuf.github.io/GraphvizOnline/) to generate a visual execution plan diagram. + + - This command only takes effect on the next query statement. + +The command is as follows. + +```ngql +nebula> :dot +``` + +The example is as follows. + +```ngql +nebula> :dot a.dot +nebula> PROFILE FORMAT="dot" GO FROM "player100" OVER follow; +``` + +### Load test datasets + +The name of the test dataset is nba. To check the detailed information on the Schema and data, run the relevant `SHOW` command. -* Enable Nebula Console export mode: +The command is as follows. ```ngql -nebula> :SET CSV +nebula> :play nba ``` -* Disable Nebula Console export mode: +### Repeat the execution + +This command repeats the next command N times, and then prints the average execution time. The command is as follows. ```ngql -nebula> :UNSET CSV +nebula> :repeat N +``` + +Examples are as follows. + +```ngql +nebula> :repeat 3 +nebula> GO FROM "player100" OVER follow; ++-------------+ +| follow._dst | ++-------------+ +| "player101" | ++-------------+ +| "player125" | ++-------------+ +Got 2 rows (time spent 2602/3214 us) + +Fri, 20 Aug 2021 06:36:05 UTC + ++-------------+ +| follow._dst | ++-------------+ +| "player101" | ++-------------+ +| "player125" | ++-------------+ +Got 2 rows (time spent 583/849 us) + +Fri, 20 Aug 2021 06:36:05 UTC + ++-------------+ +| follow._dst | ++-------------+ +| "player101" | ++-------------+ +| "player125" | ++-------------+ +Got 2 rows (time spent 496/671 us) + +Fri, 20 Aug 2021 06:36:05 UTC + +Executed 3 times, (total time spent 3681/4734 us), (average time spent 1227/1578 us) +``` + +### Sleep + +The command sleeps for N seconds. It is often used to modify the Schema because the modification of the Schema is implemented asynchronously, and Nebula Graph synchronizes the data in the next heartbeat cycle. The command is as follows: + +```ngql +nebula> :sleep N ``` ## Disconnect Nebula Console from Nebula Graph -You can use `:EXIT` or `:QUIT` to disconnect from Nebula Graph. For convenience, Nebula Console supports using these commands in lower case without the colon, such as `quit`. +Users can use `:EXIT` or `:QUIT` to disconnect from Nebula Graph. For convenience, Nebula Console supports using these commands in lower case without the colon, such as `quit`. + +The example is as follows. ```ngql nebula> :QUIT diff --git a/docs-2.0/2.quick-start/4.nebula-graph-crud.md b/docs-2.0/2.quick-start/4.nebula-graph-crud.md index edb603e6c3a..1aa5e1ad93a 100644 --- a/docs-2.0/2.quick-start/4.nebula-graph-crud.md +++ b/docs-2.0/2.quick-start/4.nebula-graph-crud.md @@ -2,6 +2,8 @@ This topic will describe the basic CRUD operations in Nebula Graph. +For more information, see [nGQL guide](../3.ngql-guide/1.nGQL-overview/1.overview.md). + ## Graph space and Nebula Graph schema A Nebula Graph instance consists of one or more graph spaces. Graph spaces are physically isolated from each other. You can use different graph spaces in the same instance to store different datasets. @@ -25,7 +27,9 @@ In this topic, we will use the following dataset to demonstrate basic CRUD opera ## Check the machine status in the Nebula Graph cluster -First, we recommend that you check the machine status to make sure that all the Storage services are connected to the Meta services. Run `SHOW HOSTS` as follows. +!!! Note + + First, we recommend that you check the machine status to make sure that all the Storage services are connected to the Meta services. Run `SHOW HOSTS` as follows. ```ngql nebula> SHOW HOSTS; @@ -47,7 +51,9 @@ From the **Status** column of the table in the return results, you can see that ### Asynchronous implementation of creation and alteration -Nebula Graph implements the following creation or alteration operations asynchronously in the next heartbeat cycle. The operations won't take effect until they finish. +!!! caution + + Nebula Graph implements the following creation or alteration operations asynchronously in the **next** heartbeat cycle. The operations will not take effect until they finish. * `CREATE SPACE` * `CREATE TAG` @@ -79,20 +85,15 @@ To make sure the follow-up operations work as expected, take one of the followin [replica_factor = ,] vid_type = {FIXED_STRING() | INT64} ) - [comment = '']; + [COMMENT = '']; ``` - + For more information on parameters, see [CREATE SPACE](../3.ngql-guide/9.space-statements/1.create-space.md). -| Property | Description | -| - | - | -| `partition_num` | Specifies the number of partitions in each space. The suggested number of partitions is 5 times the number of hard disks in the cluster. For example, if you have 3 hard disks in the cluster, we recommend that you set 15 partitions. | -| `replica_factor` | Specifies the number of replicas in the Nebula Graph cluster. The suggested number of replicas is 3 in a production environment and 1 in a test environment. The number of replicas must always be an **odd** number for the need of quorum-based voting. | -|`vid_type` | Specifies the data type of VIDs in a graph space. Available values are `FIXED_STRING(N)` and `INT64`. `N` represents the maximum length of the VIDs and it must be a positive integer. The default value is `FIXED_STRING(8)`. If you set a VID length greater than `N`, Nebula Graph will throw an error. To set integer VIDs for vertices, set `vid_type` to `INT64`. | -| `comment` | The remarks of graph spaces. Its maximum length is 256 bytes. The default space has no remarks. | + * List graph spaces and check if the creation is successful: @@ -160,15 +161,18 @@ To make sure the follow-up operations work as expected, take one of the followin ```ngql CREATE {TAG | EDGE} { | }( -[, ...]); +[, ...]) +[COMMENT = '']; ``` +For more information on parameters, see [CREATE TAG](../3.ngql-guide/10.tag-statements/1.create-tag.md) and [CREATE EDGE](../3.ngql-guide/11.edge-type-statements/1.create-edge.md). + ### Examples Create tags `player` and `team`, edge types `follow` and `serve`. Descriptions are as follows. | Component name | Type | Property | -| -------------- | ---- | -------- | +| :--- | :--- | :--- | | player | Tag | name (string), age (int) | | team | Tag | name (string) | | follow | Edge type | degree (int) | @@ -178,27 +182,19 @@ Create tags `player` and `team`, edge types `follow` and `serve`. Descriptions a nebula> CREATE TAG player(name string, age int); Execution succeeded (time spent 20708/22071 us) -Wed, 24 Feb 2021 03:47:01 EST - nebula> CREATE TAG team(name string); Execution succeeded (time spent 5643/6810 us) -Wed, 24 Feb 2021 03:47:59 EST - nebula> CREATE EDGE follow(degree int); Execution succeeded (time spent 12665/13934 us) -Wed, 24 Feb 2021 03:48:07 EST - nebula> CREATE EDGE serve(start_year int, end_year int); Execution succeeded (time spent 5858/6870 us) - -Wed, 24 Feb 2021 03:48:16 EST ``` ## Insert vertices and edges -You can use the `INSERT` statement to insert vertices or edges based on existing tags or edge types. +Users can use the `INSERT` statement to insert vertices or edges based on existing tags or edge types. ### nGQL syntax @@ -221,7 +217,7 @@ You can use the `INSERT` statement to insert vertices or edges based on existing [, -> [@] : ([, ...]), ...]; ``` - For details, see [INSERT EDGE](../3.ngql-guide/13.edge-statements/1.insert-edge.md). + For more information on parameters, see [INSERT EDGE](../3.ngql-guide/13.edge-statements/1.insert-edge.md). ### Examples @@ -231,22 +227,14 @@ You can use the `INSERT` statement to insert vertices or edges based on existing nebula> INSERT VERTEX player(name, age) VALUES "player100":("Tim Duncan", 42); Execution succeeded (time spent 28196/30896 us) - Wed, 24 Feb 2021 03:55:08 EST - nebula> INSERT VERTEX player(name, age) VALUES "player101":("Tony Parker", 36); Execution succeeded (time spent 2708/3834 us) - Wed, 24 Feb 2021 03:55:20 EST - nebula> INSERT VERTEX player(name, age) VALUES "player102":("LaMarcus Aldridge", 33); Execution succeeded (time spent 1945/3294 us) - Wed, 24 Feb 2021 03:55:32 EST - nebula> INSERT VERTEX team(name) VALUES "team200":("Warriors"), "team201":("Nuggets"); Execution succeeded (time spent 2269/3310 us) - - Wed, 24 Feb 2021 03:55:47 EST ``` * Insert edges representing the relations between basketball players and teams: @@ -255,22 +243,14 @@ You can use the `INSERT` statement to insert vertices or edges based on existing nebula> INSERT EDGE follow(degree) VALUES "player100" -> "player101":(95); Execution succeeded (time spent 3362/4542 us) - Wed, 24 Feb 2021 03:57:36 EST - nebula> INSERT EDGE follow(degree) VALUES "player100" -> "player102":(90); Execution succeeded (time spent 2974/4274 us) - Wed, 24 Feb 2021 03:57:44 EST - nebula> INSERT EDGE follow(degree) VALUES "player102" -> "player101":(75); Execution succeeded (time spent 1891/3096 us) - Wed, 24 Feb 2021 03:57:52 EST - nebula> INSERT EDGE serve(start_year, end_year) VALUES "player100" -> "team200":(1997, 2016), "player101" -> "team201":(1999, 2018); Execution succeeded (time spent 6064/7104 us) - - Wed, 24 Feb 2021 03:58:01 EST ``` ## Read data @@ -281,7 +261,7 @@ You can use the `INSERT` statement to insert vertices or edges based on existing * The [LOOKUP](../3.ngql-guide/7.general-query-statements/5.lookup.md) statement is based on [indexes](#about_indexes). It is used together with the `WHERE` clause to search for the data that meet the specific conditions. -* The [MATCH](../3ngql-guide/../3.ngql-guide/7.general-query-statements/2.match.md) statement is the most commonly used statement for graph data querying. But, it relies on [indexes](#about_indexes) to match data patterns in Nebula Graph. +* The [MATCH](../3ngql-guide/../3.ngql-guide/7.general-query-statements/2.match.md) statement is the most commonly used statement for graph data querying. It can describe all kinds of graph patterns, but it relies on [indexes](#about_indexes) to match data patterns in Nebula Graph. Therefore, its performance still needs optimization. ### nGQL syntax @@ -291,7 +271,7 @@ You can use the `INSERT` statement to insert vertices or edges based on existing GO [[ TO] STEPS ] FROM OVER [REVERSELY] [BIDIRECT] [WHERE [AND | OR expression ...])] - YIELD [DISTINCT] + YIELD [DISTINCT] ; ``` * `FETCH` @@ -345,7 +325,7 @@ You can use the `INSERT` statement to insert vertices or edges based on existing ```ngql nebula> GO FROM "player100" OVER follow WHERE $$.player.age >= 35 \ - -> YIELD $$.player.name AS Teammate, $$.player.age AS Age; + YIELD $$.player.name AS Teammate, $$.player.age AS Age; +---------------+-----+ | Teammate | Age | +---------------+-----+ @@ -366,8 +346,8 @@ You can use the `INSERT` statement to insert vertices or edges based on existing ```ngql nebula> GO FROM "player100" OVER follow YIELD follow._dst AS id | \ - GO FROM $-.id OVER serve YIELD $$.team.name AS Team, \ - $^.player.name AS Player; + GO FROM $-.id OVER serve YIELD $$.team.name AS Team, \ + $^.player.name AS Player; +-----------+---------------+ | Team | Player | +-----------+---------------+ @@ -390,8 +370,8 @@ You can use the `INSERT` statement to insert vertices or edges based on existing ```ngql nebula> $var = GO FROM "player100" OVER follow YIELD follow._dst AS id; \ - GO FROM $var.id OVER serve YIELD $$.team.name AS Team, \ - $^.player.name AS Player; + GO FROM $var.id OVER serve YIELD $$.team.name AS Team, \ + $^.player.name AS Player; +---------+-------------+ | Team | Player | +---------+-------------+ @@ -420,13 +400,13 @@ Got 1 rows (time spent 2006/2406 us) ## Update vertices and edges -You can use the `UPDATE` or the `UPSERT` statements to update existing data. +Users can use the `UPDATE` or the `UPSERT` statements to update existing data. `UPSERT` is the combination of `UPDATE` and `INSERT`. If you update a vertex or an edge with `UPSERT`, the database will insert a new vertex or edge if it does not exist. !!! Note - `UPSERT` operates serially in a partition-based order. Therefore, it is slower than `INSERT` OR `UPDATE`. + `UPSERT` operates serially in a partition-based order. Therefore, it is slower than `INSERT` OR `UPDATE`. And `UPSERT` has concurrency only between multiple partitions. ### nGQL syntax @@ -459,8 +439,6 @@ You can use the `UPDATE` or the `UPSERT` statements to update existing data. nebula> UPDATE VERTEX "player100" SET player.name = "Tim"; Execution succeeded (time spent 3483/3914 us) - Wed, 21 Oct 2020 10:53:14 UTC - nebula> FETCH PROP ON player "player100"; +---------------------------------------------+ | vertices_ | @@ -494,8 +472,8 @@ You can use the `UPDATE` or the `UPSERT` statements to update existing data. Wed, 21 Oct 2020 11:11:50 UTC nebula> UPSERT VERTEX "player111" SET player.name = "Dwight Howard", player.age = $^.player.age + 11 \ - WHEN $^.player.name == "Ben Simmons" AND $^.player.age > 20 \ - YIELD $^.player.name AS Name, $^.player.age AS Age; + WHEN $^.player.name == "Ben Simmons" AND $^.player.age > 20 \ + YIELD $^.player.name AS Name, $^.player.age AS Age; +---------------+-----+ | Name | Age | +---------------+-----+ @@ -539,21 +517,21 @@ You can use the `UPDATE` or the `UPSERT` statements to update existing data. ## About indexes -You can add indexes to tags and edge types with the [CREATE INDEX](../3.ngql-guide/14.native-index-statements/1.create-native-index.md) statement. +Users can add indexes to tags and edge types with the [CREATE INDEX](../3.ngql-guide/14.native-index-statements/1.create-native-index.md) statement. -### Must-read for using indexes +!!! caution "Must-read for using indexes" -* Both `MATCH` and `LOOKUP` statements depend on the indexes. But indexes can dramatically reduce the write performance (as much as 90% or even more). **DO NOT** use indexes in production environments unless you are fully aware of their influences on your service. + Both `MATCH` and `LOOKUP` statements depend on the indexes. But indexes can dramatically reduce the write performance (as much as 90% or even more). **DO NOT** use indexes in production environments unless you are fully aware of their influences on your service. -* You **MUST** rebuild indexes for pre-existing data. Otherwise, the pre-existing data cannot be indexed and therefore cannot be returned in `MATCH` or `LOOKUP` statements. For more information, see [REBUILD INDEX](../3.ngql-guide/14.native-index-statements/4.rebuild-native-index.md). + Users **MUST** rebuild indexes for pre-existing data. Otherwise, the pre-existing data cannot be indexed and therefore cannot be returned in `MATCH` or `LOOKUP` statements. For more information, see [REBUILD INDEX](../3.ngql-guide/14.native-index-statements/4.rebuild-native-index.md). ### nGQL syntax * Create an index: ```ngql - CREATE {TAG | EDGE} INDEX [IF NOT EXISTS] - ON { | } (prop_name_list); + CREATE {TAG | EDGE} INDEX [IF NOT EXISTS] + ON { | } ([]) [COMMENT = '']; ``` * Rebuild an index: @@ -581,12 +559,16 @@ Make sure there is an [index](#about_indexes) for `LOOKUP` or `MATCH` to use. If Find the information of the vertex with the tag `player` and its value of the `name` property is `Tony Parker`. +This example creates the index `player_name_0` on the player name property. + ```nGQL -// Create an index for the player name property. nebula> CREATE TAG INDEX player_name_0 on player(name(10)); Execution succeeded (time spent 3465/4150 us) +``` + +This example rebuilds the index to make sure it takes effect on pre-existing data. -// Rebuild the index to make sure it takes effect on pre-existing data. +```nGQL nebula> REBUILD TAG INDEX player_name_0 +------------+ | New Job Id | @@ -594,17 +576,23 @@ nebula> REBUILD TAG INDEX player_name_0 | 31 | +------------+ Got 1 rows (time spent 2379/3033 us) +``` -// Use LOOKUP statement to retrieve the vertex property. +This example uses the `LOOKUP` statement to retrieve the vertex property. + +```nGQL nebula> LOOKUP ON player WHERE player.name == "Tony Parker" \ -YIELD player.name, player.age; + YIELD player.name, player.age; +-------------+---------------+------------+ | VertexID | player.name | player.age | +-------------+---------------+------------+ | "player101" | "Tony Parker" | 36 | +-------------+---------------+------------+ +``` + +This example uses the `MATCH` statement to retrieve the vertex property. -// Use MATCH statement to retrieve the vertex property. +```nGQL nebula> MATCH (v:player{name:"Tony Parker"}) RETURN v; +-----------------------------------------------------+ | v | diff --git a/docs-2.0/2.quick-start/5.start-stop-service.md b/docs-2.0/2.quick-start/5.start-stop-service.md index 895bd98058c..89706148205 100644 --- a/docs-2.0/2.quick-start/5.start-stop-service.md +++ b/docs-2.0/2.quick-start/5.start-stop-service.md @@ -1,6 +1,6 @@ # Manage Nebula Graph services -The `nebula.service` script can start, stop, restart, terminate, and check the Nebula Graph services. This topic takes starting, stopping and checking the Nebula Graph services for examples. +The `nebula.service` script can start, stop, restart, terminate, and check the Nebula Graph services. `nebula.service` is stored in the `/usr/local/nebula/scripts` directory by default, which is also the default installation path of Nebula Graph. If you have customized the path, use the actual path in your environment. @@ -8,8 +8,8 @@ The `nebula.service` script can start, stop, restart, terminate, and check the N ```bash $ sudo /usr/local/nebula/scripts/nebula.service -[-v] [-c ] - +[-v] [-c ] + ``` @@ -48,7 +48,7 @@ $ sudo /usr/local/nebula/scripts/nebula.service start all Run the following command in the `nebula-docker-compose/` directory to start Nebula Graph services. ```bash -nebula-docker-compose]$ docker-compose up -d +[nebula-docker-compose]$ docker-compose up -d Building with native build. Learn about native build in Compose here: https://docs.docker.com/go/compose-native-build/ Creating network "nebula-docker-compose_nebula-net" with the default driver Creating nebula-docker-compose_metad0_1 ... done @@ -66,14 +66,14 @@ Creating nebula-docker-compose_graphd_1 ... done !!! danger - Don't run `kill -9` to forcibly terminate the processes, otherwise, there will be a low probability of data loss. + Do not run `kill -9` to forcibly terminate the processes, otherwise, there will be a low probability of data loss. ### In non-container environment Run the following command to stop Nebula Graph services. ```bash -sudo /usr/local/nebula/scripts/nebula.service stop all +$ sudo /usr/local/nebula/scripts/nebula.service stop all [INFO] Stopping nebula-metad... [INFO] Done [INFO] Stopping nebula-graphd... @@ -111,7 +111,7 @@ Removing network nebula-docker-compose_nebula-net !!! Note - If you are using a developing or nightly version for testing and having compatibility issues, try to run 'docker-compose down-v' to **DELETE** all data stored in Nebula Graph and import data again. + If you are using a developing or nightly version for testing and having compatibility issues, try to run `docker-compose down-v` to **DELETE** all data stored in Nebula Graph and import data again. ## Check the service status @@ -125,19 +125,19 @@ $ sudo /usr/local/nebula/scripts/nebula.service status all * Nebula Graph is running normally if the following information is returned. -```bash -[INFO] nebula-metad: Running as 26601, Listening on 9559 -[INFO] nebula-graphd: Running as 26644, Listening on 9669 -[INFO] nebula-storaged: Running as 26709, Listening on 9779 -``` + ```bash + [INFO] nebula-metad: Running as 26601, Listening on 9559 + [INFO] nebula-graphd: Running as 26644, Listening on 9669 + [INFO] nebula-storaged: Running as 26709, Listening on 9779 + ``` * If the returned information is similar to the following one, there must be a problem. Users can check the corresponding information to troubleshoot problems or go to [Nebula Graph Forum](https://discuss.nebula-graph.io/) for help. -```bash -[INFO] nebula-metad: Running as 25600, Listening on 9559 -[INFO] nebula-graphd: Exited -[INFO] nebula-storaged: Running as 25646, Listening on 9779 -``` + ```bash + [INFO] nebula-metad: Running as 25600, Listening on 9559 + [INFO] nebula-graphd: Exited + [INFO] nebula-storaged: Running as 25646, Listening on 9779 + ``` The Nebula Graph services consist of the Meta Service, Graph Service, and Storage Service. The configuration files for all three services are stored in the `/usr/local/nebula/etc/` directory by default. You can check the configuration files according to the returned information to troubleshoot problems. @@ -184,3 +184,7 @@ a74054c6ae25 vesoft/nebula-graphd:v2-nightly "/usr/local/nebula/b…" 36 nebula-docker-compose]$ docker exec -it 2a6c56c405f5 bash [root@2a6c56c405f5 nebula]# ``` + +## Next + +[Connect to Nebula Graph](../2.quick-start/3.connect-to-nebula-graph.md) diff --git a/docs-2.0/2.quick-start/assets.png b/docs-2.0/2.quick-start/assets.png new file mode 100644 index 00000000000..f0dba0f5374 Binary files /dev/null and b/docs-2.0/2.quick-start/assets.png differ diff --git a/docs-2.0/2.quick-start/console.png b/docs-2.0/2.quick-start/console.png new file mode 100644 index 00000000000..3f08d4ba19b Binary files /dev/null and b/docs-2.0/2.quick-start/console.png differ