ArangoDB-IN运算符非常慢

Question

我在ArangoDB中使用IN运算符时遇到一些性能问题。

简而言之，我有一个来自拆分函数的计算（运行时）id数组，我只想获取Collection的选定元素，然后收集或过滤其他数据。

在这里您可以找到AQL查询 ：

LET toInclude = SPLIT('Collection/1,Collection/2,Collection/3', ',')

FOR result IN Collection
  FILTER result._id IN toInclude  
  COLLECT property = result.property 
  WITH COUNT INTO count
return  {property, count}

数组toInclude的元素可以是300000+，查询可以花费10分钟以上来完成工作。

该split -函数结束在3秒时， property字段建立索引，所以这个问题是在IN操作符。

我该怎么做才能解决此演出问题？

非常感谢你！

丹尼尔

Answer 1

我尝试对包含100,000个文档的toInclude 500,000个字符串条目进行查询。

确实需要很长时间才能完成2.7。 执行时间约为4xx秒。 该查询花费大量时间IN此处评估FILTER的IN运算符。 实际上，将为找到的每个文档评估FILTER条件。 这将与我使用的数据进行大约100,000 x 500,000 / 2比较。

在2.8中，使用相同的数据进行相同的查询大约需要2.7秒，因此该问题似乎没有发生。 2.8中有很多优化程序更改，而导致加速的原因是IN表达式将直接在索引中求值。 FILTER将在那里进行优化。

因此，一种解决方案是在ArangoDB 2.8可用时使用它（当前它在beta中）。

另一个解决方法是改进优化程序，以检测IN的右侧在查询中是const，以便它可以对结果进行排序，并可以使用二分查找（对数而不是线性复杂度）进行IN 。 但这还不可用。

2.7的解决方法是单独计算IN列表，并将其作为数组插入查询中。 这样， IN列表将是一个常量值，优化器将能够对其进行预排序，以便可以使用二进制搜索。 但是，这要求在原始查询之前/之前执行SPLIT操作。

更新 ：在2.8中，现在存在一个附加的优化器规则，可以针对上述情况和其他情况对IN列表值进行预排序。 这使IN运算符可以使用二进制搜索，它具有对数复杂度，而不是某些情况下的线性复杂度。 此更改将包含在2.8 beta2中。