使用预先计算的哈希值进行ElasticSearch基数聚合(无杂音3)

v8wbuo2f  于 6个月前  发布在  ElasticSearch
关注(0)|答案(1)|浏览(71)

根据ElasticSearch文档,您可以通过在索引文档之前预先计算哈希来提高基数聚合的性能。文档建议使用mapper-murmur 3插件,然而,它也指定您可以从客户端无需插件即可完成此操作。我有一个高基数字符串/关键字字段,我正在对其运行基数聚合,我想探索预处理的方法。计算哈希 * 没有 * 杂音3插件.
我的问题如下:
1.如果我们在索引之前预先计算哈希值,那么索引文档中哈希值的数据类型是否重要?是否需要将其哈希为长型或数字型值/字段,或者基于字符串的关键字字段可以吗?
1.如果哈希值存储在基于字符串的关键字中,ElasticSearch如何知道它不需要计算该值的哈希值?如果该值被索引为字符串/关键字字段,该值看起来不像任何其他字符串字段吗?
1.最后,预计算哈希对基数聚合的内存使用有意义的影响吗?或者主要是速度?我的直觉是,预计算哈希不会使用更少的内存,因为它只是删除了必须对每个唯一值计算哈希的步骤,但我想我会要求更好地了解它在幕后做什么。
谢谢你,谢谢

omvjsjqw

omvjsjqw1#

在Elasticsearch 2.x之前的版本中(最高1.7),cardinality聚合用于提供rehash: true/false flag,允许您指定是否需要在搜索时对基数聚合运行的字段的值进行散列。这用于字段值已经由客户端代码散列并以散列方式存储/索引的情况。但是,这个选项在2.x中消失了,因为mapper-murmur3 plugin was introduced作为散列被认为是便宜的。
关于Murmur 3,您需要知道的是,它是一个成熟的field type called murmur3,通常用作子字段,它会自动将父字段的值散列为数字散列(而不是基于字符串的,如UUID,SHA 256或MD5)。此外,通常只有在高基数keyword字段上使用murmur3哈希字段才有意义,但不是在数值字段或低基数keyword字段上,因为增益可以忽略不计,同时增加了磁盘使用量。
因此,如果你决定使用自己的哈希函数预先计算哈希值,你有两个选择:
1.你可以使用一个哈希函数,它产生一个数字哈希值,类似于Murmur 3所做的。
1.你可以使用一个哈希函数来产生一个字符串哈希值,如果你想直接使用这个值而不需要对它进行哈希处理,你可以配置一个特定的execution_hint,称为directavailable since 8.4),在这种情况下,它的行为方式与数字哈希完全相同,比如Murmur 3。
使用direct执行提示对基于字符串的哈希字段进行聚合查询的示例:

GET test/_search
{
  "size": 0,
  "aggs": {
    "count": {
      "cardinality": {
        "field": "hash_field",
        "execution_hint": "direct"         <---- add this
      }
    }
  }
}

字符串
CardinalityAggregator类的源代码中直接查看拾取是如何工作的也很有趣。
我想这应该回答了你上面所有的问题。

相关问题