ElasticSearch 2 (12) - Shard數調優（ElasticSearch性能）

ElasticSearch 2 (12) - Shard數調優（ElasticSearch性能）

摘要

當建立一個索引的時候，咱們常常會面對一個問題：要爲索引分配多少個shard？多少個replica？對於這個問題，仍然沒有明確的統一答案，可是本文會給出一些引導，方便在實施ElasticSearch時給出合適的Shard和Replica數。

---

版本

elasticsearch版本: elasticsearch-2.x

內容

什麼是一個Shard？

Shard就是一個Lucene Index，參照文章(深刻理解Shard和Lucene Index)。

Index須要多少個Shard？

回答這個問題，咱們須要先談談節點，一個集羣有多個節點，具體須要多少個節點合適，是另一個問題，可是這個數字也會影響咱們對Shard數的設置。

Shard數 ＝ Node數？

整體上說，當咱們節點數和Shard數相等時，ElasticSearch集羣的性能能夠達到最優。即，對於一個3節點集羣，咱們爲每一個集羣節點分配一個Shard，總共3個Shard。可是因爲ElasticSearch的不可變性（Immutable）的限制，系統沒法對Shard進行從新拆分分配，除非從新索引這個文件集合。因此，當咱們須要增長更多節點的時候，又但願Shard能利用到增長節點帶來的系統性能提高時，咱們就不得不進行從新索引，因爲重索引開銷巨大，這是咱們不但願看到的。

StackExchange用ElasticSearch支持它的搜索，當前（2016-3-1日），它網站的ElasticSearch索引佔用440GB。

若是須要從新創建索引，將會是一個巨大的開銷，爲了支持將來可能的水平擴展，咱們會爲集羣分配比node數更多的shard數，也就是說每一個節點會有多個Shard。

若是單個node分配多個shard，就會引入另一系列的性能問題，咱們知道對於任意一次完整的搜索，ElasticSearch會分別對每一個shard進行查詢，最後進行彙總。當節點數和shard數是一對一的時候，全部的查詢能夠並行運行。可是，對於具備多個shard的節點，若是磁盤是15000RPM或SSD，可能會相對較快，可是這也會存在等待響應的問題，因此一般不推薦一個節點超過2個shard。

3節點6shard，即每一個節點2shard，這可使咱們在將來輕鬆的橫向擴展到6個節點，應對許多極端的場景。

Replicas數呢？

Replica也是Shard，與shard不一樣的是，replica只會參與讀操做，同時也能提升集羣的可用性。對於Replica來講，它的主要做用就是提升集羣錯誤恢復的能力，因此replica的數目與shard的數目以及node的數目相關，與shard不一樣的是，replica的數目能夠在集羣創建以後變動，切代價較小，因此相比shard的數目而言，沒有那麼重要。

Replica的故事（宕機）

3 node, 3 shard, 0 replica

一個節點宕機

整個服務不可用

3 node, 3 shard, 1 replica (each)

一個節點宕機

兩個節點宕機

服務仍然可用

3 node, 3 shard, 2 replica (each)

當存儲費用較低時，能夠考慮

參考

參考來源:

http://engineering.datarank.com/2015/07/08/balancing-elasticsearch-cluster-by-shard-size.html

http://engineering.datarank.com/2015/06/30/analysis-of-hotspots-in-clusters-of-log-normally-distributed-data.html

https://en.wikipedia.org/wiki/Shard_(database_architecture)

How many shards should Elasticsearch indexes have?

Optimizing Elasticsearch: How Many Shards per Index?

ELASTICSEARCH – HOW MANY SHARDS?

結束