HBase/Cassandra上属性图的数据模型

Question

我愿意将属性图存储到HBase中.属性图是图节点和边具有属性,并且多个边可以链接相同的节点元组,只要边属于不同类型即可.

我的查询模式要么是要求属性和邻域,要么遍历图形.一个例子是:Vertex [name = claudio] => OutgoingEdge [knows] => Vertex [gender = female],这将给我克劳迪奥喜欢的所有女性.

我知道图形数据库就是这样做的,但是如果数据集庞大,它们通常不会在多个节点上缩放.所以我愿意在NoSQL ColumnStore(HBase,Cassandra ......)上实现它.

我的数据模型如下.

顶点表:
键:vertexid(uuid)
族"属性:":<属性名称> => <属性值>,...
族"OutgoingEdges:":<edge key> => <other vertexid>,...
Family "IncomingEdges:":与传出边缘相同......

这个表允许我快速获取顶点及其邻接列表的属性.我不能将vertexid用作另一个端点,因为多个边(具有不同类型)可以连接相同的两个顶点.

边缘表:
键:edge键(复合(<source vertexid>,<destination vertexid>,<edge typename>))(即vertexid1_vertexid2_knows)
族"Properties:":<property name> => <property value>,...

这个表允许我快速获取边的属性.

边缘类型:
key:composite(<source vertexid>,"out | in",<edge typename>)(即vertexid1_out_knows)
族"Neighbor:":<destination vertexid> => null,...

这个表允许我搜索/扫描从顶点传入或传出的边缘并属于特定类型,并且是API的遍历能力的核心(所以我希望它在两个方面尽可能快网络I/O(RPC),磁盘I/O(搜索)).它还应该"缩放"图形的大小,这意味着随着图形的增长,这种类型的操作的成本应该取决于从顶点传出的边缘的数量而不是顶点和边缘的总数量.上面的例子我会考虑使用属性名称的vertexid1源顶点:claudio我将扫描vertexid1_out_knows并接收连接的顶点列表.之后,我可以扫描这些顶点上的"属性:性别"列,并查找具有"女性"值的列.

问题:

1)概述:您是否为我的运营看到了更好的数据模型？
2)我可以将所有内容都放在一个表格中,对于某些键,某些家族将是空的(即"OutgoingEdges:"系列对边缘没有意义)？我喜欢这样,因为你可以看到所有的键都是由vertexid uuid前缀组成的,所以它们非常紧凑,主要适用于同一个regionserver.
3)我想对于扫描我会广泛使用滤波器.我猜regexp Filter将是我的朋友.您是否担心应用于此数据模型的过滤器的性能？

Answer 1

这种类型的模型对于 Cassandra 来说似乎是一个明智的起点（对 HBase 不太了解） - 但对于任何分布式存储，您在遍历时都会遇到问题，因为遍历将跨越多个节点。

这就是为什么Neo4J等专用图数据库采用单节点设计，并尽量将所有数据保存在RAM中。

查找特定节点或边的属性应该可以很好地工作并且可以水平扩展 - Twitter 的FlockDB（现在显然已被放弃）就是一个著名的例子。

您还需要考虑是否需要除 ID 之外的查找（即是否需要任何索引）？