分片和副本的設計為 ES 提供了支持分布式和故障轉移的特性，但并不意味著分片和副本是可以無限分配的。而且索引的分片完成分配后由于索引的路由機制，我們是不能重新修改分片數的。 <br/> 一個分片并不是沒有代價的。需要了解： * 一個分片的底層即為一個 Lucene 索引，會消耗一定文件句柄、內存、以及 CPU 運轉。 * 每一個搜索請求都需要命中索引中的每一個分片，如果每一個分片都處于不同的節點還好， 但如果多個分片都需要在同一個節點上競爭使用相同的資源就有些糟糕了。 * 用于計算相關度的詞項統計信息是基于分片的。如果有許多分片，每一個都只有很少的數據會導致很低的相關度。 一個業務索引具體需要分配多少分片可能需要架構師和技術人員對業務的增長有個預先的判斷，橫向擴展應當分階段進行。為下一階段準備好足夠的資源。 只有當你進入到下一個階段，你才有時間思考需要作出哪些改變來達到這個階段。一般來說，我們遵循一些原則： * 控制每個分片占用的硬盤容量不超過 ES 的最大 JVM 的堆空間設置（一般設置不超過 32G，參考下文的 JVM 設置原則），因此，如果索引的總容量在 500G 左右，那分片大小在 16 個左右即可；當然，最好同時考慮原則 2。 * 考慮一下 node 數量，一般一個節點有時候就是一臺物理機，如果分片數過多，大大超過了節點數，很可能會導致一個節點上存在多個分片，一旦該節點故障，即使保持了 1 個以上的副本，同樣有可能會導致數據丟失，集群無法恢復。所以， 一般都設置分片數不超過節點數的 3 倍。 * 主分片，副本和節點最大數之間數量，我們分配的時候可以參考以下關系： ``` 節點數<=主分片數*(副本數) ```