ElasticSearch分片

本文内容参考了田雪松老师编著的《Elastic Stack应用宝典》

ElasticSearch作为一个搜索引擎，会存储海量的数据。而存储海量的数据，就要解决如何存储的问题，并且保证数据不会丢失，同时还需要保证数据检索的效率，尽可能不会因为数据的增加而影响检索速度。

分片和集群

目前，解决大数据存储的通用方案是分片（Shard）。它的核心思想是，通过把数据拆分为大小合适的片段，然后分别存储到集群内不同的节点上。这样一来，存储的容量可以随着节点的增加而增加，理论上来说就没有上限了。同时数据分片带来的收益不仅仅是数据的存储，对于数据处理来说也可以大幅提升性能和吞吐量。

在现有硬件技术条件下，硬盘读写速度与CPU处理能力不在一个数量级上，所以硬盘往往是数据处理的最大瓶颈。即使有多个CPU或者多个线程并发处理数据，只要处理的数据在同一个硬盘上，当达到了硬盘的读写上限后，数据处理的速度也不会得到显著提升。在使用数据分片技术后，数据会被散列到不同机器的硬盘上，数据的读写也就被分散到不同的硬盘上，这会显著提升数据处理的速度。

分片的基础是要存储到不同的机器上，所以需要有集群的能力。Elasticsearch创建集群非常简单，只要集群中的节点在相互连接的网络中，并且具有相同的集群名称即可。在配置文件config/elasticsearch.yml增加配置：

cluster.name=elasticsearch

当启动了多个实例时，可以在Kibana上查询节点信息：

GET _nodes

创建了Elasticsearch集群后，就需要确定索引分片的数量。分片一般会均匀地分散到集群的不同节点上，这就将存储和检索负载分散到集群的不同节点上。索引分片数量是在创建索引时通过number_of_shards参数设置的。在索引定义好分片数量后，当有新的节点加入集群时，Elasticsearch会将分片均衡地散列到新的节点。

例如，索引分片数量为2，当集群中只有一个节点a时，这些分片将全部位于节点a上；而当有节点b加入到集群中时，Elasticsearch会动态地将其中一个分片复制到节点b上。这也意味着如果索引的分片数量为1，那么这个索引未来将无法扩容。

路由

分片解决了海量文档存储的问题，但也引入了一个新的问题，那就是如何确定文档应该存储到哪个分片。在Elasticsearch中，确定文档存储在哪一个分片中的机制被称为路由（Routing）。

计算文档路由的具体运算公式如下：

$shard\_num=hash(\_routing)\%num\_primary\_shards$

shard_num为分片序号，hash为散列函数，_routing为路由参数，而num_primary_shards则是一个索引的主分片数量。这里之所以要使用主分片主要是为了区别副本分片，即在运算时并不包含副本分片数量。

在默认情况下，文档的_routing参数是文档ID。可以自定义路由规则，但是要注意，如果文档添加时的路由规则与文档检索时的路由规则不相同，在检索文档时就有可能被路由到错误的分片上，从而导致检索失败。为了避免这种情况的发生，可以在创建索引时将文档路由参数设置为强制要求：

PUT index_name
{"mappings": {"_routing": {"required": true}}
}

在路由参数设置为强制之后，对文档CRUD操作都必须要指定routing参数，否则在执行请求时将报错误。

由于路由选择对于索引性能的影响很大，往往选择的routing参数看似分散但却会路由到相同的分片。为了解决这个问题，Elasticsearch又引入了另一个分区参数来平衡路由运算，这就是routing_partition_size。引入这个参数后，路由运算公式变为:

$shard\_num=(hash(\_routing)+hash(\_id)\%routing\_partition\_size)\%num\_primary\_shards$

在添加了分区参数以后，分片编号同时由路由参数_routing和索引_id字段共同决定，这也就加大分片均衡的可能性。routing_partition_size参数必须大于1并且小于主分片数量。

容量规划

文档所在分片除了由routing参数决定以外，索引分片数量也是其中一个重要的决定因素。在索引分片数量发生变化时，即使routing参数不变，最终的分片位置也会发生变化。

如果在运行时索引分片数量发生了变化，为了保证文档存储和检索都能路由到正确的分片，已经存储到分片中的文档就必须做分片的重新路由。这个过程在Elasticsearch中叫重新索引（Reindex），显然当分片中已经存储了大量文档时，这将是一个非常耗费资源的过程。

为了避免重新索引导致的性能开销，索引分片数量一旦在创建索引时确定后就不能再修改。虽然解决了重新索引问题，但索引的存储容量也被分片数量、节点存储容量限制死了。节点存储容量决定了分片容量的上限，而索引总容量则是单个分片容量与分片数量的乘积。从性能角度考虑，分片太大显然会降低检索速度，所以单个分片的容量也不能过大，需要根据用户对检索性能的要求估算单个分片的容量上限。尽管最好的办法是将分片平均分配到不同的节点上，但如果节点存储容量大于单分片容量上限时，也可以考虑在一个节点上存储多个分片。尽管如此，这还是意味着索引存储容量存在上限，所以在创建索引时有必要对索引容量预先做好规划。如果用户在容量规划时低估了文档容量，那么索引将无法通过扩容来支持更多的文档。

索引容量规划主要是根据一些已知条件规划分片数量，这些已知条件主要包括文档存储整体容量和检索性能要求两个方面。通过检索性能要求可以估算出每个分片的最大容量，再使用整体容量除以分片大小就可以估算出分片数量。文档整体容量有时可能无法估算，比如说日志文件每天都在产生，数量只可能越来越多，不可能估算出上限来。这种情况下可以取一个固定的时间段，比如一天或是一个月，每隔这样一段时间就创建一个新的索引出来。由于固定时间段内的文档数量可估算，所以分片数量也就可以预先估算。

事实上，无论容量规划得多科学依然不能完全避免文档实际存储量与索引容量不相符的情况。在这种情况下，惟一可行的办法就是创建新的索引，再将原索引中的文档存储到新的索引中。

副本

当集群中存储分片的节点发生故障，分片技术并不能保证文档存储、检索等服务依然可用，更不能保证分片中的数据不丢失。为了解决这个问题，Elasticsearch在存储上又引入了另一项称为副本（Replica）的技术。副本是主分片的复制品，它与主分片的数据完全一致，能够在主分片故障时迅速恢复数据。所以主分片与副本分片永远不会在同一节点上，因为这样对于数据恢复没有任何意义。在默认情况下，Elasticsearch为每个索引都设置了1个副本分片，这意味着集群中应该至少有两个节点。如果集群中只有一个节点，副本分片就永远不会被创建，这时Elasticsearch就会将集群健康状态设置为黄色。索引的副本分片数量可以通过number_of_replicas参数设置。

查看集群中的分片情况：