段合并 segments merge 被删除的文档的删除时间

2.5 段合并

每个索引分为多个“写一次，读多次”的段 write once and read many times  segments

建立索引时，一个段写入磁盘以后就不能更新：被删除的文档的信息存储在一个单独的文件中

【段合并 segments merge】

多个段可以通过段合并合并在一起

当强制段合并或者Luncene决定合并时，这些小段就会由Lucene合并成为更大的段

合并时间

当强制段合并或者Lucene决定合并时，这些小段就会由Lucene合并成更大的daunt

为什么合并

1. 合并时，不再需要的信息将被删除，例如，被删除的文档；
2. 检索大段比检索存有相同数据的多个小段速度更快：一般情况下，搜索只需要将查询词与那些被编入索引的词相匹配，通过多个小段查找会比让一个大段直接提供结果慢且需要内存更多。

合并策略

tired 默认，合并尺寸大致相似的段，并考虑每个层tier允许的最大段数；

log_byte_size

log_doc

1.1节提到段及其不变性，指出Lucene库以及Elasticsearch中一旦数据被写入某些结构，就不 再改变。虽然这简化了一些东西，但是也引入了额外的工作，其中一个例子是删除。由于段是无 法改变的，因而有关删除的相关信息必须单独存储并动态应用到搜索过程中。这样做是为了从返 回结果中去除已删除的文件。另一个例子是文档无法修改（有些修改是可能的，例如修改数值型 doc值）。当然，我们可以说，Elasticsearch支持文档更新（请参阅1.4节）。然而在底层，实际上是 删除旧文档，再把更新内容的文档编入索引。

随着时间的推移和持续索引数据，越来越多的段被创建。因此，搜索性能可能会降低，而且 索引可能比原先大，因为它仍含有被删除的文件。这使得段合并有了用武之地。

2.5.1 段合并

段合并的处理过程是：底层的Lucene库获取若干段，并在这些段信息的基础上创建一个新的 段。由此产生的段拥有所有存储在原始段中的文档，除了被标记为删除的那些之外。合并操作之 后，源段将从磁盘上删除。这是因为段合并在CPU和I/O的使用方面代价是相当高的，关键是要 适当地控制这个过程被调用的时机和频率。

2.5.2 段合并的必要性

你可能会问为何要费心段合并。首先，构成索引的段越多，搜索速度越慢，需要使用的Lucene

内存也越多。其次，索引使用的磁盘空间和资源，例如文件描述符。如果从索引中删除许多文档， 直到合并发生，则这些文档只是被标记为已删除，而没有在物理上删除。因而，大多数占用了CPU 和内存的文档可能并不存在！好在Elasticsearch使用合理的默认值做段合并，这些默认值很可能 不再需要做任何更改。

2.5.3 合并策略

合并策略描述了应执行合并过程的时机。Elasticsearch允许配置以下三种不同的策略。

 tiered：这是默认合并策略，合并尺寸大致相似的段，并考虑到每个层（tier）允许的最
大段数量；
 log_byte_size：这个合并策略下，随着时间推移，将产生由索引大小的对数构成的索
引，其中存在着一些较大的段以及一些合并因子较小的段等；
 log_doc：这个策略类似于log_byte_size合并策略，但根据索引中的文档数而非段的
实际字节数来操作。

上述的每个策略都有自己的参数来定义行为以及可以覆盖的默认值。本书不做详细描述。如 果你想了解更多，请查看 Mastering ElasticSearch，或去 http://www.elasticsearch.org/guide/en/ elasticsearch/reference/current/index-modules-merge.html了解详情。

可使用index.merge.policy.type属性来设置想使用的合并策略，如下所示： index.merge.policy.type: tiered

值得一提的是，索引创建后将无法再对值进行修改。

2.5.4 合并调度器

合并调度器指示Elasticsearch合并过程的方式，有如下两种可能。

 并发合并调度器：这是默认的合并过程，在独立的线程中执行，定义好的线程数量可以
并行合并。
 串行合并调度器：这一合并过程在调用线程（即执行索引的线程）中执行。合并进程会
一直阻塞线程直到合并完成。

调度器可使用index.merge.scheduler.type参数设置。若要使用串行合并调度器，需把参 数值设为serial；若要使用并发调度器，则需把参数值设为concurrent。例如下面的调度程序： index.merge.scheduler.type: concurrent

2.5.5 合并因子

每种合并策略都有好几种设置，我们已经说过在这里不一一介绍，但是合并因子是个例外，

它指定了索引过程中段合并的频率。合并因子较小时，搜索的速度更快，占用的内存也更少，但 索引的速度会减慢；合并因子较大时，则索引速度加快，这是因为发生的合并较少，但搜索的速 度变慢，占用的内存也会变大。对于log_byte_size和 log_doc合并策略，可以通过index. merge.policy.merge_factor参数来设置合并因子。

index.merge.policy.merge_factor: 10

上述例子将合并因子的值设置成10，10也是默认值。建议在批量索引时设置更高的merge_ factor属性值，普通的索引维护则设置较低的属性值。

2.5.6 调节

之前提到过，合并可能需要很多的服务器资源。合并过程通常与其他操作并行执行，所以理 论上不会产生太大的影响。在实践中，磁盘I/O操作的数量可能非常大，以致严重影响了整体性 能。这时，调节（throttling）可以改善此情况。事实上，此功能既可用于限制合并的速度，也可 以用于使用数据存储的所有操作。可以在Elasticsearch的配置文件中对调节进行设置（elasticsearch.yml文件），也可以动态使用设置API来设置（请参阅8.7.2节）。调整调节的设置有两个：type 和value。

为了设置调节类型，设置indices.store.throttle.type属性值为下列值之一。

 none：该值定义不打开调节。

 merge：该值定义调节仅在合并过程中有效。

 all：该值定义调节在所有数据存储活动中有效。

第二个属性，indices.store.throttle.max_bytes_per_sec，描述了调节限制I/O操作 的数量。顾名思义，该属性告诉我们每秒可以处理的字节数量。来看看以下配置：

这个例子中，我们限制合并操作为每秒10 MB。默认情况下，Elasticsearch使用merge调节类 型，max_bytes_per_sec属性设置值为20 mb。这意味着所有的合并操作都限于每秒20 MB。

为了执行批量请求，Elasticsearch提供了_bulk端点，形式可以是/_bulk，也可以是/index_ name/_bulk，甚至是/index_name/type_name/_bulk。第二种和第三种形式定义了索引名称 和类型名称的默认值。可以在请求的信息行中省略这些属性，Elasticsearch将使用默认值。