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)
当存储费用较低时，可以考虑
参考
参考来源:
How many shards should Elasticsearch indexes have?
Optimizing Elasticsearch: How Many Shards per Index?
ELASTICSEARCH – HOW MANY SHARDS?