Elasticsearch主分片数写入后不能改

首先这是一个非常深刻的问题；表面看是"设计限制"，但背后其实是 分布式系统一致性、数据路由模型与工程权衡的必然结果。

🔑 核心原因：文档路由（Document Routing）依赖分片数

Elasticsearch 写入一条文档时，会用以下公式决定它去哪个主分片：es可是尊重规则的守法公民

shard = hash(routing) % number_of_primary_shards

routing 默认是文档的 _id，也可自定义；
hash() 是确定性哈希（如 Murmur3）；
% number_of_primary_shards 是关键！

🧩 举个🌰 假设你创建索引时设了 number_of_shards: 3：

文档 _id	hash(_id)	shard = hash % 3
"A"	100	1
"B"	101	2
"C"	102	0

所有客户端和节点都按这个规则路由；但是如果 现在，如果你突然把分片数改成 4：

文档 _id	hash(_id)	shard = hash % 4
"A"	100	0 ← 变了！
"B"	101	1 ← 变了！
"C"	102	2 ← 变了！

💥灾难发生：我读一下，就有种天塌了的赶脚

原来在 shard-1 的文档 A，现在应该去 shard-0；
但 shard-0 里根本没有 A；
客户端按新规则查 A → 查不到；
按旧规则写 A → 写到错误分片，导致数据重复或丢失。

🧱 深层原因 1：分片是 Lucene 索引，不是逻辑分区

很多人误以为"分片"像数据库的"分区表"，可以动态切分。但 每个 Shard = 一个完整的 Lucene 索引实例，包含：

倒排索引（Inverted Index）
正排存储（Doc Values）
Segment 文件集合
提交点（Commit Point）

**Lucene 本身不支持"分裂索引"**不能把一 Lucene 索引"切成两半"变成两个合法索引------因为：

FST 词典是整体构建的；
Doc ID 是连续分配的；
Segment 合并策略基于全局视图。

所以，Shard 是物理不可分割的单元。像湾湾一样

⚖️ 深层原因 2：一致性 vs 灵活性的工程权衡

方案	问题
在线重路由 + 数据迁移	需要锁整个索引，期间不可写；迁移 TB 级数据耗时数小时
双写 + 切流	实现复杂，易出错，需外部协调
虚拟分片（如 Dynamo 的 Partition）	需彻底重构 ES 路由层，破坏 Lucene 兼容性

而 ES 的选择是：

✅ 简单、可靠、高性能❌ 不支持运行时扩主分片

和 Kafka 的 Partition 数不能改是同一类设计哲学 ：用创建时的规划，换取运行时的确定性。一脉相承，大佬都像一块去了，果然人以类聚物以群分，能设计出来这么些伟大作品都是相似思想的

✅ 那怎么解决"分片数预估不准"的问题？

用运维手段解决架构限制，简单来说就是迁移，没办法，牺牲一下空间也是值得的

复制代码

// 创建新索引，设更多分片
PUT /my_index_v2
{
  "settings": { "number_of_shards": 6 }
}

// 把旧数据全量迁移到新索引
POST /_reindex
{
  "source": { "index": "my_index_v1" },
  "dest": { "index": "my_index_v2" }
}

层级	原因
路由层	文档到分片的映射依赖 `hash % N`，N 改变 → 映射失效
存储层	Shard = Lucene 索引，物理上不可分裂
一致性	动态扩分片需复杂协调，违背 ES "简单可靠" 哲学
工程现实	Reindex 已足够应对绝大多数场景

💡 我们项目最佳实践建议：

日志类索引：按天/周建索引，单索引分片数 = 3～6（未来最大节点数 × 1～2）
业务索引：预估 1～2 年数据量，单分片控制在 20--50GB
永远不要设 number_of_shards: 1（无法扩展）