ArangoDB索引用于边集合

Question

任务：更新许多边缘属性的最快方法。 出于性能原因，我忽略了图形方法并直接使用集合进行过滤。

ArangoDB 2.8b3

查询[优惠 - 边缘集合]：

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），'过期'索引也不使用。 请解释一下这种行为的原因，如果我在规划数据模型时肯定知道的话，有可能指定用于最短路径的索引提示吗？

Answer 1

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

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

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

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

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

目前，属性_from和_to在边集合的始终存在的边缘索引中自动编入索引，并且它们不能用于其他用户定义的索引中。 这是我们希望在将来的版本中添加的功能，因为_from和_to可以访问用户定义的索引，可以在[ "_from", "_to", "expired" ]上创建组合（排序）索引[ "_from", "_to", "expired" ]这将是比任何单独的三个单属性索引的潜在更具有选择性。