Indexing ArangoDB-IN操作员非常慢

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

简单地说，我有一个在运行时计算的ID数组，来自一个拆分函数，我只想获得集合的选定元素，然后收集或过滤其他数据

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

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

拆分函数在3sec中完成，属性字段被索引，因此问题在in运算符中

我能做些什么来解决这些性能问题

多谢各位

---

Daniele

我在toInclude中用500000个字符串条目对100000个文档集合进行了查询

完成2.7确实花了很长时间。执行时间约为4xx秒。查询花费大量时间评估运算符中的筛选器。事实上，将为找到的每个文档评估筛选条件。这将与我使用的数据进行大约100000 x 500000/2的比较

在2.8中，使用相同的数据进行相同的查询大约需要2.7秒，因此问题似乎不会出现在那里。在2.8中，优化器做了很多更改，导致加速的原因是in表达式将直接在索引中计算。过滤器将在那里进行优化

因此，一个修复方案是在Arangodb2.8目前处于测试阶段时使用它

另一个解决方案是改进优化器，以检测IN的右侧是查询中的常量，这样它可以对结果进行排序，并且可以使用二进制搜索对数而不是线性复杂度。但目前还没有

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

---

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

查看您的拆分-您的字符串不包含用于拆分它们的字符？如果删除查询的COLLECT部分，这会改变性能吗？抱歉，AQL中有一个输入错误，现在我要修复：LET toInclude=SPLIT'Collection/1，Collection/2，Collection/3'关于删除COLLECT，性能问题没有变化如果使用，它是否显示查询是否使用索引？使用的索引：Id类型集合唯一稀疏选择性。字段范围11 primary sinistres true false 100.00%\u key`[\u id==toInclude]`如果没有IN运算符，则需要0.2秒。非常感谢stj！我想知道beta版有多稳定，因为一月份我们必须发布一个带有arangodb的软件，我需要使用in operator进行修复。否则，我必须重写软件这一部分的逻辑。我可以在linux服务器上安装测试版和稳定版吗？我必须只更改数据库的端口吗？再次感谢你。Daniele这取决于您的安装方法。这些软件包通常会替换旧的软件包。但是，您可以创建一个测试包并在其中安装测试包。如果你正在运行debian/ubuntu，你可能会发现它很有用。我们计划在本周发布一个新的2.8测试版。关于稳定性：新的beta版将比前一个更稳定，但它仍然是beta版，目前还不推荐用于生产。

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}