Janusgraph的功能和未来

如何解决Janusgraph的功能和未来

我正在从事的项目目前使用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顶点的数量级中，对所有具有拥有Give属性的顶点的查询将花费8到10秒（10次相同查询的平均时间，该时间在Java程序中的前后） ）。该命令本身非常简单：

  g.V().has("secText","some text").inE().outV();

  此外，当我尝试插入更多记录（扩展到10万个顶点）时，docker映像似乎崩溃了。

  我们想知道这是由于docker映像的有限性引起的还是有任何问题或者是否正常？无论如何，它看起来确实非常缓慢。

• 我们在镇上使用Janusgraph建立了2个节点的Cassandra集群（在2个不同的VM上），结果还是很慢。

• 根据我在Internet上阅读的内容，人们似乎在使用Janusgraph部署并在生产中使用了数百万个顶点，因此我想他们可以在几毫秒内执行简单的查询。那里的秘密是什么？您需要128GB的RAM才能使整个设备正常运行吗？还是有我不知道的遵循良好实践的指南？我尽力使用Janusgraph的官方文档和在类似此处的论坛上的用户评论，但我对此并不担心：/

关于Janusgraph的未来：

• Janusgraph在头几年（如2016-2018年）似乎发展很快，但是在过去的几个月中，除了几个月前发布的0.5版本之外，我没有看到Janusgraph社区的大量活动。例如，自去年以来没有会议。 所以我想知道：Janusgraph是否在正确的轨道上得以持续并保持了很多年。是因为COVID导致事情变慢了还是有事情发生？
• Janusgraph中是否考虑了向后兼容性？从我在文档中可以看到的内容来看，许多事情已经从0.2 / 0.3版本更改为0.4和0.5。例如，Cassandra Thrift和嵌入式系统已被弃用。因此，在生产环境中，我们不能总是负担每年的版本更新，在某些组件已过时的情况下，请不要进行代码修改，Janusgraph开发人员是否打算尽快实现一些向后兼容性，或者我们是否应该等待该版本的1.0版本？

感谢您阅读所有这些内容，我期待您能为我提供的所有答案:)祝您愉快！

梅尔

解决方法

带有Cassandra的JanusGraph在存储层有设计限制，这会降低性能。实际上，它具有大型，可伸缩但缓慢的图形数据库，可提供Cassandra的复制和冗余优势。

Cassandra可以分片数据，并且擅长在整个集群中随机分布数据，但是这破坏了快速进行遍历所需的数据局部性。除了Cassandra之外，JanusGraph还支持多种后端存储选项，这意味着它没有严格调整到任何特定的存储体系结构。

内存可能会有所不同，因此请验证已为每个节点上的JVM分配了多少内存，使用G1GC并禁用交换。 VisualVM有助于分析您的内存空间。

,

您好，我知道这可能会迟到，但请告诉我。您是否访问所有顶点以进行分析或事务查询？ OLAP 还是 OLTP？因为您查询的顶点和边的数量以及您如何查询会产生重大影响。例如，您是否告诉 Janusgraph 返回一个顶点，该顶点具有数百万条边，所有这些边都在一个镜头中，还是只有少数几条。这被称为热顶点（一个顶点有很多不能存储在一个服务器实例上的边）。