我正在从事的项目目前使用 Neo4j 社区。目前我们处理具有 5-20M 边的 1-5M 顶点,但我们的目标是处理具有 50-100M 边的 10-20M 顶点。
我们正在讨论切换到图形数据库开源项目的想法,这将使我们能够按这些比例进行扩展。目前,我们的注意力集中在 Cassandra 的 Janusgraph 上。
我们有一些关于 Janusgraph 的功能和开发的问题,如果有人能回答,我们会很高兴! (也许是 Misha Brukman 或 Aaron Ploetz?)
关于 Janusgraph 功能:
g.V().has("secText", "some text").inE().outV();
此外,当我尝试插入更多记录(扩展到 10 万个顶点)时,docker 图像似乎崩溃了。不知道是不是因为docker镜像的特性有限,或者是有什么问题还是正常的?无论如何,它似乎真的,真的很慢。
关于 Janusgraph 的 future :
所以我想知道:Janusgraph 是否走在正确的轨道上,能够持续并在 future 很多年得到维护。事情是不是因为 COVID 而放慢了一点,或者有什么事情吗?
感谢您阅读所有这些,我期待着您能给我的所有答案:) 祝您有美好的一天!
梅尔
最佳答案
使用 Cassandra 的 JanusGraph 在存储层存在设计限制,这会降低性能。在实践中,它是一个大型、可扩展但速度较慢的图形数据库,可提供 Cassandra 的复制和冗余优势。
Cassandra 对数据进行分片并且非常擅长在集群中随机分布数据,但是这会破坏数据局部性,而这正是快速高效遍历所需的。除了 Cassandra 之外,JanusGraph 还支持多种后端存储选项,这意味着它没有针对任何特定的存储架构进行紧密调整。
内存会有所不同,因此请验证您在每个节点上为 JVM 分配了多少内存,使用 G1GC 并禁用交换。 VisualVM 有助于分析您的内存空间。
关于neo4j - Janusgraph 功能和 future ,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/63567936/