performance - 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 上有系统索引，在过期时有范围索引

查询说明显示

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

系统索引仅用于过滤部分记录 (_to)，而不用于两者 (_from, _to)，'expired' 索引也未使用。请向我解释这种行为的原因，如果我在规划数据模型时确定知道，是否有可能指定要用于最短路径的索引提示？

Answer 1

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

它将在 expired 的 skiplist 索引和 [ "_from", "_to"] 的边缘索引之间进行选择，并将选择一个它决定了较低的成本，这是通过指数选择性估计来衡量的。正如解释输出所示，它似乎选择了 _to 上的边缘索引。

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

没有办法向优化器提供任何索引使用提示——除此之外，它不能为这个特定查询同时使用两个索引。

查看解释输出中的选择性估计，边缘索引似乎不是很有选择性，这意味着会有很多具有相同 _to 值的边缘。由于优化器还应该考虑 _from 上的索引，因此我假设索引的选择性更低，并且这些索引中的每一个最多只能帮助跳过 50% 的边缘，这不是很多。如果确实如此，那么查询仍将检索(和后过滤)大量文档，这解释了潜在的缓慢。

目前，属性 _from 和 _to 自动在边缘集合的始终存在的边缘索引中建立索引，它们不能用于其他用户定义的索引. 这是我们希望在未来版本中添加的一项功能，因为 _from 和 _to 可用于用户定义的索引，因此可以创建组合(排序) [ "_from", "_to", "expired"] 上的索引，这可能比孤立的三个单属性索引中的任何一个都更具选择性。