相信讀者建立index的時候，一定曾經糾結過分片數應該分配多少。筆者從實用角度來講述一下index分片數量的選擇，index分片數量嚴格來說不能過多，也不能過少，還要兼顧分片平衡以及集群壓力。現在從一些角度來講主分片數應該怎麼選擇。
分析：若乙個es集群的節點數為3，則考慮業務擴充套件（無論是容量還是其它），可能需要新增1個節點共4個節點，可能用於正常增長；有時需要新增2臺（共5個節點）或者3臺機器（共6個節點），可能是新功能導致資料增加很多；甚至是業務猛增，需要直接擴容5個節點（共8個節點）。考慮擴充套件因素，要使得index與節點數量較為均衡，正好為3、4、5、6等整數倍，那麼一定是其最小公倍數30個資料分片。有的讀者會問若是7個節點、8個節點、9個節點呢？這就要考慮擴容場景，一般來講，正常擴容3到4個節點還是比較常見的，若是資料猛增，一定不僅僅是擴容兩個節點總共5個節點，往往是直接翻倍擴容為6個節點，甚至將近3倍，擴容至8個節點，甚至是12個，24個分片。所以對於乙個不是很大的index，容量小於500g，且考慮節點數為3，每個節點的容量為1.5t，不妨設定主分片為12，副本分片為1，共24個分片。方便以後擴充套件。無論是增加乙個節點，還是翻倍擴容，再翻倍，都能保持分片數量是節點數的整數倍。集群壓力是均衡的！
結論：
若index < 50g，且未來index資料肯定不會有較多增長。則可以將分片數設定為3或者6，副本分片為1
若index < 500g，且未來index資料會增長，但不會增長到10t量級，建議主分片數為12，副本分片數為1
若index容量極大，主分片可以為30、60、120。若到120，則有可能是有120個節點，若一台機器部署兩個節點，則需要60臺機器，相信es集群已經非常大了。這種情況最好需要業務按照業務邏輯進行拆分。
因為乙個分片就是乙個luence，而luence的文件數限制在2g個，所以考慮到這個限制，對於文件數非常多的index，千萬不能設定特別少的分片數，若超過此限制，對於集群會是災難性的，集群會狂打異常日誌，資料無法寫入，導致節點所在機器因日誌太多很快到100%。即使讓業務停止讀寫，重新reindex的時間也非常久！而且機器擴充套件也不方便，往往最後評估處理的方案是將異常的index刪除，重新建立新的index。
還有就是段檔案，乙個段檔案不要超過20g（實際**注釋有50g限制一說），推薦乙個分片能對應合併為1個段檔案。這個並不是強制性的，有的index是10t的容量，卻設定了10個主分片，副本分片為0，集群可以工作，但通常不建議這麼做。還有乙個說法是文件數不要超過1000w，主要是考慮到去query乙個表，到千萬級，往往效能未必能跟上。
過多的es分片會給主節點帶來更多的壓力，需要去維護更多分片的狀態，集群壓力也會因此變大，不建議建立1000個資料分片。cerebral外掛程式觀察es狀態，若乙個集群所有總的分片數超過1w，開啟頁面也會有一定的延遲，給維護帶來一定困難，表現就是集群管理頁面特別卡！若出現太多分片，則需要考慮降低分片數量或者拆分集群。
結論：
單分片文件數不能超過2g個。
最初規劃index，單分片容量建議不超過20g，文件數不要超過1000w。
不建議將index資料分片設定超多。
若業務讀寫請求每次能夠路由到某個分片，或者絕大部分都能路由到某個片中，則index主分片數越多越好。單個節點擁有更多的分片能提公升併發處理的能力，筆者曾調優過一次因為擴容導致集群處理能力並未增加，從而滿足不了業務請求的案例。雖然這樣，但是建議控制在120以內。若業務都是query某個條件，需要遍歷查詢所有分片，建議分片數不要過多，因為分片越多，拆分的子請求也越多，單個節點因擁有的分片數過多導致併發大，耗費更多的io負載和cpu負載。
集群按天、小時週期建立請求索引，推薦乙個節點乙個資料分片，若集群擴容或者縮容，則會導致index分片節點數量不一致，當天一定要修改分片數，確保明天的index與新擴縮容的集群的節點數是一致的即可。可能讀者會疑惑為何要這麼做，按天、小時建立索引，往往有如下特徵：資料越舊越沒價值，日誌場景居多，且資料量比較多，使用query請求查詢每個分片的情況居多，且一般需要保留3-7天，甚至更長。若當天擴縮容，則今天和舊的好多index就會發生分片遷移，單個index可能會導致分片不均勻，但是往往有幾個舊的index一起混合分布在各個節點，平衡了集群壓力，隨著時間增長，舊的index一方面逐天逐小時被刪除，另一方面是被讀的可能性越來越小。非常常見的場景是讀1小時、讀3小時、讀6小時、讀12小時、讀24小時，後面就是統計3天，統計一周的頻率，最後即使是舊的index分片不均勻，讀的請求越來越少， 也會隨著時間的變化慢慢被刪除。每個節點分配乙個資料分片，能讓業務query最小的分片數量，耗費更少的io和cpu。
結論：業務請求若為routing欄位，大部分都能路由到某個分片，以get請求居多，那麼建議用較多的資料分片。
業務請求若為query請求，且每次都要請求每個分片，則建議一般不要超過12個分片，單節點擁有分片不建議超過3個。
按天、小時週期建立請求索引，乙個節點乙個資料分片，若擴容集群或者縮容，當時調整分片數即可。
以上就是筆者維護了諸多es集群總結的經驗。這些原則並非是完全適用所有情況，但大部分情況均適用，希望大家能夠用到。若是新手看著麻煩，乾脆就這麼記住：資料量小，主分片為6；資料量大，主分片為12；再多，可以為30！
ElasticSearch分片詳解
1.我們能夠傳送請求給集群中任意乙個節點。每個節點都有能力處理任意請求。每個節點都知道任意文件所在的節點 2.新建索引和刪除請求都是寫操作，它們必須在主分片上成功完成才能賦值到相關的複製分片上 3.在主分片和複製分片上成功新建 索引或刪除乙個文件必要的順序步驟 1 客戶端給node1 傳送新建 索引...
Elasticsearch 分片原理1
elasticsearch版本 6.0 elasticsearch基於lucene，採用倒排索引寫入磁碟，lucene引入了按段搜尋的概念，來動態更新索引。乙個lucene索引包含乙個提交點和三個短，如圖 關於索引和分片乙個lucene索引在elasticsearch成為分片，乙個elasticse...
控制Elasticsearch分片和副本的分配
es集群中索引可能由多個分片構成，並且每個分片可以擁有多個副本。通過將乙個單獨的索引分為多個分片，我們可以處理不能在乙個單一的伺服器上面執行的大型索引，簡單的說就是索引的大小過大，導致效率問題。不能執行的原因可能是記憶體也可能是儲存。由於每個分片可以有多個副本，通過將副本分配到多個伺服器，可以提高查...