Lucene索引是基於多個索引段創建的。索引文件中的大部分數據都是壹次寫入多次讀取，只有用來保存文檔刪除信息的文件才會被多次更改。
在某些時候，當滿足某些條件時，多個索引段將被復制並合並為壹個更大的索引段，而那些舊的索引段將被丟棄並從磁盤中刪除。這種操作稱為段合並。
Elasticsearch允許用戶選擇段合並策略和商店級節流。
壹般情況下，不需要修改段合並的默認設置。記錄日誌時，日誌每天、每周和每月都有索引。舊索引通常是只讀的，並且不能修改。在這種情況下，將每個索引的段減少到1是有效的。搜索過程將使用更少的資源並具有更好的性能。
雖然分段合並是lucene的責任，但是elasticsearch也允許用戶配置想要的分段合並策略。
到目前為止，有三種合並策略可用:
為了通知elasticsearch我們想要使用的段合並策略，我們可以將配置文件的index.merge.policy字段撕成想要的段合並策略類型，比如:index.merge.policy.type: tiered。
Es允許我們定制合並策略的執行模式。有兩種調度程序。
默認值為ConcurrentMerge-Scheduler。
調度程序使用多線程來執行索引合並操作。
它使用相同的線程來執行所有的索引合並操作。合並時，該線程的其他文檔處理將被掛起，因此索引操作將被延遲。
通過每秒自動刷新來創建新的細分市場，用不了多久細分市場的數量就會爆炸。分段太多是個問題。每個段都會消耗文件句柄、內存和cpu資源。更重要的是，每個搜索請求需要依次檢查每個段。分段越多，查詢越慢。
ES通過在後臺合並片段來解決這個問題。小段合並成大段，再合並成更大的段。
這是從文件系統中刪除舊文檔的時候。舊段不會被復制到更大的新段。
在這個過程中妳什麽都不用做。ES會在妳索引和搜索的時候自動處理。這個過程如下所示:兩個已提交的段和壹個未提交的段合並成壹個更大的段:
圖1:兩個已提交的段和壹個未提交的段合並成壹個更大的段。
圖2:段合並後，舊的段被刪除。
合並大段會消耗大量IO和CPU，如果不勾選會影響搜索性能。默認情況下，ES限制合並過程，以便搜索可以有足夠的資源。
優化API最好描述為強制合並段API。它強制段合並以達到指定的max_num_segments參數。這是為了減少段數(通常為1)並提高搜索性能。
優化API在某些情況下很有用。典型的場景是記錄日誌，在這種情況下，日誌按日、周和月進行索引。舊索引通常是只讀的，並且不能修改。在這種情況下，將每個索引的段減少到1是有效的。搜索過程將使用更少的資源並具有更好的性能:
參考鏈接:
/article/16/0229/201432 . html
/wangnan 9279/文章/詳情/68066935