如何提高 Neptune 中的 order().by() 性能？

Question

我正在尝试通过遍历解决性能问题，并将其追踪到 order().by() 步骤。似乎order().by() 大大增加了所需的语句索引操作数（每个分析器）并显着减慢了执行速度。

无序遍历非常快：

g.V().hasLabel("post").limit(40)

执行时间：2 毫秒

索引操作数：1

添加单个排序步骤会增加数千个索引操作并且运行速度会慢得多。

g.V().hasLabel("post").order().by("createdDate", desc).limit(40)

执行时间：62 毫秒

索引操作：3909

添加单个过滤步骤会增加数千个索引操作并且运行速度会更慢：

g.V().hasLabel("post").has("isActive", true).order().by("createdDate", desc).limit(40)

执行时间：113 毫秒

索引操作数：7575

但是，相同的无排序过滤遍历运行速度与原始未过滤遍历一样快：

g.V().hasLabel("post").has("isActive", true).limit(40)

执行时间：1 毫秒

索引操作数：49

当我们在生产中构建实际遍历时，大约有 12 个过滤步骤和 4 个by() 步进调制器，导致遍历需要超过 6000 毫秒才能完成超过 33000 个索引操作。删除order().by() 步骤会导致相同的遍历快速运行（500 毫秒）。

问题似乎与order().by() 和排序所需的索引操作数有关。我已经看到here 提到的性能问题，但添加barrier() 并没有帮助。遍历也完全优化，无需 Tinkerpop 转换。

我正在运行引擎版本 1.1.0.0 R1。大约有 5000 个post 顶点。

如何提高这种遍历的性能？

Answer 1

因此，在任何图形数据库（包括 Neptune）中提高排序性能的唯一方法通常是在执行排序之前将项目过滤到最小集合。

order().by() 步骤要求必须返回所有符合条件的元素，才能按指定对它们进行排序。当仅使用limit(N) 步骤时，只要返回N 项目，遍历就会终止。这就是为什么您看到仅使用 limit() 选项的时间明显更快的原因，它只需要处理和返回更少的数据，因为它返回的第一个 N 记录可能是任何顺序的。