首页 文章

ArangoDB索引用于边集合

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

performance indexing arangodb aql

1 回答

  • 3

    对于在查询中结合逻辑AND的过滤条件，ArangoDB 's query optimizer will pick a single index. This is the reason why it hasn' t同时选取了边缘索引 and skiplist索引 .

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

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

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

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

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

    回复于

相关问题