es中段是怎么合并的

在 ES（Elasticsearch）中，合并（merge）操作通常是指索引中段（segments）的合并。Elasticsearch 使用段（segment）来存储数据，随着时间的推移，数据不断被写入索引，这些数据会被组织成多个段。当数据量增大时，段的数量也会增多，过多的小段可能会影响查询性能。因此，Elasticsearch 会在后台定期执行合并操作，将多个小段合并成较大的段，以提升查询效率并减少磁盘空间的使用。

1. 段合并的背景

• Elasticsearch 是基于 Apache Lucene 构建的，Lucene 采用段化存储（Segmented Storage）来管理索引。
• 每当新的文档被添加到索引时，它会被写入到一个新的段中，直到达到某个阈值（如磁盘空间或写入速率），才会将这些段合并成较大的段。
• 每次合并后，新的段包含了原有段的所有数据，但会丢弃已删除的文档（通过标记为“删除”而非实际删除）。

2. 合并的方式

合并操作主要是通过 Lucene 中的 Merge Policy 和 Merge Scheduler 来控制。Elasticsearch 会在后台使用以下机制来决定何时执行合并操作：

• 自动合并：Elasticsearch 会根据配置的阈值（如段的数量、大小等）来自动进行合并。合并操作是异步进行的，不会影响前台的查询操作。

• 合并触发的条件

  ：通常，当段的数量过多或者单个段的大小过小时，Elasticsearch 会触发合并操作。合并的过程是通过

  MergePolicy
  

  来调整的。常见的合并策略包括：

  • LogByteSizeMergePolicy：基于段的字节大小来进行合并。
  • TieredMergePolicy：基于段的层次结构来进行合并，通常适用于包含大量文档的情况。

• 手动触发合并：可以通过 API（如 force_merge）来手动触发合并操作。例如，在删除大量文档或更新索引时，可能需要通过手动触发合并操作来优化索引。

理解 TieredMergePolicy 中的 层次（tier） 概念，对于更好地优化 Elasticsearch 的段合并策略至关重要。TieredMergePolicy 采用分层的策略来管理段的合并，它的主要目标是控制每个层次中的段的数量、大小以及合并的频率，从而提高索引的查询效率，并避免过早或过频繁的合并。

2.1TieredMergePolicy 的层次结构

在 TieredMergePolicy 中，层次（tier）是指按照段的大小划分的不同“层级”。这些层次帮助管理段的合并，避免过度合并小段，同时确保合并后的段大小合理，能够有效地提升查询性能。

具体来说，Elasticsearch 会将索引中的段分成若干层，每个层次内的段符合某些大小范围。每个层次内的段被合并成一个新的段，直到最终的段符合某个阈值。合并通常发生在以下几种情况：

• 每个层次中的段数量超过设定的阈值，即该层次的段数量过多，可能会导致查询性能下降。
• 每个层次中的段大小过大，即某些段已经过大，合并可以减少查询时需要加载的段数。

2.2 层次的基本规则

TieredMergePolicy 的层次规则可以通过以下几个核心参数来理解：

• segments_per_tier（每个层次的最大段数）：
  • 该参数决定了每个层次最多可以包含多少个段。如果某个层次的段数超过了这个值，就会触发合并操作。
  • 默认值：10，意味着每个层次最多有 10 个段。如果某个层次中的段数超过 10 个，就会触发合并，将这些段合并为一个更大的段。
• floor_segment（最小段大小）：
  • 该参数定义了段的最小大小。任何小于这个大小的段不会被合并。
  • 默认值：2MB，即小于 2MB 的段不会被合并，因为它们太小，合并也无法带来显著的性能提升。
• max_merged_segment（最大合并段大小）：
  • 该参数定义了合并后段的最大大小。合并后的段不应该超过此大小，否则会导致过大的段，影响查询性能。
  • 默认值：5GB，即合并后的段最大不超过 5GB。

2.3 如何理解层次（tier）

层次是 TieredMergePolicy 的核心概念，它描述了段在合并过程中的分组方式。可以通过以下几个层次的特征来理解它的工作机制：

• 第一层：包含最小的段，通常是刚刚写入索引的段，这些段很小（可能只有几MB），不适合马上合并，因此它们会被保留在第一层。
• 第二层及以上：随着段的合并，它们逐渐被移动到更高层次。合并后的段会被分配到第二层、第三层等，直到它们合并成一个大的段。
  • 如果一个层次中的段数超过了 segments_per_tier 的最大值，或者其中某些段的大小过大（超过了 max_merged_segment），就会触发合并操作，将这些段合并成一个更大的段，并移动到下一层。

