轉(zhuǎn)載自：https://blog.csdn.net/u010454030/article/details/71762838

我們都知道Elasticsearch是一個分布式的搜索引擎囚巴，每個索引都可以有多個分片饥努，用來將一份大索引的數(shù)據(jù)切分成多個小的物理索引毅该，解決單個索引數(shù)據(jù)量過大導(dǎo)致的性能問題，另外每個shard還可以配置多個副本竞慢，來保證高可靠以及更好的抗并發(fā)的能力。

將一個索引切分成多個shard，大多數(shù)時候是沒有問題的，但是在es里面如果索引被切分成多個shard诈胜，在使用group進(jìn)行聚合時，可能會出現(xiàn)問題冯事，這個在官網(wǎng)文檔里焦匈，描述也非常清楚

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html#_shard_size_3

下面就針對官網(wǎng)的例子，描述下桅咆，group count如果有多個shard可能會出現(xiàn)的問題

假設(shè)我們現(xiàn)在括授，我們有一份商品的索引數(shù)據(jù)坞笙，它有3個shard岩饼，每個shard的數(shù)據(jù)如下所示：

image.png

現(xiàn)在我們的需求是，按商品分組求top5的商品薛夜，es收到這個請求后籍茧，會去搜索這三個shard，然后子每個shard上面取top5梯澜，數(shù)據(jù)如下圖所示：

image.png

最后寞冯，將三個shard的top5的數(shù)據(jù)，最后做一下匯聚然后最終排序取top5結(jié)果如下圖：

image.png

最后我們發(fā)現(xiàn)這個top5的結(jié)果晚伙，并不是100%精確的吮龄，只是一個近似精確的結(jié)果值：

Product A在所有top5的shard數(shù)據(jù)里面都存在，所以它的結(jié)果是精確的咆疗， Product C僅僅返回了 shard A 和 C里面的top5的數(shù)據(jù)漓帚，所以這里顯示50是不精確的， Product C在shard B里面也存在午磁，但是它在 top5里面沒有出現(xiàn)尝抖，所以group后的結(jié)果實際上是有誤差的毡们，再來看下 Product Z僅僅返回了2個shards的數(shù)據(jù) 因為第三個里面不存在，所以它的結(jié)果是準(zhǔn)確的昧辽，最后我們注意下 Product H實際上它的總數(shù)是44衙熔，橫跨三個shard 但是它在每個shard的top5里面并沒有出現(xiàn)，所以最終的top5里面也沒有這條數(shù)據(jù)搅荞，這樣看來最終的top5的值并不是100% 準(zhǔn)確的红氯，這一點在設(shè)計和使用es的時候需要特別注意。

雖然我們可以調(diào)大返回size的個數(shù)來提高精確度取具，但是size個數(shù)的提升脖隶，也意味著有更多的數(shù)據(jù)會被返回，從而會導(dǎo)致檢索性能的下降暇检，這一點是需要找到平衡點的产阱。

那么有沒有方法避免這種不精確的統(tǒng)計的呢？

答案是有的块仆，es官網(wǎng)文檔里面也提到构蹬，總共有2種：

第一種：

聚合操作在單個shard時是精確的，也就是說我們索引的數(shù)據(jù)全部插入到一個shard的時候 它的聚合統(tǒng)計結(jié)果是準(zhǔn)確的悔据。

第二種：

在索引數(shù)據(jù)的時候庄敛，使用route路由字段，將所有聚合的數(shù)據(jù)分布到同一個shard即可科汗，這樣再聚合時也是精確的藻烤。

上面的兩種辦法都是可以解決的，第一種適合數(shù)據(jù)量不大的場景下头滔，我們直接把數(shù)據(jù)放在一份索引里面怖亭，第二種辦法適合數(shù)據(jù)量比較大的場景下，我們通過業(yè)務(wù)字段將相同屬性的數(shù)據(jù)路由在同一個shard里面即可坤检，具體使用哪個需要和具體的業(yè)務(wù)場景相結(jié)合兴猩。

總結(jié)：

es雖然很強(qiáng)大，但是在一些場景下也是有局限的早歇，比如上面提到的聚合分組的這個情況倾芝，或者聚合分組+分頁的情況，此外min箭跳，max晨另，sum這些函數(shù)在多個shard中聚合結(jié)果是準(zhǔn)確的，count是近似準(zhǔn)確的谱姓，但是es能保證top 前幾的數(shù)據(jù)是精確的借尿，這也是為什么搜索引擎一般都返回top n數(shù)據(jù)作為最終的返回結(jié)果，當(dāng)然上面提到那個例子逝段，如果聚合的key本來就很少垛玻，那么它的聚合結(jié)果也是準(zhǔn)確的割捅，比如按性別，月份聚合帚桩，因為這些返回的key亿驾，都是有限的，所以結(jié)果沒問題账嚎，但是一旦對分組的個數(shù)沒法確定莫瞬，這種情況下出現(xiàn)問題的幾率就比較大，跨表或者跨分片聚合其實在任何db系統(tǒng)里面都會存在這種問題郭蕉，所以我們應(yīng)該盡量在設(shè)計業(yè)務(wù)時就考慮到這種特殊情況疼邀，然后最終做特殊處理。
————————————————
版權(quán)聲明：本文為CSDN博主「三劫散仙」的原創(chuàng)文章召锈，遵循CC 4.0 BY-SA版權(quán)協(xié)議旁振，轉(zhuǎn)載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/u010454030/article/details/71762838