ElasticSearch 2 (12) - Shard數調優（ElasticSearch效能）
摘要
當建立一個索引的時候，我們經常會面對一個問題：要為索引分配多少個shard？多少個replica？對於這個問題，仍然沒有明確的統一答案，但是本文會給出一些引導，方便在實施ElasticSearch時給出合適的Shard和Replica數。
版本
elasticsearch版本: elasticsearch-2.x
內容
什麼是一個Shard？
Shard就是一個Lucene Index，參照文章(深入理解Shard和Lucene Index)。
Index需要多少個Shard？
回答這個問題，我們需要先談談節點，一個叢集有多個節點，具體需要多少個節點合適，
Shard數 ＝ Node數？
總體上說，當我們節點數和Shard數相等時，ElasticSearch叢集的效能可以達到最優。即，對於一個3節點叢集，我們為每個叢集節點分配一個Shard，總共3個Shard。但是由於ElasticSearch的不可變性（Immutable）的限制，系統無法對Shard進行重新拆分分配，除非重新索引這個檔案集合。所以，當我們需要增加更多節點的時候，又希望Shard能利用到增加節點帶來的系統性能提升時，我們就不得不進行重新索引，由於重索引開銷巨大，這是我們不希望看到的。
如果需要重新建立索引，將會是一個巨大的開銷，為了支援未來可能的水平擴充套件，我們會為叢集分配比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)
當儲存費用較低時，可以考慮
