ES写入优化

ES索引数据简述：

1. logstash（或其他的ES client）通过调用index（单条）或bulk（批量）接口将数据导入到ES
2. ES收到请求首先将数据存入index buffer，为了保证数据完整性和异常恢复，将数据同时写入translog（默认配置为同步写入，即条记录会进行一次写磁盘），此时数据不能够被检索到
3. index buffer根据不同索引配置的refresh时间（默认1s），定时或在index buffer空间满了以后执行refresh，将数据刷写到fliesystem cache中，此时数据可以被检索到
4. filesystem cache 通过flush操作将数据持久化到磁盘，flush操作是异步的，一般30分钟或translog区域超过阈值后执行。
5. 在执行flush之前数据都在内存中保存，数据的安全由translog保证，在执行完成flush操作后，才会删除对应的translog内容，数据持久化和建立倒排索引时会根据配置的压缩算法（默认deflate算法）进行压缩，至此ES的整个索引工作完成
6. 数据虽然写完了，但是ES的磁盘操作并没有结束，还要根据索引得数据量对Lucene的segment进行合并，不过这个过程也是异步的并且是在集群空间是执行。
   

综上所述，结合目前的部署测试情况及之前提出的优化建议，总结如下：
因为目前磁盘的IO是ES索引数据的瓶颈，同样容量的数据，只有通过以下几种方式进行写入优化
8. 释放IO资源，降低同等压力下ES集群的吞吐量，降低磁盘的IOPS
9. 根据提出的优化建议对优化项进行了分类
10. 增加处理线程，
11. 合理数据建模减少磁盘开销

关于批量写入的优化项

1. （已执行） 尽量使用bulk接口导入数据，目前连接ES的所有Client都使用的是bulk接口进行的数据写入，一个bulk请求的数据容量约15m

关于异步处理数据的优化项

1. （已执行）调整index_buffer到translog的刷新频率，通过调整index.translog.durability,index.translog.syn_interval,index.translog.flush_threshould_size,将translog的刷新调整成异步，否则这个机制就会造成大量的IOPS，为了不用每条数据都进行刷写磁盘，调整这个值为异步会导致数据丢失的风险，因为当异常中断了，未被刷新到内存中的数据，因为异步的问题部分数据也会保存不到translog中，导致未落盘且未刷新到translog中的数据丢失，目前的配置是可能丢失1S以内的数据
2. （已执行）调整refresh_interval的值，在执行refresh时也可以增加两次refresh操作的间隔时间，同时也要调大index buffer在堆内存的比例（不能调整过大，会导致GC压力），让内存缓存更多的数据提高索引效率，还这样会减少lucene segment，减少segment合并产生的IO开销。这个配置导致的风险是消息的延迟，这个值配置的越大，日志消息的延迟就随之增加。
3. （已执行）关于队列的问题，ES本身是没有缓冲队列的，只有一个处理事件的线程池的等待队列，当处理线程占满是，在处理能力之外的请求会放置在等待队列中等待空闲线程来处理，将处理线程池长度设置为CPU核数+1，等待队列配置为1000。通过这样的配置来减少CPU上下文的切换，减少索引数据的开销
4. （未执行）在整个ELK的日志监控系统中，ES本身没有缓冲队列，kafka起到了缓冲日志的作用，同时logstash也支持磁盘队列对数据进行缓冲，logstash的磁盘队列没有开启。

关于压缩的优化项

1.（已执行）使用ES默认生成的主键，能够提压缩率
2.（已执行）尽量保证每次插入数据的字段先后顺序不变，能够提高数据压缩率
3.（未执行）给不同的索引根据数据特性配置不同的数据压缩算法

关于数据建模的优化项

1. （已执行）``减少text字段的使用，减少动态识别字段的可能，目前主要的索引都配置了template来规范数据模型，减少text字段的使用，降低了磁盘占用
2. （未执行）禁止算分，在template中的字段配置项增加norms=false配置，禁止算分，提高索引效率

负载均衡

1. （未执行，目前未发现热点服务器）确保分片均匀分配到所有的节点上，否则如果有热点节点，就会导致数据偏移，热点节点上的数据延迟时间增长。通过在索引上配置index.routing.allocation.total_shard_per_node,用这个保证主分片在每个节点上的分布的最多阈值。这个数字不能配置过小，节点下线会导致，分片无法分配。