腾讯云 Elasticsearch 实战篇（二十一） 如何选择合适的ES存储集群？

前言 |

通过我们前面的ELK学习，我们已经深入了解了ELK的相关知识以及腾讯云Elasticsearch 的操作与维护，那么，在实际生产应用中，我们如何根据企业自身业务的数据存量需求去选择合适配置的腾讯云ES集群进而保证企业应用的高效持续安全呢？那么今天我们就来讲讲这个问题：

一、节点类型存储配置建议

腾讯云 Elasticsearch Service（ES）集群每个节点均是由计算（云服务器）和存储（云硬盘）两部分构成。依托腾讯云 ES 提供的弹性伸缩机制，在业务规模增大，性能遇到瓶颈的时候，您可以随时扩容，调整得到合适的集群规格。

1、腾讯云提供的可供选择的计算机型（云服务器）列表：

2、存储

腾讯云 ES 节点存储部分采用的是云硬盘（SSD 或高性能），用户可以根据业务需求自定义磁盘大小。单节点存储范围在100G~1T之间。ES是集群是线性扩展的。集群能力随着节点数的增加而增加。

3、那么，问题来了，我到底应该如何去选择适合自己的ES集群呢？同样，按照上面的存储和计算2部分来分析：

（1）存储容量评估

影响腾讯云 ES 服务存储容量的主要因素如下：

• 副本数量：副本有利于增加数据的可靠性，但同时会增加存储成本。默认和建议的副本数量为1，对于部分可以承受异常情况导致数据丢失的场景，可考虑设置副本数量为0。
• 数据膨胀：除原始数据外，ES 需要存储索引、列存数据等，在应用编码压缩等技术后，一般膨胀10%。
• 内部任务开销：ES 占用约20%的磁盘空间，用于 segment 合并、ES Translog、日志等。
• 操作系统预留：Linux 操作系统默认为 root 用户预留5%的磁盘空间，用于关键流程处理、系统恢复、防止磁盘碎片化问题等。

因此，为保证服务的稳定运行，建议至少预留50%的存储空间，因此建议申请的存储容量为：

存储容量=原数据*（1+副本数量）*2.2

那么，我们来算一下，比如我公司的业务数据在半年内大概会逐步到200G的索引。副本1个。那么我要申请的云存储空间为：

200*（1+1）*2.2 = 880G 也就是1T 的存储空间

（2）计算资源评估

ES 的计算资源主要消耗在写入和查询过程，而不同业务场景在写入和查询方面的复杂度不同、比重不同，导致计算资源相比存储资源较难评估，但一般情况下，存储资源会较早成为瓶颈，因此建议您优先评估存储资源量，在实际测试过程中确认计算资源是否足够，您结合存储资源初步选择计算资源，然后在测试过程中验证、调整。根据经验：为了保证性能，在内存与数据量间有一个建议的比例：

- 搜索类项目的比列建议在1：16以内 ，也就是说1GB的JVM 内存可以存16GB的磁盘数据

- 日志类项目的比列建议在1：48~~~1：96之间，也就是说1G的JVM 内存可以相当于48G的数据量

- ES JVM 的内存不要大于31G，预留一半给操作系统，用作文件缓存。这里选的ES云主机节点的内存包括JVM+操作系统共用

-建议您至少选择3个节点，避免 ES 实例出现脑裂问题，保证 ES 实例具有较高的节点故障容错能力。

-如果您有非常大的存储容量需求，建议选择高规格的节点，避免大量低规格节点，这对大实例的性能、稳定性等有较大好处。

-定期自动化删除过期不必要的索引，根据业务情况删除时间很久之前不用的索引，可以参考这个文章：

https://cloud.tencent.com/developer/article/1361207

那么我们再来算一下？上面那个存数数据我们算1T，这个集群我们给他3个节点，那么每个node就是1TB/3=333GB,也就是400GB索引数据。

如果是搜索类项目，每个node内存应该是400GB/16=25G<31G,也就是我们要选3台配置为25G内存的节点。3个节点足够

如果是日志类项目，每个Node内存应该是400G/48=9G<31G,3个节点也足够

因此，综上所述，那么可以选择8核*32G*3节点数或者16核64GB*3节点的规格

二、分片数量评估

每个 ES 索引被分为多个分片，数据按哈希算法打散到不同的分片中。由于索引分片的数量影响读写性能、故障恢复速度，且通常无法轻松更改，需要提前考虑。这里给出配置分片数量的一些常用建议：

• 建议单个分片大小保持在10GB - 50GB之间，您可以据此初步确定 Index 的分片数量。分片不宜过大或过小：过大可能使 ES 的故障恢复速度变慢；过小可能导致非常多的分片，但因为每个分片使用一些数量的 CPU 和内存，从而导致读写性能、内存不足等问题。一般设置为30G即可。
• 在测试阶段，可以根据每个 Index 的实际大小、预期未来增长情况，适当调整分片数量。
• 当分片数量超过数据节点数量时，建议分片数量接近数据节点的整数倍，方便分片在所有数据节点均匀分布。
• 对于日志、Metric 等场景中，建议使用 ES 自带的 Rollover Index 功能，持续滚动产生新的 Index。方便在发现分片大小不合理时，通过该功能及时调整分片数量。

腾讯云CES技术团队的推荐方案是： 对于数据量较小（100GB以下）的index，往往写入压力查询压力相对较低，一般设置3~5个shard，number_of_replicas设置为1即可（也就是一主一从，共两副本） 。 对于数据量较大（100GB以上）的index： 一般把单个shard的数据量控制在（20GB~50GB） 让index压力分摊至多个节点：可通过index.routing.allocation.total_shards_per_node参数，强制限定一个节点上该index的shard数量，让shard尽量分配到不同节点上 综合考虑整个index的shard数量，如果shard数量（不包括副本）超过50个，就很可能引发拒绝率上升的问题，此时可考虑把该index拆分为多个独立的index，分摊数据量，同时配合routing使用，降低每个查询需要访问的shard数量。

例如， 假设实例有5个数据节点，Index 当前大小为150GB，预期半年后增长50%。如果我们控制每个单分片为30GB，则大约需要150GB * （1 + 50%） / 30 ≈ 7个分片，考虑到有两个数据节点支撑2/7的数据压力，节点间压力相对不均匀，我们把分片数量调整到10个。

三、总结

我们如何选择合适的ES集群才能保证业务高效的运转是一个长期而复杂的过程。由于场景应用都不一样，我们需要在实际生产中结合存储资源初步选择计算资源进而不断去验证、调整。当您需要对实例扩容时，建议优先进行纵向扩容，然后再考虑横向扩容增加节点个数。，最好的方法还是需要您在业务的实际使用过程中逐步去探索。依托腾讯云 ES 提供的弹性伸缩机制，在业务规模增大，性能遇到瓶颈的时候，您可以随时扩容，调整得到合适的集群规格。

当完成实例类型的初步选择后，您可以使用真实数据进行测试，通过观察 CPU 使用率、写入指标（性能、拒绝率）、查询指标（QPS、拒绝率）等监控信息，进一步确认实例类型是否合适。另外，建议针对上述监控信息配置告警，方便在线上使用时，及时发现资源不足等问题。

感谢社区好文分享的干货学习（强烈推荐）：https://cloud.tencent.com/developer/article/1507657