Elasticsearch批量主键查询的时间复杂度及性能可行性问询

背景概述 #

我有一个业务场景，需要通过主键查询少于18000条记录，要求查询响应时间控制在1秒内。目前数据存储在DynamoDB中，已经使用支持非阻塞I/O的DynamoDB Enhanced SDK客户端做并行批量查询，实现了P100延迟低于500毫秒。

现在想探索另一种方案：将数据同步到Elasticsearch，通过terms查询获取目标文档。

ES查询示例 #

实验用的查询语句如下：

GET /chemicals/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "terms": {
            "chemicalId": [
              "C0001",
              "C0002",
              ...
              "C18000"
            ]
          }
        },
        {
          "term": {
            "isActive": true
          }
        }
      ]
    }
  },
  "size":10000
}

实验结果 #

本次实验在包含3万条文档的chemicals索引中进行，查询整体延迟控制在1秒内，ES响应显示处理时间为123毫秒。

我的初步理解：因为chemicalId是keyword类型，且每个ID最多关联一个文档，所以1.8万个term的查询时间复杂度是O(1)，而非O(logN)。

核心疑问 #

1. 上述理解是否有误？
2. 随着数据量增长，该查询的时间复杂度是否会上升？

补充背景 #

• 允许最终一致性
• 虽非典型搜索场景，但后续可能需要聚合和过滤功能，希望确认Elasticsearch能否满足这类批量查询需求

解答 #

你的初步理解存在偏差，实际情况如下：

1. 时间复杂度并非严格O(1)：Elasticsearch中keyword类型字段默认会构建倒排索引，terms查询时，ES会遍历你传入的每个term，在倒排索引中快速定位对应文档ID（该定位操作接近O(1)），但整体查询的时间复杂度是O(K)——K为传入的term数量（即18000），而非O(1)。不过因为单个term的定位操作极快，所以整体延迟依然能维持在较低水平。
2. 数据量增长的影响：只要集群内存缓存（文件系统缓存、ES的fielddata缓存）能覆盖chemicalId和isActive字段的索引数据，数据量增长不会导致延迟显著上升。若数据量远超缓存能力，会触发磁盘IO操作，延迟会有所增加，但只要集群资源配置合理（足够内存、适配的分片数），依然能将响应时间控制在1秒内。
3. ES对该场景的适配性：结合你的补充背景，ES完全能满足需求：
   • 最终一致性：通过Logstash、CDC工具等实现的异步数据同步，天然支持最终一致性
   • 聚合与过滤：ES对多维度聚合、复杂过滤的支持成熟，可应对后续业务拓展
   • 查询优化空间：当前terms查询还可优化，比如将size调整为18000避免分页，若chemicalId是文档ID，改用ids查询能进一步降低延迟

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