白话Elasticsearch47-深入聚合数据分析之Cardinality Aggs-cardinality算法之优化内存开销以及HLL算法
文章目錄
- 概述
- 官方說明
- precision_threshold優化準確率和內存開銷
- HyperLogLog++ (HLL)算法性能優化
概述
繼續跟中華石杉老師學習ES,第47篇
課程地址: https://www.roncoo.com/view/55
官方說明
Cardinality Aggregation:戳這里
precision_threshold優化準確率和內存開銷
原始數據:
統計下有多少個不同的品牌
DSL:
GET /tvs/sales/_search {"size" : 0,"aggs" : {"distinct_brand" : {"cardinality" : {"field" : "brand","precision_threshold" : 100 }}} } 注意下 "precision_threshold" : 100 的意思是: brand去重,如果brand的unique value,在100個以內,小米,長虹,三星,TCL,HTL。。。 在多少個unique value以內,cardinality,幾乎保證100%準確 。
cardinality算法,會占用precision_threshold * 8 byte 內存消耗,100 * 8 = 800個字節 占用內存很小。。。而且unique value如果的確在值以內,那么可以確保100%準確
precision_threshold,值設置的越大,占用內存越大, 假設設置 1000,那么1000 * 8 = 8000 / 1000 = 8KB,可以確保更多unique value的場景下,100%的準確
field,去重,count,這時候,unique value,10000, precision_threshold=10000,10000 * 8 = 80000個byte,80KB
HyperLogLog++ (HLL)算法性能優化
cardinality底層算法:HLL算法,HLL算法的性能會對所有的uqniue value取hash值,通過hash值近似去求distcint count,存在誤差 .
默認情況下,發送一個cardinality請求的時候,會動態地對所有的field value,取hash值;
優化的話: 將取hash值的操作,前移到建立索引的時候 ,如下
PUT /tvs/ {"mappings": {"sales": {"properties": {"brand": {"type": "text","fields": {"hash": {"type": "murmur3" }}}}}} }這樣在執行同樣的查詢的話,就不會在請求的時候執行hash值了。
GET /tvs/sales/_search {"size" : 0,"aggs" : {"distinct_brand" : {"cardinality" : {"field" : "brand.hash","precision_threshold" : 100 }}} }總結
以上是生活随笔為你收集整理的白话Elasticsearch47-深入聚合数据分析之Cardinality Aggs-cardinality算法之优化内存开销以及HLL算法的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 白话Elasticsearch46-深入
- 下一篇: 白话Elasticsearch48-深入