Janusgraph的能力和未来

Question

我正在从事的项目目前使用Neo4j社区。目前，我们处理1-5米的顶点有5-20M的边，但我们的目标是处理10-20M的顶点w/ 50-100 m的边。我们正在讨论切换到图形数据库开放源码项目的想法，该项目将使我们能够按此比例进行扩展。目前，我们的注意力集中在卡桑德拉的詹图格上。

我们有一些关于Janusgraph的能力和发展的问题，我们很高兴有人能回答！(也许是米莎·布鲁克曼还是亚伦·普洛伊茨？)

简图功能：

• 我们做了一些实验，使用的是Janusgraph现成的对接器映像，查询是通过java程序发出的。java程序和docker映像在同一台机器上运行。当10k-20k顶点插入50k-100 k边时，对具有and属性的所有顶点的查询需要8至10秒(平均时间超过10个相同的查询，在java程序中的命令之前和之后经过的时间)。命令本身非常简单：

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

此外，当我尝试插入更多的记录(扩展到100 k的顶点)时，停靠者图像似乎崩溃了。

我们想知道这是否是由于码头形象的有限性质，或是否有任何问题，或是否可能是正常的？不管怎样，看起来真的，真的很慢。--

• 我们建立了两个节点的卡桑德拉集群(在两个不同的VM上)，并在镇子上安装了詹纳斯图，结果也很慢。

从我在互联网上看到的

• 来看，人们似乎对生产中的数以百万计的顶点使用Janusgraph部署，所以我猜他们可以在毫秒内执行简单的查询。那有什么秘密？您是否需要像128 to的RAM才能正确地执行整个任务？或者，也许有一个指南，一个好的做法，遵循，我不知道？我尽了最大努力在这里这样的论坛上使用JanusGraph官方文档和用户评论，但恐怕没那么多:/

关于詹斯图的未来：

在最初几年(比如2016-2018年)，

• Janusgraph似乎发展得相当迅速，但在过去的几个月里，除了几个月前发布的0.5版外，我没有看到Janusgraph社区有多少活动。例如，自去年以来没有举行过任何会议。因此，我想知道: Janusgraph在正确的轨道上，将持续和维持许多年以后。是因为COVID的原因，事情慢了一点，还是有什么问题？
• 是在Janusgraph中考虑的向后兼容性吗？从我在文档中可以看到的内容来看，许多东西已经从0.2/0.3版本更改为0.4和0.5版。例如，许多人都会像卡桑德拉·萨夫拉那样被废弃。因此，在我们不能总是每年更新版本的生产环境中，在某些组件被废弃的情况下，抛开代码修改不谈，Janusgraph是否考虑很快实现一些向后兼容性，还是应该等待1.0版本的实现呢？

谢谢你阅读这篇文章，我期待着你能给我的所有答案:)祝你今天愉快！

麦尔

Answer 1

卡桑德拉的JanusGraph在存储层有设计限制，这使得性能变慢。实际上，它是一个大的、可扩展的、但速度慢的图形数据库，它提供了Cassandra的复制和冗余优势。

Cassandra分解数据，并且非常擅长在集群中随机分配数据，但是这会破坏数据的局部性，这是使遍历更快、更高效所必需的。除了Cassandra，JanusGraph还支持多个后端存储选项，这意味着它没有对任何特定的存储体系结构进行严格的调整。

内存可能会产生影响，因此验证您在每个节点上为JVM分配了多少内存，使用G1GC并禁用交换。VisualVM有助于分析您的内存空间。

Answer 2

你好，我知道可能要晚了但是请告诉我。您是否访问所有用于分析或事务查询的顶点？OLAP还是OLTP？因为你要查询多少个顶点和边，以及你是如何做到这一点的，所以有很大的影响。例如，您是否告诉Janusgraph返回一个顶点，该顶点有数以百万计的边，所有这些边都在一次拍摄中，或者只有少数几个边。这被称为热点顶点(一个顶点具有许多不能存储在一个服务器实例上的边缘)。