信息聚合系列之近似聚合
摘要
如果所有的數(shù)據(jù)都在一臺機器上，那么生活會容易許多，CS201 課商教的經(jīng)典算法就足夠應(yīng)付這些問題。但如果所有的數(shù)據(jù)都在一臺機器上矢门，那么就不需要像 Elasticsearch 這樣的分布式軟件了。不過一旦我們開始分布式數(shù)據(jù)存儲灰蛙，算法的選擇就需務(wù)必小心祟剔。
版本
elasticsearch版本: elasticsearch-2.x
內(nèi)容
如果所有的數(shù)據(jù)都在一臺機器上，那么生活會容易許多摩梧，CS201 課商教的經(jīng)典算法就足夠應(yīng)付這些問題物延。但如果所有的數(shù)據(jù)都在一臺機器上，那么就不需要像 Elasticsearch 這樣的分布式軟件了仅父。不過一旦我們開始分布式數(shù)據(jù)存儲叛薯，算法的選擇就需務(wù)必小心。
有些算法可以分布執(zhí)行笙纤，到目前為止討論過的所有聚合都是單次請求獲得精確結(jié)果的耗溜。這些類型的算法通常是高度并行的，因為它們無須任何額外代價省容，就能在多臺機器上并行執(zhí)行抖拴。比如當(dāng)計算?max?度量時，以下的算法就非常簡單：
請求廣播到所有分片腥椒。
查看每個文檔的?price?字段阿宅。如果?price > current_max，將?current_max?替換成?price笼蛛。
返回所有分片的最大?price?并傳給協(xié)調(diào)節(jié)點洒放。
找到從所有分片返回的最大?price?。這是最終的最大值滨砍。
這個算法可以隨著機器數(shù)的線性增長而橫向擴展往湿，無須任何協(xié)調(diào)操作（機器之間不需要討論中間結(jié)果），而且內(nèi)存消耗很型锵贰（一個整型就能代表最大值）领追。
不幸的是，不是所有的算法都像獲取最大值這樣簡單日川。更加復(fù)雜的操作則需要在算法的性能和內(nèi)存使用上做出權(quán)衡蔓腐。對于這個問題矩乐，我們有個三角因子模型：大數(shù)據(jù)龄句、精確性和實時性回论。
我們需要選擇其中兩項：
精確 + 實時
數(shù)據(jù)可以存入單臺機器的內(nèi)存之中，我們可以隨心所欲分歇，使用任何想用的算法傀蓉。結(jié)果會 100% 精確，響應(yīng)會相對快速职抡。
大數(shù)據(jù) + 精確
傳統(tǒng)的 Hadoop葬燎。可以處理 PB 級的數(shù)據(jù)并且為我們提供精確的答案缚甩，但它可能需要幾周的時間才能為我們提供這個答案谱净。
大數(shù)據(jù) + 實時
近似算法為我們提供準(zhǔn)確但不精確的結(jié)果。
Elasticsearch 目前支持兩種近似算法（cardinality（基數(shù)）?和?percentiles（百分位數(shù)））擅威。它們會提供準(zhǔn)確但不是 100% 精確的結(jié)果壕探。以犧牲一點小小的估算錯誤為代價，這些算法可以為我們換來高速的執(zhí)行效率和極小的內(nèi)存消耗郊丛。
對于大多數(shù)應(yīng)用領(lǐng)域李请，能夠?qū)崟r返回高度準(zhǔn)確的結(jié)果要比 100% 精確結(jié)果重要得多。乍一看這可能是天方夜譚厉熟。有人會叫“我們需要精確的答案导盅！”。但仔細考慮 0.5% 錯誤所帶來的影響：
99% 的網(wǎng)站延時都在 132ms 以下揍瑟。
0.5% 的誤差對以上延時的影響在正負 0.66ms 白翻。
近似計算會在毫秒內(nèi)放回結(jié)果，而“完全正確”的結(jié)果就可能需要幾秒月培，甚至無法返回嘁字。
只要簡單的查看網(wǎng)站的延時情況，難道我們會在意近似結(jié)果是在 132.66ms 內(nèi)返回而不是 132ms杉畜？當(dāng)然纪蜒，不是所有的領(lǐng)域都能容忍這種近似結(jié)果，但對于絕大多數(shù)來說是沒有問題的此叠。接受近似結(jié)果更多的是一種文化觀念上的壁壘而不是商業(yè)或技術(shù)上的需要纯续。
查找唯一值的數(shù)目（Finding Distinct Counts）
Elasticsearch 提供的首個近似聚合是基數(shù)度量。它提供一個字段的基數(shù)灭袁，即該字段的唯一值的數(shù)目猬错。可能會對 SQL 形式比較熟悉：
SELECTDISTINCT(color)FROMcars
Distinct 計數(shù)是一個普通的操作茸歧，可以回答很多基本的商業(yè)問題：
網(wǎng)站的獨立訪問用戶（UVs）是多少倦炒？
賣了多少種汽車？
每月有多少獨立用戶購買了商品软瞎？
我們可以用基數(shù)度量確定經(jīng)銷商銷售汽車顏色的種類：
GET/cars/transactions/_search? {"size":0,"aggs": {"distinct_colors": {"cardinality": {"field":"color"}? ? ? ? ? }? ? ? }? }
返回的結(jié)果表明已經(jīng)售賣了三種不同顏色的汽車：
..."aggregations": {"distinct_colors": {"value":3}? }...
可以讓我們的例子變得更有用：每月有多少顏色的車被售出逢唤？為了得到這個度量拉讯，我們只需要將一個?cardinality?度量嵌入一個?date_histogram：
GET/cars/transactions/_search? {"size":0,"aggs": {"months": {"date_histogram": {"field":"sold","interval":"month"},"aggs": {"distinct_colors": {"cardinality": {"field":"color"}? ? ? ? ? ? }? ? ? ? ? }? ? ? ? }? ? }? }
學(xué)會權(quán)衡（Understanding the Trade-offs）
正如我們本章開頭提到的，cardinality?度量是一個近似算法鳖藕。它是基于?HyperLogLog++（HLL）算法的魔慷，HLL 會先對我們的輸入作哈希運算，然后根據(jù)哈希運算的結(jié)果中的 bits 做概率估算從而得到基數(shù)著恩。
我們不需要理解技術(shù)細節(jié)（如果確實感興趣院尔，可以閱讀這篇論文），但我們最好應(yīng)該關(guān)注一下這個算法的特性：
可配置的精度喉誊，用來控制內(nèi)存的使用（更精確 ＝ 更多內(nèi)存）邀摆。
對于低基數(shù)集能夠達到高準(zhǔn)確度。
固定的內(nèi)存使用伍茄。即使有幾千或甚至上百億的唯一值隧熙，內(nèi)存的使用也只是依賴于配置里的精度要求。
要配置精度幻林，我們必須指定?precision_threshold?參數(shù)的值贞盯。這個閥值定義了在何種基數(shù)水平下我們希望得到一個近乎精確的結(jié)果。參考以下示例：
GET/cars/transactions/_search? {"size":0,"aggs": {"distinct_colors": {"cardinality": {"field":"color","precision_threshold":100#1}? ? ? ? ? }? ? ? }? }
#1?precision_threshold?接受 0–40,000 之間的數(shù)字沪饺，更大的值還是會被當(dāng)作 40,000 來處理躏敢。
示例會確保當(dāng)字段唯一值在 100 以內(nèi)時會得到非常準(zhǔn)確的結(jié)果。盡管算法是無法保證這點的整葡，但如果基數(shù)在閥值以下件余，幾乎總是 100% 正確的。高于閥值的基數(shù)會開始節(jié)省內(nèi)存而犧牲準(zhǔn)確度遭居，同時也會對度量結(jié)果帶入誤差啼器。
對于指定的閥值，HLL 的數(shù)據(jù)結(jié)構(gòu)會大概使用內(nèi)存?precision_threshold * 8?字節(jié)俱萍，所以就必須在犧牲內(nèi)存和獲得額外的準(zhǔn)確度間做平衡端壳。
在實際應(yīng)用中，100?的閥值可以在唯一值為百萬的情況下仍然將誤差維持 5% 以內(nèi)枪蘑。
速度優(yōu)化（Optimizing for Speed）
如果想要獲得唯一數(shù)目的值损谦，通常需要查詢整個數(shù)據(jù)集合（或幾乎所有數(shù)據(jù)）。所有基于所有數(shù)據(jù)的操作都必須迅速岳颇，原因是顯然的照捡。HyperLogLog 的速度已經(jīng)很快了，它只是簡單的對數(shù)據(jù)做哈希以及一些位操作话侧。
但如果速度對我們至關(guān)重要栗精，可以做進一步的優(yōu)化，因為 HLL 只需要字段內(nèi)容的哈希值悲立，我們可以在索引時就預(yù)先計算好赢赊。就能在查詢時跳過哈希計算然后將數(shù)據(jù)信息直接加載出來级历。
注意
預(yù)先計算哈希值只對內(nèi)容很長或者基數(shù)很高的字段有用叭披，計算這些字段的哈希值的消耗在查詢時是無法忽略的寥殖。
盡管數(shù)值字段的哈希計算是非常快速的嚼贡，存儲它們的原始值通常需要同樣（或更少）的內(nèi)存空間同诫。這對低基數(shù)的字符串字段同樣適用粤策，Elasticsearch 的內(nèi)部優(yōu)化能夠保證每個唯一值只計算一次哈希。
基本上說误窖，預(yù)先計算并不能保證所有的字段都快，它只對那些具有高基數(shù)和內(nèi)容很長的字符串字段有作用柔吼。需要記住的是預(yù)先計算也只是簡單地將代價轉(zhuǎn)到索引時丙唧，代價就在那里想际，不增不減。
To do this, we need to add a new multifield to our data. We’ll delete our index, add a new mapping that includes the hashed field, and then reindex:
要想這么做胡本，我們需要為數(shù)據(jù)增加一個新的多值字段。我們先刪除索引友鼻，再增加一個包括哈希值字段的映射闺骚，然后重新索引：
DELETE/cars/PUT/cars/{"mappings": {"transactions": {"properties": {"color": {"type":"string","fields": {"hash": {"type":"murmur3"#1}? ? ? ? ? ? }? ? ? ? ? }? ? ? ? }? ? ? }? ? }? }? POST/cars/transactions/_bulk? {"index": {}}? {"price":10000,"color":"red","make":"honda","sold":"2014-10-28"}? {"index": {}}? {"price":20000,"color":"red","make":"honda","sold":"2014-11-05"}? {"index": {}}? {"price":30000,"color":"green","make":"ford","sold":"2014-05-18"}? {"index": {}}? {"price":15000,"color":"blue","make":"toyota","sold":"2014-07-02"}? {"index": {}}? {"price":12000,"color":"green","make":"toyota","sold":"2014-08-19"}? {"index": {}}? {"price":20000,"color":"red","make":"honda","sold":"2014-11-05"}? {"index": {}}? {"price":80000,"color":"red","make":"bmw","sold":"2014-01-01"}? {"index": {}}? {"price":25000,"color":"blue","make":"ford","sold":"2014-02-12"}
#1 多值字段的類型是?murmur3僻爽，這是一個哈希函數(shù)。
現(xiàn)在當(dāng)我們執(zhí)行聚合時胸梆，我們使用?color.hash?字段而不是?color?字段：
GET/cars/transactions/_search? {"size":0,"aggs": {"distinct_colors": {"cardinality": {"field":"color.hash"#1}? ? ? ? ? }? ? ? }? }
#1 注意我們指定的是哈希過的多值字段，而不是原始字段兢卵。
現(xiàn)在?cardinality?度量會讀取?"color.hash"?里的值（預(yù)先計算的哈希值），并將它們作為原始值的動態(tài)哈希值秽荤。
每個文檔節(jié)省的時間有限甜奄，但如果哈希每個字段需要 10 納秒而我們的聚合需要訪問一億文檔窃款，那么每個查詢就需要多花 1 秒鐘的時間。如果我們發(fā)現(xiàn)自己在很多文檔都會使用?cardinality?基數(shù)烟阐，可以做些性能分析看是否有必要在我們部署的應(yīng)用中采用預(yù)先計算哈希的方式紊扬。
百分計算（Calculating Percentiles）
Elasticsearch 提供的另外一個近似度量就是?percentiles?百分位數(shù)度量。百分位數(shù)展現(xiàn)某以具體百分比下觀察到的數(shù)值扩淀。例如啤挎，第95個百分位上的數(shù)值，是高于 95% 的數(shù)據(jù)總和胜臊。
百分位數(shù)通常用來找出異常伙判。在（統(tǒng)計學(xué)）的正態(tài)分布下，第 0.13 和 第 99.87 的百分位數(shù)代表與均值距離三倍標(biāo)準(zhǔn)差的值勒魔。任何處于三倍標(biāo)準(zhǔn)差之外的數(shù)據(jù)通常被認為是不尋常的菇曲，因為它與平均值相差太大常潮。
更具體的說，假設(shè)我們正運行一個龐大的網(wǎng)站，而我們的任務(wù)是保證用戶請求能得到快速響應(yīng)萧朝，因此我們就需要監(jiān)控網(wǎng)站的延時來判斷響應(yīng)是否能達到目標(biāo)夏哭。
在此場景下竖配，一個常用的度量方法就是平均響應(yīng)延時，但這是一個不好的選擇（盡管很常用），因為平均數(shù)通常會隱藏那些異常值运悲，中位數(shù)有著同樣的問題班眯。我們可以嘗試最大值，但這個度量會輕而易舉的被單個異常值破壞署隘。
在圖 Figure 40, “Average request latency over time” 查看問題磁餐。如果我們倚靠如平均值或中位數(shù)這樣的簡單度量，就會得到像這樣一幅圖 Figure 40, “Average request latency over time”.
Figure 40. Average request latency over time
一切正常羞延。圖上有輕微的波動脾还，但沒有什么值得關(guān)注的。但如果我們加載 99 百分位數(shù)時（這個值代表最慢的 1% 的延時）嗤谚，我們看到了完全不同的一幅畫面怔蚌，如圖Figure 41, “Average request latency with 99th percentile over time” 所示桦踊。
Figure 41. Average request latency with 99th percentile over time
令人吃驚！在上午九點半時鳄橘，均值只有 75ms。如果作為一個系統(tǒng)管理員术徊，我們都不會看他第二眼鲸湃。一切正常！但 99 百分位告訴我們有 1% 的用戶碰到的延時超過 850ms笋除，這是另外一幅場景炸裆。在上午4點48時也有一個小波動，這甚至無法從平均值和中位數(shù)曲線上觀察到国拇。
這只是百分位的一個應(yīng)用場景惯殊，百分位還可以被用來快速用肉眼觀察數(shù)據(jù)的分布土思，檢查是否有數(shù)據(jù)傾斜或雙峰甚至更多。
百分位度量（Percentile Metric）
讓我加載一個新的數(shù)據(jù)集（汽車的數(shù)據(jù)不太適用于百分位）陕习。我們要索引一系列網(wǎng)站延時數(shù)據(jù)然后運行一些百分位操作進行查看：
POST/website/logs/_bulk? {"index": {}}? {"latency":100,"zone":"US","timestamp":"2014-10-28"}? {"index": {}}? {"latency":80,"zone":"US","timestamp":"2014-10-29"}? {"index": {}}? {"latency":99,"zone":"US","timestamp":"2014-10-29"}? {"index": {}}? {"latency":102,"zone":"US","timestamp":"2014-10-28"}? {"index": {}}? {"latency":75,"zone":"US","timestamp":"2014-10-28"}? {"index": {}}? {"latency":82,"zone":"US","timestamp":"2014-10-29"}? {"index": {}}? {"latency":100,"zone":"EU","timestamp":"2014-10-28"}? {"index": {}}? {"latency":280,"zone":"EU","timestamp":"2014-10-29"}? {"index": {}}? {"latency":155,"zone":"EU","timestamp":"2014-10-29"}? {"index": {}}? {"latency":623,"zone":"EU","timestamp":"2014-10-28"}? {"index": {}}? {"latency":380,"zone":"EU","timestamp":"2014-10-28"}? {"index": {}}? {"latency":319,"zone":"EU","timestamp":"2014-10-29"}
數(shù)據(jù)有三個值：延時址愿、數(shù)據(jù)中心的區(qū)域以及時間戳响谓。讓我們對數(shù)據(jù)全集執(zhí)行百分位操作以獲得數(shù)據(jù)分布情況的直觀感受：
GET/website/logs/_search? {"size":0,"aggs": {"load_times": {"percentiles": {"field":"latency"#1}? ? ? ? ? },"avg_load_time": {"avg": {"field":"latency"#2}? ? ? ? ? }? ? ? }? }
#1?percentiles?度量被應(yīng)用到?latency?延時字段硼啤。
#2 為了比較克锣，我們對相同字段使用?avg?度量辐烂。
默認情況下捂贿，percentiles?度量會返回一組預(yù)定義的百分位數(shù)值：[1, 5, 25, 50, 75, 95, 99]厂僧。它們表示了人們感興趣的常用百分位數(shù)值，極端的百分位數(shù)在范圍的兩邊辰妙，其他的一些處于中部密浑。在返回的響應(yīng)中粗井，我們可以看到最小延時在 75ms 左右，而最大延時差不多有 600ms呆瞻。與之形成對比的是径玖，平均延時在 200ms 左右颤介，信息并不是很多：
..."aggregations": {"load_times": {"values": {"1.0":75.55,"5.0":77.75,"25.0":94.75,"50.0":101,"75.0":289.75,"95.0":489.34999999999985,"99.0":596.2700000000002}? ? },"avg_load_time": {"value":199.58333333333334}? }
所以顯然延時的分布很廣滚朵，然我們看看它們是否與數(shù)據(jù)中心的地理區(qū)域有關(guān)：
GET/website/logs/_search? {"size":0,"aggs": {"zones": {"terms": {"field":"zone"#1},"aggs": {"load_times": {"percentiles": {#2"field":"latency","percents": [50,95.0,99.0]#3}? ? ? ? ? ? ? ? ? },"load_avg": {"avg": {"field":"latency"}? ? ? ? ? ? ? ? ? }? ? ? ? ? ? ? }? ? ? ? ? }? ? ? }? }
#1 首先根據(jù)區(qū)域我們將延時分到不同的桶中。
#2 再計算每個區(qū)域的百分位數(shù)值韵吨。
#3?percents?參數(shù)接受了我們想返回的一組百分位數(shù)移宅，因為我們只對長的延時感興趣。
在響應(yīng)結(jié)果中糠悼，我們發(fā)現(xiàn)歐洲區(qū)域（EU）要比美國區(qū)域（US）慢很多浅乔，在美國區(qū)域（US），50 百分位與 99 百分位十分接近席噩，它們都接近均值。
與之形成對比的是鲁捏，歐洲區(qū)域（EU）在 50 和 99 百分位有較大區(qū)分∠糗剑現(xiàn)在双揪，顯然可以發(fā)現(xiàn)是歐洲區(qū)域（EU）拉低了延時的統(tǒng)計信息，我們知道歐洲區(qū)域的 50% 延時都在 300ms+运吓。
..."aggregations": {"zones": {"buckets": [? ? ? ? ? {"key":"eu","doc_count":6,"load_times": {"values": {"50.0":299.5,"95.0":562.25,"99.0":610.85}? ? ? ? ? ? },"load_avg": {"value":309.5}? ? ? ? ? },? ? ? ? ? {"key":"us","doc_count":6,"load_times": {"values": {"50.0":90.5,"95.0":101.5,"99.0":101.9}? ? ? ? ? ? },"load_avg": {"value":89.66666666666667}? ? ? ? ? }? ? ? ]? ? }? }? ...
百分位等級（Percentile Ranks）
這里有另外一個緊密相關(guān)的度量叫?percentile_ranks疯趟。百分位度量告訴我們落在某個百分比以下的所有文檔的最小值。例如倦青，如果 50 百分位是 119ms盹舞，那么有 50% 的文檔數(shù)值都不超過 119ms踢步。percentile_ranks?告訴我們某個具體值屬于哪個百分位。119ms 的?percentile_ranks?是在 50 百分位述雾。這基本是個雙向關(guān)系兼丰，例如：
50 百分位是 119ms。
119ms 百分位等級是 50 百分位取募。
所以假設(shè)我們網(wǎng)站必須維持的服務(wù)等級協(xié)議（SLA）是響應(yīng)時間低于 210ms蟆技。然后，開個玩笑旺聚，我們老板警告我們?nèi)绻憫?yīng)時間超過 800ms 會把我開除砰粹。可以理解的是弄痹，我們希望知道有多少百分比的請求可以滿足 SLA 的要求（并期望至少在 800ms 以下Ｇ镀鳌）。
為了做到這點蚓让，我們可以應(yīng)用?percentile_ranks?度量而不是?percentiles?度量：
GET/website/logs/_search? {"size":0,"aggs": {"zones": {"terms": {"field":"zone"},"aggs": {"load_times": {"percentile_ranks": {"field":"latency","values": [210,800]#1}? ? ? ? ? ? ? ? ? }? ? ? ? ? ? ? }? ? ? ? ? }? ? ? }? }
#1?percentile_ranks?度量接受一組我們希望分級的數(shù)值讥珍。
在聚合運行后衷佃，我們能得到兩個值：
"aggregations": {"zones": {"buckets": [? ? ? ? ? {"key":"eu","doc_count":6,"load_times": {"values": {"210.0":31.944444444444443,"800.0":100}? ? ? ? ? ? }? ? ? ? ? },? ? ? ? ? {"key":"us","doc_count":6,"load_times": {"values": {"210.0":100,"800.0":100}? ? ? ? ? ? }? ? ? ? ? }? ? ? ]? ? }? }
這告訴我們?nèi)c重要的信息：
在歐洲（EU），210ms 的百分位等級是 31.94% 衰腌。
在美國（US）觅赊，210ms 的百分位等級是 100% 琼稻。
在歐洲（EU）和美國（US）帕翻，800ms 的百分位等級是 100% 。
通俗的說紫岩，在歐洲區(qū)域（EU）只有 32% 的響應(yīng)時間滿足服務(wù)等級協(xié)議（SLA）睬塌，而美國區(qū)域（US）始終滿足服務(wù)等級協(xié)議的歇万。但幸運的是贪磺，兩個區(qū)域所有響應(yīng)時間都在 800ms 以下诅愚，所有我們還不會被炒魷魚（至少目前不會）。
percentile_ranks?度量提供了與?percentiles?相同的信息刹前，但它以不同方式呈現(xiàn)雌桑，如果我們對某個具體數(shù)值更關(guān)心筹燕，使用它會更方便。
學(xué)會權(quán)衡（Understanding the Trade-offs）
和基數(shù)一樣过咬，計算百分位需要一個近似算法制妄。樸素的實現(xiàn)會維護一個所有值的有序列表，但當(dāng)我們有幾十億數(shù)據(jù)分布在幾十個節(jié)點時衔掸，這幾乎是不可能的俺抽。
取而代之的是?percentiles?使用一個 TDigest 算法（由 Ted Dunning 在?Computing Extremely Accurate Quantiles Using T-Digests?里面提出的）磷斧。有了 HyperLogLog，就不需要理解完整的技術(shù)細節(jié)冕末，但有必要了解算法的特性：
百分位的準(zhǔn)確度與百分位的極端程度相關(guān)侣颂，也就是說 1 或 99 的百分位要比 50 百分位要準(zhǔn)確。這只是數(shù)據(jù)結(jié)構(gòu)內(nèi)部機制的一種特性藻肄，但這是一個好的特性，因為多數(shù)人只關(guān)心極端的百分位斗幼。
對于數(shù)值集合較小的情況抚垄，百分位非常準(zhǔn)確呆馁。如果數(shù)據(jù)集足夠小，百分位可能 100% 精確阴挣。
隨著桶里數(shù)值的增長纺腊，算法會開始對百分位進行估算揖膜。它能有效在準(zhǔn)確度和內(nèi)存節(jié)省之間做出權(quán)衡。不準(zhǔn)確的程度比較難以總結(jié)拜隧，因為它依賴于聚合時數(shù)據(jù)的分布以及數(shù)據(jù)量的大小趁仙。
與基數(shù)類似雀费，我們可以通過修改參數(shù)?compression?來控制內(nèi)存與準(zhǔn)確度之間的比值。
TDigest 算法用節(jié)點近似計算百分比：節(jié)點越多律胀，準(zhǔn)確度越高（同時內(nèi)存消耗也越大），這都與數(shù)據(jù)量成正比逛漫。compression?參數(shù)限制節(jié)點的最大數(shù)目為?20 * compression赘艳。
因此，通過增加壓縮比值菩暗，我們可以提高準(zhǔn)確度同時也消耗更多內(nèi)存旭蠕。更大的壓縮比值會使算法運行更慢，因為底層的樹形數(shù)據(jù)結(jié)構(gòu)的存儲也會增長佑稠，也導(dǎo)致操作的代價更高舌胶。默認的壓縮比值是?100疮丛。
一個節(jié)點粗略計算使用 32 字節(jié)的內(nèi)存誊薄，所以在最壞的情況下（例如，大量數(shù)據(jù)有序存入）似袁，默認設(shè)置會生成一個大小約為 64KB 的 TDigest昙衅。在實際應(yīng)用中定鸟，數(shù)據(jù)會更隨機，所以 TDigest 使用的內(nèi)存會更少啼县。
被ES的聚合效率折騰的沒脾氣季眷，轉(zhuǎn)幾篇文章看看
