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的數目而言，沒有那么重要。