在Elasticsearch（ES）中，随着数据量的增长，对索引进行扩展或调整分片设置可以通过以下三种方案实现：
写在前面的话
Elasticsearch的设计原则之一是不可变性：一旦数据被写入，就不能修改其结构。
在实际业务开始前应充分评估当前集群的状态和未来的增长趋势，但是由于没有做好容量规划与评估，没有设计灵活的代码，或者不熟悉硬件的性能等原因，随着单个索引数据越来越多，初始设置的分片较少已经满足不了读写性能的需要，最终不得不改。
方案一：增加主分片数量
1.新建索引
如果你还没有大量的数据并且可以重新索引，此时回头还不晚，立即创建指定一个更大的主分片数的新索引。
PUT /new_index
{
"settings": {
"number_of_shards": 50 // 根据数据规模和节点数量合理设定
},
"mappings": {...} // 定义索引映射，可以与原来一致，也可以借此机会修改
}2.迁移数据到新索引
然后使用reindexAPI将旧索引的数据迁移到具有适当分片数量的新索引。
3.增加副本分片数量
副本分片可以在不影响现有数据分布的情况下动态增加，以提高读取性能或增强容错能力。
PUT /existing_index/_settings
{
"number_of_replicas": 2 // 增加副本数量
}方案二：水平扩展集群
添加更多的节点到ES集群，这允许系统自动将分片分布到更多的硬件资源上，从而分散负载并提升整体性能。只有增加更多的物理机资源，均衡数据才能有效分担搜索或写入的压力。
尤其是写入性能为瓶颈时，采用多实例的方式扩大分片数是无效的。
方案三：分片拆分（Split）
使用Split接口执行索引分片拆分。
具体来说，Split API允许管理员选择一个现有的索引，并将其主分片（primary shard）拆分成两个或多个新主分片。在拆分过程中：
- 数据迁移：Elasticsearch会将源索引中选定的主分片上的部分数据移动到新创建的索引中。
- 保留元数据：拆分后的每个新索引都会继承原索引的映射（mappings）、设置（settings）以及其他元数据。
- 负载均衡：拆分后，Elasticsearch集群会自动调整这些新分片在集群内的分布，确保数据在各个节点之间均匀分布，从而提高整体集群的性能和稳定性。
- 可用性：在整个split过程中，为了保证数据一致性，可能需要先将索引设置为只读状态，待拆分操作完成后再恢复读写功能。
总结
三个方案的优缺点与适用场景如下：
方案 | 优点 | 缺点 | 适合场景 |
1.重新索引 | 可以更新字段映射结构； 可以缩小也可以扩大分片数 | 速度最慢； 且需要ES中有原始数据_source； 相当于重新导入数据！ | 有原始数据且需要修改字段映射； 想要缩小分片数。 |
2.水平扩容 | 业务无感知，性能提升快 | 需要花钱，买机器！ 实际上不能修改主分片数。 | 不差钱的，追求高性能的主。 初始分片数大于机器数量！ |
3.分片拆分 | 拆分速度很快； 不需要原始数据就能操作 | 初始需求空间很大； 分片数不可以任意指定 | 只想扩大一下分片数的场景。 |
离开场景谈架构都是耍流氓，技术没有最好，只有最合适。
与君共赏
凡事预则立，不预则废。
--《礼记·中庸》
宜未雨而绸缪，毋临渴而掘井。
--明|朱柏庐《治家格言》
