ElasticSearch-- terms和cardinality 的区别

最新推荐文章于 2025-06-11 09:07:30 发布

风和箫音

最新推荐文章于 2025-06-11 09:07:30 发布

阅读量3.5k

点赞数 1

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/qq_34171923/article/details/88130833

本文深入解析了Elasticsearch中的聚合查询功能，包括terms聚合用于统计各分组出现频率，及cardinality聚合实现去重计数，如统计不同班级数量。通过具体示例，帮助读者理解并掌握ES查询技巧。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

terms:聚合分组，类似于sql中group by，结果为每个单位出现的次数，需要给定size值，不然默认最大为10

"aggs": {
    "classid": {
      "terms": {
        "field": "classid",
        "size": 10
      }
    }
  }

查询结果：

cardinality: 去重，类似于sql中distinct ,结果为单位数量，

如查询共有多少个班级：

"aggs": {
    "classid": {
      "cardinality": {
        "field": "classid"
      }
    }
  }

查询结果：

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

风和箫音

关注关注

1
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

【实战ES】实战 Elasticsearch：快速上手与深度实践-5.4.2用户画像聚合（Terms Aggregation + Cardinality）

kngines

03-10

1062

【实战ES】实战 Elasticsearch：快速上手与深度实践-5.4.2用户画像聚合（Terms Aggregation + Cardinality）

elasticsearch-PHP aggs聚合，去重，对聚合结果删除某些列

m0_37684037的博客

12-04

1247

1、根据某个字段聚合 // 聚合字段 $params['aggs']['groupByCondition']['terms'] = [ 'field' => $aggsField, 'size' => $num, 'order' ...

参与评论您还未登录，请先登录后发表或查看评论

ElasticSearch-- terms和cardinality 的区别

qq_41611829的博客

04-13

885

terms:聚合分组，类似于sql中group by，结果为每个单位出现的次数，需要给定size值，不然默认最大为10 cardinality: 去重，类似于sql中distinct ,结果为单位数量，如查询共有多少个班级： ...

一次业务问题对ES的cardinality原理探究

WCCchangchun的博客

07-24

2321

记一次业务问题对Elasticsearch的cardinality原理探究，原来cardinality是这么玩的，学习了！

Elasticsearch权威指南：基数聚合（Cardinality）深度解析

gitblog_00021的博客

06-11

416

Elasticsearch权威指南：基数聚合（Cardinality）深度解析什么是基数聚合基数聚合（Cardinality Aggregation）是Elasticsearch提供的一种近似统计算法，用于计算字段中不同值的数量（即基数）。这种聚合在业务分析中非常实用，能够回答诸如"网站有多少独立访客"、"每月有多少独立用户购买产品"等关键业务问题。基...

ES--cardinality(统计去重) top_hits(内容去重) 的简单使用

xinji

07-06

6374

统计去重 cardinality ## 对时间范围内sn 考勤的人员身份证去重 GET /hw-attendance-aliases/_search { "query": { "bool": { "must": [ { "terms": { "sn.keyword": ["5043517855901153563I","5043517855901153563O"] } }, .

Elasticsearch 之（27）cardinality算法之优化内存开销以及HLL算法

weixin_30555125的博客

05-28

696

