提問：
既然多個shard會被分配到同一個node上，那么為什么不把多個shard合并成一個然后存在當前node上呢，簡而言之也就是讓node和shard形成一對一的關系呢 ？非常好的問題，這正是理解Elasticsearch分片（shard）設計思想的關鍵點！
為什么不讓一個 node 只存儲一個 shard，實現一對一關系？
主要原因有以下幾點：
1. 分片的數量 ≠ 節點的數量，彈性擴展和伸縮能力
- 分片數固定（不可變），節點數可以動態變化
一旦創建索引后，主分片數就不可更改（7.x后不能動態調整主分片數量）。但實際運行時，集群節點數量是可以動態增加或減少的。 - 多shard 少node
比如你有5個shard，只有3個node，它們怎么分？只能有node上有多個shard。 - 擴容和負載均衡
比如初期2個node，5個shard都只能堆在這2個node上。之后，水平擴容——加節點后，Elasticsearch會自動把這些shard搬過去并負載均衡，但分片數不會增加，如果一個node只能有一個shard，總shard數大于node數/小于node數，都無法自洽。
2. 粒度決定并發，分片越多并發能力越強
- 多shard并發查詢/索引
訪問或寫入單個shard是有性能瓶頸的，尤其是大數據場景下。
多個shard可以并發處理，提高帶寬利用率和處理速度。 - Node本身多核CPU，資源可以共享
一個node比如16核，多個shard可以充分“吃滿”資源，同一node不同shard任務并發處理。
3. 容災與高可用策略靈活
- 副本shard（replica shard）不能和主shard在同一個node上
如果node與shard一對一，就是node掛=分片丟失，無法高可用。 - 通過多shard和多副本分散在多個node上，可以靈活應對節點損壞，提升系統彈性和數據安全。
4. 管理和生命周期操作更靈活
- 可以對單個shard做遷移、均衡、快照、恢復，細粒度管理，便于維護。
- 滾動部署時更方便，可以無縫切換負載。
5. 節點數 >> 索引數量 or << 索引數量的情況
- 一個集群同時有100個索引，每個索引5個shard，總共500個shard。node數量假如只有10個？只能每個node承載N個shard。
- node數量遠超過shard數，單node可能一個都沒有/部分承載。
總結
Elasticsearch 設計分片（shard）機制，是為了實現彈性伸縮、負載均衡、并發性能提升和高可用容災“多目標”，絕不是一一對應就能解決的。讓shard數量遠多于node數量，是分布式架構的基本思想之一。
所以，不讓shard和node一對一，而是允許多個shard分配在同一個node上，是為了支持彈性擴展、高并發、容災、高利用率等多種需求。
)
