极限压榨elasticsearch写入速度

极限压榨elasticsearch写入速度

不羡鸳鸯不羡仙，一行代码调半天。原创：小姐姐味道（微信公众号ID：xjjdog）

ES使用非常广泛，尤其是ELKB，几乎是上点规模的日志系统，都在用它。

日志属于写多读少的业务场景，对写入速度要求很高。拿我们其中一个集群来说，单集群日志量达到百TB，每秒钟日志写入量达到10W条。

ES不是单纯的顺序写，为了构造倒排索引，保证数据的可靠性和实时性，背后有很多耗时的merge或者额外操作，磁盘I/O和CPU的压力非常的大！

使用iotop去观测，可以发现ES的进程几乎占满了SSD磁盘的I/O资源，达到200MB/s+。使用top命令观测，发现8核CPU的user几乎占满。ES是非常能吃资源的。

既然能很容易发现系统的瓶颈，那就着力去优化这个资源，极限压榨一下ES的写入速度。

本次优化的示例版本是7.9.2。ES的版本升的是真快，已经完全脱离了5的时代了。 

1、哪些操作占用资源

要进行优化，需要首先知道ES的写入过程，了解哪些步骤最耗时。

首先，就是副本（replica）问题，为了保证起码的高可用，这里的副本数量设置为1，是节省不了的。所以，将副本数量设置为0，只适合数据首次导入的时候。

如上图，一条数据想要最终落地，是需要经过多个步骤的。这个过程，甚至会有tranlog这样的备份机制。

ES的底层存储是Lucene，包含一系列的反向索引。这样的索引就成为段（segment）。但记录不会直接写入段，而是先写入一个缓冲区。

当缓冲区满了，或者在缓冲区呆的够久，达到了刷新时间（划重点），会一次性将缓冲区的内容写进段中。

这也是为什么refresh_interval属性的配置会严重的影响性能。如果你不要很高的实时性，不妨将其配置的大一点。

缓冲区默认使用堆空间的10%，最小值为48mb（针对于分片的）。如果你的索引多且写入重，这部分内存的占用是可观的，可以适当加大。

2、开始优化

数据写入，主要有三个动作：flush、refresh和merge。通过调整它们的行为，即可在性能和数据可靠性之间进行权衡。

flush

从上面的介绍可以看出来，translog写入了一份全量的数据，它有点像MysSQL中的binlog，或者redis的aof，用来保证异常情况下的数据安全。

这是因为，我们把数据写到磁盘后，还要调用fsync才能把数据刷到磁盘中，如果不这样做在系统掉电的时候就会导致数据丢失。

ES默认每次请求都进行一次flush，但对于日志来说，这没有必要，可以将这个过程改为异步的，参数如下：

curl-H"Content-Type: application/json"-XPUT'http://localhost:9200/_all/_settings?preserve_existing=true'-d'{

  "index.translog.durability" : "async", 

"index.translog.flush_threshold_size" : "512mb",

  "index.translog.sync_interval" : "60s"

}'

这可以说是最重要的一步优化了，对性能的影响最大，但在极端情况下会有丢失部分数据的可能。对于日志系统来说，是可以忍受的。

refresh

除了写translog，ES还会将数据写入到一个缓冲区中。但是注意了！此时，缓冲区的内容是无法被搜索到的，它还需要写入到segment里面才可以。

这就是refresh动作，默认1秒。也就是你写入的数据，大概率1秒之后才会被搜索到。

所以ES并不是一个实时性的搜索系统，它是一个类实时系统（near-realtime）。

通过index.refresh_interval可以修改这个刷新间隔。

对于日志系统来说，当然要把它调大一点啦。xjjdog这里调整到了120s，减少了这些落到segment的频率，速度自然会快。

curl-H"Content-Type: application/json"-XPUT'http://localhost:9200/_all/_settings?preserve_existing=true'-d'{

  "index.refresh_interval" : "120s"

}'

merge

merge其实是lucene的机制，它主要是合并小的segment块，生成更大的segment，来提高检索的速度。

原因就是refresh过程会生成一大堆小segment文件，数据删除也会产生空间碎片。所以merge，通俗来讲就像是碎片整理进程。像postgresql等，也有vaccum进程在干同样的事。

显而易见，这种整理操作，既让费I/O，又浪费CPU。

要命的是，merge有三种策略。

tiered 默认选项，它能合并大小相似的索引段，并考虑每层允许的索引段的最大个数。

log_byte_size 以字节数的对数为计算单位，选择多个索引来合并创建新索引。

log_doc 以索引段的文档数量为计算单位，选择多个索引来合并创建新索引。

每一种策略都有非常详细的针对性配置，在此不啰嗦。

由于日志系统并没有随机性的删除操作，所以我们保持默认就可以。

3、微调

新版本对线程池的配置进行了优化，不需要配置复杂的search、bulk、index线程池。有需要配置下面几个就行了：thread_pool.get.size, thread_pool.write.size, thread_pool.listener.size, thread_pool.analyze.size。具体可观测_cat/thread_pool接口暴露的数据进行调整。

其实，可以通过配置多块磁盘的方式，来分散I/O的压力，但容易会造成数据热点集中在单块磁盘上。

Lucene的索引建立过程，非常耗费CPU，可以减少倒排索引的数量来减少CPU的损耗。第一个优化就是减少字段的数量；第二个优化就是减少索引字段的数量。具体的操作，是将不需要搜索的字段，index属性设置为not_analyzed或者no。至于_source和_all，在实际调试中效果不大，不再赘述。

另外，如果日志是通过filebeat或者logstash这样的组件传导过来的，一般都是开启了批量模式。通过批量能够增加性能，但也不宜过大，可根据实际观测进行设置，一般1k-1w之间都是可以的。

End

ES有多种使用场景。鉴于它NoSQL的本质，有的甚至用它来替代传统的关系型数据库。

这是没有问题的，但要注意它的延迟。本文侧重的是吞吐量优先的日志写入场景，数据的延迟就尤为明显。ES默认不是为了这种场景设计的，所以开箱即用的配置就显得效率很低。

我们了解到ES写入有flush、refresh和merge过程。其中，对I/O影响最大的就是translog和merge的动作；对CPU影响最大的是索引创建和merge的过程。在平常的mapping设计中，要尽量减少字段的数量，以及索引字段的数量。如此双管齐下，才能把CPU和I/O两个瓶颈点给解决掉。

作者简介：小姐姐味道 (xjjdog)，一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。

原文地址：https://juejin.im/post/6885320503867736078