【翻译】Elasticsearch索引性能优化（2）
nodexy 发表了文章 • 0 个评论 • 137 次浏览 • 2017-10-15 13:41
本文翻译自QBox官方博客的“Elasticsearch索引性能优化”系列文章中的第二篇，版权归原作者 Adam Vanderbush所有。该系列文章共有三篇，其中第一篇已有同行翻译，参考链接http://www.zcfy.cc/article/how ... .html 后续还会有第三篇的推送，敬请关注。
作者：Adam Vanderbush
译者：杨振涛@vivo
本系列文章重点关注如何最大化地提升elasticsearch的索引吞吐量和降低监控与管理负荷。
Elasticsearch是准实时的，这表示当索引一个文档后，需要等待下一次刷新后就可以搜索到该文档了。
刷新是一个开销较大的操作，这就是为什么默认要设置一个特定的间隔，而不是每索引一个文档就刷新一次。如果想索引大批量的文档，并不需要立刻就搜索到新的索引信息，为了优化索引性能甚至搜索性能，可以临时降低刷新的频率，直到索引操作完成。
一个索引库的分片由多个段组成。Lucene的核心数据结构中，一个段本质上是索引库的一个变更集。这些段是在每次刷新时所创建，随后会在后台合并到一起，以保证资源的高效使用；每个段都会消耗文件句柄、内存和CPU。工作在该场景背后的Lucene负责段的合并，一旦处理不当，可能会消耗昂贵的计算资源并导致Elasticsearch自动降级索引请求到一个单一线程上。
本文将继续关注Elasticsearch的索引性能调优，重点聚焦在集群和索引级别的各种索引配置项设置。
1 关注refresh_interval参数
这个间隔通过参数index.refresh_interval设置，既可以在Elasticsearch配置文件里全局设置，也可以针对每一个索引库单独设置。如果同时设置，索引库设置会覆盖全局配置。默认值是1s，因此最新索引的文档最多不超过1s后即可搜索到。
因为刷新是非常昂贵的操作，提升索引吞吐量的方式之一就是增大refresh_interval；更少的刷新意味着更低的负载，并且更多的资源可以向索引线程倾斜。因此，根据搜索需求，可以考虑设置刷新间隔为大于1秒的值；甚至可以考虑在某些时候，比如执行批量索引时，临时关闭索引库的刷新操作，执行结束后再手动打开。
更新设置API可以在批量索引时动态改变索引以便更加高效，然后再修改为更加实时的索引状态。在批量索引开始前，设置：$(document).ready(function() {$('pre code').each(function(i, block) { hljs.highlightBlock( block); }); });curl -XPUT 'localhost:9200/test/_settings' -d '{
"index" : {
"refresh_interval" : "-1"
}
}'
如果要做一次较大的批量导入，可以考虑设置index.number_of_replicas: 0来禁止副本。当设置了副本后，整个文档会被发送到副本节点，并重复索引过程；这意味着每个副本都会执行分析、索引及可能的合并操作。反之，如果索引时设置0副本，完成后再打开副本支持，恢复过程实质上只是一个网络字节流传输的过程，这比重复索引过程要高效得多了。curl -XPUT 'localhost:9200/my_index/_settings' -d ' {
"index" : {
"number_of_replicas" : 0
}
}'
然后一旦批量索引完成，即可更新设置（比如恢复成默认设置）：curl -XPUT 'localhost:9200/my_index/_settings' -d '{
"index" : {
"refresh_interval" : "1s"
}
}'
并且可以强制触发一次合并：curl -XPOST 'localhost:9200/my_index/_forcemerge?max_num_segments=5'
刷新API支持显式地刷新一个或多个索引库，以便让上次刷新后的所有操作完成并可被搜索感知。实时或近实时能力取决于所使用的索引引擎。比如，内置引擎要求显式调用刷新，而默认地刷新是周期性执行的。curl -XPOST 'localhost:9200/my_index/_refresh'
2 段与合并
段合并是一个计算开销较大的操作，而且会消耗大量的磁盘I/O。由于合并操作比较耗时，尤其是较大的段，所以一般设定为后台执行；这也没什么太大问题，因为大段的合并相对还是比较少的。
但也有时候，合并速率会低于生产速率；一旦如此，Elasticsearch将会自动地限流索引请求到一个单一线程。这能阻止段爆发问题，否则在合并前可能会生成数百个段。
Elasticsearch在这里默认是比较保守的：不希望搜索性能受到后台合并操作的挤兑；但有时（尤其是使用SSD，或写日志的场景）节流限制会过低。
默认的20 MB/s对于传统机械磁盘是一个挺不错的设置；如果使用SSD，可能要考虑加大该设置到100–200 MB/s。curl -XPUT 'localhost:9200/test/_settings' -d '{
"index" : {
"refresh_interval" : "-1"
}
}'
如果正在做批量导入，且根本不介意搜索，就可以彻底关闭合并限流；这样索引操作就会根据磁盘的速率尽可能快地执行：curl -XPUT 'localhost:9200/_cluster/settings' -d '{
"transient" : {
"indices.store.throttle.type" : "none"
}
}'
设置限流类型为none就可以完全关闭合并限流；等批量导入完成后再恢复该配置项为merge。curl -XPUT 'localhost:9200/_cluster/settings' -d '{
"transient" : {
"indices.store.throttle.type" : "merge"
}
}'
注意：上面的设置只适用于Elasticsearch 1.X版本，Elasticsearch 2.X移除了索引级别的速率限制（indices.store.throttle.type、 indices.store.throttle.max_bytes_per_sec、index.store.throttle.type、 index.store.throttle.max_bytes_per_sec），下沉到Lucene的ConcurrentMergeScheduler，以自动管理限流。
合并调度器（ConcurrentMergeScheduler）在需要时会控制合并操作的执行。合并操作运行在独立的线程池中，一旦达到最大线程数，更多的合并请求将会阻塞等待，直到有可用的合并线程。
合并调度器支持下列动态设置：
index.merge.scheduler.max_thread_count
最大线程数默认为 Math.max(1,Math.min(4,Runtime.getRuntime().availableProcessors() / 2))，对于固态硬盘（SSD）工作得很好；如果使用传统机械硬盘，则降低到1。
机械介质在并发I/O方面有较大的时间开销，因此需要减少线程数，以便能按索引并发访问磁盘。该设置允许每次有max_thread_count + 2个线程操作磁盘，所以设置为1表示支持3个线程。
如果使用机械硬盘而不是SSD，就要在elasticsearch配置文件中加入以下配置：
index.merge.scheduler.max_thread_count: 1
当然也可以为单个索引库设置：curl -XPUT 'localhost:9200/my_index/_settings' -d '{
"index.merge.scheduler.max_thread_count" : 1
}'
为所有已创建的索引库设置：curl -XPUT 'localhost:9200/_settings' -d '{
"index.merge.scheduler.max_thread_count" : 1
}'
3 事务日志的清理
在节点挂掉时事务日志可以防止数据丢失，设计初衷是帮助在flush时原本丢失的分片恢复运行。该日志每5秒，或者在每个索引、删除、更新或批量请求（不管先后顺序）完成时，会提交到磁盘一次。
对Lucene的变更仅会在一次Lucene提交后持久化到磁盘，Lucene提交是比较重量级的操作，索引不能再每个索引或删除操作后就执行。当进程退出或硬件故障时，一次提交后或另一次提交前的变更将会丢失。
为防止这些数据丢失，每个分片有一个事务日志，或者与之关联的预写日志。任何索引或删除操作，在内置的Lucene索引处理完成后都是写到事务日志中。崩溃发生后，就可以从事务日志回放最近的事务来恢复分片。
Elasticsearch的flush操作，本质上是执行了一次Lucene提交并启动了一个新的事务日志；这些都是在后台自动完成的，目的是确保事务日志不会变得过大，否则恢复数据期间的回放操作可能需要消耗相当长的时间。这个功能同样暴露了一个API供调用，虽然很少需要手动触发。
与刷新（refresh）一个索引分片相比，真正昂贵的操作是flush其事务日志（这涉及到Lucene提交）。Elasticsearch基于许多随时可变的定时器来执行flush。通过延迟flush或者彻底关闭flush可以提升索引吞吐量。不过并没有免费的午餐，延迟flush最终实际执行时显然会消耗更长的时间。
下列可动态更新的配置控制着内存缓存刷新到磁盘的频率：
index.translog.flush_threshold_size - 一旦事务日志达到这个值，就会发生一次flush；默认值为512mb。
index.translog.flush_threshold_ops - 在多少操作后执行flush，默认无限制。
index.translog.flush_threshold_period - 触发一次flush前的等待时间，不管日志大小，默认值为30分钟。
index.translog.interval - 检查是否需要flush的时间间隔，随机在该时间到2倍之间取值，默认为5秒。
可以把index.translog.flush_threshold_size的值从默认值的512MB调大比如到1GB，这样在一次flush发生前就可以在日志中积累更大的段。通过构建更大的段，就可以减少flush的次数以及大段的合并次数。所有这些措施加起来就会减少磁盘I/O并获得更好的索引效率。
当然，这需要一定数量的可用堆内存，用于额外的缓存空间，所以调整此类配置时请注意这一点。
4 索引缓冲区的容量规划
索引缓冲区用于存储新的索引文档，如果满了，缓冲区的文档就会写到磁盘上的一个段。节点上所有分片的缓冲区都是独立的。
下列配置项是静态的，并且必须在集群的每个数据节点上都配置：
indices.memory.index_buffer_size - 可设置为百分比或者字节数大小，默认是10%，表示总内存的10%分配给该节点，作为索引缓冲区大小，全局共享。
indices.memory.min_index_buffer_size - 如果index_buffer_size设置为百分比，那么这项配置用于指定一个绝对下限，默认是48MB。
indices.memory.max_index_buffer_size - 如果index_buffer_size设置为百分比，那么这项配置用于指定一个绝对上限，默认是无限制。
配置项indices.memory.index_buffer_size定义了可供索引操作使用的堆内存百分比（剩余堆内存将主要用于检索操作）。如果要索引很多数据，默认的10%可能会太小，有必要调大该值。
5 索引和批量操作的线程池大小
接下来试试在节点级别调大索引和批量操作的线程池大小，看看否带来性能提升。
index - 用于索引和删除操作。线程类型是固定大小的（fixed)，默认大小是可用处理器核数，队列大小queue_size是200，该线程池最大为1+可用处理器核数。
bulk - 用于批量操作。线程类型是固定大小的，默认大小是可用处理器核数，队列大小是50，线程池最大为1+可用处理器核数。
单个分片与独立的Lucene是一个层次，因此同时执行索引的并发线程数是有上限的，在Lucene中默认是8，而在ES中可以通过index.index_concurrency配置项来设置。
在为该参数设置默认值时应当多想一想，特别是对于往一个索引库索引数据时，一个节点只有一个分片的情况。
由于索引/批量线程池可以保护和控制并发，所以大部分时候都可以考虑调大默认值；尤其是对于节点上没有其他分片的情况（评估是否值得），可以考虑调大该值。
关于译者
杨振涛
vivo互联网搜索引擎团队负责人，开发经理。10年数据和软件领域经验，先后从事基因测序、电商、IM及厂商互联网领域的系统架构设计和实现。专注于实时分布式系统和大数据的存储、检索和可视化，尤其是搜索引擎及深度学习在NLP方向的应用。技术翻译爱好者，TED Translator，InfoQ中文社区编辑。
未经授权，禁止转载。
英文原文地址：https://qbox.io/blog/maximize- ... art-2 查看全部
作者：Adam Vanderbush
译者：杨振涛@vivo
本系列文章重点关注如何最大化地提升elasticsearch的索引吞吐量和降低监控与管理负荷。
Elasticsearch是准实时的，这表示当索引一个文档后，需要等待下一次刷新后就可以搜索到该文档了。
刷新是一个开销较大的操作，这就是为什么默认要设置一个特定的间隔，而不是每索引一个文档就刷新一次。如果想索引大批量的文档，并不需要立刻就搜索到新的索引信息，为了优化索引性能甚至搜索性能，可以临时降低刷新的频率，直到索引操作完成。
一个索引库的分片由多个段组成。Lucene的核心数据结构中，一个段本质上是索引库的一个变更集。这些段是在每次刷新时所创建，随后会在后台合并到一起，以保证资源的高效使用；每个段都会消耗文件句柄、内存和CPU。工作在该场景背后的Lucene负责段的合并，一旦处理不当，可能会消耗昂贵的计算资源并导致Elasticsearch自动降级索引请求到一个单一线程上。
本文将继续关注Elasticsearch的索引性能调优，重点聚焦在集群和索引级别的各种索引配置项设置。
1 关注refresh_interval参数
这个间隔通过参数index.refresh_interval设置，既可以在Elasticsearch配置文件里全局设置，也可以针对每一个索引库单独设置。如果同时设置，索引库设置会覆盖全局配置。默认值是1s，因此最新索引的文档最多不超过1s后即可搜索到。
因为刷新是非常昂贵的操作，提升索引吞吐量的方式之一就是增大refresh_interval；更少的刷新意味着更低的负载，并且更多的资源可以向索引线程倾斜。因此，根据搜索需求，可以考虑设置刷新间隔为大于1秒的值；甚至可以考虑在某些时候，比如执行批量索引时，临时关闭索引库的刷新操作，执行结束后再手动打开。
更新设置API可以在批量索引时动态改变索引以便更加高效，然后再修改为更加实时的索引状态。在批量索引开始前，设置：$(document).ready(function() {$('pre code').each(function(i, block) { hljs.highlightBlock( block); }); });curl -XPUT 'localhost:9200/test/_settings' -d '{
"index" : {
"refresh_interval" : "-1"
}
}'
如果要做一次较大的批量导入，可以考虑设置index.number_of_replicas: 0来禁止副本。当设置了副本后，整个文档会被发送到副本节点，并重复索引过程；这意味着每个副本都会执行分析、索引及可能的合并操作。反之，如果索引时设置0副本，完成后再打开副本支持，恢复过程实质上只是一个网络字节流传输的过程，这比重复索引过程要高效得多了。curl -XPUT 'localhost:9200/my_index/_settings' -d ' {
"index" : {
"number_of_replicas" : 0
}
}'
然后一旦批量索引完成，即可更新设置（比如恢复成默认设置）：curl -XPUT 'localhost:9200/my_index/_settings' -d '{
"index" : {
"refresh_interval" : "1s"
}
}'
并且可以强制触发一次合并：curl -XPOST 'localhost:9200/my_index/_forcemerge?max_num_segments=5'
刷新API支持显式地刷新一个或多个索引库，以便让上次刷新后的所有操作完成并可被搜索感知。实时或近实时能力取决于所使用的索引引擎。比如，内置引擎要求显式调用刷新，而默认地刷新是周期性执行的。curl -XPOST 'localhost:9200/my_index/_refresh'
2 段与合并
段合并是一个计算开销较大的操作，而且会消耗大量的磁盘I/O。由于合并操作比较耗时，尤其是较大的段，所以一般设定为后台执行；这也没什么太大问题，因为大段的合并相对还是比较少的。
但也有时候，合并速率会低于生产速率；一旦如此，Elasticsearch将会自动地限流索引请求到一个单一线程。这能阻止段爆发问题，否则在合并前可能会生成数百个段。
Elasticsearch在这里默认是比较保守的：不希望搜索性能受到后台合并操作的挤兑；但有时（尤其是使用SSD，或写日志的场景）节流限制会过低。
默认的20 MB/s对于传统机械磁盘是一个挺不错的设置；如果使用SSD，可能要考虑加大该设置到100–200 MB/s。curl -XPUT 'localhost:9200/test/_settings' -d '{
"index" : {
"refresh_interval" : "-1"
}
}'
如果正在做批量导入，且根本不介意搜索，就可以彻底关闭合并限流；这样索引操作就会根据磁盘的速率尽可能快地执行：curl -XPUT 'localhost:9200/_cluster/settings' -d '{
"transient" : {
"indices.store.throttle.type" : "none"
}
}'
设置限流类型为none就可以完全关闭合并限流；等批量导入完成后再恢复该配置项为merge。curl -XPUT 'localhost:9200/_cluster/settings' -d '{
"transient" : {
"indices.store.throttle.type" : "merge"
}
}'
注意：上面的设置只适用于Elasticsearch 1.X版本，Elasticsearch 2.X移除了索引级别的速率限制（indices.store.throttle.type、 indices.store.throttle.max_bytes_per_sec、index.store.throttle.type、 index.store.throttle.max_bytes_per_sec），下沉到Lucene的ConcurrentMergeScheduler，以自动管理限流。
合并调度器（ConcurrentMergeScheduler）在需要时会控制合并操作的执行。合并操作运行在独立的线程池中，一旦达到最大线程数，更多的合并请求将会阻塞等待，直到有可用的合并线程。
合并调度器支持下列动态设置：
index.merge.scheduler.max_thread_count
最大线程数默认为 Math.max(1,Math.min(4,Runtime.getRuntime().availableProcessors() / 2))，对于固态硬盘（SSD）工作得很好；如果使用传统机械硬盘，则降低到1。
机械介质在并发I/O方面有较大的时间开销，因此需要减少线程数，以便能按索引并发访问磁盘。该设置允许每次有max_thread_count + 2个线程操作磁盘，所以设置为1表示支持3个线程。
如果使用机械硬盘而不是SSD，就要在elasticsearch配置文件中加入以下配置：
index.merge.scheduler.max_thread_count: 1
当然也可以为单个索引库设置：curl -XPUT 'localhost:9200/my_index/_settings' -d '{
"index.merge.scheduler.max_thread_count" : 1
}'
为所有已创建的索引库设置：curl -XPUT 'localhost:9200/_settings' -d '{
"index.merge.scheduler.max_thread_count" : 1
}'
3 事务日志的清理
在节点挂掉时事务日志可以防止数据丢失，设计初衷是帮助在flush时原本丢失的分片恢复运行。该日志每5秒，或者在每个索引、删除、更新或批量请求（不管先后顺序）完成时，会提交到磁盘一次。
对Lucene的变更仅会在一次Lucene提交后持久化到磁盘，Lucene提交是比较重量级的操作，索引不能再每个索引或删除操作后就执行。当进程退出或硬件故障时，一次提交后或另一次提交前的变更将会丢失。
为防止这些数据丢失，每个分片有一个事务日志，或者与之关联的预写日志。任何索引或删除操作，在内置的Lucene索引处理完成后都是写到事务日志中。崩溃发生后，就可以从事务日志回放最近的事务来恢复分片。
Elasticsearch的flush操作，本质上是执行了一次Lucene提交并启动了一个新的事务日志；这些都是在后台自动完成的，目的是确保事务日志不会变得过大，否则恢复数据期间的回放操作可能需要消耗相当长的时间。这个功能同样暴露了一个API供调用，虽然很少需要手动触发。
与刷新（refresh）一个索引分片相比，真正昂贵的操作是flush其事务日志（这涉及到Lucene提交）。Elasticsearch基于许多随时可变的定时器来执行flush。通过延迟flush或者彻底关闭flush可以提升索引吞吐量。不过并没有免费的午餐，延迟flush最终实际执行时显然会消耗更长的时间。
下列可动态更新的配置控制着内存缓存刷新到磁盘的频率：
index.translog.flush_threshold_size - 一旦事务日志达到这个值，就会发生一次flush；默认值为512mb。
index.translog.flush_threshold_ops - 在多少操作后执行flush，默认无限制。
index.translog.flush_threshold_period - 触发一次flush前的等待时间，不管日志大小，默认值为30分钟。
index.translog.interval - 检查是否需要flush的时间间隔，随机在该时间到2倍之间取值，默认为5秒。
可以把index.translog.flush_threshold_size的值从默认值的512MB调大比如到1GB，这样在一次flush发生前就可以在日志中积累更大的段。通过构建更大的段，就可以减少flush的次数以及大段的合并次数。所有这些措施加起来就会减少磁盘I/O并获得更好的索引效率。
当然，这需要一定数量的可用堆内存，用于额外的缓存空间，所以调整此类配置时请注意这一点。
4 索引缓冲区的容量规划
索引缓冲区用于存储新的索引文档，如果满了，缓冲区的文档就会写到磁盘上的一个段。节点上所有分片的缓冲区都是独立的。
下列配置项是静态的，并且必须在集群的每个数据节点上都配置：
indices.memory.index_buffer_size - 可设置为百分比或者字节数大小，默认是10%，表示总内存的10%分配给该节点，作为索引缓冲区大小，全局共享。
indices.memory.min_index_buffer_size - 如果index_buffer_size设置为百分比，那么这项配置用于指定一个绝对下限，默认是48MB。
indices.memory.max_index_buffer_size - 如果index_buffer_size设置为百分比，那么这项配置用于指定一个绝对上限，默认是无限制。
配置项indices.memory.index_buffer_size定义了可供索引操作使用的堆内存百分比（剩余堆内存将主要用于检索操作）。如果要索引很多数据，默认的10%可能会太小，有必要调大该值。
5 索引和批量操作的线程池大小
接下来试试在节点级别调大索引和批量操作的线程池大小，看看否带来性能提升。
index - 用于索引和删除操作。线程类型是固定大小的（fixed)，默认大小是可用处理器核数，队列大小queue_size是200，该线程池最大为1+可用处理器核数。
bulk - 用于批量操作。线程类型是固定大小的，默认大小是可用处理器核数，队列大小是50，线程池最大为1+可用处理器核数。
单个分片与独立的Lucene是一个层次，因此同时执行索引的并发线程数是有上限的，在Lucene中默认是8，而在ES中可以通过index.index_concurrency配置项来设置。
在为该参数设置默认值时应当多想一想，特别是对于往一个索引库索引数据时，一个节点只有一个分片的情况。
由于索引/批量线程池可以保护和控制并发，所以大部分时候都可以考虑调大默认值；尤其是对于节点上没有其他分片的情况（评估是否值得），可以考虑调大该值。
关于译者
杨振涛
vivo互联网搜索引擎团队负责人，开发经理。10年数据和软件领域经验，先后从事基因测序、电商、IM及厂商互联网领域的系统架构设计和实现。专注于实时分布式系统和大数据的存储、检索和可视化，尤其是搜索引擎及深度学习在NLP方向的应用。技术翻译爱好者，TED Translator，InfoQ中文社区编辑。
未经授权，禁止转载。
英文原文地址：https://qbox.io/blog/maximize- ... art-2 查看全部
本文翻译自QBox官方博客的“Elasticsearch索引性能优化”系列文章中的第二篇，版权归原作者 Adam Vanderbush所有。该系列文章共有三篇，其中第一篇已有同行翻译，参考链接http://www.zcfy.cc/article/how ... .html 后续还会有第三篇的推送，敬请关注。
作者：Adam Vanderbush
译者：杨振涛@vivo
本系列文章重点关注如何最大化地提升elasticsearch的索引吞吐量和降低监控与管理负荷。
Elasticsearch是准实时的，这表示当索引一个文档后，需要等待下一次刷新后就可以搜索到该文档了。
刷新是一个开销较大的操作，这就是为什么默认要设置一个特定的间隔，而不是每索引一个文档就刷新一次。如果想索引大批量的文档，并不需要立刻就搜索到新的索引信息，为了优化索引性能甚至搜索性能，可以临时降低刷新的频率，直到索引操作完成。
一个索引库的分片由多个段组成。Lucene的核心数据结构中，一个段本质上是索引库的一个变更集。这些段是在每次刷新时所创建，随后会在后台合并到一起，以保证资源的高效使用；每个段都会消耗文件句柄、内存和CPU。工作在该场景背后的Lucene负责段的合并，一旦处理不当，可能会消耗昂贵的计算资源并导致Elasticsearch自动降级索引请求到一个单一线程上。
本文将继续关注Elasticsearch的索引性能调优，重点聚焦在集群和索引级别的各种索引配置项设置。
1 关注refresh_interval参数
这个间隔通过参数index.refresh_interval设置，既可以在Elasticsearch配置文件里全局设置，也可以针对每一个索引库单独设置。如果同时设置，索引库设置会覆盖全局配置。默认值是1s，因此最新索引的文档最多不超过1s后即可搜索到。
因为刷新是非常昂贵的操作，提升索引吞吐量的方式之一就是增大refresh_interval；更少的刷新意味着更低的负载，并且更多的资源可以向索引线程倾斜。因此，根据搜索需求，可以考虑设置刷新间隔为大于1秒的值；甚至可以考虑在某些时候，比如执行批量索引时，临时关闭索引库的刷新操作，执行结束后再手动打开。
更新设置API可以在批量索引时动态改变索引以便更加高效，然后再修改为更加实时的索引状态。在批量索引开始前，设置：
curl -XPUT 'localhost:9200/test/_settings' -d '{
"index" : {
"refresh_interval" : "-1"
}
}'如果要做一次较大的批量导入，可以考虑设置index.number_of_replicas: 0来禁止副本。当设置了副本后，整个文档会被发送到副本节点，并重复索引过程；这意味着每个副本都会执行分析、索引及可能的合并操作。反之，如果索引时设置0副本，完成后再打开副本支持，恢复过程实质上只是一个网络字节流传输的过程，这比重复索引过程要高效得多了。
curl -XPUT 'localhost:9200/my_index/_settings' -d ' {
"index" : {
"number_of_replicas" : 0
}
}'然后一旦批量索引完成，即可更新设置（比如恢复成默认设置）：
curl -XPUT 'localhost:9200/my_index/_settings' -d '{
"index" : {
"refresh_interval" : "1s"
}
}'并且可以强制触发一次合并：
curl -XPOST 'localhost:9200/my_index/_forcemerge?max_num_segments=5'刷新API支持显式地刷新一个或多个索引库，以便让上次刷新后的所有操作完成并可被搜索感知。实时或近实时能力取决于所使用的索引引擎。比如，内置引擎要求显式调用刷新，而默认地刷新是周期性执行的。
curl -XPOST 'localhost:9200/my_index/_refresh'2 段与合并
段合并是一个计算开销较大的操作，而且会消耗大量的磁盘I/O。由于合并操作比较耗时，尤其是较大的段，所以一般设定为后台执行；这也没什么太大问题，因为大段的合并相对还是比较少的。
但也有时候，合并速率会低于生产速率；一旦如此，Elasticsearch将会自动地限流索引请求到一个单一线程。这能阻止段爆发问题，否则在合并前可能会生成数百个段。
Elasticsearch在这里默认是比较保守的：不希望搜索性能受到后台合并操作的挤兑；但有时（尤其是使用SSD，或写日志的场景）节流限制会过低。
默认的20 MB/s对于传统机械磁盘是一个挺不错的设置；如果使用SSD，可能要考虑加大该设置到100–200 MB/s。
curl -XPUT 'localhost:9200/test/_settings' -d '{
"index" : {
"refresh_interval" : "-1"
}
}'如果正在做批量导入，且根本不介意搜索，就可以彻底关闭合并限流；这样索引操作就会根据磁盘的速率尽可能快地执行：
curl -XPUT 'localhost:9200/_cluster/settings' -d '{
"transient" : {
"indices.store.throttle.type" : "none"
}
}'设置限流类型为none就可以完全关闭合并限流；等批量导入完成后再恢复该配置项为merge。
curl -XPUT 'localhost:9200/_cluster/settings' -d '{
"transient" : {
"indices.store.throttle.type" : "merge"
}
}'注意：上面的设置只适用于Elasticsearch 1.X版本，Elasticsearch 2.X移除了索引级别的速率限制（indices.store.throttle.type、 indices.store.throttle.max_bytes_per_sec、index.store.throttle.type、 index.store.throttle.max_bytes_per_sec），下沉到Lucene的ConcurrentMergeScheduler，以自动管理限流。
合并调度器（ConcurrentMergeScheduler）在需要时会控制合并操作的执行。合并操作运行在独立的线程池中，一旦达到最大线程数，更多的合并请求将会阻塞等待，直到有可用的合并线程。
合并调度器支持下列动态设置：
index.merge.scheduler.max_thread_count
最大线程数默认为 Math.max(1,Math.min(4,Runtime.getRuntime().availableProcessors() / 2))，对于固态硬盘（SSD）工作得很好；如果使用传统机械硬盘，则降低到1。
机械介质在并发I/O方面有较大的时间开销，因此需要减少线程数，以便能按索引并发访问磁盘。该设置允许每次有max_thread_count + 2个线程操作磁盘，所以设置为1表示支持3个线程。
如果使用机械硬盘而不是SSD，就要在elasticsearch配置文件中加入以下配置：
index.merge.scheduler.max_thread_count: 1
当然也可以为单个索引库设置：
curl -XPUT 'localhost:9200/my_index/_settings' -d '{
"index.merge.scheduler.max_thread_count" : 1
}'为所有已创建的索引库设置：
curl -XPUT 'localhost:9200/_settings' -d '{
"index.merge.scheduler.max_thread_count" : 1
}'
3 事务日志的清理
在节点挂掉时事务日志可以防止数据丢失，设计初衷是帮助在flush时原本丢失的分片恢复运行。该日志每5秒，或者在每个索引、删除、更新或批量请求（不管先后顺序）完成时，会提交到磁盘一次。
对Lucene的变更仅会在一次Lucene提交后持久化到磁盘，Lucene提交是比较重量级的操作，索引不能再每个索引或删除操作后就执行。当进程退出或硬件故障时，一次提交后或另一次提交前的变更将会丢失。
为防止这些数据丢失，每个分片有一个事务日志，或者与之关联的预写日志。任何索引或删除操作，在内置的Lucene索引处理完成后都是写到事务日志中。崩溃发生后，就可以从事务日志回放最近的事务来恢复分片。
Elasticsearch的flush操作，本质上是执行了一次Lucene提交并启动了一个新的事务日志；这些都是在后台自动完成的，目的是确保事务日志不会变得过大，否则恢复数据期间的回放操作可能需要消耗相当长的时间。这个功能同样暴露了一个API供调用，虽然很少需要手动触发。
与刷新（refresh）一个索引分片相比，真正昂贵的操作是flush其事务日志（这涉及到Lucene提交）。Elasticsearch基于许多随时可变的定时器来执行flush。通过延迟flush或者彻底关闭flush可以提升索引吞吐量。不过并没有免费的午餐，延迟flush最终实际执行时显然会消耗更长的时间。
下列可动态更新的配置控制着内存缓存刷新到磁盘的频率：
index.translog.flush_threshold_size - 一旦事务日志达到这个值，就会发生一次flush；默认值为512mb。
index.translog.flush_threshold_ops - 在多少操作后执行flush，默认无限制。
index.translog.flush_threshold_period - 触发一次flush前的等待时间，不管日志大小，默认值为30分钟。
index.translog.interval - 检查是否需要flush的时间间隔，随机在该时间到2倍之间取值，默认为5秒。
可以把index.translog.flush_threshold_size的值从默认值的512MB调大比如到1GB，这样在一次flush发生前就可以在日志中积累更大的段。通过构建更大的段，就可以减少flush的次数以及大段的合并次数。所有这些措施加起来就会减少磁盘I/O并获得更好的索引效率。
当然，这需要一定数量的可用堆内存，用于额外的缓存空间，所以调整此类配置时请注意这一点。
4 索引缓冲区的容量规划
索引缓冲区用于存储新的索引文档，如果满了，缓冲区的文档就会写到磁盘上的一个段。节点上所有分片的缓冲区都是独立的。
下列配置项是静态的，并且必须在集群的每个数据节点上都配置：
indices.memory.index_buffer_size - 可设置为百分比或者字节数大小，默认是10%，表示总内存的10%分配给该节点，作为索引缓冲区大小，全局共享。
indices.memory.min_index_buffer_size - 如果index_buffer_size设置为百分比，那么这项配置用于指定一个绝对下限，默认是48MB。
indices.memory.max_index_buffer_size - 如果index_buffer_size设置为百分比，那么这项配置用于指定一个绝对上限，默认是无限制。
配置项indices.memory.index_buffer_size定义了可供索引操作使用的堆内存百分比（剩余堆内存将主要用于检索操作）。如果要索引很多数据，默认的10%可能会太小，有必要调大该值。
5 索引和批量操作的线程池大小
接下来试试在节点级别调大索引和批量操作的线程池大小，看看否带来性能提升。
index - 用于索引和删除操作。线程类型是固定大小的（fixed)，默认大小是可用处理器核数，队列大小queue_size是200，该线程池最大为1+可用处理器核数。
bulk - 用于批量操作。线程类型是固定大小的，默认大小是可用处理器核数，队列大小是50，线程池最大为1+可用处理器核数。
单个分片与独立的Lucene是一个层次，因此同时执行索引的并发线程数是有上限的，在Lucene中默认是8，而在ES中可以通过index.index_concurrency配置项来设置。
在为该参数设置默认值时应当多想一想，特别是对于往一个索引库索引数据时，一个节点只有一个分片的情况。
由于索引/批量线程池可以保护和控制并发，所以大部分时候都可以考虑调大默认值；尤其是对于节点上没有其他分片的情况（评估是否值得），可以考虑调大该值。
关于译者
杨振涛
vivo互联网搜索引擎团队负责人，开发经理。10年数据和软件领域经验，先后从事基因测序、电商、IM及厂商互联网领域的系统架构设计和实现。专注于实时分布式系统和大数据的存储、检索和可视化，尤其是搜索引擎及深度学习在NLP方向的应用。技术翻译爱好者，TED Translator，InfoQ中文社区编辑。
未经授权，禁止转载。
英文原文地址：https://qbox.io/blog/maximize- ... art-2
