【问题标题】:Faster JanusGraph queries更快的 JanusGraph 查询
【发布时间】:2022-01-13 13:56:20
【问题描述】:

以前我的 janusgraph 在近 1000 个元素上运行良好。我制作了 100k 的图表,现在一些查询非常慢。我使用 Cassandra 作为数据库后端,使用弹性搜索作为索引后端。

例如 g.V().hasLabel('Person').union(count(), range(0, 15)) 这需要 1.3 分钟。我只想得到15个“人”。应该很快。

g.E().count() 需要 1.4 分钟。为什么这么慢?我只有 200k 节点和 400k 边。

我的“Person”节点类型也有一些复合索引。我有“人”节点类型的所有属性的索引

感谢您的建议

【问题讨论】:

  • 我会首先对查询执行.profile(),以确保查询正在使用索引。
  • @KelvinLawrence 我确实为 JanusGraphStep([],[~label.eq(Person)]) 运行了 .profile() 78 秒(99% 的执行时间)所以它似乎不使用索引但可以count() 查询使用索引?混合索引有帮助吗?

标签: gremlin tinkerpop janusgraph


【解决方案1】:

计算具有特定标签的顶点是 JanusGraph 只能通过运行全表扫描来解决的常见用例。因此,对于较大的图形,计数变得非常缓慢。因为用例如此频繁,所以为它创建了一个issue

如果您将 Janusgraph 与混合索引的索引后端一起使用。可以在 JanusGraph 中运行所谓的直接索引查询,它可以以更快的方式return totals 的索引命中。不过,这不适用于标签过滤器,但适用于索引属性。

【讨论】:

  • '直接索引查询'对于一般情况没有帮助。我的查询包含一些条件,然后是类似于.union(count(), range(0, 15)) 的语句,所以我需要计算不同的东西。索引可以帮助它吗?
猜你喜欢
  • 2019-02-14
  • 1970-01-01
  • 2019-07-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-06-05
  • 2017-01-15
  • 1970-01-01
相关资源
最近更新 更多