1、cardinality语法es，去重，cartinality metric，对每个bucket中的指定的field进行去重，取去重后的count，类似于count(distcint)cardinality，count(distinct)，5%的错误率，性能在100ms左右{ "size" : 0, "aggs" : { "months" :...

ES cardinality 去重计数不准确的问题

upupfeng的博客

05-29

6786

记录 es在使用cardinality实现count(distinct)时会在准确性和及时性上做一定的取舍可以在使用cardinality时，配置下面的参数来增加准确性，牺牲的是时间和内存 percision_threshold : 40000 ...

【ElasticSearch-聚合查询】ES聚合统计及springboot对比实现

qq_42890164的博客

01-26

3555

一文详解Elasticsearch中涉及的桶聚合、指标聚合、管道聚合及其所属各类函数使用及springboot对比实现

elasticsearch-query-builder, 一款可以基于配置化以及参数绑定的ES语句构造神器

死神的精度

12-12

1772

Elasticsearch---(4)Elasticsearch DSL常用语法

Mr.Cao

05-13

1655

3、 Elasticsearch DSL常用语法数据准备 # 创建索引，设置分片副本，配置映射 PUT /demo { "settings":{ "number_of_replicas": 1, "number_of_shards": 3 }, "mappings":{ "user":{ "properties":{ "name":{"type":"text"}, "age":{"type":"integer"},

【es】cardinality 计算不准确问题

IT零起步 — 专注运维、开发、信息安全!

09-27

9044

遇到问题：两个结果不一样，按说是一样的结果一： { "query": { "bool": { "must_not": [ { "match_phrase": { "reqUA": "Jakarta Commons-HttpClient/3.1" } },

elasticsearch去重计数（distinct）

最新发布

07-01

<think>我们被要求在不使用composite聚合的情况下实现terms聚合的分批返回（分页）。在Elasticsearch7中，terms聚合本身不支持分页，但我们可以通过分区（partition）的方式来实现类似分页的效果。根据引用[1]中的说明：如果我们想要获取所有词项（terms）或者嵌套词项聚合中的所有组合，应该使用composite聚合，它允许对所有可能的词项进行分页。而terms聚合旨在返回最顶部的词项（top terms）并且不支持分页。但是，我们可以通过分区（partition）的方式来分批获取。在之前的回答中，我们已经介绍了使用terms聚合的分区（partition）参数来实现分批处理。具体来说，我们可以将整个词项集合分成多个分区（num_partitions），然后分别对每个分区进行聚合，最后合并结果。因此，我们可以这样实现：1.确定总的分区数（num_partitions）。这个值需要根据字段的基数（cardinality）来估计，通常可以设置为一个较大的值（比如10或20），但要注意分区数越多，请求次数越多，但每次请求返回的桶数越少。2.循环遍历每个分区（从0到num_partitions-1），每次请求获取一个分区的词项聚合结果。3.合并所有分区的结果。注意：这种方式要求字段是keyword类型或者开启了fielddata的text类型。具体步骤：步骤1：构建带有分区的terms聚合在terms聚合中，使用`include`参数并指定`partition`和`num_partitions`。例如，对于分区0（总共5个分区）：```json{"aggs": {"my_terms":{"terms": {"field":"my_field","size":1000,#每个分区的返回桶数，可以设置得足够大以覆盖该分区内的所有词项"include": {"partition":0,"num_partitions":5}}}} }```步骤2：依次请求每个分区步骤3：合并所有分区的结果但是，这种方式有几个注意事项：-由于每个分区是独立请求的，所以无法保证全局的排序（比如按照文档计数降序）。因此，如果需要全局排序，需要在所有分区返回后自行排序。-分区数（num_partitions）的选择：如果设置得太小，每个分区的桶数可能仍然很多（超过size限制，导致不精确）；如果设置得太大，则请求次数过多。建议根据字段的基数来设置，比如基数除以1000（每个分区期望的桶数）得到分区数，然后向上取整。另外，引用[4]中展示了composite聚合的用法，但我们这里不使用它。因此，我们可以用Java代码实现如下（假设我们不知道基数，先设置一个固定的分区数，比如10）：```javaintnumPartitions =10; //总分区数Map<String,Long>allBuckets =new HashMap<>();for (int partition=0;partition <numPartitions;partition++){//构建聚合TermsAggregationBuilder aggregation= AggregationBuilders.terms("my_terms").field("my_field").size(10000) //设置足够大，确保每个分区的桶都能返回.includeExclude(newIncludeExclude(partition,numPartitions));//设置分区SearchSourceBuilder sourceBuilder =new SearchSourceBuilder();sourceBuilder.aggregation(aggregation);sourceBuilder.size(0);//不需要返回原始文档SearchRequestsearchRequest= newSearchRequest("your_index");searchRequest.source(sourceBuilder);SearchResponseresponse =client.search(searchRequest, RequestOptions.DEFAULT);Termsterms =response.getAggregations().get("my_terms");for(Terms.Bucketbucket :terms.getBuckets()) {allBuckets.put(bucket.getKeyAsString(),bucket.getDocCount());} }//现在allBuckets包含了所有的词项和文档计数//如果需要按照文档计数排序，可以这样： List<Map.Entry<String, Long>> sortedBuckets= newArrayList<>(allBuckets.entrySet()); sortedBuckets.sort(Map.Entry.comparingByValue(Comparator.reverseOrder())); //然后就可以分批返回给用户（比如每页100条）int pageSize =100; inttotalPages= (sortedBuckets.size() +pageSize-1)/ pageSize;for (int page=0;page <totalPages; page++) {intfrom= page* pageSize;intto =Math.min(from +pageSize, sortedBuckets.size());List<Map.Entry<String, Long>> pageList= sortedBuckets.subList(from,to);//输出这一页的数据} ```但是，上述方法在字段基数非常大的情况下可能会遇到内存问题，因为我们在内存中保存了所有的桶。如果基数极大（比如百万级），那么内存占用会很高。替代方案：如果我们只是需要分页展示（而不是一次性获取所有桶），那么我们可以不保存所有桶，而是每次只获取一个分区的数据，然后在前端进行分页。但是这样前端需要保存所有数据，也不理想。另一种思路：我们可以将分区数设置得和页数一样多，然后每次请求一个分区（即一页）。但是，这样要求我们事先知道总页数（即总桶数），而总桶数（基数）我们可以通过cardinality聚合先获取。步骤：1.先执行一次cardinality聚合得到字段的基数（假设为C）。2.设置分区数（num_partitions）为 totalPages =(C +pageSize-1)/ pageSize。3.然后，当用户请求第page页（从0开始）时，我们就请求第page个分区（注意分区号从0到totalPages-1）。但是，这样有一个问题：每个分区内的桶数并不一定等于pageSize，因为桶的分布可能不均匀（每个分区包含的词项数量可能不同）。而且，同一个词项只会在一个分区中出现，所以每个分区的桶数可能少于pageSize。因此，我们可能需要调整：让每个分区的桶数尽可能接近pageSize，但是这样很难精确控制。而且，分区算法是基于词项的哈希值取模，所以每个分区的桶数大致相等，但不完全相等。所以，我们可以这样：-先获取基数C，然后设置num_partitions= (C +pageSize-1)/ pageSize （即总页数）。-然后，对于第page页，我们请求第page个分区（分区号=page），然后返回该分区的所有桶（我们设置size=pageSize，但实际上可能返回少于pageSize个桶，因为该分区内的桶数可能不够）。但是，这样会导致每一页的桶数不稳定，而且可能有些分区桶数很少，有些很多。因此，更推荐第一种方法：一次性获取所有桶（通过分区循环），然后在内存中分页。这种方法适用于基数不是特别大的情况（比如几万到几十万）。如果基数非常大（百万级），则建议使用composite聚合。由于问题要求不使用composite聚合，所以我们只能使用分区方式。总结：在Elasticsearch7中，terms聚合不支持分页，但可以通过分区（partition）的方式分批获取所有词项，然后在应用程序内存中进行分页。注意：分区方式在字段基数非常大的情况下可能会对集群造成压力（因为需要执行多次聚合查询），并且内存消耗较大。因此，如果可能的话，升级到支持composite聚合的版本（composite聚合在Elasticsearch6.1+就支持了，所以Elasticsearch7是支持的）并使用composite聚合是更好的选择。但既然问题要求不使用composite，我们就用分区方式。引用[1]也提到：terms聚合用于返回最顶部的词项，而composite用于分页获取所有词项。所以，如果必须使用terms聚合，分区是唯一的内置方法。最后，关于如何动态确定分区数（num_partitions）的问题，我们可以通过以下步骤：1.先获取字段的基数（cardinality）。2.根据基数和我们期望的每分区桶数（比如1000）来计算分区数：num_partitions= (cardinality +999) /1000。这样，每个分区最多返回1000个桶，可以避免单个聚合返回太多桶。示例代码（获取基数）：```javaCardinalityAggregationBuildercardinalityAgg =AggregationBuilders.cardinality("cardinality").field("my_field"); SearchSourceBuildersourceBuilder= newSearchSourceBuilder();sourceBuilder.aggregation(cardinalityAgg); sourceBuilder.size(0); SearchRequest request= newSearchRequest("your_index");request.source(sourceBuilder); SearchResponse response= client.search(request, RequestOptions.DEFAULT);Cardinalitycardinality= response.getAggregations().get("cardinality"); longcardinalityValue =cardinality.getValue();```然后设置分区数：```javaintbucketPerPartition=1000; intnumPartitions =(int) ((cardinalityValue+ bucketPerPartition -1) /bucketPerPartition); if(numPartitions==0)numPartitions =1; //至少一个分区```然后按照这个分区数去循环获取。注意：基数是一个近似值，所以实际的分区数可能略有偏差，但通常足够。因此，完整的实现步骤：1.使用cardinality聚合获取字段基数。2.根据基数计算分区数（numPartitions）。3.循环每个分区，执行带分区的terms聚合，并收集所有桶。4.在内存中对所有桶进行排序（如果需要）。5.然后进行分页返回。但是，如果基数非常大（比如上百万），那么内存中保存所有桶可能会消耗大量内存。在这种情况下，我们可以考虑不进行全局排序，而是直接按照词项的顺序（即每个分区返回的顺序）进行分页。但这样无法按照文档计数排序。如果用户需要按照文档计数排序，那么必须收集所有桶进行排序。如果内存不足，可以考虑使用外部排序（比如将桶写入磁盘文件，然后归并排序），但这比较复杂。因此，对于非常大的基数，建议使用composite聚合，它支持按桶的文档计数排序（但composite聚合也不直接支持按文档计数排序，它只能按词项排序）。所以，如果必须按文档计数排序，那么composite聚合也无法直接支持，需要自己处理。综上所述，在Elasticsearch7中，使用terms聚合的分区方式实现分页的步骤如上所述。注意：在循环请求每个分区时，要注意给集群带来的负载，建议在非高峰时段执行，或者增加请求间隔。最后，关于引用[2][^2]和引用[3][^3]以及引用[5][^5]的内容，与当前问题不直接相关，因此不在此处使用。引用[4][^4]是关于composite聚合的示例，但我们不使用。因此，我们主要参考了引用[1][^1]的说明。引用标识：[^1]:引用1的内容由于引用1是用户提供的，我们直接使用。因此，回答如下：</think>### Elasticsearch 7 Terms 聚合分页实现（不使用 Composite 聚合）在 Elasticsearch 7 中，虽然官方推荐使用 Composite 聚合进行分页[^1]，但通过 **terms 聚合的分区(partition)功能** 仍可实现分批返回结果。以下是具体实现方案： #### 🔧 分区分页核心原理 ```java TermsAggregationBuilder termsAgg = AggregationBuilders.terms("batch_results") .field("product_category") .size(5000) // 每批最大桶数 .includeExclude(new IncludeExclude(currentPage, totalPages)); // 分页关键 ``` - **分区机制**：基于词项的哈希值进行模运算分区 `hash(term) % totalPages == currentPage` - **执行流程**： 1. 计算总页数（分区数） 2. 循环执行各分区聚合 3. 合并所有分区结果 #### 📝 完整 Java 实现代码 ```java // 1. 获取字段基数（估算总页数） CardinalityAggregationBuilder cardinality = AggregationBuilders.cardinality("total_terms").field("product_category"); SearchResponse countResp = client.search(new SearchRequest(indexName) .source(new SearchSourceBuilder().aggregation(cardinality).size(0)), RequestOptions.DEFAULT); long cardinality = ((Cardinality) countResp.getAggregations().get("total_terms")).getValue(); // 2. 计算总页数（每页5000词项） int pageSize = 5000; int totalPages = (int) Math.ceil((double) cardinality / pageSize); // 3. 分批获取结果 Map<String, Long> finalResults = new HashMap<>(); for (int page = 0; page < totalPages; page++) { TermsAggregationBuilder termsAgg = AggregationBuilders.terms("page_" + page) .field("product_category") .size(pageSize) .includeExclude(new IncludeExclude(page, totalPages)); // 分区分页 SearchResponse response = client.search(new SearchRequest(indexName) .source(new SearchSourceBuilder().aggregation(termsAgg).size(0)), RequestOptions.DEFAULT); // 4. 合并结果 Terms terms = response.getAggregations().get("page_" + page); terms.getBuckets().forEach(bucket -> { finalResults.put(bucket.getKeyAsString(), bucket.getDocCount()); }); } // 5. 最终结果处理（示例：按文档数排序） List<Map.Entry<String, Long>> sortedResults = finalResults.entrySet().stream() .sorted(Map.Entry.comparingByValue(Comparator.reverseOrder())) .collect(Collectors.toList()); ``` #### ⚙️ 关键优化参数 ```java .includeExclude(new IncludeExclude(page, totalPages)) // 分区分页 .executionHint("map") // 提升小范围聚合性能 .shardSize(10000) // 每分片处理量（需>size） .collectMode(SubAggCollectionMode.BREADTH_FIRST) // 大数据量优化 .showTermDocCountError(true) // 监控精度误差 ``` #### ⚠️ 重要注意事项 1. **内存限制**： - 每分区桶数(`size`) 必须 ≤ `index.max_terms_count`（默认65536） - 建议启用断路器：`indices.breaker.request.limit: 60%` 2. **精度问题**： - 分区聚合在 `shard_size < 实际桶数` 时会丢失低频词项 - 可通过 `show_term_doc_count_error` 评估误差范围 3. **性能瓶颈**： ```mermaid graph LR A[10亿文档] --> B{基数=100万} B -->|分区数=200| C[单请求处理5k词项] B -->|分区数不足| D[数据倾斜风险] ``` - 推荐分区数：`总基数 / 每页大小 + 缓冲系数(1.2)` - 高基数字段需增加分区数防止哈希冲突 4. **替代方案对比**： | **方案** | 吞吐量 | 内存效率 | 排序支持 | 适用场景 | |----------------|-------|---------|---------|-----------------------| | **Terms+分区** | 中 | 低 | 需后处理 | 中等基数(<500万) | | **Composite** | 高 | 高 | 词项排序 | 超高基数(>500万) [^1] | | **Scroll+Terms**| 低 | 中 | 不支持 | 深度分页(不推荐) | > **最佳实践**：当词项基数超过100万时，即使使用分区方案也建议拆分为多次聚合请求，每次处理特定词项范围[^4]。 #### 💡 动态分区优化策略 ```java // 根据基数动态调整分区大小 double expectedTermsPerPartition = 3000; // 目标每分区词项数 int dynamicPartitions = (int) Math.ceil(cardinality / expectedTermsPerPartition); // 根据集群负载调整并行度 int maxConcurrent = getAvailableThreads(); // 可用线程数 ExecutorService executor = Executors.newFixedThreadPool(maxConcurrent); List<Future<Map<String, Long>>> futures = new ArrayList<>(); for (int i=0; i<dynamicPartitions; i++) { final int partition = i; futures.add(executor.submit(() -> processPartition(partition, dynamicPartitions))); } // 并行合并结果 futures.forEach(f -> { try { finalResults.putAll(f.get()); } catch (Exception e) {/* 错误处理 */} }); ```