图数据库中，用点还是用属性来存储属性的权衡问题

在图数据库里，有时候会碰到一个看起来要做出一些取舍的地方，那就是：很多元素都有的，且重复值很多的一个属性，是应该将其作为顶点的属性来存储，还是当做一个顶点，然后用边来将元素指向该顶点来表示一个属性？例如以下的例子：

在我们的图中需要存储用户注册时的phone段和ip段。这两个属性是所有的用户顶点都需要的属性，而且这两个属性的重复度比较高，也就是很多很多顶点都有相同的phone段或者ip段。此时我们有两种不同的思路来解决这个问题：

思路1：将phone和ip当做用户顶点的属性。根据我们需要的读取模式，给phone和ip创建索引来加快查询效率。

思路2：phone和ip不作为属性，而是将不同的phone和ip段当做顶点保存在图数据库中，用户的ip和phone的值通过边指向不同的代表phone的顶点和ip的顶点，通过这种方式来实现保存其属性。

表面看起来这两种方式都可以实现功能，实际上他们之间还是有很多不同的。我们需要分析其各自不同的利弊，从而在不同的情形下选用不同的模型来解决问题。

用属性存储的方式的优点：

这种思路更直观一些，也更符合我们一般对顶点和属性的理解。

对与顶点属性本身的查询效率更高一些，因为不涉及顶点的traversal。如果使用顶点的方式存储，则涉及到边的向外遍历。尤其是如果我们要一次获取多个属性时，这种方式直接在顶点内就可以获取，而第二种方式则需要遍历n条边来获取n个属性。

存储需要的空间小一些，不需要在storage backend中使用额外的记录来存储这些保存属性的点以及指向这些代表属性的点的边。

图的schema会简单一些。不需要额外定义多个vertex label和edge label。

在导入顶点时速度会快一些，尤其是在开启了bulk loading模式时。因为这种方式在添加一个用户顶点时，只需要添加一个顶点和其对应的属性即可。而第二种方式里，我们除了需要添加用户顶点本身，还要在添加用户顶点之前先把属性顶点添加到库里（而在数据准备阶段，还需要将这些属性的数据单独剥离出来，并去掉其重复值），并在添加用户顶点时从库中查询已经添加的属性顶点，并添加指向这些顶点的边。这会导致图的准备阶段多浪费大量的时间。

用顶点存储的方式的优点：

以上的属性存储的方式的优点也恰恰是顶点存储的方式的缺点。这种方式并不直观，对顶点属性值的查询效率也不高，而且会增加额外的记录来保存点和边。另外会导致schema变得复杂，也会在导入数据时额外浪费时间花在属性顶点的查询上。

但这种方式也有其优点，那就是将属性的由点及面变得简单，尤其是在一个分析中涉及多个由点及面的情形时，这种方式的优点就能展现出来。而这也常常是图数据库需要做的东西，尤其在涉及社群分析时。

我们这里的由点及面代表的含义是：我们需要找出所有的跟某个或者某几个顶点的某些属性相同的全部顶点。

以以下的要求为例：当我们需要找到跟张三和李四使用同一个电话段或者ip段的用户使用的phone和ip的分组情况。

如果我们的图的schema是基于第一种情况存储的，这就变成了一个比较棘手的问题。我们需要首先找到张三和李四的电话作为phoneSet，然后找到张三和李四的ip作为ipSet，然后查询电话和ip与集合中的值相同的记录。

这种需求，如果放在普通的数据库中，实际上就是根据属性的join操作。这种看似简单的操作在图数据库中要实现确面临比较大的困难，原因在于：图数据库中解决连接的操作是通过边来实现的，且没有别的解决方式。换句话说，图数据库中，相同属性之间的点是没有东西能够将其快速连接起来的。

这也就是第二种方式最大的意义所在。以该题为例，我们通过gremlin可以很容易的实现（假设张三的顶点是v3，李四顶点是v4）：

g.V(v3, v4).out("ip", "phone").in("ip", "phone").values().groupCount()

总结：如果属性重复度很低，或者属性不涉及连接操作，则使用属性存储是更好也更直观的方式。但如果涉及属性的连接操作，而且属性的重复度很高，则可以考虑用点来存储属性。