为了实现类似等价的sql:
SELECT COUNT(DISTINCT deviceID) FROM t_order_report;
为什么我要说类似等价呢? 因为从精确性、性能等角度还是存在很大的差别!
用户可以通过时间、套餐类型、订单状态等等查询条件,过滤出满足条件的设备数信息
因此使用deviceID+各种限制条件 作为Key存储达到去重效果的方式不可行。
AggregationBuilders.cardinality("deviceCount").field("deviceID").precisionThreshold(自定义一个精度范围100-40000)
优点:性能快,亿级别的记录在1秒内完成
缺点:存在只能保证最大40000条记录内的精确,超过的存在5%的误差,不适合需要精确去重场景
AggregationBuilders.terms("deviceCount").field("deviceID").size(Integer.MAX_VALUE);
说明:默认只聚合10个桶,size(Integer.MAX_VALUE)可以指定桶个数
优点:结果精确
缺点:只适合聚合少量桶场景(100以内),否则性能极差(十万级的桶需要分钟级完成)
scroll查询全量数据后手动去重
缺点:性能不达标
pass...
使用聚合方式实现
按 floor distinct,并取出 num 最大的一条记录
{ "size": 0, "aggregations": { "field1": { "terms": { "field": "floor", "size": 20 }, "aggs": { "num_top": { "top_hits": { "_source": true, "size":1, "sort": {"num":"asc"} } } } } } }注:不可以分页
使用 collapse 折叠功能
例如,下面的查询检索 message 中有 elasticsearch 值的 twitter,按喜好数量对它们进行排序并按用户 distinct(取排序后每个用户的第一条数据)。
GET /twitter/_search { "query": { "match": { "message": "elasticsearch" } }, "collapse" : { "field" : "user" }, "sort": ["likes"], "from": 10 }inner_hits
curl -X GET "localhost:9200/twitter/_search" -H 'Content-Type: application/json' -d' { "query": { "match": { "message": "elasticsearch" } }, "collapse" : { "field" : "user", "inner_hits": { "name": "last_tweets", "size": 5, "sort": [{ "date": "asc" }] }, "max_concurrent_group_searches": 4 }, "sort": ["likes"] } '注:仅仅适用于 keyword 和数字类型
按 floor distinct 后总数,使用到了数值度量聚合
{ "aggs": { "distinct": { //该参数 key 随意 "cardinality": { "field": "floor" } } } } // 相应 ... "aggregations" : { "distinct" : { "value" : 20 } }总结:目前elasticsearch 对海量数据去重,支持的并不友好,暂无好的解决方案