Elasticsearch写入速度优化
文章目录
背景
在ES的默认设置下，是综合考虑数据可靠性、搜索实时性、写入速度等因素的。有时候，业务上对数据可靠性和搜索实时性要求并不高，反而对写入速度要求很高，此时可以调整一些策略，最大化写入速度。综合来说，提升写入速度从以下几方面入手：
- 加大translog flush间隔，目的是降低iops、writeblock。
- 加大index refresh间隔，除了降低I/O，更重要的是降低了segment merge频率。
- 调整bulk请求。
- 优化磁盘间的任务均匀情况，将shard尽量均匀分布到物理主机的各个磁盘。
- 优化节点间的任务分布，将任务尽量均匀地发到各节点。
- 优化Lucene层建立索引的过程，目的是降低CPU占用率及I/O，例如，禁用_all字段。
一个系统性问题往往是多种因素造成的，在处理集群的写入性能问题上，先将问题分解，在单台上进行压测，观察哪种系统资源达到极限，例如，CPU或磁盘利用率、I/O block、线程切换、堆栈状态等。然后分析并调整参数，优化单台上的能力，先解决局部问题，在此基础上解决整体问题会容易得多。
translog flush间隔调整
在默认设置下，translog的持久化策略为：每个请求都“flush”。对应配置项如下：
index.translog.durability: request
这是影响ES写入速度的最大因素。但是只有这样，写操作才有可能是可靠的。如果系统可以接受一定概率的数据丢失，则调整translog持久化策略为周期性和一定大小的时候“flush”。如下配置表示translog的刷盘策略按sync_interval配置的120s时间周期进行，或当超过1024mb大小也会导致refresh操作，产生新的Lucene分段。
index.translog.durability: async
index.translog.sync_interval: 120s (default 5s)
index.translog.flush_threshold_size: 1024mb (default 512mb)
索引刷新间隔refresh_interval
默认情况下索引的refresh_interval为1秒，这意味着数据写1秒后就可以被搜索到，每次索引的refresh会产生一个新的Lucene段，这会导致频繁的segment merge行为，如果不需要这么高的搜索实时性，应该降低索引refresh周期，例如：
index.refresh_interval: 120s (default 1s)
段合并优化
segment merge操作对系统I/O和内存占用都比较高，merge行为由Lucene控制，配置如下。最大线程数max_thread_count的默认值是一个比较理想的值，如果只有一块硬盘并且非SSD，则应该把它设置为1，因为在旋转存储介质上并发写，由于寻址的原因，只会降低写入速度。
index.merge.scheduler.max_thread_count (default Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors()/2)))
index.merge.policy.*
merge策略有三种：
- tiered（默认策略）：分层合并策略，该策略将大小相似的段放在一起合并，当然段的数量会限制在每层允许的最大数量之中。
- log_byte_size：字节大小对数合并策略，将创建由多个大小处于对数运算后大小在指定范围索引组成的索引。
- loc_doc：文档数量对数合并策略，与log_byte_size策略类似，只是将以段的字节大小来计算的方式换成了文档数量。
索引创建时合并策略就已确定，不能更改，但是可以动态更新策略参数。如果堆栈经常有很多merge，则可以考虑适当增加index.merge.policy.segments_per_tier配置的值（该配置指定了每层分段的数量，取值越小则最终segment越少，因此需要merge的操作越多，可以考虑适当增加此值）。同时可以考虑适当降低index.merge.policy.max_merged_segment的值（指定了单个segment的最大容量）。
index.merge.policy.segments_per_tier (default 10，其应该大于等于index.merge.policy.max_merge_at_once。)
index.merge.policy.max_merged_segment (default 5GB)
indexing buffer
indexing buffer在为doc建立索引时使用，当缓冲满时会刷入磁盘，生成一个新的segment，这是除refresh_interval刷新索引外，另一个生成新segment的机会。每个shard有自己的indexing buffer，indices.memory.index_buffer_size大小的配置需要除以这个节点上所有shard的数量，可以考虑适当增大该值（在执行大量的索引操作时，默认设置可能不够，这和可用堆内存、单节点上的shard数量相关）。
indices.memory.index_buffer_size （默认为整个堆空间的10%）
indices.memory.min_index_buffer_size （默认为48MB）
indices.memory.max_index_buffer_size （默认为无限制）
使用bulk请求
批量写比一个索引请求只写单个文档的效率高得多，但是要注意bulk请求的整体字节数不要太大，太大的请求可能会给集群带来内存压力，因此每个请求最好避免超过几十M字节，即使较大的请求看上去执行得更好。
bulk线程池和队列
建立索引的过程属于计算密集型任务，应该使用固定大小的线程池配置，来不及处理的任务放入队列。线程池最大线程数量应配置为CPU核心数+1，这也是bulk线程池的默认设置，可以避免过多的上下文切换。队列大小可以适当增加，但一定要严格控制大小，过大的队列导致较高的GC压力，并可能导致Full GC频繁发生。
并发执行bulk请求
bulk写请求是个长任务，为了给系统增加足够的写入压力，写入过程应该多个客户端、多线程地并行执行，如果要验证系统的极限写入能力，那么目标就是把CPU压满。磁盘util、内存等一般都不是瓶颈。如果CPU没有压满，则应该提高写入端的并发数量。但是要注意bulk线程池队列的reject情况，出现reject代表ES的bulk队列已满，客户端请求被拒绝，此时客户端会收到429错误（TOO_MANY_REQUESTS），客户端对此的处理策略应该是延迟重试。不可忽略这个异常，否则写入系统的数据会少于预期。即便客户端正确处理了429错误，我们仍然应该尽量避免产生reject。因此，在评估极限的写入能力时，客户端的极限写入并发量应该控制在不产生reject前提下的最大值为宜。
磁盘间的任务均衡
如果部署方案是为path.data配置多个路径来使用多块磁盘，则ES在分配shard时，落到各磁盘上的shard可能并不均匀，这种不均匀可能会导致某些磁盘繁忙，利用率在较长时间内持续达到100%。这种不均匀达到一定程度会对写入性能产生负面影响。
ES在处理多路径时，优先将shard分配到可用空间百分比最多的磁盘上（预估一下shard会使用的空间，从磁盘可用空间中减去这部分），因此短时间内创建的shard可能被集中分配到这个磁盘上，即使可用空间是99%和98%的差别。
从可用空间减去预估大小的机制只存在于一次索引创建的过程中，下一次的索引创建，磁盘可用空间并不是上次做完减法以后的结果。最终的效果是，这种机制并没有从根本上解决问题，即使没有完美的解决方案，这种机制的效果也不够好。
节点间的任务均衡
为了节点间的任务尽量均衡，数据写入客户端应该把bulk请求轮询发送到各个节点。当使用Java API或REST API的bulk接口发送数据时，客户端将会轮询发送到集群节点，节点列表取决于：
- 使用Java API时，当设置client.transport.sniff为true（默认为false）时，列表为所有数据节点，否则节点列表为构建客户端对象时传入的节点列表。
- 使用REST API时，列表为构建对象时添加进去的节点。
Java API的TransportClient和REST API的RestClient都是线程安全的，如果写入程序自己创建线程池控制并发，则应该使用同一个Client对象。在此建议使用REST API，Java API会在未来的版本中废弃，REST API有良好的版本兼容性。理论上，Java API在序列化上有性能优势，但是只有在吞吐量非常大时才值得考虑序列化的开销带来的影响，通常搜索并不是高吞吐量的业务。
要观察bulk请求在不同节点间的均衡性，可以通过cat接口观察bulk线程池和队列情况：
_cat/thread_pool
索引过程调整和优化
自动生成doc ID
通过ES写入流程可以看出，导入doc时如果外部指定了id，则ES会先尝试读取原来doc的版本号，以判断是否需要更新。这会涉及一次读取磁盘的操作，通过自动生成doc ID可以避免这个环节。
调整字段Mappings
- 减少字段数量，对于不需要建立索引的字段，不写入ES。
- 将不需要建立索引的字段index属性设置为not_analyzed或no。对字段不分词，或者不索引，可以减少很多运算操作，降低CPU占用。尤其是binary类型，默认情况下占用CPU非常高，而这种类型进行分词通常没有什么意义。
- 减少字段内容长度，如果原始数据的大段内容无须全部建立索引，则可以尽量减少不必要的内容。
- 使用不同的分析器（analyzer），不同的分析器在索引过程中运算复杂度也有较大的差异。
调整_source字段
_source字段用于存在doc原始数据，对于部分不需要存储的字段，可以通过includes excludes过滤，或者将_source禁用，一般用于索引和数据分离。
这样可以降低I/O的压力，不过实际场景中大多不会禁用_source，而即使过滤掉某些字段，对于写入速度的提升作用也不大，满负荷写入情况下，基本是CPU先跑满了，瓶颈在于CPU。
禁用_all字段
禁用_all字段可以明显降低对CPU和I/O的压力，_all字段默认为不启用。_all字段中包含所有分段分词后的关键词，作用是可以在搜索的时候不指定特定字段，从所有字段中检索。默认禁用_all字段主要有以下几点原因：
- 由于需要从其他的全部字段复制所有字段值，导致_all字段占用非常大的空间。
- _all字段有自己的分析器，在进行某些查询时（例如，同义词），结果不符合预期，因为没有匹配同一个分析器。
- 由于数据重复引起的额外建立索引的开销。
- 想要调试时，其内容不容易检查。
- 有些用户甚至不知道存在这个字段，导致了查询混乱。
- 有更好的替代方法。
对Analyzed的字段禁用Norms
Norms用于在搜索时计算doc的评分，如果不需要评分，则可以将其禁用。
PUT my-index/_mapping
{
"properties": {
"title": {
"type": "text",
"norms": false
}
}
}
index_options设置
index_options用于控制在建立倒排索引过程中，哪些内容会被添加到倒排索引，例如，doc数量、词频、positions、offsets等信息，优化这些设置可以一定程度降低索引过程中的运算任务，节省CPU占用率。