elasticsearch默认配置综合考虑了数据可靠性、搜索实时性、写入速度等因素,在某些场景下,对于可靠性和实时性要求不高,而对写入速度要求比较高,此时,可以通过调整一些策略来提升写入的速度。
01
使用SSD替代普通机械磁盘
当存量大量的写入请求时，refresh indexing buffer和flush translog都会导致大量的磁盘IO，IO压力会显著增加,可以考虑使用SSD替换普通机械磁盘，提升一定的写入速率。
02
批量写入设置副本为0
elasticsearch在写入数据时,如果存在副本,则写完主分片以后,会将请求转发给所有的副本分片,等所有的分片写完成以后才算写入成功,写入到副本分片的数据也需要索引的过程,批量写入的时间会比较长,而设置副本为0时,只写主分片,重新调整副本数量以后只涉及主分片数据复制到副本分片的过程，节省了索引过程，提升了写入速率。
03
加大translog flush时间间隔
从ES2.X开始默认的translog flush策略为:
index.translog.durability:request,这种情况下每次index、bulk、delete、update都会触发translog flush,好处是保证了数据的可靠性,不会在断电等情况下造成部分数据丢失,但是每次flush的效率明显较低,且I/O压力比较大。
在对可靠性要求不那么高的场景下,允许一定概率的数据丢失,可以调整translog flush策略:
- 设置index.translog.durability:async 关闭index、bulk、delete、update等操作同步flush translog,使用默认的定时刷新、文件大小阈值刷新的机制,策略由参数sync_interval和flush_threshold_size决定。
- 设置index.translog.sync_interval:5s此配置默认5s,表示默认每个5s会定时执行fsync,将translog buffer刷新到磁盘中。
- 设置index.translog.flush_threshold_size:512mb此配置默认512mb,表示当translog buffer达到512mb的时候,将会触发一次translog flush,同时也会触发一次index commit,导致refresh操作,产生新的lucene分段。
04
加大indexing refresh时间间隔
elasticsearch索引的过程是先将数据写入indexing buffer,通过定时refresh或者buffer满了refresh的机制,将index buffer写入os cache,此时数据就可以被搜索了,因为默认情况下这个定时的refresh设置为1s,所以我们一般说elasticsearch是近实时的。
每次的refresh操作,都会导致产生一个新的lucene分段,当lucene分段太多的时候会导致频繁的segment merge,这对于系统的I/O和内存有较大的影响,如果对于实时性要求比较低,可以适当调大index.refresh_interval的值，减少IO操作，这样子可以在一定程度上提升写入速率。
05
增大indexing buffer
与上一个建议策略类似，elasticsearch进行索引操作时,数据首先会写入内存缓冲区,这个区域被称为indexing buffer,当indexing buffer满了的时候,会触发刷盘操作,indexing buffer的大小由以下配置确定:
- indices.memory.index_buffer_size
默认为整个堆空间的10%,indexing buffer是针对shard的,每个shard都有自己的indexing buffer,所以这个配置需要除以所在节点所有的shard数目。 - indices.memory.min_index_buffer_size
indexing buffer的最小值,默认为48MB。 - indices.memory.max_index_buffer_size
indexing buffer的最大值,默认为无限制。
当存在大量的数据索引的时候,可以适当的增加indexing buffer,减少刷盘的操作。
06
优化段合并
要避免写入的过程中出现大量的段合并,因为段合并会对I/O和内存有比较大的压力,从ES2.X开始通过以下配置来控制段合并策略:
- index.merge.scheduler.max_thread_count
配置用于segments merge的最大线程数目,默认为Math.max(1,Math.min(4,Runtime.getRuntime().availableProcessors()/2)),如果只有一块硬盘且非SSD,则应该设置为1,因为旋转存储介质每次需要寻址,无法实现并发写,多个线程导致竞争,写入速度更慢。 - index_merge.policy.*
配置merge的策略,默认有三种策略: tiered(默认)、log_byete_size、log_doc,索引创建以后策略就被确定下来无法更改,但可以动态更新策略参数,例如如果merge比较多的话,可以调整index.merge.policy.segments_per_tier,该属性指定了每层分段的数量,值越小,segments越少,则merge操作越多.可以适当增加该值,减少merge。 - index_merge.policy.max_merged_segment
指定单个segment的最大容量,默认为5GB,可以根据需要适当调小此值，因为此值越大也就意味着可以合并更多的segment。
07
使用bulk请求
批量写比单写一个文档的效率更高,可以适当使用bulk请求来提升写入效率,不过要注意请求的整体字节数不要太大,以免对内存造成压力。
bulk请求属于计算密集型的操作,应该设置固定大小的线程池,建议CPU核心数+1,不宜过多导致大量的线程上下文切换,同时,配置适当大小的队列长度,来不及处理的请求放入队列之中。
08
shard均匀分布
通过配置path.data为多个目录，每个目录挂载不同的磁盘，享受磁盘的并行读取和写入，相当于实现了RAID 0，提升了写入的能力，并且因为elasticsearch本身具备副本机制，所以一定程度上也保证了数据的安全性。
09
优化Lucene索引过程
从Lucene索引的过程出发，减少中间过程消耗的时间，降低CPU占用率及I/O，主要有以下方面：
- 索引文档时使用自动生成doc ID的方式,不要指定id,因为指定id会涉及到读取原来的doc版本号的操作。
- 认真考虑字段是否可能使用到,没使用到的字段不要放入Elasticsearch。
- 不需要被索引的字段的index属性设置为not_analyzed或者no。
- 减少被索引的字段的长度,只保留必要的长度。
- Elasticsearch6.0之前的版本,禁用all字段,使用特定字段的查询代替all类型的查询,例如query_string和simple_query_string,这样子可以减少内存损耗和复制操作。
- 如果不在乎评分,则对于Analyzed的字段在mapping中将norms设置为false,禁用norms,节省一些写操作和空间。