shard簡介
Elasticsearch 中的數據會整理爲索引。每個索引又由一個或多個分片組成。每個分片都是一個 Lucene 索引實例，您可以將其視作一個獨立的搜索引擎，它能夠對 Elasticsearch 集羣中的數據子集進行索引並處理相關查詢。
分片是 Elasticsearch 在集羣內分發數據的單位。Elasticsearch 在對數據進行再平衡（例如發生故障後）時移動分片的速度取決於分片的大小和數量，以及網絡和磁盤性能。
刷新
數據寫到分片上週，會定期寫到磁盤上不可更新的lucene段中，這個時候數據遍可以查詢了，這個就是刷新。
合併
隨着段數越來越多，這些段會定期合併爲更大的段。這一過程稱爲合併。由於所有段都是不可更改的，這意味着在索引期間所用磁盤空間通常會上下浮動，這是因爲只有合併後的新段創建完畢之後，它們所替換的那些段才能刪掉。合併是一項極其耗費資源的任務，尤其耗費磁盤 I/O。
index可能帶來的問題
對於每個 Elasticsearch 索引，mapping映射和狀態的相關信息都存儲在集羣狀態中。這些信息存儲在內存中，以便快速訪問。因此，如果集羣中的索引和分片數量過多，這會導致集羣狀態過大，如果mapping映射較大的話，尤爲如此。這會導致更新變慢，因爲所有更新都需要通過單線程完成，從而在將變更分發到整個集羣之前確保一致性。
解決：
- 對於數據量小的數據，可以使用一個固定名字或者按照月/年存儲數據到index，有助於減少存儲在集羣中的索引和分片數量。
- 相似數據結構的數據都存儲到一個index中，有助於減少存儲在集羣中的索引和分片數量。
shard可能帶來的問題
- 一個shard底層爲一個lucene索引，會消耗一定文件句柄，內存，cpu等。例如堆內存會存儲分片級別以及段級別信息的數據結構，因爲只有這樣才能確定數據在磁盤上的存儲位置。這些數據結構的大小並不固定，不同用例之間會有很大的差別。
- 每個search請求都需要命中index中的shard，如果每一個shard都處於不同的節點還好，如果多個shard都需要在同一個節點上競爭使用相同的資源，可能導致效率降低。
- 用於計算相關度的詞項統計信息是基於分片的。如果有許多分片，每一個都只有很少的數據會導致很低的相關度。
- 在 Elasticsearch 中，每個查詢都是在單個分片上以單線程方式執行的。然而，可以同時對多個分片進行處理。這意味着，最低查詢延時（假設沒有緩存）將取決於數據、查詢類型，以及分片大小。儘管查詢很多個小分片會加快單個分片的處理速度，但是由於有很多任務需要進入隊列並按順序加以處理，所以與查詢較少的大分片相比，這種方法並不一定會加快查詢速度。如果有多個併發查詢，擁有很多（成百上千）小分片還會降低查詢吞吐量。
- shard過大，導致集羣故障後恢復緩慢
- shard過小，導致shard的段過小，影響段合併效率和浪費資源
優化shard的辦法
- shard大小官方通常建議介於20GB至40GB之間
- 儘管並沒有關於shard大小的固定限值，但是官方建議將50GB作爲shard大小的上限。
- 多個shard儘量分佈再不同的節點。因爲一個index對應的shard在每個節點分配一個對性能提升最好。考慮到高可用和吞吐量，shard是需要配置副本的，故建議根據此公式平衡節點數量，主shard，shard副本的關係：
Max number of nodes = Number of primary shards * (number of primary shard replicas +1) - 對於數據量小的數據，可以使用一個固定名字或者按照月/年存儲數據到index，有助於減少存儲在集羣中的索引和分片數量。
- 建議把每天的數據存儲到按照天命名的index中。此類index允許用戶在很細的粒度層面管理保留期，也方便用戶根據每天不斷變化的數據量輕鬆進行調整，也有助於降低單個shard的大小。
- 相似數據結構的數據都存儲到一個index中，有助於減少存儲在集羣中的索引和分片數量。
- 使用shrink index API把數據量小且使用了多個shard的index壓縮成較少shard的index。
- 確保對於節點上已配置的每個GB堆內存，將分片數量保持在20以下。如果某個節點擁有30GB的堆內存，那其最多可有600個分片，但是在此限值範圍內，您設置的分片數量越少，效果就越好。
總結
es中並不是shard數量越多越好，也不是shard越小越好，要根據實際情況來優化shard相關參數。
參考
https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster