我们希望用图表来表示数据，并考虑使用graphdb中的一种。在我们的供应商调查过程中，一位Maven建议在密集的图表上使用graphdb效率不高，我们最好使用cassandra这样的基于列的数据库。
我对您的用例进行了一些思考，并考虑到您的图非常密集（关系数=节点数的平方），而且您似乎只需要从特定节点沿着不同的关系进行几次遍历。
当你有稀疏的图（关系数〈〈节点数^ 2）和深度遍历（从4-5跳到数百跳）时，图数据库往往工作得很好。如果我对你的用例理解正确的话，列数据库通常应该比图更好。
我们的用例最终可能会有一个节点连接到数以千万计的其他节点，不同节点之间大约有30%的重叠--所以从某种程度上说，这可能是一个密集的图，总体上可能有几十亿个节点。
查看Neo4j源代码，我发现节点上引用了isDense标志来区分处理逻辑--不确定它有什么作用。但我也想知道它是否是作为一个边缘情况补丁完成的，如果图中的大多数节点是密集的，它就不能很好地工作。
有没有人在稠密图上使用graphdbs的经验，在这种情况下应该考虑使用graphdbs？
所有的意见都是赞赏！
2条答案
按热度按时间ffscu2ro1#
当想到使用graph DB时，它显示多个表彼此链接，这是graph DB的完美用例。
我们处理的JansuGraph的规模为20B个顶点和15B个边。它不是一个顶点连接了10s M个顶点的大型密集图。但我们仍然观察到了超级节点的情况，其中一个顶点连接了比预期更多的顶点。但在我们的用例中，当进行遍历时（DFS）我们总是遍历一个节点的最多N个子节点和有限的深度，比如M，考虑到非图DBS（柱状、关系、雅典娜等）中所需的连接数量，这是绝对好的。
唯一的方法（我觉得）得到一个节点的所有关系是做一个完整的DFS或内部连接数据集，直到没有共同的数据找到。
很高兴了解更多关于其他创造性解决方案的信息。
gpfsuwkq2#
我没有使用图数据库的密集图的经验，但我不认为密集图是一个问题。既然你要使用图算法，我想，你会受益于使用图数据库（取决于算法的复杂性-越多的“跳”，你越受益于恒定的边遍历时间）。
一个好的折衷方案是使用一个非本Map形数据库（如Titan，它的后续产品JanusGraph，Mongo Db等），它实际上使用基于列的存储（Cassandra，Barkley DB等）作为后端。