Elasticsearch是否需要拆分低频访问文档以提升查询性能？

是否需要拆分两类文档？ #

有必要做针对性优化，不推荐完全忽略该需求。总200万的文档量本身不大，但95%的查询集中在仅占2.5%的活跃文档上，不做优化的话，绝大多数查询都要扫描全量200万文档的索引，CPU、内存资源浪费非常明显，后续文档量或者QPS上涨时延迟会快速升高。

可选的拆分/优化方式（按运维成本从低到高排序） #

1. 无索引结构改造：自定义路由+过滤缓存 #

你提到的按照active/inactive状态哈希分配分片的需求，ES原生就有对应的routing（路由）能力支持，不需要自己实现哈希逻辑：

• 写入文档时，指定routing参数值为文档的状态（active/inactive），ES会自动按路由键的哈希值分配分片，相同状态的文档会集中存储在相同分片中
• 查询活跃文档时，指定routing=active，查询请求只会分发到存储活跃文档的分片，不会扫描全部分片

同时给active布尔字段建立索引，查询时添加active=true的过滤条件，ES的Filter缓存会自动缓存活跃文档的过滤结果集，95%的高频查询可以直接命中缓存，性能提升非常明显。
该方案无需修改现有索引结构，业务代码修改量极小，运维成本几乎为0，是当前量级下的首选方案。

2. 单索引生命周期管理（ILM）自动分层 #

如果后续文档量还会持续上涨，可以给文档增加status_update_time（状态变更时间）字段，配置ILM策略：

• 文档状态变为inactive超过预设阈值（比如30天）后，自动迁移到温冷节点，分片设置为只读并开启高压缩比存储，大幅降低存储成本
• 业务侧查询逻辑完全不需要修改，对外还是同一个索引访问

3. 双索引拆分 #

也就是你考虑的分别建立doc_active和doc_inactive两个独立索引：

• 写入时根据文档状态写入对应索引，高频查询仅需要访问5万量级的活跃索引，延迟可以压到毫秒级
• 需要同时查询两类文档时，通过绑定两个索引的别名doc_all查询即可

你担心的运维成本问题可以通过ILM自动迁移解决：配置规则当文档状态变为inactive时，自动从活跃索引移动到非活跃索引，不需要人工介入，长期运维成本并不高。该方案适合后续QPS较高、对延迟要求严苛的场景。

是否可以完全不做优化？ #

如果当前查询QPS极低（每秒低于10次），且后续没有明显的业务增长预期，不做优化也能正常运行，但从长期资源效率和扩展性来看，还是建议至少做路由+过滤的轻量优化。

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