2.4. 合并过程中的层次示例

假设我们有以下设置：

• segments_per_tier = 10：每个层次最多包含 10 个段。
• floor_segment = 2MB：最小段大小为 2MB。
• max_merged_segment = 5GB：每个合并后的段最多为 5GB。

假设索引中当前有以下段（按大小排序）：

• 第一层：5 个段，分别为 1MB, 1.5MB, 2MB, 3MB, 4MB（都小于 max_merged_segment，适合保持在第一层）。
• 第二层：12 个段，大小分别为 10MB, 20MB, 30MB 等。
• 第三层：15 个段，大小分别为 100MB, 200MB 等。

在合并的过程中，TieredMergePolicy 会按以下规则工作：

• 第一层的段会尽量保留原样（因为它们很小，合并后可能会浪费资源）。

• 第二层的段，如果超过 10 个段，将被合并成更大的段，直到每个层次中段的数量少于 segments_per_tier（此处为 10）。

• 合并后的段会继续向 更高的层次移动，直到满足合并后的大小上限（例如 5GB）。

2.5. TieredMergePolicy 的优势

• 减少频繁的合并：与 LogByteSizeMergePolicy（基于字节大小的合并策略）不同，TieredMergePolicy 会根据段的数量和层次来调整合并的时机，从而减少了过早合并小段的频率。它避免了过度合并的情况，提升了系统的性能和稳定性。
• 合并过程优化：它通过分层控制，使得每个层次中的段数量和大小都在合理范围内，从而避免了过大的段带来的性能问题，也避免了段数量过多导致的查找效率降低。

2.6. 小结

TieredMergePolicy 通过将段分成多个层次来管理合并策略，每个层次的段数和大小有一定的限制。每当一个层次中的段数超出限制时，Elasticsearch 就会触发合并操作，将小段合并为更大的段，并向更高层次迁移。这样可以有效地控制合并过程，减少系统负载，提高查询效率。

• 每个层次的段数超过 segments_per_tier 时会触发合并。
• 合并的最大段大小由 max_merged_segment 控制。
• 最小段大小由 floor_segment 控制，不会合并小于该大小的段。

通过调整这些参数，可以根据实际业务需求优化 Elasticsearch 索引的合并行为，从而平衡性能和资源消耗。

3. 合并过程中的优化

• 去除已删除文档：合并过程中，Lucene 会通过清理标记为删除的文档来减少索引的大小。虽然删除操作是逻辑删除，但合并会物理删除这些文档，从而释放空间。
• 合并段的大小：合并后，新的段会比原来的段大，这样可以减少段的数量。大段通常会更有效地利用缓存和 I/O，从而提高查询性能。

4. 合并的性能考虑

• 后台运行，不影响查询：合并通常是后台任务，不会影响前端的查询性能。然而，在合并过程中，可能会有较高的磁盘和 CPU 使用率，所以在负载较高的生产环境中，要注意合并的频率和时机。
• 优化合并策略：可以根据实际的硬件环境和使用场景来调整合并的策略。例如，在资源紧张的情况下，可以延迟合并，减少系统负担；而在高查询量的环境中，可以加快合并，以提高查询性能。

5. 使用 API 手动合并

• 可以通过

  POST /index_name/_forcemerge
  

  API 来手动触发合并：

  POST /my_index/_forcemerge?max_num_segments=1
  

  这个命令会将

  my_index
  

  索引的段合并为最多一个段。注意，

  max_num_segments
  

  是可选的参数，用于指定要保留的最大段数。

6. 合并的影响

• 查询性能的提高：合并后，查询通常会变得更高效，因为段数减少了，搜索时需要遍历的段也更少。
• 磁盘空间的释放：合并会去除已删除文档，因此可以减少索引的磁盘占用。
• 暂时的性能波动：在合并操作进行时，可能会对系统的 I/O 和 CPU 造成一定压力，导致短期的性能波动。因此，最好在系统负载较低时执行合并操作，或者在需要时配置合并的优先级。

总结来说，Elasticsearch 的合并操作主要目的是通过减少段的数量来优化查询性能和磁盘占用。它是一个自动化的过程，但也可以根据实际情况进行手动触发和配置调整。