@TOC
前言
ES 的默认配置，是综合了数据可靠性、写入速度、搜索实时性等因素。实际使用时，我们需要根据公司要求，进行偏向性的优化。
对于写入优化，综合来说，可以考虑以下几个方面来提升写索引的性能：
- [ ] 加大 Translog Flush ，目的是降低 Iops、Writeblock
- [ ] 增加 Index Refresh 间隔，目的是减少 Segment Merge 的次数
- [ ] 调整 Bulk 线程池和队列
- [ ] 优化节点间的任务分布
- [ ] 优化 Lucene 层的索引建立，目的是降低 CPU 及 IO
1、bulk批量写入
- 如果业务场景支持将一批数据聚合起来，一次性写入Elasticsarch，那么尽量采用bulk的方式，bulk批量写入的速度远高于一条一条写入大量document的速度。
- 并不是bulk size越大越好，而是根据写入数据量具体来定的，因为越大的bulk size会导致内存压力过大。
- Bulk 默认设置批量提交的数据量不能超过 100M。数据条数一般是根据文档的大小和服务器性能而定的，但是单次批处理的数据大小应从
5MB～15MB 逐渐增加，当性能没有提升时，把这个数据量作为最大值,计算公式为：
一次bulk写入的数据量大小=一次bulk批量写入的文档数*每条数据量的大小。
2、多线程写入
- 单线程发送bulk请求是无法最大化Elasticsearch集群写入的吞吐量的。如果要利用集群的所有资源，就需要使用多线程并发将数据bulk写入集群中。多线程并发写入同时可以减少每次底层磁盘fsync的次数和开销。
- 一旦发现ES返回了TOO_MANY_REQUESTS的错误，JavaClient也就是EsRejectedExecutionException。此时说明Elasticsearch已经达到了一个并发写入的最大瓶颈了。推荐使用CPU核数的2倍线程数。
3、修改索引刷新时间
为了提高索引性能，Elasticsearch 在写入数据时候，采用延迟写入的策略，即数据先写到内存中，默认情况下索引的refresh_interval为1秒，当超过默认 1 秒 （index.refresh_interval）会进行一次写入操作，就是将内存中 segment 数据刷新到操作系统中，这意味着数据写1秒后就可以被搜索到，所以这就是为什么 Elasticsearch 提供的是近实时搜索功能，而不是实时搜索功能,每次索引的 refresh 会产生一个新的 lucene 段,这会导致频繁的 segment merge 行为。
当然像我们目前的场景对数据延迟要求不高的话，我们可以通过延长 refresh 时间间隔，可以有效的减少 segment 合并压力，提供索引速度。
甚至，在进行全量索引时，可以将 refresh 次数临时关闭，即 index.refresh_interval 设置为 -1，数据导入成功后再打开到正常模式，比如 30s。
以bvd_entity索引为例，我们最终调整修改索引刷新时间间隔为180s：
curl -XPUT --tlsv1.2 --negotiate -k -v -u : "https://192.168.1.101:24100/bvd_entity/_settings" -H 'Content-Type: application/json' -d'
{
"refresh_interval": "180s"
}'4、修改merge参数以及线程数
Elasticsearch写入数据时，refresh刷新会生成1个新的segment，segments会按照一定的策略进行索引段合并merge。merge的频率对写入和查询的速度都有一定的影响，如果merge频率比较快，会占用较多的IO，影响写入的速度，但同时segment个数也会比较少，可以提高查询速度。所以merge频率的设定需要根据具体业务去权衡，同时保证写入和查询都相对快速。Elasticsearch默认使用TieredMergePolicy，可以通过参数去控制索引段合并merge的频率：
1).参数“index.merge.policy.floor_segment”，Elasticsearch避免产生很小的segment，小于这个阀值的所有的非常小的segment都会merge直到达到这个floor的size，默认是2MB。
2).参数“index.merge.policy.max_merge_at_once”，一次最多只merge多少个segments，默认是10。
3).参数“index.merge.policy.max_merged_segment”，超过多大size的segment不会再做merge，默认是5g。
4).参数“index.merge.policy.segment_per_tier”默认为10，表示每个tier允许的segment个数，注意这个值要大于等于“index.merge.policy.max_merge_at_once”值，否则这个值会先于最大可操作数到达，就会立刻做merge，这样会造成频繁merge。
5).参数“ index.merge.scheduler.max_thread_count
”，单个shard上可能同时合并的最大线程数。默认会启动 Math.max(1, Math.min(4,
Runtime.getRuntime().availableProcessors() / 2))
个线程进行merge操作，适用于SSD固态硬盘。但是如果硬盘是机械硬盘，很容易出现IO阻塞，将线程数设置为1。
一般情况下，通过调节参数index.merge.policy.max_merge_at_once和index.merge.policy.segment_per_tier去控制merge的频率。
| 参数修改 | 好处 | 坏处 |
|---|---|---|
| 提高“index.merge.policy.max_merge_at_once”和“index.merge.policy.segment_per_tier”参数值 | 提升indexing速度 | 减少了segment merge动作的发生，意味着更多的segments，会降低searching速度 |
| 降低“index.merge.policy.max_merge_at_once”和“index.merge.policy.segment_per_tier”参数值 | Segments更少，即能够提升searching速度 | 更多的segments merge操作，会花费更多系统资源(CPU/IO/RAM)，会降低indexing速度 |
修改参数命令如下示例：
curl -XPUT --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex-001/_settings?pretty" -H 'Content-Type: application/json' -d'
{
"merge":{
"scheduler":{
"max_thread_count" : "1"
},
"policy":{
"segments_per_tier" : "20",
"max_merge_at_once": "20"，
"floor_segment" : "2m",
"max_merged_segment" : "5g"
}
}
}'5、事务日志translog调整
translog写入了一份全量的数据，它有点像MysSQL中的binlog(记录所有数据库表结构变更(例如CREATE、ALTER TABLE…)以及表数据修改(INSERT、UPDATE、DELETE…)的二进制日志)，用来保证异常情况下的数据安全。这是因为，我们把数据写到磁盘后，还要调用fsync才能把数据刷到磁盘中，如果不这样做在系统掉电的时候就会导致数据丢失。在ES 2.x开始，默认情况下，translog的持久化策略为：每个请求都“flush”。
对应配置:index.translog.durability:request
以bvd_entity索引为例，我们的事物日志调整为：
curl -XPUT --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/bvd_entity/_settings" -H 'Content-Type: application/json' -d'
{
"translog" : {
"flush_threshold_size" : "1g",--当translog的大小达到此值时会进行一次flush操作
"sync_interval" : "180s",--设置刷盘时间为180s
"durability" : "async" --设置translog策略为异步
},
}'6、index buffer
indexing buffer 在为doc建立索引时使用，当缓冲满时会刷入磁盘，生成一个新的segment,这是除了refresh_interval 刷新索引外，另一个生成新segment的机会。每个shard有自己的indexing buffer,下面的这个buffer大小的配置需要除以这个节点上索引shard的数量：
indices.memory.index_buffer_size 默认是整个堆空间的10%
indices.memory.min_index_buffer_size 默认48MB
indices.memory.max_index_buffer_size 默认无限制
在执行大量的索引操作时，indices.memory.index_buffer_size的默认设置可能不够，这和可用堆内存，单节点上的shard数量相关，可以考虑适当增大该值。
7、磁盘间的任务均衡
ES 在分配shard的时候，落到各个磁盘的shard可能并不均匀，这种不均匀可能导致某些磁盘繁忙，对写入性能会产生一定的影响。
为了让各个实例上的分片均匀分布，添加如下参数，设置每个索引在单个实例上的分片个数，如下所示为每个索引在每个实例上的分片为2个。
curl -XPUT --tlsv1.2 --negotiate -k -u : "https://ip:httpport/myindex/_settings?pretty' -H 'Content-Type:application/json' -d '
{
"index.routing.allocation.total_shards_per_node":"2"
}'8、Mapping优化
8.1、自动生成docID(避免ES对自定义ID验证的操作)
分析 es 写入流程可以知道,写入 doc 时如果是外部指定了 id,es 会先尝试读取原来doc的版本号, 判断是否需要更新,使用自动生成 doc id 可以避免这个环节。
8.2、调整字段Mapping
- 减少不必要的字段数量
- 将不需要建立索引字段的index属性设置为not_analyzed或no。对字段不分词或不建立索引，减少相应的操作，特别是binary类型
- 减少字段内容长度
- 使用不同的分析器（analyzer），不同分析器之间的运算复杂度也不相同
8.3、调整_source字段
“_source”字段包含在索引时传递的原始JSON文档正文。该“_source”字段本身不被索引（因此是不可搜索的），但它被存储，以便在执行撷取请求时可以返回，例如get或search。
虽然很方便，但是“_source”字段确实在索引中有不小的存储开销。因此，可以使用如下方式禁用:
curl -XPUT --tlsv1.2 --negotiate -k -u : 'https://ip:httpport/tweets?pretty' -H 'Content-Type: application/json' -d'
{
"mappings": {
"tweet": {
"_source": {
"enabled": false
}
}
}
}'在禁用_source 字段之前请注意：如果_source字段不可用，则不支持以下功能：
- update，update_by_query，reindex APIs.
- 高亮
- 将索引从一个Elasticsearch索引reindex（重索引）到另一个索引的能力，以便更改映射或分析，或将索引升级到新的主要版本。
- 通过查看索引时使用的原始文档来调试查询或聚合的能力。
- 潜在的未来可能会自动修复索引损坏的能力。
所以，一般真实场景下，这个字段不会被禁用。
8.4、禁用_all
_all字段中包含所有字段分词后的关键词，作用是可以搜索的时候不指定特定字段，从所有字段所有中减少，如果我们明确知道要检索哪些字段，就可以选择将这个字段禁用，否则会额外增加索引存储开销。
8.5、禁用Norms
Norms用于在搜索时计算doc的评分，如果不需要评分，则可以将其禁用：
"title":{"type":"string","norms":{"enabled":false}}8.6、index_options设置
index_options用于控制在建立倒排索引过程中，哪些内容会被添加到倒排索引中，例如：
"index_options" : "docs" ,
# 4个可选参数
# docs（索引文档号）,
# freqs（文档号 + 词频），
# positions（文档号 + 词频 + 位置，通常用来距离查询），
# offsets（文档号 + 词频 + 位置 + 偏移量，通常被使用在高亮字段）优化这些设置可以一定程度上降低索引过程中的计算任务，接收CPU占用率。
9、优化存储
ES 是一种密集使用磁盘的应用，在段合并的时候会频繁操作磁盘，所以对磁盘要求较高，当磁盘速度提升之后，集群的整体性能会大幅度提高。
磁盘的选择，提供以下几点建议：
- 使用 SSD。就像其他地方提过的，他们比机械磁盘优秀多了。
- 使用 RAID 0。条带化 RAID 会提高磁盘 I/O，代价显然就是当一块硬盘故障时整个就故障了。不要使用镜像或者奇偶校验 RAID
因为副本已经提供了这个功能。 - 另外，使用多块硬盘，并允许 Elasticsearch 通过多个 path.data 目录配置把数据条带化分配到它们上面,如下所示：
path.data:/path/to/data1,/path/to/data2。 - 不要使用远程挂载的存储，比如 NFS 或者 SMB/CIFS。这个引入的延迟对性能来说完全是背道而驰的。
总结
通过上面优化手段，博主亲测优化效率：
- [x] 优化后，每秒写入速度从900+ 提升到每秒2.9万左右，截图如下：
- [x] 查询性能，由原来的8.4秒，降低到2秒，为了不涉密截图不能放
