AWS Neptune 查询正在阻止所有其他查询

问：

我们正在使用 AWS Neptune Graph 数据库，需要查询子图。 我们的数据库中大约有 300-400 个独立图，一次只需要查询其中一个。

我们的模型主要是这样的： 图模型 我们有 300-400 个“A”顶点。这是我们的顶级元素，每个以“A”开头的图形都独立于其他图形。 每个“A”顶点可以有多个（20-100）个“B”顶点。每个“B”顶点可以有多个（2-10）个“C”顶点。 所以我们有 A、B、C 作为一个层次结构。在此之下，我们有我们的“数据”顶点，它或多或少是连续的几个顶点（D，E，F，G），这可能是几次（1-10）。最后一个“G”顶点连接到下一个“B”顶点下的下一个“D”顶点。

我们需要查询从 A 或一些特定 B 开始的完整图。

目前，我们正在使用此查询来获取整个图形（所有顶点和边），然后删除一些连接。此查询是我们事务中的第一个查询。交易需要一些时间，因为它会添加很多顶点和 egdes。事务中的第一个查询会阻止所有其他查询。我们收到一个 ConcurrentModificationException。

如果查询图形中 A（ID： 4711） 的长事务正在运行：

• 我无法在 Jupyter Notebook 上添加顶点（A、B、C、..）
• 我无法对不同的 A 顶点运行相同的查询。

-> 结果始终是 ConcurrentModificationException。

看起来查询确实阻止了所有顶点的完整索引。无法添加任何其他顶点。

我们有一个后台进程正在更新数据库，此事务最多需要 30 秒。然后我们有很多这样的更新。就像每分钟更新一个不同的 A 子图一样。另一方面，用户使用该应用程序，也可以编辑数据。 目前的问题是，更改 A（ID：4711） 子图的数据也会阻止 A（4712） 子图的更改，即使它们之间完全没有联系。

g.V().hasLabel("A").has("v",4711).outE("s").inV()
.hasLabel("B").hasId("c4...a","a0...f","ac...3")
.outE("h").inV()
.bothE("sv","ev")
.bothV().not(hasLabel("C")).simplePath()
.barrier()
.repeat(outE().not(hasLabel("sv","ev")).simplePath().inV())
.until(or(outE().count().is(0),hasLabel("C"),hasLabel("AP","AC").bothE("sv","ev").count().is(P.gt(0))))
.path().unfold().dedup().or(hasLabel("sp").has("ev"),hasLabel("ev")).barrier()
.drop()

有没有机会重写这个查询，它不会阻止数据库？我的意思是子图是完全独立的，我不明白为什么这个查询会阻止全范围的索引。

如果我使用 %%gremlin 配置文件在 DEV 环境中运行查询：

Predicates
==========
# of predicates: 79

Results
=======
Count: 12

Index Operations
================
Query execution:
    # of statement index ops: 3283
    # of unique statement index ops: 1984
    Duplication ratio: 1.65
    # of terms materialized: 598
Serialization:
    # of statement index ops: 3
    # of unique statement index ops: 3
    Duplication ratio: 1.0
    # of terms materialized: 21

如果我甚至在具有更多数据的数据库上运行该查询，我会得到以下结果：

Predicates
==========
# of predicates: 62

Results
=======
Count: 66

Index Operations
================
Query execution:
    # of statement index ops: 26412
    # of unique statement index ops: 9403
    Duplication ratio: 2.81
    # of terms materialized: 1706
Serialization:
    # of statement index ops: 3
    # of unique statement index ops: 3
    Duplication ratio: 1.0
    # of terms materialized: 94

对我来说，看起来我们在这个查询中有太多的索引操作。您知道我们如何防止该查询扫描数据库/索引吗？