ES forceMerge 强制段合并为什么会提升检索性能？

  根据以前的测试，forceMerge段合并，将段的个数合并成一个。带来了将近一倍的性能提升，测试过程文档（请参考我的另外一篇文章）：ES优化实战- forceMerge搜索提升测试报告_es forcemerge_水的精神的博客

  注意，这次测试，只是这对一个长文本字段（就像一篇文章）的检索测试。假如同时对多个字段做检索，带来的性能会好更多！

  时间已经过去了许久，对检索的原理，对es集群的理解也有了更高的层次。再写一篇文章，来讲讲为什么会性能提升。讲讲段合并的适用场景，以及需要注意的事项。用的好了性能提升很多，用的不好，性能反而降低很多。

---

能够提升的原理

在 Elasticsearch 中，Lucene 索引被分为多个段（segments）以提高查询性能。每个段都是一个完整的 Lucene 索引，包含一部分数据。当一个文档被添加到索引中时，它会被添加到一个新的段中。这些新的段需要合并到更大的段中，以便更快地执行搜索操作。

forceMerge 是 Elasticsearch 提供的一个 API，可以将多个段合并成一个更大的段。这个过程可以通过减少段数来提高性能，因为

• 更少的段意味着更少的搜索和查询操作需要执行。
• 这可以减少内存使用
• 因为段其实就是底层的一个个小文件。将小文件合并成大文件，毋庸置疑的是，去IO 1个G的一个文件，和IO将拆分每个10M的小文件，用的时间肯定是不一样的。IO一个大文件速度会更快一些。
• 并减少查询所需的磁盘 I/O 操作次数。
• 根据lucene的检索原理，默认，lucene在段中的检索，是单线程的。大体的流程是，串性在每个段中执行检索，然后再做结果的reduce合并。假如将所有的段合并成一个段，那么检索起来，至少在一个分片中。是不用做数据合并的。

当 Elasticsearch 需要执行搜索时，它必须在所有分片的所有段上执行查询。如果分片中包含大量小段，则需要执行的查询次数将非常多，从而导致搜索性能下降。如果使用 forceMerge 将这些小段合并为更大的段，则查询次数将减少，并且查询性能将得到显著提高。

forceMerge注意事项

• 但是，需要注意的是，forceMerge 操作是一项资源密集型操作，会消耗大量的 CPU、磁盘和内存资源。这也是为什么官方默认只给一个merge线程。这个过程一定会影响到查询的性能，写入的性能。
• 此外，forceMerge 过程中，需要花费一倍的磁盘空间。可以简单的它时间上就像是一个reindex过程，在reindex完成之前，你的集群中存放的数据它就一定是双倍的。只有等合并完成，它才会将原来的删掉。因为它将多个段合并为一个更大的段。这可能会对磁盘空间产生影响，因此需要确保有足够的磁盘空间可供使用。
• 一定一定要注意。这项操作，建议只对不变更的数据做merge成一个段的操作。因为假如何合并完成后，再有更新，或者新写入，仍然会产生很多新的段。这会让检索性能降低很多。因为forceMerge 是一个强制的操作。但是新加进来的段，根据合并策略，它是没有办法和原来的段合并的！