4

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

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)，“过期”索引也未使用。请向我解释这种行为的原因，如果我在规划数据模型时确定，是否有可能指定用于最短路径的索引提示？

4

1 回答 1

3

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

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

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

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

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

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

于 2016-01-04T19:19:26.767 回答