Elasticsearch最佳实践之分片使用优化

本文由云+社区发表

做者：老生姜

1、遇到的问题

　　与大多数分布式系统同样，Elasticsearch按照必定的Hash规则把用户数据切分红多个分片，而后打散到不一样机器进行存储，从而实现大规模数据的分布式存储。

cluster.png

　　然而在一些复杂的应用场景中使用Elasticsearch，常常会遇到分片过多引起的一系列问题。起初咱们在支撑内部某业务时，单集群内有约1000个子业务，大部分子业务保留31天的数据。若是每一个子业务按天滚动创建Index，每一个Index 5个分片、一主两从共三副本的状况下，集群内部会有多达45w~个分片。在集群内分片过多时，常常遇到下面这些问题：

　　1. 建立分片慢：Elasticsearch建立分片的速度会随着集群内分片数的增长而变慢。以ES 5.5.2版本、3节点集群为例，在默认配置下，当集群分片数超过1w时，建立index的耗时通常在几十秒甚至以上。 　　2. 集群易崩溃：在凌晨触发Elasticsearch自动建立Index时，因为建立速度太慢，容易致使大量写入请求堆积在内存，从而压垮集群。 　　3. 写入拒绝：分片过多的场景中，若是不能及时掌控业务变化，可能常常遇到单分片记录超限、写入拒绝等问题。

2、解决过程

1. 拆分集群 对于存在明显分界线的业务，能够按照业务、地域使用不一样集群，这种拆分集群的思路是很是靠谱的。Elasticsearch官方建议使用小而美的集群，避免巨无霸式的集群，咱们在实际使用过程当中对这一点也深有体会。但对于咱们的场景，已经按照地域拆分了集群，且同一地域的子业务间分界线不明显，拆分过多的集群维护成本较高。
2. 调整滚动周期 根据保留时长调整index滚动周期是最简单有效的思路。例如保留3天的数据按天滚动，保留31天的数据按周滚动，保留一年的数据按月滚动。合理的滚动周期，能够在存储成本增长不大的状况下，大幅下降分片数量。 对于咱们的场景，大部分数据保留31天，在按周滚动的状况下，集群的总分片数能够降低到6.5w~个。
3. 合理设置分片数和副本数 集群内部除个别子业务压力较高外，大部分业务压力较小，合理设置单Index的分片数效果也不错。咱们的经验是单个分片的大小在10GB~30GB之间比较合适，对于压力很是小的业务能够直接分配1个分片。其余用户可结合具体场景考虑，同时注意单分片的记录条数不要超过上限2,147,483,519。 在平衡咱们的业务场景对数据可靠性的要求 及 不一样副本数对存储成本的开销 两个因素以后，咱们选择使用一主一从的副本策略。 目前咱们集群单Index的平均分配数为3，集群的总分片数降低到3w~个。
4. 分片分配流程优化 默认状况下，ES在分配分片时会考虑分片relocation对磁盘空间的影响。在分片数较少时，这个优化处理的反作用不明显。但随着单机分片数量的上升，这个优化处理涉及的多层循环嵌套过程耗时愈发明显。可经过cluster.routing.allocation.disk.include_relocations: false关闭此功能，这对磁盘均衡程度影响不明显。
5. 预建立Index 对于单集群3w分片的场景，集中在每周某天0点建立Index，对集群的压力仍是较大，且存储空间存在波动。考虑到集群的持续扩展能力和可靠性，咱们采用预建立方式提早建立分片，并把按Index的建立时间均匀打散到每周的每一天。
6. 持续调整分片数 对于集群分片的调整，一般不是一蹴而就的。随着业务的发展，不断新增的子业务 或 原有子业务规模发生突变，都须要持续调整分片数量。 默认状况下，新增的子业务会有默认的分片数量，若是不足，会在测试阶段及上线初期及时发现。随着业务发展，系统会考虑Index近期的数据量、写入速度、集群规模等因素，动态调整分片数量。

3、后续

　　目前，Elasticsearch的分片均衡策略尚有瑕疵，例如：1. 机器的空间利用不是很是均衡，对于此类场景，用户可暂时经过调整机器空间的高低水位线配置触发数据均衡；2. 当集群扩容新节点时，Elasticsearch会把大量新建分片分配到新机器，致使新机器压力太高，目前用户可临时经过index.routing.allocation.total_shards_per_node配置进行限制。

　　这是咱们后续在分片使用方面的优化工做，经过直接优化分片均衡策略，更优雅的解决上述问题。若是你们有分片使用方面的问题 或 经验，欢迎一块儿交流讨论！

此文已由腾讯云+社区在各渠道发布

获取更多新鲜技术干货，能够关注咱们腾讯云技术社区-云加社区官方号及知乎机构号