Arangodb 斯基普利斯特的慢排序？

我显然遗漏了一些东西，当我运行以下查询时，我得到了40毫秒的响应：

FOR t IN tt
FOR a in aa 
FILTER a.from._key == t._key
AND a.value == @v
LIMIT 20 RETURN t

但是，当我添加排序时，查询将一直运行，直到我必须终止它

FOR t IN tt
FOR a in aa
FILTER a.from._key == t._key
AND a.value == @v
SORT t.identifier.value ASC
LIMIT 20 RETURN t

我在identifier.value上有skiplist索引，但当我查看执行计划时，我看到一个可怕的完整集合扫描

2 EnumerateCollectionNode 240126 - FOR t IN tt   /* full collection scan */ 

我有250000份tt文档，如：

{
  “_key”: "CA0350ED-4929-3D1A-37A5-8AB951CE3AB5"
  "type": “f.g.h”,
  "identifier": {
    “dist”: “N”,
    "value": "Matt100145 ZZZ"
  }
}

以及500000份aa格式的文件，如：

{
  “_key”: "1BBDE335-B118-3ED5-DE3B-77D822822210"
  "type": “a.b.c”,
  "from": {
    "_key": "CA0350ED-4929-3D1A-37A5-8AB951CE3AB5",
    "value": "Matt100145 ZZZ”
    }
  },
  "value": “ZZZ”
}

tt中的所有identifier.value值都是MattNUMBER ZZZ（测试数据），所以这可能是造成问题的原因

没有排序的查询计划如下所示：

Execution plan:
 Id   NodeType        Est.   Comment
  1   SingletonNode      1   * ROOT
  9   IndexNode          2     - FOR a IN aa   /* hash index scan */
  8   IndexNode          2       - FOR t IN tt   /* primary index scan */
  6   LimitNode          2         - LIMIT 0, 20
  7   ReturnNode         2         - RETURN t

Indexes used:
 By   Type      Collection   Unique   Sparse   Selectivity   Fields        Ranges
  9   hash      aa   false    false        50.00 %   [ `value` ]   (a.`value` == "Matt123")
  8   primary   tt       true     false       100.00 %   [ `_key` ]    (a.`from`.`_key` == t.`_key`)

Execution plan:
 Id   NodeType                   Est.   Comment
  1   SingletonNode                 1   * ROOT
  2   EnumerateCollectionNode   85706     - FOR t IN tt   /* full collection scan */
  6   CalculationNode           85706       - LET #4 = t.`identifier`.`value`   /* attribute expression */   /* collections used: t : tt */
 10   IndexNode                 85706       - FOR a IN aa   /* hash index scan */
 11   CalculationNode           85706         - LET #2 = (a.`value` == "Matt123")   /* simple expression */   /* collections used: a : aa */
  5   FilterNode                85706         - FILTER #2
  7   SortNode                  85706         - SORT #4 ASC
  8   LimitNode                    20         - LIMIT 0, 20
  9   ReturnNode                   20         - RETURN t

Indexes used:
 By   Type   Collection   Unique   Sparse   Selectivity   Fields            Ranges
 10   hash   aa   false    false        50.00 %   [ `from._key` ]   (a.`from`.`_key` == t.`_key`)

而排序如下所示：

Execution plan:
 Id   NodeType        Est.   Comment
  1   SingletonNode      1   * ROOT
  9   IndexNode          2     - FOR a IN aa   /* hash index scan */
  8   IndexNode          2       - FOR t IN tt   /* primary index scan */
  6   LimitNode          2         - LIMIT 0, 20
  7   ReturnNode         2         - RETURN t

Indexes used:
 By   Type      Collection   Unique   Sparse   Selectivity   Fields        Ranges
  9   hash      aa   false    false        50.00 %   [ `value` ]   (a.`value` == "Matt123")
  8   primary   tt       true     false       100.00 %   [ `_key` ]    (a.`from`.`_key` == t.`_key`)

Execution plan:
 Id   NodeType                   Est.   Comment
  1   SingletonNode                 1   * ROOT
  2   EnumerateCollectionNode   85706     - FOR t IN tt   /* full collection scan */
  6   CalculationNode           85706       - LET #4 = t.`identifier`.`value`   /* attribute expression */   /* collections used: t : tt */
 10   IndexNode                 85706       - FOR a IN aa   /* hash index scan */
 11   CalculationNode           85706         - LET #2 = (a.`value` == "Matt123")   /* simple expression */   /* collections used: a : aa */
  5   FilterNode                85706         - FILTER #2
  7   SortNode                  85706         - SORT #4 ASC
  8   LimitNode                    20         - LIMIT 0, 20
  9   ReturnNode                   20         - RETURN t

Indexes used:
 By   Type   Collection   Unique   Sparse   Selectivity   Fields            Ranges
 10   hash   aa   false    false        50.00 %   [ `from._key` ]   (a.`from`.`_key` == t.`_key`)

---

有人能帮忙吗？

在您的案例中，不清楚这两个集合上实际有哪些索引。提到了一个索引，但要运行良好，两个索引会更好。 以下是我使用的设置：

db.tt.ensureIndex({ type: "skiplist", fields: ["identifier.value"] });
db.aa.ensureIndex({ type: "skiplist", fields: ["value"] });

通过此设置和一些示例数据，我从ArangoDB 3.3.12获得的执行计划是：

查询字符串： 对于tt中的t，对于aa中的过滤器a.from.\u key==t.\u key和a.value==v LIMIT 20返回t

Execution plan:
 Id   NodeType         Est.   Comment
  1   SingletonNode       1   * ROOT
  9   IndexNode       25000     - FOR a IN aa   /* skiplist index scan */
  8   IndexNode       25000       - FOR t IN tt   /* primary index scan */
  6   LimitNode          20         - LIMIT 0, 20
  7   ReturnNode         20         - RETURN t

Indexes used:
 By   Type       Collection   Unique   Sparse   Selectivity   Fields        Ranges
  9   skiplist   aa           false    false            n/a   [ `value` ]   (a.`value` == 123)
  8   primary    tt           true     false       100.00 %   [ `_key` ]    (a.`from`.`_key` == t.`_key`)

这似乎是一个很好的执行计划。你能检查一下这些索引对你的情况是否也有帮助吗

---

（注意：下次请发布您创建的所有索引以及完整的执行计划，而不仅仅是一个片段-这样您可能会得到更精确的帮助）

请添加一个数据示例以及您拥有的文档数量。我已经用您要求的详细信息更新了问题-谢谢！还有一些问题：aa中有多少文档引用tt中的文档键？对于500k和250k文档，aa中是否有两个文档平均引用同一tt密钥？它总是像2，1，3，0，4吗？总体分布情况如何？有几千个aa文档用于几个tt键，而其他的只有1:1的对应关系吗？因为这是唯一的测试数据，我在aa中设置了两个文档，它们引用相同的tt。实际上，它可能是10或20而不是2，但在aa中总是比tt多。我也有关于值的索引。我已经升级到3.3.12（我在3.3.4上），并且我有与您相同的查询计划。然而，当我添加排序时，它是慢的，即SORT t.identifier.value ASC。我在原始问题中添加了带有排序的查询计划。我刚刚注意到，如果我将顺序切换为aa中的a，那么对于tt中的t，我在排序查询中获得了很好的性能？？？