performance - 术语聚合性能高基数

Question

我希望对最近观察到的 flex 1.5.2中的查询性能进行一些说明。

我有一个具有高基数(大约200,000,000)的字符串字段。
我观察到，如果我使用带有执行提示global_ordinals_low_cardinality的简单术语聚合，则会发生两件事:
1.查询返回的结果与global_ordinals或global_ordinals_hash相同。
2.查询执行明显更快。 (大约是global_ordinals的两倍，是global_ordinals_hash的四倍。

这是查询:

{
   "aggs": {
      "myTerms": {
         "terms": {
            "field": "myField",
            "size": 1000,
            "shard_size": 1000,
            "execution_hint": "global_ordinals_low_cardinality"
         }
      }
   }
}

我不明白为什么在这种情况下使用global_ordinals_low_cardinality甚至是合法的，因为我的字段具有很高的基数。所以也许我不明白global_ordinals_low_cardinality到底是什么意思？

其次，我还有另一个数值字段(长整数)，其基数值大致相同。
long字段的值实际上是从上方针对同一字符串字段的预先计算的哈希值(murmur3)，我使用它可以大大加快基数聚合。
在数字字段上运行相同的术语聚合的效果与global_ordinals_hash一样糟糕。
实际上，我使用什么执行提示都没有关系，执行时间保持不变。

那么，为什么global_ordinals_low_cardinality适用于字符串类型，而不适用于长类型？是否因为数字字段根本不需要全局序数？

谢谢

Answer 1

我认为official documentation和源代码都对此有所启发。首先，需要提到的一件事是execution_hint就是它的名字，即只是ES会尝试遵守的提示，但如果认为不合适，可能并非在所有情况下都适用。

因此，仅具有高基数字段的事实就排除了global_ordinals_low_cardinality的使用，因为:

global_ordinals_low_cardinality is only enabled by default on low-cardinality fields.

至于 global_ordinals_hash，它主要用于内部术语聚合(此处不是这种情况)，并且 map仅在对脚本运行聚合并且很少有文档与查询匹配时使用(也不是cas)。

因此，您只有一个选择，即 global_ordinals，这是顶级术语聚合中使用的默认提示。

如前所述， execution_hint只是您指定的提示，但是无论如何，ES都会尽力为数据选择正确的执行模式。对源代码的研究很有启发性，并为以下几点提供了一些启示:

Starting here，您将看到:

on line 201，您的提示已被读取，如果该字段不支持全局序数(lines 205-241)

，则可能会被覆盖

如果您的field is numeric，execution_hint被完全忽略，则可能可以回答您的问题。