elasticsearch 中每個(gè)索引都會(huì)創(chuàng)建一個(gè)到多個(gè)分片和零個(gè)到多個(gè)副本往枷，這些分片或副本實(shí)質(zhì)上都是lucene索引
歡迎訪問本人博客：http://wangnan.tech
lucene索引是基于多個(gè)索引段創(chuàng)建颗胡，索引文件中絕大部分?jǐn)?shù)據(jù)都是只寫一次付呕，讀多次媒峡，而只有用于保存文檔刪除信息的文件才會(huì)被多次更改
在某些時(shí)刻，當(dāng)某種條件滿足時(shí)掠手，多個(gè)索引段會(huì)被拷貝合并到一個(gè)更大的索引段抒巢，而那些舊的索引段會(huì)被拋棄并從磁盤中刪除，這操作叫做段合并（segment merging）
為什么要進(jìn)行段合并介粘？
- 索引段的個(gè)數(shù)越多殖氏，搜索性能越低且消耗內(nèi)存更多
- 索引段是不可變的，物理上你并不能從中刪除信息（如果你碰巧從索引中刪除了大量文檔姻采，但這些文檔只是做了刪除標(biāo)記雅采，物理上并沒有被刪除）而當(dāng)段合并發(fā)送時(shí)，這些標(biāo)記為刪除的文檔并沒有被復(fù)制到新的索引段中
段合并好處
- 當(dāng)多個(gè)索引段合并為一個(gè)的時(shí)候，會(huì)減少索引段的數(shù)量并提高搜索速度
- 同時(shí)也會(huì)減少索引的容量（文檔數(shù)）
段合并代價(jià)
- IO操作代價(jià)婚瓜，在速度較慢的系統(tǒng)中宝鼓，段合并會(huì)顯著影響性能
elasticsearch允許用戶選擇段合并政策（merge policy）及儲(chǔ)存級(jí)節(jié)流（store level throttling）
選擇正確的段合并策略
盡管段合并是lucene的責(zé)任，elasticsearch也允許用戶配置想用的段合并策略
到目前為止有三種可用的合并策略：
-
tiered（默認(rèn)）
它能合并大小相似的索引段巴刻，并考慮每層允許的索引段的最大個(gè)數(shù) -
log_byte_size
該策略不斷地以字節(jié)數(shù)的對(duì)數(shù)為計(jì)算單位愚铡，選擇多個(gè)索引來合并創(chuàng)建新索引 -
log_doc
與log_byte_size類似，不同的是前者基于索引的字節(jié)數(shù)計(jì)算胡陪，后者基于索引段文檔數(shù)計(jì)算
為了告知elasticsearch我們想使用的段合并策略沥寥，可以將配置文件的index.merge.policy字段淚痣成我們期望的段合并策略類型例如：index.merge.policy.type: tiered
調(diào)度
es允許我們定制合并策略的執(zhí)行方式，調(diào)度器分兩種
默認(rèn)的是并發(fā)合并調(diào)度器 ConcurrentMerge-Scheduler
并發(fā)合并調(diào)度器
該調(diào)度器使用多線程執(zhí)行索引合并操作
順序合并調(diào)度器
它使用同一個(gè)線程執(zhí)行所有的索引合并操作柠座，在執(zhí)行合并時(shí)邑雅，該線程的其他文檔處理都會(huì)被掛起，從而索引操作會(huì)延遲進(jìn)行
（注：內(nèi)容整理自《深入理解elasticsearch》）
