涉及大量 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 情况、集群索引数、集群分片数、集群未分配分片数、单节点承载的最大数据量
索引层面:索引单分片最大存储容量、索引是否只读
业务层面:读取和写入的平均延迟、读取和写入的拒绝率、每秒写入次数。
| 节点类型 | 节点类型 | 存储需求 | 内存需求 | 计算需求 | 网络需求 | 节点数量 |
|---|---|---|---|---|---|---|
| 主节点 | 管理集群状态 | 低 | 低 | 低 | 低 | 最少3个 |
| 数据节点 | 存储与检索数据 | 极高 | 高 | 高 | 中 | |
| Ingest 节点 | 转换输入的数据 | 低 | 中 | 高 | 中 | |
| 机器学习节点 | 运行机器学习模型 | 低 | 极高 | 极高 | 中 | |
| 协调节点 | 分发请求,合并结果 | 低 | 中 | 中 | 中 |
一般从3个维度评估,分别是存储容量、分片数、搜索吞吐量。
存储容量根据以下信息评估:
假设副本分片的数量为 r,数据膨胀系统为 g,内部任务开销比例为 t,操作系统预留比例为 0,警戒比例为 w,可以通过以下公式计算存储:
存储容量=原始数据量*(1+r)*(1+g)*(1-t)/(1-o)*(1+w)
根据经验值计算,存储容量约为原始数据量的 1.67 倍。根据存储容量,可以通过以下公式评估需要的数据节点数:
数据节点数=ceil(存储容量/单节点内存/内存与磁盘比例)+ 容错数据节点数
| 节点类型 | 存储目标 | 磁盘类型建议 | 内存与磁盘比例 |
|---|---|---|---|
| 热节点 | 搜索为主 | SSD 大于 200Gbit/s | 1:30 |
| 温节点 | 存储为主 | HDD 约 100Gbit/s | 1:100 |
| 冷节点 | 归档为主 | 小于 100Gbit/s | 1:500 |
腾讯云对冷节点和热节点内存与磁盘比例的经验值分别为 1:480 和 1:96
分片数需要根据业务进行合理配置,可以参考以下信息评估:
官方建议 1GB JVM 堆内存承载的分片数不超过 20个。
总的数据节点数=ceil(总分片数/(20*单节点内存))