vesoft-inc · foesa-yang · Mar 8, 2022 · Jan 13, 2022 · Jan 14, 2022 · Jan 14, 2022
diff --git a/docs-2.0/1.introduction/0-0-graph.md b/docs-2.0/1.introduction/0-0-graph.md
diff --git a/docs-2.0/1.introduction/0-1-graph-database.md b/docs-2.0/1.introduction/0-1-graph-database.md
diff --git a/docs-2.0/1.introduction/0-2.relates.md b/docs-2.0/1.introduction/0-2.relates.md
diff --git a/docs-2.0/1.introduction/1.what-is-nebula-graph.md b/docs-2.0/1.introduction/1.what-is-nebula-graph.md
@@ -2,7 +2,7 @@
 
 Nebula Graph is an open-source, distributed, easily scalable, and native graph database. It is capable of hosting graphs with hundreds of billions of vertices and trillions of edges, and serving queries with millisecond-latency.
 
-![Nebula Graph birdview](nebula-birdview.png)
+![Nebula Graph birdview](nebula-graph-birdview-3.0.png)
 
 ## What is a graph database
 

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
@@ -84,10 +84,6 @@ In the `nebula-graphd.conf` file, when `enable_optimizer` is set to be `true`, P
 
     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 by default.
-
 ## Executor
 
 The Executor module consists of Scheduler and Executor. The Scheduler generates the corresponding execution operators against the execution plan, starting from the leaf nodes and ending at the root node. The structure is as follows.

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
@@ -70,37 +70,37 @@ Therefore, Nebula Graph develops its own KVStore with RocksDB as the local stora
 
 - One Nebula Graph KVStore cluster supports multiple graph spaces, and each graph space has its own partition number and replica copies. Different graph spaces are isolated physically from each other in the same cluster.
 
-<!--
-## Data storage formats
+## Data storage structure
 
-Nebula Graph stores vertices and edges. Efficient property filtering is critical for a Graph Database. So, Nebula Graph uses keys to store vertices and edges, while uses values to store the related properties.
+Graphs consist of vertices and edges. Nebula Graph uses key-value pairs to store vertices, edges, and their properties. Vertices and edges are stored in keys and their properties are stored in values. Such structure enables efficient property filtering.
 
-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.
+- The storage structure of vertices
 
-- Vertex format
+  Different from Nebula Graph version 2.x, version 3.x added a new key for each vertex. Compared to the old key that still exists, the new key has no `TagID` field and no value. Vertices in Nebula Graph can now live without tags owing to the new key.
 
-    ![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)
+    ![The vertex structure of Nebula Graph](https://github.com/vesoft-inc/nebula-docs-cn/blob/{{nebula.branch}}/docs-2.0/1.introduction/3.nebula-graph-architecture/3.0-vertex-key.png?raw=true)
 
     |Field|Description|
     |:---|:---|
     |`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 the space.|
+    |`VertexID`|The 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.|
+    |`SerializedValue`|The serialized value of the key. It stores the property information of the vertex.|
 
-- Edge Format
+- The storage structure of edges
 
-    ![The edge format of storage service](https://docs-cdn.nebula-graph.com.cn/docs-2.0/1.introduction/2.nebula-graph-architecture/storage-edge-format.png)
+    ![The edge structure of Nebula Graph](https://github.com/vesoft-inc/nebula-docs-cn/blob/{{nebula.branch}}/docs-2.0/1.introduction/3.nebula-graph-architecture/3.0-edge-key.png?raw=true)
 
     |Field|Description|
     |:---|:---|
     |`Type`|One byte, used to indicate the key type.|
-    |`PartID`|Three bytes, used to indicate the sharding partition. This field can be used to scan the partition data based on the prefix when re-balancing the partition.|
-    |`VertexID`|Used to indicate vertex ID. The former VID refers to source VID in out-edge and dest VID in in-edge, while the latter VID refers to dest VID in out-edge and source VID in in-edge.|
-    |`Edge Type`|Four bytes, used to indicate edge type. Greater than zero means out-edge, less than zero means in-edge.|
+    |`PartID`|Three bytes, used to indicate the partition ID. This field can be used to scan the partition data based on the prefix when re-balancing the partition.|
+    |`VertexID`|Used to indicate vertex ID. The former VID refers to the source VID in the outgoing edge and the dest VID in the incoming edge, while the latter VID refers to the dest VID in the outgoing edge and the source VID in the incoming edge.|
+    |`Edge Type`|Four bytes, used to indicate the edge type. Greater than zero indicates out-edge, less than zero means in-edge.|
     |`Rank`|Eight bytes, used to indicate multiple edges in one edge type. Users can set the field based on needs and store weight, such as transaction time and transaction number.|
     |`PlaceHolder`|One byte. Reserved.|
--->
+    |`SerializedValue`|The serialized value of the key. It stores the property information of the edge.|
 
 ### Property descriptions
 
@@ -114,12 +114,11 @@ Since in an ultra-large-scale relational network, vertices can be as many as ten
 
 ![data partitioning](https://www-cdn.nebula-graph.com.cn/nebula-blog/DataModel02.png)
 
-<!--
-### Edge and storage amplification
+### Edge partitioning and storage amplification
 
 In Nebula Graph, an edge corresponds to two key-value pairs on the hard disk. When there are lots of edges and each has many properties, storage amplification will be obvious. The storage format of edges is shown in the figure below.
 
-![edge storage](https://docs-cdn.nebula-graph.com.cn/docs-2.0/1.introduction/2.nebula-graph-architecture/two-edge-format.png)
+![partitioning by edge](https://github.com/vesoft-inc/nebula-docs-cn/blob/{{nebula.branch}}/docs-2.0/1.introduction/3.nebula-graph-architecture/edge-division.png?raw=true)
 
 In this example, ScrVertex connects DstVertex via EdgeA, forming the path of `(SrcVertex)-[EdgeA]->(DstVertex)`. ScrVertex, DstVertex, and EdgeA will all be stored in Partition x and Partition y as four key-value pairs in the storage layer. Details are as follows:
 

diff --git a/docs-2.0/1.introduction/nebula-birdview.png b/docs-2.0/1.introduction/nebula-birdview.png
diff --git a/docs-2.0/1.introduction/nebula-graph-birdview-3.0.png b/docs-2.0/1.introduction/nebula-graph-birdview-3.0.png