2. Elasticsearch 核心概念：集群、节点、索引、分片、副本的深入理解
好，咱们正式开始聊 Elasticsearch 的核心概念。说实话，很多初学者一上来就被这些名词搞晕了。集群、节点、索引、分片、副本……听起来像是一堆独立的东西。但在我眼里，它们其实是一套完整的“分布式协作体系”。
我习惯用一个比喻来理解：把 Elasticsearch 想象成一个大型图书馆。你想想看，图书馆有书架（节点）、有图书分类（索引）、有同一本书的不同复本（副本），还有把厚书拆成几册（分片）。嗯，这个比喻虽然简单，但核心逻辑全对上了。
2.1 集群（Cluster）—— 你的搜索系统“大本营”
集群，说白了就是一组 Elasticsearch 节点的集合。它们一起干活，对外提供统一的搜索能力。
每个集群都有一个唯一的名字，默认叫 elasticsearch。我个人习惯在生产环境里把集群名改成有业务含义的，比如 log-prod-cluster 或 search-v2-cluster。为什么？因为一旦你管理几十个集群，默认名会让你崩溃。
核心要点：集群是“逻辑上的整体”，节点是“物理上的个体”。你操作集群时，其实是在操作一组节点。
我在项目中遇到过一个问题：两个不同环境的节点因为集群名都叫 elasticsearch，不小心连到了一起。结果测试数据写到了生产集群，差点酿成大祸。所以，集群名一定要区分环境。
2.2 节点（Node）—— 集群里的“螺丝钉”
节点就是一台服务器上运行的 Elasticsearch 实例。每个节点都有自己的名字，默认是随机生成的 UUID 字符串。我建议你手动命名，比如 node-data-01、node-master-01，这样排查问题时一眼就能看出节点角色。
节点有几种角色，我列个表给你看：
| 角色 | 作用 | 我常用的场景 |
|---|---|---|
| Master-eligible | 参与集群主节点选举 | 3台专用 master 节点，不存数据 |
| Data | 存储数据、执行 CRUD 和搜索 | 大部分节点都是 data 角色 |
| Ingest | 数据预处理管道 | 日志场景常用，减轻 data 节点压力 |
| Coordinating | 负载均衡、请求转发 | 作为网关层，接收客户端请求 |
你可能会问：一个节点能不能身兼多职？当然可以。但我建议你职责分离。我曾经在一个项目里把所有角色都堆到同一批节点上，结果 master 选举时因为磁盘 I/O 高导致超时，集群差点脑裂。嗯，那次教训挺深刻的。
2.3 索引（Index）—— 你的“数据仓库”
索引是 Elasticsearch 里最核心的数据组织单位。你可以把它类比成关系数据库里的“数据库”或“表”。但注意，只是类比，不是完全等价。
一个索引包含一堆结构相似的文档。比如你有一个商品搜索系统，那你可以建一个 products 索引，里面存所有商品信息。
我个人习惯给索引命名时加上版本号或日期，比如 logs-2025-01、products-v2。为什么？因为索引一旦创建，很多设置（比如分片数）就不能改了。加上版本号，方便以后重建索引。
小技巧：索引名支持通配符。比如查询 logs-2025-* 可以匹配所有 2025 年的日志索引。这在做时间序列数据管理时非常有用。
2.4 分片（Shard）—— 分布式系统的“基石”
分片，说白了就是把一个索引拆成多份。每一份就是一个分片，它是一个完整的 Lucene 索引实例。
为什么要拆？因为单机存不下。你想想看，一个索引可能有几百 TB 的数据，一台机器根本扛不住。分片让数据可以分布到多台机器上，并行读写，性能自然就上去了。
分片分为两种：
- 主分片（Primary Shard）：数据写入时先写主分片。索引创建时指定，之后不能修改。
- 副本分片（Replica Shard）：主分片的拷贝，用于高可用和读负载均衡。
这里有个坑，我踩过：主分片数一旦设定，就不能改了。所以创建索引前一定要想清楚。我一般建议：
- 数据量小于 100GB：5 个主分片就够了
- 数据量 100GB ~ 1TB：10~20 个主分片
- 超过 1TB：按每个分片 30~50GB 来估算
注意：分片不是越多越好。分片太多会导致集群管理开销大，搜索时合并结果也慢。我曾经见过一个索引分了 100 个分片，结果每次搜索都要等好几秒，因为协调节点要合并 100 份结果。嗯，这就是过度分片的代价。
2.5 副本（Replica）—— 高可用的“保险”
副本就是主分片的拷贝。每个主分片可以有零个或多个副本。副本的作用有两个：
- 高可用：如果某个节点挂了，副本可以顶上，数据不丢。
- 提升读性能：搜索请求可以分发到副本上并行执行。
副本数是可以动态调整的。我建议生产环境至少设置 1 个副本，也就是 number_of_replicas: 1。这样即使一个节点宕机，数据仍然完整。
但副本也不是越多越好。每个副本都会占用磁盘和内存。我曾经为了追求高可用，把副本数设成了 3，结果集群存储成本直接翻了 4 倍（1 主 + 3 副本）。后来发现其实 1 个副本就够用了，除非你的读请求量极大。
2.6 它们之间的关系——一张图说清楚
我习惯用这个逻辑来理解它们的关系：
集群（Cluster）
└── 节点（Node）1, 2, 3, ...
└── 索引（Index）
├── 主分片（Primary Shard）0, 1, 2, ...
│ └── 文档（Document）
└── 副本分片（Replica Shard）0, 1, 2, ...
└── 文档（Document）说白了，集群是顶层容器，节点是运行实例，索引是逻辑分组，分片是物理存储单元，副本是冗余备份。它们层层嵌套，共同构成了 Elasticsearch 的分布式基石。
2.7 实战建议：如何规划你的集群
根据我的经验，给你几个落地建议：
- 小规模（< 100GB）：3 个节点，每个节点既是 master 又是 data。5 个主分片，1 个副本。够用。
- 中等规模（100GB ~ 1TB）：3 个专用 master 节点 + 5~10 个 data 节点。10~20 个主分片，1~2 个副本。
- 大规模（> 1TB）：3 个专用 master + N 个 data 节点（按需扩展）。分片数按每个分片 30~50GB 计算。副本 1 个起步，读压力大时再加。
我的习惯：创建索引时，先用少量数据测试分片策略。比如先写 1 万条数据，看看分片大小，再估算全量数据需要多少分片。别一上来就拍脑袋定分片数，容易翻车。
好了，这一章的核心概念就聊到这里。记住一句话：集群是家，节点是人，索引是书柜，分片是抽屉，副本是备份钥匙。理解了这个关系，后面的内容你会学得特别顺。