优化含超大量terms的ElasticSearch查询方案咨询

问题场景 #

我们处理数十亿条记录的数据集，全部存储于ElasticSearch，查询与聚合操作均基于该平台。因terms查询默认最多支持1024个值，我们将10万个device_id拆分为多个terms子句，通过should逻辑组合，但当前查询速度极慢。需要针对该场景的优化方案，或支持实时/近实时处理的替代搜索引擎。

简化查询体 #

{"_source": {
    "excludes": [
        "raw_msg"
    ]
},
"query": {
        "filter": {
            "bool": {
                "must": [
                    {
                        "range": {
                            "create_ms": {
                                "gte": 1664985600000,
                                "lte": 1665071999999
                            }
                        }
                    }
                ],
                "should": [
                    {
                        "terms": {
                            "device_id": [
                                "1328871",
                                "1328899",
                                "1328898",
                                "1328934",
                                "1328919",
                                "1328976",
                                "1328977",
                                "1328879",
                                "1328910",
                                "1328902",
                                ...       # 更多值，因terms不支持超过1024个值，故用should拼接所有子句
                            ]
                        }
                    },
                    {
                        "terms": {
                            "device_id": [
                                "1428871",
                                "1428899",
                                "1428898",
                                "1428934",
                                "1428919",
                                "1428976",
                                "1428977",
                                "1428879",
                                "1428910",
                                "1428902",
                                ...
                            ]
                        }
                    },
                    ...  # 拼接更多terms子句直到包含全部10万个值
                ],
                "minimum_should_match": 1
            }
        }
},
"aggs": {
    "create_ms": {
        "date_histogram": {
            "field": "create_ms",
            "interval": "hour",
        }
    }
},
"size": 0}

数据简化结构 #

{
    "id" : {
        "type" : "long"
    },
    "content" : {
        "type" : "text"
    },
    "device_id" : {
        "type" : "keyword"
    },
    "create_ms" : {
        "type" : "date"
    },
    ... # 更多字段
}

ElasticSearch 内部优化方案 #

• 调整terms查询上限：ES默认通过index.max_terms_count限制terms的最大值为1024，可直接修改该参数支持10万个值。
  • 动态设置（无需重启）：执行PUT /_all/_settings {"index.max_terms_count": 100000}
  • 永久设置：在elasticsearch.yml中添加index.max_terms_count: 100000，重启生效。修改后可将所有device_id合并到单个terms子句中，避免拆分多个should带来的性能开销。
• 使用Terms Lookup查询：若10万个device_id已存储在ES的某个索引中（比如一个设备列表索引），可通过terms lookup直接从该索引获取device_id列表，无需客户端传递大量参数，减少网络传输压力。示例：

  {
    "terms": {
      "device_id": {
        "index": "device_list",
        "id": "device_ids_doc",
        "path": "ids"
      }
    }
  }
  

• 数据预聚合优化：针对时间维度的聚合需求，使用ES的Rollup功能对历史数据按device_id和create_ms（小时级）做预聚合，存储到rollup索引中。查询时直接访问rollup索引，避免对原始数十亿条数据做实时聚合，大幅提升速度。
• 优化过滤顺序与索引：确保create_ms字段使用合适的日期类型并建立有效索引，时间范围过滤会快速缩小数据集，再执行device_id匹配，减少后续处理的数据量。同时，将device_id的terms查询放在filter上下文（当前已在filter中），利用缓存提升重复查询的性能。

替代搜索引擎方案（支持实时/近实时） #

• ClickHouse：列式OLAP数据库，支持实时写入（MergeTree引擎），对大维度过滤和聚合的性能远超ES。十亿级数据下，按device_id过滤+时间聚合的查询延迟可控制在秒级甚至毫秒级，适合该场景。
• Apache Pinot：专为实时分析设计的OLAP引擎，支持低延迟的查询和聚合，支持实时数据 ingestion。针对高并发、大数据量的多维分析场景优化，能高效处理10万device_id的过滤与时间聚合。
• Apache Solr：与ES同属Lucene生态，支持自定义terms查询上限，配置灵活，实时索引能力优异。对于大terms查询的处理性能优于拆分should子句的ES方案，适合需要保持Lucene生态的场景。

内容的提问来源于stack exchange，提问作者buxizhizhoum