我们想在图表中展示我们的数据，并考虑使用其中一个 graphdbs。在我们的供应商调查过程中，一位专家建议在密集图上使用 graphdb 效率不高，我们最好使用像 cassandra 这样的基于列的数据库。
I gave your use case some thought and given your graph is very dense (number of relationships = number of nodes squared) and that you seem to only need a few hop traversals from the particular node along different relationships. I’d actually recommend you also try out a columnar database.
Graph databases tend to work well when you have sparse graphs (num of relationships << num of nodes ^ 2) and with deep traversals - from 4-5 hops to hundreds of hops. If I understood your use-case correctly, a columnar database should generally outperform graphs there.
我们的用例最终可能会将节点连接到数千万个其他节点，不同节点之间大约有 30% 的重叠 - 因此在某种程度上，它可能是一个密集图。总体上可能会有几十亿个节点。
查看 Neo4j 源代码，我发现节点上有一些 isDense 标志的引用，以区分处理逻辑 - 不确定它的作用。但我也想知道它是否是作为边缘案例补丁完成的，如果图中的大多数节点都是密集的，它就不会很好地工作。
有没有人有在密集图上使用 graphdbs 的经验，在这种情况下应该考虑它吗？
感谢所有意见!
最佳答案
当想到图数据库的使用时，它显示多个表相互链接，这是图数据库的完美用例。
我们正在处理具有 20B 个顶点和 15B 个边的规模的 JansuGraph。它不是一个顶点与 10s M 个顶点相连的大稠密图。但是，我们仍然观察到了 super 节点的情况，其中一个顶点与比预期更多的顶点相连。但是对于我们在进行遍历 (DFS) 时的用例，我们总是遍历一个节点的最大 N 个子节点和一个有限的深度，比如 M，考虑到非图 DBS(列式、关系式、Athena)中所需的连接数量，这绝对没问题等..)。
获得节点所有关系的唯一方法(我觉得)是进行完整的 DFS 或内部连接数据集，直到找不到公共(public)数据为止。
很高兴了解更多关于其他创意解决方案的信息。
关于neo4j - 是否可以在大型密集图上使用 graphdb，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49306337/