我目前正在工作的项目中使用Neo4j社区版。我们处理1-5M个顶点,5-20M条边,但我们的目标是处理10-20M个顶点和50-100M条边的数据量。我们正在讨论切换到一个图数据库开源项目,以便能够按比例扩展。目前我们考虑使用Janusgraph和Cassandra。
关于Janusgraph的能力,我们有一些问题需要解答:
关于Janusgraph的能力,我们有一些问题需要解答:
- 我们使用了Janusgraph的ready-to-use docker镜像进行了一些实验,通过Java程序发出查询请求。Java程序和docker镜像在同一台机器上运行。当插入10k-20k个顶点,50k-100k条边时,查询所有具有给定属性的顶点需要花费8到10秒钟(在Java程序中执行10个相同的查询,统计平均时间,包括命令之前和之后的时间)。查询本身非常简单:
g.V().has("secText", "some text").inE().outV();
此外,当我尝试插入更多记录时(向100k个顶点扩展),docker镜像似乎会崩溃。我们想知道这是否是由于docker镜像的局限性,还是存在任何问题,或者这种情况是否正常?总之,它看起来非常非常慢。 - 我们在两个不同的VM上设置了一个2节点的Cassandra集群,并使用Janusgraph进行测试,结果也很慢。
- 从我在互联网上阅读到的信息来看,人们似乎在生产中使用Janusgraph部署了数百万个顶点,所以我猜他们可以在毫秒级别内执行简单的查询。那么秘诀是什么?你需要像128GB的RAM一样的东西才能使整个系统正确运行吗?或者可能有一些我不知道的好的实践指南吗?我尽力使用了Janusgraph的官方文档和用户在论坛上的评论,但我怕这些还不够。
- Janusgraph在前几年(例如2016-2018)似乎发展相当迅速,但是最近几个月我没有看到Janusgraph社区有太多的活动,除了几个月前发布的0.5版本。例如,自从去年以来就没有再举行会议。 因此,我想知道:Janusgraph是否正在正确的轨道上持续发展并将被维护多年。事情是否因COVID而放缓?还是有其他原因?
- 在Janusgraph中考虑到向后兼容性吗?从文档中可以看出,在版本0.2 / 0.3到0.4和0.5之间有许多变化。许多内容即将过时,例如Cassandra Thrift和嵌入式。因此,在生产环境中,我们不能总是负担得起每年更新版本,更不用说在某些组件过时的情况下进行代码修改,那么Janusgraph开发人员是否想要尽快实现一些向后兼容性,或者我们应该等待1.0版本呢?
感谢您阅读这些内容,我期待着您能给我所有的答案 :) 祝您愉快!
Mael
WARN transaction.StandardJanusGraphTx: Query requires iterating over all vertices [()]. For better performance, use indexes
或者使用profile()
检查你的查询。关于索引的更多信息请参考 https://docs.janusgraph.org/index-management/index-performance/。 - mad