Elasticsearch的读写性能优化与负面清单

Elasticsearch的读写性能优化与负面清单

写性能

场景1 内存参数配置不合理

是否给Elasticsearch实例足够的内存，如果内存足够的话，建议配置30GB每个Elasticsearch数据实例节点。

场景2 bulk提交量过大，导致内存被堆满

一次提交的bulk数量不宜过大，实践证明5-10MB左右大小合适。

场景3 客户端IP/端口配置问题

因为Elasticsearch的客户端采用的是轮询的方式，所以尽量配置所有节点的IP、端口，或者开启嗅探功能。

场景4 写入时指定DOC ID，导致读IO高

写入时指定DOC ID，意味着首先需要判断ID是否重复，如果在大数据量的场景下，可能会需要从磁盘进行一次读操作，从而占用大量的磁盘IO，导致写入速度慢。

场景5 bulk队列积压，请求线程被拒绝

大量的bulk队列被等待或者积压，导致线程被拒绝，这时候需要适当降低业务请求的并发量。

场景6 热分片问题

单个索引的分片集中分布在某几个机器节点上，导致写入压力无法均匀地分布到各个机器节点上，形成阻塞的问题。

场景7 集群不稳定，大量分片迁移和恢复

如果你的集群处于不稳定的状态，比如有大量的分片在做均衡迁移或者恢复，都会占用大量的资源，导致写入资源被占用。

场景8 部分实例长时间不断的full GC，导致实例处于假死状态

部分场景下，数据实例处于长时间不断的full GC，但此时并没有完全脱离集群，写入请求仍然往这个节点发送，此时节点已经无法处理了（后续版本已经修改为默认使用G1GC，现场根据需要修改重启ES）。

快速解决办法：重启问题实例。

场景9 磁盘IO瓶颈

当磁盘出现IO瓶颈，能怎么办呢，换更好的盘？？，或者扩容吧。

场景10 查询业务占用大量的资源

高并发的查询或者大数据的查询可能会占用大量的资源，此时需要衡量你的系统侧重点了，实在不行，扩容吧。

场景11 索引段合并占用大量的IO资源

索引段合并太频繁同样会占用大量的IO资源，如果不是SSD盘，将索引段合并线程设置为1。

场景12 分词器设计不合理

不同的分词对写入影响很大，分词器设计不合理，可能会存在大量的CPU计算和过度分词等问题。

读性能

数据量大小

随着数据量的增加，索引和搜索所需的时间也会增加，上线初期可能无法感知，随着数据量的逐渐增大到一定程度，性能可能会急剧地下降。

索引设计

索引的设计，包括分片和副本的配置，以及Mapping和Analyzer的设置，都可能影响搜索性能。例如，过多的分片可能导致交互增多，而过少的分片可能导致单个分片的数据累积过多，从而影响性能。

硬件资源

硬件资源如CPU、内存、磁盘I/O等也会影响ES的性能。例如，如果内存不足，排序和统计等操作可能会受到影响。同样，磁盘的读写速度也会影响ES的性能，使用SSD和RAID等技术可以提高磁盘I/O性能。

查询复杂性

复杂的查询可能需要更多的计算资源和时间，因此也会影响ES的性能。

网络延迟

如果ES集群分布在不同的地理位置，网络延迟可能会成为影响性能的一个因素。这种情况比较少见，但如果符合自己的情况，需要考虑！

并发请求

大量的并发请求可能会使ES服务器过载，导致性能下降。

数据分布

数据的分布也会影响ES的性能。例如，如果数据分布不均匀，某些节点可能会承受更大的负载，从而影响性能。

这需要进行数据均衡或者数据重索引的操作。

负面清单

以下操作或用法会显著造成性能下降，建议业务进行优化。

1.大量模糊匹配搜索

没有根据业务进行友好分词，直接默认或者按字数循环分词后，强行使用大量的模糊匹配进行查询，这种用法是性能地域，完全无法发挥索引的作用（类似数据库中使用like %% 查询，造成ES性能降级）。

在业务上线初期，由于数据量小可能察觉不到该做法的危害，随着数据量的增长，搜索性能将会急剧下降。

2.使用超大返回结果集

ES默认的返回结果条数限制在10000条，对于搜索场景来说已经足够（若每页20条结果，可以翻500页）。

如果在一次查询中需要返回几十上百万的结果，说明这不是ES所适合的场景，建议使用其他OLAP数据库。

3.写入大量数据时指定文档ID

指定ID后无法发挥批量写入的优势，写入性能明显降低且会造成读压力。