ArangoDB索引在边集合中的使用

Question

任务：更新多个边属性的最快方式。出于性能方面的考虑，我忽略了图形方法，直接使用集合进行过滤。

ArangoDB 2.8b3

查询 [Offer - 边集合]：

FOR O In Offer
FILTER O._from == @from and O._to == @to and O.expired > DATE_TIMESTAMP(@newoffertime)
UPDATE O WITH { expired: @newoffertime } IN Offer
RETURN { _key: OLD._key, prices_hash: OLD.prices_hash }

我在_to、_from上建立了系统索引，同时在expired上建立了范围索引。

查询说明显示：

7   edge   Offer        false    false        49.51 %   [ `_from`, `_to` ]   O.`_to` == "Product/1023058135528"

系统索引仅用于过滤部分记录（_to），而不是同时过滤起始和结束记录（_from，_to），“expired”索引也没有被使用。请解释一下这种行为的原因，并且如果我在规划数据模型时确定要使用哪些索引，则有可能指定最短路径的提示吗？

- Felix Berth

Answer 1

针对您的查询中使用逻辑AND组合的过滤条件，ArangoDB的查询优化器会选择一个单一的索引。这就是为什么它没有同时选择边缘索引和跳表索引的原因。

它会在expired上的跳表索引和["_from", "_to"]上的边缘索引之间进行选择，并选择它确定成本更低的那个，该成本由索引选择性估计值来衡量。正如解释输出所示，它似乎选择了_to上的边缘索引。

边缘索引在内部由两个单独的哈希索引组成，一个在_from属性上，另一个在_to属性上，因此它允许通过_from和_to属性快速访问。但是，它不是["_from", "_to"]上的组合索引，因此不支持同时请求_from和_to的查询。它必须选择其中一个内部哈希索引，并且在该查询中似乎选择了_to上的那个。决策再次基于平均索引选择性。

无法向优化器提供任何索引使用提示 - 除此之外，对于此特定查询，它将无法同时使用两个索引。

从解释输出中的选择性估计来看，边缘索引并不是非常有选择性，这意味着会有很多具有相同_to值的边缘。由于优化器还应该考虑到_from上的索引，我认为该索引的选择性甚至更低，并且每个索引只能帮助跳过最多50％的边缘，这并不是很多。如果实际情况确实如此，则查询仍将检索（和后置过滤）大量文档，从而解释了潜在的缓慢。

目前，在边缘集合的始终存在的边缘索引中自动索引了_from和_to属性，并且不能在其他用户定义的索引中使用它们。

这是我们希望在未来版本中添加的功能，因为通过访问用户定义的索引中的_from和_to，可以创建一个组合（排序）索引["_from", "_to", "expired"]，它可能比任何三个单独的属性索引更具选择性。

- stj