vid-par

docs/manual-EN/1.overview/1.concepts/1.data-model.md

@@ -23,13 +23,13 @@ To better understand the elements of a graph data model, let us walk through eac
 
 ## Vertices
 
-Vertices are typically used to represent entities in the real world. In the preceding example, the graph contains eleven vertices.
+Vertices are typically used to represent entities in the real world. In **Nebula Graph**, vertices are identified with vertex identifiers (i.e. VIDs). The `VID` must be unique in the graph space. In the preceding example, the graph contains eleven vertices.
 
 <img src="https://user-images.githubusercontent.com/42762957/64932628-00eecf00-d873-11e9-844b-6b2a535ca734.png" width="15%" height="20%">
 
 ## Tags
 
-In **Nebula Graph**, vertex properties are clustered by **tags**. In the example above, the vertices have tags **player** and **team**.
+In **Nebula Graph**, vertex properties are clustered by **tags**. One vertex can have one to multiple tags. In the preceding example, the vertices have tags **player** and **team**.
 
 <img src="https://user-images.githubusercontent.com/42762957/64932330-bff5bb00-d870-11e9-9940-4ff76ceca353.png" width="50%" height="25%">
 
@@ -43,13 +43,20 @@ Edges are used to connect vertices. Each edge usually represents a relationship
 
 `Each edge` is an instance of an edge type. Our example uses _**serve**_ and _**like**_ as edge types. Take edge _**serve**_ for example, in the preceding picture, vertex `101` (represents a **player**) is the source vertex and vertex `215` (represents a **team**) is the target vertex. We see that vertex `101` has an outgoing edge while vertex `215` has an incoming edge.
 
-## Properties
+## Properties of Vertices and Edges
 
-Properties are named-value pairs within vertices and edges. In our example graph, we have used the properties `id`, `name` and `age` on **player**, `id` and `name` on **team**, and `likeness` on _**like**_ edge.
+Both vertices and edges can have properties. Properties are described with key value pairs. In our example graph, we have used the properties `id`, `name` and `age` on **player**, `id` and `name` on **team**, and `likeness` on _**like**_ edge.
 
 ## Edge Rank
 
 Edge rank is an immutable user-assigned 64-bit signed integer. It affects the edge order of the same edge type between two vertices. The edge with a higher rank value comes first. When not specified, the default rank value is zero. The current sorting basis is "binary coding order", i.e. 0, 1, 2, ... 9223372036854775807, -9223372036854775808, -9223372036854775807, ..., -1.
+In addition to an edge type, the edge between two vertices must have an edge rank. The edge rank is a 64-bit integer assigned by the user; if not specified, the edge rank defaults to 0.
+
+An edge can be represented uniquely with the [source vertex, edge type, edge rank and the dest vertex].
+
+The edge rank affects the edge order of the same edge type between two vertices. The edge with a higher rank value comes first.
+
+The current sorting basis is "binary coding order", i.e. 0, 1, 2, ... 9223372036854775807, -9223372036854775808, -9223372036854775807, ..., -1.
 
 ## Schema
 

docs/manual-EN/2.query-language/1.data-types/type-conversion.md

@@ -8,9 +8,9 @@ Implicit conversions are automatically performed when a value is copied to a com
 
 1. Following types can implicitly converted to `bool`:
 
-- The conversions from/to bool consider `false` equivalent to `0` for empty string types, true is equivalent to all other values.
-- The conversions from/to bool consider `false` equivalent to `0` for int types, true is equivalent to all other values.
-- The conversions from/to bool consider `false` equivalent to `0.0` for float types, true is equivalent to all other values.
+   - The conversions from/to bool consider `false` equivalent to `0` for empty string types, true is equivalent to all other values.
+   - The conversions from/to bool consider `false` equivalent to `0` for int types, true is equivalent to all other values.
+   - The conversions from/to bool consider `false` equivalent to `0.0` for float types, true is equivalent to all other values.
 
 2. `int` can implicitly converted to `double`.
 
@@ -20,8 +20,4 @@ In addition to implicit type conversion, explicit type conversion is also suppor
 
 `(type_name)expression`.
 
