elasticsearch的shard优化-Toy模板网

这篇具有很好参考价值的文章主要介绍了elasticsearch的shard优化。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

shard简介

Elasticsearch 中的数据会整理为索引。每个索引又由一个或多个分片组成。每个分片都是一个 Lucene 索引实例，您可以将其视作一个独立的搜索引擎，它能够对 Elasticsearch 集群中的数据子集进行索引并处理相关查询。
分片是 Elasticsearch 在集群内分发数据的单位。Elasticsearch 在对数据进行再平衡（例如发生故障后）时移动分片的速度取决于分片的大小和数量，以及网络和磁盘性能。

刷新

数据写到分片上周，会定期写到磁盘上不可更新的lucene段中，这个时候数据遍可以查询了，这个就是刷新。

合并

随着段数越来越多，这些段会定期合并为更大的段。这一过程称为合并。由于所有段都是不可更改的，这意味着在索引期间所用磁盘空间通常会上下浮动，这是因为只有合并后的新段创建完毕之后，它们所替换的那些段才能删掉。合并是一项极其耗费资源的任务，尤其耗费磁盘 I/O。

index可能带来的问题

对于每个 Elasticsearch 索引，mapping映射和状态的相关信息都存储在集群状态中。这些信息存储在内存中，以便快速访问。因此，如果集群中的索引和分片数量过多，这会导致集群状态过大，如果mapping映射较大的话，尤为如此。这会导致更新变慢，因为所有更新都需要通过单线程完成，从而在将变更分发到整个集群之前确保一致性。

解决

对于数据量小的数据，可以使用一个固定名字或者按照月/年存储数据到index，有助于减少存储在集群中的索引和分片数量。
相似数据结构的数据都存储到一个index中，有助于减少存储在集群中的索引和分片数量。

shard可能带来的问题

一个shard底层为一个lucene索引，会消耗一定文件句柄，内存，cpu等。例如堆内存会存储分片级别以及段级别信息的数据结构，因为只有这样才能确定数据在磁盘上的存储位置。这些数据结构的大小并不固定，不同用例之间会有很大的差别。
每个search请求都需要命中index中的shard，如果每一个shard都处于不同的节点还好，如果多个shard都需要在同一个节点上竞争使用相同的资源，可能导致效率降低。
用于计算相关度的词项统计信息是基于分片的。如果有许多分片，每一个都只有很少的数据会导致很低的相关度。
在 Elasticsearch 中，每个查询都是在单个分片上以单线程方式执行的。然而，可以同时对多个分片进行处理。这意味着，最低查询延时（假设没有缓存）将取决于数据、查询类型，以及分片大小。尽管查询很多个小分片会加快单个分片的处理速度，但是由于有很多任务需要进入队列并按顺序加以处理，所以与查询较少的大分片相比，这种方法并不一定会加快查询速度。如果有多个并发查询，拥有很多（成百上千）小分片还会降低查询吞吐量。
shard过大，导致集群故障后恢复缓慢，写入放大，导致 bulk queue打满，拒绝率上升
shard过小，导致shard的段过小，无法充分利用多节点资源，机器资源不均衡，影响段合并效率和浪费资源

优化shard的办法

shard大小官方通常建议介于20GB至40GB之间
尽管并没有关于shard大小的固定限值，但是官方建议将50GB作为shard大小的上限。
多个shard尽量分布再不同的节点。因为一个index对应的shard在每个节点分配一个对性能提升最好。考虑到高可用和吞吐量，shard是需要配置副本的，故建议根据此公式平衡节点数量，主shard，shard副本的关系：

Max number of nodes = Number of primary shards * (number of primary shard replicas +1)

对于数据量小的数据，可以使用一个固定名字或者按照月/年存储数据到index，有助于减少存储在集群中的索引和分片数量。
建议把每天的数据存储到按照天命名的index中。此类index允许用户在很细的粒度层面管理保留期，也方便用户根据每天不断变化的数据量轻松进行调整，也有助于降低单个shard的大小。
相似数据结构的数据都存储到一个index中，有助于减少存储在集群中的索引和分片数量。
使用shrink index API把数据量小且使用了多个shard的index压缩成较少shard的index。
确保对于节点上已配置的每个GB堆内存，将分片数量保持在20以下。如果某个节点拥有30GB的堆内存，那其最多可有600个分片，但是在此限值范围内，您设置的分片数量越少，效果就越好。