PB 级别数据量场景下的 Elasticsearch 调优

硬件与操作系统层面

涉及大量 Pipeline Processor 或分词操作的情况建议选择更多核的 CPU 发挥并发优势

Elasticsearch 是重 I/O 和内存操作的程序，对磁盘和内存有较高的要求。建议使用 SSD 硬盘和本地存储，避免网络传输消耗

Elasticsearch 各项查询操作都非常依赖内存。一部分是 JVM 堆内存上的一些数据结构，另一部分是非堆内存。推荐使用 64G内存的机器，并将 JVM 堆内存的大小限制为 4GB~32GB；JVM 堆内存越小，GC 越快，Lucene 缓存的内存越多，查询性能也就越好。当堆内存小于 32GB 时，JVM 会使用内存对象指针压缩技术来优化性能。一旦内存超过 32GB，则不但会浪费内存而且会导致 CPU 和 GC 的性能降低。

内存交换对 Elasticsearch 来说是显著影响性能的行为，建议配置禁用内存交换，可在 elasticsearch.yaml 中将 bootstrap.memory_lock 参数配置为 true。

集群配置层面

推荐配置 3个专有主节点仅执行集群层面的操作。

在一台物理机上建议只部署一个节点，也就是一个 Elasticsearch 进程。

当写入量较大时，集群经常会出现写入进程池满载且抛出异常的情况，可以适当增加集群写入进程池的大小，可配置的参数时 thread_pool.write.size 及 thread_pook.write.queue_size

业务操作层面

数据写入应尽量采用 bulk 方式。建议将多条数据批量写入集群中，但也需要限定同一批数据的条数，推荐设置为1000~10000条，避免对网络或发送端产生影响。

业务查询应尽量避免返回文档的所有字段，存在大量返回结果会导致额外的性能损耗。如果需要进行分页查询，应尽量避免深度随机分页。

如果业务查询不关注数据与查询条件的匹配程度，可以使用 query-bool-filter 查询代替 query 查询。

对业务的聚合查询，应避免深度嵌套聚合查询，尤其是有大量 bucket 类型的聚合查询，例如 Terms 聚合或 Filter 聚合会产生大量 bucket ，影响聚合性能。

避免对高基数字段做 Terms 聚合。（如 ip、URL 等）

对于 Ters 查询，如果匹配的字段类型很少，可以通过修改 execution_hint 参数的值来修改 Terms 聚合的执行方式以提升性能。

监控和预计指标

硬件和操作系统：CPU、内存、磁盘

集群层面：集群状态、集群的 CPU 利用率、集群的磁盘使用率、集群 JVM 个内存区的使用率、集群 GC 情况、集群索引数、集群分片数、集群未分配分片数、单节点承载的最大数据量

索引层面：索引单分片最大存储容量、索引是否只读

业务层面：读取和写入的平均延迟、读取和写入的拒绝率、每秒写入次数。

预测 Elasticsearch 规模并控制成本

数据节点配置预估

一般从3个维度评估，分别是存储容量、分片数、搜索吞吐量。

存储容量根据以下信息评估：

• 每天将存储多少原始数据
• 数据会保留多少天
• 需要设置多少副本
• 为每个数据节点计划分配多少内存
• 内存与磁盘设定的比例
• 数据膨胀系数：Elasticsearch 需要额外使用倒排索引、列式存储，一般会有10% 的数据膨胀
• 内部任务开销比例：Elasticsearch 需要额外约20%的磁盘空间，用于 segment 合并、translog 存储和运行日志等
• 操作系统预留比例：Linux 默认为 root 用户预留 5% 的磁盘空间
• 预留磁盘警戒比例：一般设置为 15%
• 保留一个数据节点用于容错

假设副本分片的数量为 r，数据膨胀系统为 g，内部任务开销比例为 t，操作系统预留比例为 0，警戒比例为 w，可以通过以下公式计算存储：

存储容量=原始数据量*（1+r）*（1+g）*（1-t）/（1-o）*（1+w）

根据经验值计算，存储容量约为原始数据量的 1.67 倍。根据存储容量，可以通过以下公式评估需要的数据节点数：

数据节点数=ceil（存储容量/单节点内存/内存与磁盘比例）+ 容错数据节点数

腾讯云对冷节点和热节点内存与磁盘比例的经验值分别为 1:480 和 1:96

分片数需要根据业务进行合理配置，可以参考以下信息评估：

• 集群有多少个索引
• 每个索引的主分片和副分片设置的数量
• 索引是否有滚动策略？是按时间滚动还是按存储容量滚动？
• 索引保留的时间

官方建议 1GB JVM 堆内存承载的分片数不超过 20个。

总的数据节点数=ceil（总分片数/（20*单节点内存））