list mode as edges

.gitignore

@@ -1,3 +1,4 @@
 site/
 *.DS_Store
+vim*
 

docs-2.0/3.ngql-guide/3.data-types/6.list.md

@@ -112,8 +112,6 @@ nebula> MATCH p = (n:player{name:"Tim Duncan"})-[:follow]->(m) \
 
 ## OpenCypher兼容性
 
-- 复合数据类型（例如set、map、list）**不能**存储为点或边的属性。
-
 - 在openCypher中，查询越界元素时返回`null`，而在nGQL中，查询越界元素时返回`OUT_OF_RANGE`。
 
     ```ngql
@@ -124,3 +122,7 @@ nebula> MATCH p = (n:player{name:"Tim Duncan"})-[:follow]->(m) \
     | OUT_OF_RANGE      |
     +-------------------+
     ```
+
+- 复合数据类型（例如set、map、list）**不能**存储为点或边的属性。
+
+    + 建议修改图建模方式：将复合数据类型建模为点的邻边，而不是该点的自身属性，每条邻边可以动态增删，并且可以设置邻边的 rank 值来控制邻边的顺序。

docs-2.0/8.service-tuning/2.graph-modeling.md

@@ -14,11 +14,41 @@
 
 在测试环节中，通常会验证各种各样的查询语句，以全面评估系统能力。但在大多数生产场景下，每个集群被频繁调用的查询语句的类型并不会太多；根据20-80原则，针对重要的查询语句进行建模优化。
 
-### 合理设置边属性
+### Tag 与 Edge Type 之间没有绑定关系
 
-- Nebula Graph 基于图拓扑结构进行深度图遍历的性能较低，但是广度优先遍历以及获取属性的性能较好。因此为了减少遍历深度，请使用点属性代替边。例如，模型a包括姓名、年龄、眼睛颜色三种属性，建议创建一个标签`person`，然后为它添加姓名、年龄、眼睛颜色的属性。如果创建一个包含眼睛颜色的标签和一个边类型`has`，然后创建一个边用来表示人拥有的眼睛颜色，这种建模方法会降低遍历性能。
+任何 Tag 可以与任何 Edge Type 相关联，完全交由应用程序控制。不需要在 Nebula Graph 中预先定义，也没有命令获取哪些 Tag 与哪些 Edge Type 相关联。
 
-- 为边创建属性时请勿使用长字符串：虽然 Nebula Graph 支持在边上存储长字符串属性，但是这些属性会同时保存在出边和入边，注意写入放大问题（write amplification）。
+### Tag/Edge Type 预先定义了一组属性
+
+建立Tag（或者Edge Type）时，需要指定对应的属性。通常称为 schema。
+
+### 区分“经常改变的部分”和“不经常改变的部分”
+
+改变指的是业务模型和数据模型上的改变（元信息），不是数据自身的改变。
+
+Nebula Graph {{ nebula.release }} 是强 schema 的系统，这意味着业务数据模型中的部分是“不应该经常改变的”，例如属性 schema 应该避免改变。类似于 MySQL 中 alter table 是应该尽量避免的操作。
+
+而点及邻边可以非常低成本的增删，因此可以将业务模型中“经常改变的部分”建模成点或边（关系），而不是属性schema。
+
+例如，在一个业务模型中，人的属性是相对固定的，例如“年龄”，“性别”，“姓名”。而“通信好友”，“出入场所”，“交易账号”，“登录设备”等是相对容易改变的。前者适合建模为属性，后者适合建模为点或边。
+
+### 广度优先大于深度优先
+
+- Nebula Graph 基于图拓扑结构进行深度图遍历的性能较低，广度优先遍历以及获取属性的性能较好。例如，模型a包括姓名、年龄、眼睛颜色三种属性，建议创建一个标签`person`，然后为它添加姓名、年龄、眼睛颜色的属性。如果创建一个包含眼睛颜色的标签和一个边类型`has`，然后创建一个边用来表示人拥有的眼睛颜色，这种建模方法会降低遍历性能。
+
+- “通过边属性获取边”的性能与“通过点属性获取点”的性能是接近的。在一些数据库中，会建议将边上的属性重新建模为中间节点的属性：例如 `(src)-[edge {P1, P2}]->(dst)`，`edge` 上有属性 `P1, P2`，会建议建模为 `(src)-[edge1]->(i_node {P1, P2})-[edge2]->(dst)`。在 Nebula Graph {{ nebula.release }} 中可以直接使用 `(src)-[edge {P1, P2}]->(dst)`，减少遍历深度有助于性能。
+
+### 边的方向
+
+查询时，如果需要使用边的逆向查询，可以用如下语法：
+
+`(dst)<-[edge]-(src)` 或者 `GO FROM dst REVERSELY`;
+
+如果不关心边的方向，可以使用如下语法：
+
+`(src)-[edge]-(dst)` 或者 `GO FROM src BIDIRECT`;
+
+因此，通常同一条边没有必要反向再冗余插入一次。
 
 ### 合理设置标签属性
 
@@ -31,3 +61,11 @@
 ### 合理设计VID
 
 参考[点VID一节](../1.introduction/3.vid.md)。
+
+### 长文本
+
+为边创建属性时请勿使用长文本：这些属性会被[存储2份](../1.introduction/3.nebula-graph-architecture/4.storage-service.md)，导致写入放大问题（write amplification）。此时建议将长文本放在 HBase/ES 中，将其地址存放在 Nebula Graph 中。
+
+## 不能支持动态时序图
+
+在某些场景下，图需要同时带有时序信息，以描述整个图的结构随着时间变化的情况。Nebula Graph {{ nebula.release }} 的边可以使用 rank 字段存放时间信息(int64)，但是点上没有字段可以存放时间信息（存放在属性会被新写入覆盖）。因此不能支持动态时序图。