Elasticsearch雖然搜索很快，但如果分片設置不當，當數據量達到一個量級後，查詢速度也會直線下降。

如果一個索引具有很大的數據量，它的數據量可能會超出單個節點的容量限制（硬盤容量），而且單個節點數據量過大，執行性能也會隨之下降，每個搜索請求的執行效率都會降低。 為了解決上述問題， Elasticsearch 提出了分片的概念，索引將劃分成多份，稱為分片。當創建索引時，可以很簡單的指定想要的分片數量。每個分片都是功能齊全的，獨立的“索引”，駐留在集群的各個節點中。

分片的作用

Elasticsearch 中的分片其實就是 Lucene 索引。

分片有兩個主要的用處：

• 水平劃分數據
• 多個分片分發工作，並行執行，從而提高性能，吞吐量

分片分為主分片和副本分片。副本分片主要功能如下：

• 高可用性：副本分片作為數據備份，當某個主分片發生故障時，副本分片能夠成為新的主分片，保證服務的可用性。
• 提高性能：副本分片本身也是一個功能齊全的獨立的分片（所以才能夠隨時取代故障的主分片），當有查詢請求時，既可以在主分片中完成查詢，也可以在副本分片中完成查詢，當然數據添加、更新的操作只能在主分片中完成。

副本分片與主分片需要分配在不同的節點上，一是為了更好的均衡負載，不同節點上二是節點發生故障時，主分片和副本分片一起故障，沒法保證高可用性。所以 Elasticsearch 集群最好要有 2 個節點或以上。

一個索引默認有 5 個主分片，每個主分片默認有 1 個副本分片，即創建一個索引默認會有 10 個分片。

實際應用舉例

場景1：數據量大小約為10GB, 用於輸入時自動提示場景，數據每天定時更新部分字段。ES集群有5臺機器。

方案一：主分片數=1，副分片數=4，每個節點持有一個分片。

• 優點：每個節點持有一個分片，讀請求可以在一個分片獲取結果，不需要合併結果等操作。
• 缺點：索引寫入的時候，全部請求到主分片的機器，再由主分片同步到副分片，由於副分片較多，寫入過程變慢。

方案二：主分片數=2，副分片數=4，每個節點持有一個主分片和一個副分片。

• 優點：副分片變少，對寫入操作友好。
• 缺點：多個分片分散在不同節點上，請求會發布到各個分片號上取topN彙總。由於評分是在各個分片內進行，在本場景中存在TF/IDF評分差異，導致返回結果排序問題。

考慮業務場景，最終選擇方案一。

場景2：在ELK(ELK是Elasticsearch、Logstash、Kibana的簡稱)中，想一下, 大部分的 Logstash 用戶並不會頻繁的進行搜索, 甚至每分鐘都不會有一次查詢. 所以這種場景, 推薦更為經濟使用的設置. 在這種場景下, 搜索性能並不是第一要素, 所以並不需要很多副本。

總結

• 讀遠大於寫的場景，可以減少主分片個數，增加副本數，提升讀吞吐率，前提是寫的優先級不高。極端情況下單分片多副本可以最大程度提升總的讀吞吐。
• 寫遠大於讀的場景，最大程度分配主分片個數，一個機器一個，並最大程度減少副本數（極端情況下集群規模不大且可用性優先級較低時可以不要副本）。

分片的大小和數量怎麼設定？

注1：小的分片會造成小的分段，從而會增加開銷。我們的目的是將平均分片大小控制在幾 GB 到幾十 GB 之間。對於基於時間的數據的使用場景來說，通常將分片大小控制在 20GB 到 40GB 之間。

注2：由於每個分片的開銷取決於分段的數量和大小，因此通過 forcemerge 操作強制將較小的分段合併為較大的分段，這樣可以減少開銷並提高查詢性能。 理想情況下，一旦不再向索引寫入數據，就應該這樣做。 請注意，這是一項比較耗費性能和開銷的操作，因此應該在非高峰時段執行。

注3：我們可以在節點上保留的分片數量與可用的堆內存成正比，但 Elasticsearch 沒有強制的固定限制。 一個好的經驗法則是確保每個節點的分片數量低於每GB堆內存配置20到25個分片。 因此，具有30GB堆內存的節點應該具有最多600-750個分片，但是低於該限制可以使其保持更好。 這通常有助於集群保持健康。

注4：如果擔心數據的快速增長, 建議根據這條限制: ElasticSearch推薦的最大JVM堆空間是 30~32G, 把分片最大容量限制為 30GB, 然後再對分片數量做合理估算。例如, 如果的數據能達到 200GB, 則最多分配7到8個分片。

開源地址

https://github.com/qfjiaoyan/elasticsearch-examples

閱讀更多 Java教研組 的文章

關鍵字: 美好，一直在身邊 ElasticSearch 副本