术语聚合性能高基数

Question

我希望能对最近观察到的弹性1.5.2中的查询性能做出一些澄清。

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

以下是查询：

{
   "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)，其基数值大致相同。long字段的值实际上是上面相同的字符串字段的预计算哈希值(murmur3)，我用它大大加快了基数聚合。在数值字段上运行相同的术语聚合与global_ordinals_hash一样糟糕。事实上，不管我使用什么执行提示，执行时间都是一样的。

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

谢谢

Answer 1

我认为正式文件和源代码都说明了这一点。首先，需要提到的一件事是，execution_hint正是它的名称所表示的，即只是一个暗示，它将尝试遵守，但如果它认为不合适，它可能不会在所有情况下都这样做。

因此，您有一个高基数字段这一事实就排除了global_ordinals_low_cardinality的使用，因为：

默认情况下，global_ordinals_low_cardinality仅在低基数字段上启用。

至于global_ordinals_hash，它主要用于内部术语聚合(这里不是这样)，map仅在脚本上运行聚合时使用，很少文档与查询匹配(也不包括cas )。

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

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

从这里开始，你会看到：

1. 线201，您的提示被读取，如果字段不支持全局序号(项目205-241)，则可能会被重写。
2. 如果您的字段是数字。，execution_hint被完全忽略，这可能会回答您的问题。