-For example, the results of
-`YIELD length((string)(123)), (int)"123" + 1`
-
-are `3, 124` respectively.
-And `YIELD (int)("12ab3")` fails in conversion.
+For example, the results of `YIELD length((string)(123)), (int)"123" + 1` are `3, 124` respectively. The results of `YIELD (int)(TRUE)` is `1`. And `YIELD (int)("12ab3")` fails in conversion.

docs/manual-EN/2.query-language/4.statement-syntax/2.data-query-and-manipulation-statements/fetch-syntax.md

@@ -13,7 +13,7 @@ FETCH PROP ON * <vertex_id_list>
 
 `*` indicates returning all the properties of the given vertex.
 
-`<tag_name>::=[tag_name [, tag_name]]` is the tag name. It must be the same tag within return_list.
+`<tag_name_list>::=[tag_name [, tag_name]]` is the tag name. It must be the same tag within return_list.
 
 `<vertex_id_list>::=[vertex_id [, vertex_id]]` is a list of vertex IDs separated by comma (,).
 

docs/manual-EN/2.query-language/4.statement-syntax/2.data-query-and-manipulation-statements/insert-vertex-syntax.md

@@ -2,7 +2,7 @@
 
 ```ngql
 INSERT VERTEX <tag_name> [, <tag_name>, ...] (prop_name_list[, prop_name_list])
-     {VALUES | VALUE} vid: (prop_value_list[, prop_value_list])
+     {VALUES | VALUE} VID: (prop_value_list[, prop_value_list])
 
 prop_name_list:
   [prop_name [, prop_name] ...]
@@ -15,7 +15,7 @@ The `INSERT VERTEX` statement inserts a vertex or vertices into **Nebula Graph**
 
 * `tag_name` denotes the `tag` (vertex type), which must be created before `INSERT VERTEX`.
 * `prop_name_list` is the property name list in the given `tag_name`.
-* `vid` is the vertex ID. The current sorting basis is "binary coding order", i.e. 0, 1, 2, ... 9223372036854775807, -9223372036854775808, -9223372036854775807, ..., -1. `vid` supports specifying ID manually, or call hash() function to generate.
+* `VID` is the vertex ID. The `VID` must be unique in the graph space. The current sorting basis is "binary coding order", i.e. 0, 1, 2, ... 9223372036854775807, -9223372036854775808, -9223372036854775807, ..., -1. `VID` supports specifying ID manually, or call hash() function to generate.
 
 * `prop_value_list` must provide the value list according to the `prop_name_list`. If no value matches the type, an error will be returned.
 

docs/manual-EN/3.build-develop-and-administration/1.build/1.build-source-code.md

@@ -106,12 +106,12 @@ $ sudo make install
 $ cd /usr/local/nebula
 $ sudo cp etc/nebula-storaged.conf.production etc/nebula-storaged.conf
 $ sudo cp etc/nebula-metad.conf.production etc/nebula-metad.conf
-$ sudo cp etc/nebula-metad.conf.production etc/nebula-metad.conf
+$ sudo cp etc/nebula-graphd.conf.production etc/nebula-graphd.conf
 # For trial
 $ cd /usr/local/nebula
 $ sudo cp etc/nebula-storaged.conf.default etc/nebula-storaged.conf
 $ sudo cp etc/nebula-metad.conf.default etc/nebula-metad.conf
-$ sudo cp etc/nebula-metad.conf.default etc/nebula-metad.conf
+$ sudo cp etc/nebula-graphd.conf.default etc/nebula-graphd.conf
 ```
 
 See the [Start and Stop Nebula Graph Services Doc](../2.install/2.start-stop-service.md) for details.

docs/manual-EN/3.build-develop-and-administration/3.configurations/0.system-requirement.md

@@ -54,7 +54,7 @@ Take AWS EC2 c5d.xlarge as an example:
 ## Resource Estimation (Three Replicas)
 
 * Storage space (full cluster): number of edges and vertices * average bytes of attributes * 6
