neo4j - Janusgraph 功能和 future

Question

我正在从事的项目目前使用 Neo4j 社区。目前我们处理具有 5-20M 边的 1-5M 顶点，但我们的目标是处理具有 50-100M 边的 10-20M 顶点。
我们正在讨论切换到图形数据库开源项目的想法，这将使我们能够按这些比例进行扩展。目前，我们的注意力集中在 Cassandra 的 Janusgraph 上。
我们有一些关于 Janusgraph 的功能和开发的问题，如果有人能回答，我们会很高兴! (也许是 Misha Brukman 或 Aaron Ploetz？)
关于 Janusgraph 功能:

我们使用 Janusgraph 即用型 docker 镜像做了一些实验，通过 java 程序发出查询。 java程序和docker镜像运行在同一台机器上。在插入 50k-100k 边的 10k-20k 顶点的量级上，对所有具有给定属性的顶点的查询需要 8 到 10 秒(平均时间超过 10 个相同的查询，在 java 程序中的命令前后耗时) )。命令本身非常简单:g.V().has("secText", "some text").inE().outV();此外，当我尝试插入更多记录(扩展到 10 万个顶点)时，docker 图像似乎崩溃了。
不知道是不是因为docker镜像的特性有限，或者是有什么问题还是正常的？无论如何，它似乎真的，真的很慢。

我们在镇上使用 Janusgraph 设置了一个 2 节点的 Cassandra 集群(在 2 个不同的虚拟机上)，结果同样很慢。

从我在互联网上读到的，人们似乎在生产中使用具有数百万个顶点的 Janusgraph 部署，所以我猜他们可以在几毫秒内执行简单的查询。那里有什么 secret ？您是否需要 128GB 的​​ RAM 才能让整个系统正常运行？或者也许有一个我不知道的良好实践指南？我尽我最大的努力使用 Janusgraph 官方文档和用户在论坛上的评论，但我担心:/

关于 Janusgraph 的 future :

Janusgraph 在最初几年(如 2016-2018 年)似乎发展得很快，但在过去的几个月里，我没有看到 Janusgraph 社区有太多事件，除了几个月前发布的 0.5 版。例如，自去年以来没有 session 。
所以我想知道:Janusgraph 是否走在正确的轨道上，能够持续并在 future 很多年得到维护。事情是不是因为 COVID 而放慢了一点，或者有什么事情吗？

Janusgraph 中是否考虑了向后兼容性？从我在文档中读到的内容来看，从 0.2/0.3 版本到 0.4 和 0.5 版本有很多变化。很多都会出现，例如 Cassandra Thrift 和嵌入式被弃用。那么，在我们不能总是负担得起每年更新版本的生产环境中，在某些组件被弃用的情况下，暂且不说代码修改，Janusgraph dev 是否​​考虑尽快实现一些向后兼容，或者我们还是应该等待对于 1.0 版本呢？

感谢您阅读所有这些，我期待着您能给我的所有答案:) 祝您有美好的一天!
梅尔

Answer 1

使用 Cassandra 的 JanusGraph 在存储层存在设计限制，这会降低性能。在实践中，它是一个大型、可扩展但速度较慢的图形数据库，可提供 Cassandra 的复制和冗余优势。
Cassandra 对数据进行分片并且非常擅长在集群中随机分布数据，但是这会破坏数据局部性，而这正是快速高效遍历所需的。除了 Cassandra 之外，JanusGraph 还支持多种后端存储选项，这意味着它没有针对任何特定的存储架构进行紧密调整。
内存会有所不同，因此请验证您在每个节点上为 JVM 分配了多少内存，使用 G1GC 并禁用交换。 VisualVM 有助于分析您的内存空间。