1. 大规模索引架构总览
当数据量从百万级文档增长到数十亿、上百亿文档时，Elasticsearch 的部署形态会发生根本性变化。单机时代“装好即用”的思路不再成立，取而代之的是一套围绕分片、角色分工、生命周期和容量规划构建的分布式架构。本节从核心概念出发，逐步展开集群角色分工、索引生命周期管理，以及大规模场景下的架构设计原则，为后续章节的性能优化打下结构基础。
一、分布式索引的三个核心概念
理解 Elasticsearch 的分布式索引，首先要抓住三个概念：分片（Shard）、副本（Replica）和路由（Routing）。
索引在逻辑上是一个整体，但在物理上被切分为若干个主分片。每个主分片是一个独立的 Lucene 索引，可以独立写入、独立检索。副本是主分片的拷贝，既承担读请求分流，也在主分片所在节点故障时被提升为新的主分片。路由则决定了文档写入哪个分片：默认使用文档 _id 的哈希值对主分片数取模，公式为 shard = hash(_id) % number_of_primary_shards。这也解释了为什么主分片数在索引创建后不能随意修改——一旦改变，所有文档的路由位置都会失效。
一个常见的容量估算示例：假设单分片建议控制在 30～50 GB，某业务每日新增 200 GB 原始数据，经索引膨胀系数约 1.1 后约为 220 GB，保留 30 天则总数据量约 6.6 TB。按每分片 40 GB 计算，需要约 165 个主分片。若集群有 10 个数据节点，则平均每节点承载约 16～17 个主分片，再叠加 1 个副本，每节点约 33 个分片。这个数量级在中等规模集群中是可接受的，但如果继续增长，就需要引入分层架构和生命周期管理。
二、集群角色分工
Elasticsearch 7.x 之后，节点角色被显式拆分，这对大规模集群尤为重要。常见的角色包括：
- master 节点：负责集群状态管理、索引创建删除、分片分配决策。大规模集群建议配置 3 个专用 master 节点，避免与数据节点混部导致选举抖动。
- data 节点：存储分片、执行写入和查询。可进一步细分为 data_hot、data_warm、data_cold、data_frozen，配合 ILM 实现数据分层。
- ingest 节点：执行预处理管道，如字段提取、富化、转换。写入吞吐高时建议独立部署，避免抢占数据节点的 CPU。
- coordinating 节点：只做请求分发和结果聚合，不存数据、不参与选举。查询并发高时，独立协调节点能显著降低数据节点压力。
- ml 节点：运行机器学习任务，与数据节点隔离，防止模型训练影响在线检索。
一个典型的大规模集群配置示例：3 个专用 master（4C8G）、6 个 data_hot（16C64G，NVMe SSD）、6 个 data_warm（16C64G，SATA SSD）、3 个 coordinating（8C16G）、2 个 ingest（8C16G）。这种分工让每类节点只做自己最擅长的事，避免资源争抢。
三、索引生命周期管理（ILM）
ILM 把索引从创建到删除的全过程划分为 Hot、Warm、Cold、Delete 四个阶段。每个阶段可以配置不同的操作：
- Hot：滚动索引（rollover）在分片达到 50 GB 或文档数达到 5 亿时触发，保证单个分片不会无限膨胀。
- Warm：执行 force merge 将段合并到较少数量，减少文件句柄和内存占用；同时可设置副本数为 1 以节省存储。
- Cold：将索引迁移到低成本节点，或转为可搜索快照（searchable snapshot），存储成本可下降约 50%。
- Delete：到期后自动删除，避免人工清理遗漏。
ILM 的价值在于把“什么时候滚动、什么时候合并、什么时候删除”这些决策从人工操作变成策略驱动，在大规模场景下这是维持集群稳定的关键机制。
四、大规模架构设计原则
结合上述概念，大规模索引架构可以归纳为几条原则：
- 分片数量与节点数匹配：单节点分片总数建议控制在 20～25 个/GB 堆内存以内，避免分片过多导致集群状态膨胀和查询开销上升。
- 冷热分层：Hot 层用高性能 SSD 承载写入和近期查询，Warm/Cold 层用大容量低成本存储承载历史数据，通过 ILM 自动迁移。
- 角色隔离：master、data、ingest、coordinating 各司其职，避免单节点承担多种角色导致资源竞争。
- 滚动索引 + 别名：写入始终指向别名，rollover 后新索引自动接管，应用无需感知索引切换。
- 容量预留：磁盘使用率控制在 85% 以下，为段合并、副本恢复和突发写入留出空间。