elasticsearch写入速度优化

        追求极致的写入速度时，很多是以牺牲可靠性和搜索实时性为代价的。有时候，业务上对数据可靠性和搜索实时性要求并不高，反而对写入速度要求很高，此时可以调整一些策略，最大化写入速度

         如果是集群首次批量导入数据，则可以将副本数设置为0，导入完毕再将副本数调整回去，这样副分片只需要复制，节省了数据同步的过程。

如果是实时数据写入，综合来说，提升写入速度从以下几方面入手：

• 加大translog flush间隔，目的是降低iops、writeblock。
• 加大index refresh间隔，除了降低I/O，更重要的是降低了segment merge频率。
• 调整bulk请求。
• 优化磁盘间的任务均匀情况，将shard尽量均匀分布到物理主机的各个磁盘。
• 优化节点间的任务分布，将任务尽量均匀地发到各节点。
• 优化Lucene层建立索引的过程，目的是降低CPU占用率及I/O，例如，禁用_all字段（ES6.0已经默认禁用，不去额外处理即可）。

translog flush间隔优化

从ES 2.x开始，在默认设置下，translog的持久化策略为：每个请求都“flush”。对应配置项如下：

index.translog.durability: request

这是影响 ES 写入速度的最大因素。但是只有这样，写操作才有可能是可靠的。如果系统可以接受一定概率的数据丢失（例如，数据写入主分片成功，尚未复制到副分片时，主机断电。由于数据既没有刷到Lucene,translog也没有刷盘，恢复时translog中没有这个数据，数据丢失），则调整translog持久化策略为周期性和一定大小的时候“flush”，例如：

index.translog.durability: async

设置为async表示translog的刷盘策略按sync_interval配置指定的时间周期进行。

index.translog.sync_interval: 120s

加大translog刷盘间隔时间。默认为5s，不可低于100ms。

index.translog.flush_threshold_size: 1024mb

超过这个大小会导致refresh操作，产生新的Lucene分段。默认值为512MB。

refresh_interval索引刷新间隔优化

默认情况下索引的refresh_interval为1秒，这意味着数据写1秒后就可以被搜索到，进而满足Elasticsearch的近实时查询，但是每次索引的refresh会产生一个新的Lucene段，这会导致频繁的segment merge行为，造成大量的磁盘io和内存占用，影响效率，如果不需要这么高的实时性，应该降低索引refresh周期，例如：

index.refresh_interval: 30s

segment merge段合并优化

segment merge操作对系统I/O和内存占用都比较高，从ES 2.0开始， merge行为不再由ES控制，而是由Lucene控制，在6.X版本中由以下配置控制：

index.merge.scheduler.max_thread_count

index.merge.policy.*

最大线程数max_thread_count的默认值如下：

Math.max（1, Math.min（4, Runtime.getRuntime（）.availableProcessors（） / 2））

以上是一个比较理想的值，当节点配置的cpu核数较高时，merge占用的资源可能会偏高，影响集群的性能，如果只有一块硬盘并且非 SSD，则应该把它设置为1，因为在旋转存储介质上并发写，由于寻址的原因，只会降低写入速度；如果Elasticsearch写路径配置多个磁盘，可以在磁盘数的范围内结合集群的负载取一个合适的值，可以通过下面的命令调整某个index的merge过程