項目中，Elastatic search（下面簡稱ES）用於數據存儲和分析。
項目中的存儲的對象有包含關係。
A對象是B對象的集合，即一個A對象包含多個屬於A對象的B對象。在前端展示的時候，需要分別對A和B級別進行查詢彙總。設計的時候，考慮到儘可能的減少存儲量又能滿足各種查詢條件，決定以B爲單位進行存儲，同時B對象擁有屬性Aid，用於表示B的歸屬。
在普通sql數據庫中如此存儲不會有什麼問題，使用distinct可以做到去重查詢，通過對Aid的去重能夠得到A的數量。ES也支持去重查詢，使用cardinality即可。但是，沒有想到的是，ES的去重，只有在基數在100-40000之間纔可以保證基本的查詢準確率。
官方文檔的描述如下：
This example will ensure that fields with 100 or fewer distinct values will be extremely accurate. Although not guaranteed by the algorithm, if a cardinality is under the threshold, it is almost always 100% accurate. Cardinalities above this will begin to trade accuracy for memory savings, and a little error will creep into the metric.
For a given threshold, the HLL data-structure will use about precision_threshold * 8 bytes of memory. So you must balance how much memory you are willing to sacri‐ fice for additional accuracy.
Practically speaking, a threshold of 100 maintains an error under 5% even when counting millions of unique values.
結論：ES的去重，同數據庫查詢的distinct。在基數爲100-40000的前提下，能夠基本準確。且不管查詢的文檔量是多少，即便是百萬級也能夠保證錯誤率在5%以下。（基數的概念，比如咱們用事務id做去重，查詢結果中不同事務id的數量即爲基數）。另外，去重的使用更加消耗內存）
目前，筆者尚無有效的解決辦法。如有解決方案，懇請賜教。