根据ElasticSearch文档,您可以通过在索引文档之前预先计算哈希来提高基数聚合的性能。文档建议使用mapper-murmur 3插件,然而,它也指定您可以从客户端无需插件即可完成此操作。我有一个高基数字符串/关键字字段,我正在对其运行基数聚合,我想探索预处理的方法。计算哈希 * 没有 * 杂音3插件.
我的问题如下:
1.如果我们在索引之前预先计算哈希值,那么索引文档中哈希值的数据类型是否重要?是否需要将其哈希为长型或数字型值/字段,或者基于字符串的关键字字段可以吗?
1.如果哈希值存储在基于字符串的关键字中,ElasticSearch如何知道它不需要计算该值的哈希值?如果该值被索引为字符串/关键字字段,该值看起来不像任何其他字符串字段吗?
1.最后,预计算哈希对基数聚合的内存使用有意义的影响吗?或者主要是速度?我的直觉是,预计算哈希不会使用更少的内存,因为它只是删除了必须对每个唯一值计算哈希的步骤,但我想我会要求更好地了解它在幕后做什么。
谢谢你,谢谢
1条答案
按热度按时间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
,称为direct
(available since 8.4),在这种情况下,它的行为方式与数字哈希完全相同,比如Murmur 3。使用
direct
执行提示对基于字符串的哈希字段进行聚合查询的示例:字符串
在
CardinalityAggregator
类的源代码中直接查看拾取是如何工作的也很有趣。我想这应该回答了你上面所有的问题。