-* Memory (full cluster): number of edges and vertices * 5 bytes + number of RocksDB instances * (write_buffer_size * max_write_buffer_number + rocksdb_block_cache), where each directory in the `--data_path` item in the `etc/nebula-storaged.conf` file corresponds to a RocksDB instance
+* Memory (full cluster): number of edges and vertices * 15 bytes + number of RocksDB instances * (write_buffer_size * max_write_buffer_number + rocksdb_block_cache), where each directory in the `--data_path` item in the `etc/nebula-storaged.conf` file corresponds to a RocksDB instance
 * Partitions number of a graph space: number of disks in the cluster * (2 to 10), the better performance of the hard disk, the larger the value.
 * Reserve 20% space for memory and hard disk buffer.
 

docs/manual-EN/3.build-develop-and-administration/5.storage-service-administration/compact.md

@@ -12,7 +12,7 @@ By default, the `disable_auto_compactions` parameter is set to `false`. Before d
 
 - The customized compact style for **Nebula Graph**. You can run the `SUBMIT JOB COMPACT` command to start it. You can use it to perform large scale background operations such as sst files merging in large scale or TTL. This kind of compact is usually performed after midnight.
 
-In addition, you can modify the number of threads in both methods by the following command. You can decrease the threads during daytime and increase it at night.
+In addition, you can modify the number of threads in both methods by the following command.
 
 ```ngql
 nebula> UPDATE CONFIGS storage:rocksdb_db_options  = \

docs/manual-EN/5.appendix/vid-partition.md

@@ -0,0 +1,25 @@
+# Vertex Identifier and Partition
+
+This document provides some introductions on vertex identifier (`VID` for short) and partition.
+
+In **Nebula Graph**, vertices are identified with vertex identifiers (i.e. `VID`s). When inserting a vertex, you must specify a `VID` for it. You can generate `VID`s either with your own application or with the hash function provided by **Nebula Graph**.
+
+`VID`s must be unique in a graph space. That is, in the same graph space, vertices with the same `VID` are considered as the same vertex. `VID`s in different graph spaces are independent of each other. In addition, one `VID` can have multiple `TAG`s.
+
+When inserting data into **Nebula Graph**, vertices and edges will distribute to different partitions. And the partitions are located on different machines. If you want some certain vertices to locate on the same partition (i.e. on the same machine), you can control the generation of the `VID`s by using the following formula.
+
+The relation between `VID` and partition is:
+
+```text
+VID mod partition_number = partition ID + 1
+```
+
+In the preceding formula,
+
+- `mod` is the modulo operation.
+- `partition_number` is the number of partition for the graph space where the `VID` is located, namely the value of `partition_num` in the [CREATE SPACE](../2.query-language/4.statement-syntax/1.data-definition-statements/create-space-syntax.md) statement.
+- `partition ID` the ID for the partition where the `VID` is located.
+
+For example, if there are 100 partitions, the vertices with `VID` 1, 11, 101, 1001 will be stored on the same partition.
+
+In addition, the correspondence between the `partition ID` and the machines are random. Therefore, you can't assume that any two partitions are located on the same machine.

docs/manual-EN/README.md

@@ -167,7 +167,7 @@ It is the optimal solution in the world capable of hosting graphs with dozens of
 * [Gremlin V.S. nGQL](5.appendix/gremlin-ngql.md)
 * [Cypher V.S. nGQL](5.appendix/cypher-ngql.md)
 * [SQL V.S. nGQL](5.appendix/sql-ngql.md)
-<!-- * [Upgrading Nebula Graph](5.appendix/upgrade-guide.md)-->
+* [Vertex Identifier and Partition](5.appendix/vid-partition.md)
 
 ## Misc
 

mkdocs.yml

@@ -208,9 +208,8 @@ nav:
       - Cypher & nGQL: manual-EN/5.appendix/cypher-ngql.md
       - Gremlin & nGQL: manual-EN/5.appendix/gremlin-ngql.md
       - SQL & nGQL: manual-EN/5.appendix/sql-ngql.md
-      # - Upgrading Nebula Graph: manual-EN/5.appendix/upgrade-guide.md
-    # - Download PDF:
-    #   - https://oss-cdn.nebula-graph.io/doc/v1.0.0-en.pdf
+      - Vertex Identifier and Partition: manual-EN/5.appendix/vid-partition.md
+
     - 中文手册:
       - https://docs.nebula-graph.com.cn/