ES使用非常广泛，尤其是ELKB，几乎是上点规模的日志系统，都在用它。
日志属于写多读少的业务场景，对写入速度要求很高。拿我们其中一个集群来说，单集群日志量达到百TB，每秒钟日志写入量达到10W条。
ES不是单纯的顺序写，为了构造倒排索引，保证数据的可靠性和实时性，背后有很多耗时的merge或者额外操作，磁盘I/O和CPU的压力非常的大!
使用iotop去观测，可以发现ES的进程几乎占满了SSD磁盘的I/O资源，达到200MB/s+。使用top命令观测，发现8核CPU的user几乎占满。ES是非常能吃资源的。
既然能很容易发现系统的瓶颈，那就着力去优化这个资源，极限压榨一下ES的写入速度。
本次优化的示例版本是。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'{
"":"async",
"":"512mb",
"":"60s"
}'
这可以说是最重要的一步优化了，对性能的影响最大，但在极端情况下会有丢失部分数据的可能。对于日志系统来说，是可以忍受的。
refresh
除了写translog，ES还会将数据写入到一个缓冲区中。但是注意了!此时，缓冲区的内容是无法被搜索到的，它还需要写入到segment里面才可以。
这就是refresh动作，默认1秒。也就是你写入的数据，大概率1秒之后才会被搜索到。
所以ES并不是一个实时性的搜索系统，它是一个类实时系统(near-realtime)。
通过可以修改这个刷新间隔。
对于日志系统来说，当然要把它调大一点啦。xjjdog这里调整到了120s，减少了这些落到segment的频率，速度自然会快。
curl-H"Content-Type:application/json"-XPUT'http://localhost:9200/_all/_settings?preserve_existing=true'-d'{
"":"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两个瓶颈点给解决掉。
