Elasticsearch是建立在Apache Lucene 基礎上的實時分散式搜尋引擎，Lucene為了提高搜尋的實時性，採用不可再修改（immutable）方式將文件儲存在一個個segment中。也就是說，一個segment在寫入到儲存系統之後，將不可以再修改。那麼Lucene是如何從一個segment中刪除一個被索引的文件呢？簡單的講，當用戶發出命令刪除一個被索引的文件#ABC時，該文件並不會被馬上從相應的儲存它的segment中刪除掉，而是通過一個特殊的檔案來標記該文件已被刪除。當用戶再次搜尋到#ABC時，Elasticsearch在segment中仍能找到#ABC，但由於#ABC文件已經被標記為刪除，所以Lucene會從發回給使用者的搜尋結果中剔除#ABC，所以給使用者感覺的是#ABC已經被刪除了。

       Elasticseach會有後臺執行緒根據Lucene的合併規則定期進行segment merging合併操作，一般不需要使用者擔心或者採取任何行動。被刪除的文件在segment合併時，才會被真正刪除掉。在此之前，它仍然會佔用著JVM heap和作業系統的檔案cache等資源。在某些情況下，我們需要強制Elasticsearch進行segment merging，已釋放其佔用的大量系統資源。

_optimize命令可強制進行segment合併，並刪除所有標記為刪除的文件。Segment merging要消耗CPU，以及大量的I/O資源，所以一定要在你的ElasticSearch叢集處於維護視窗期間，並且有足夠的I/O空間的（如：SSD）的條件下進行；否則很可能造成叢集崩潰和資料丟失。

       下圖展示了我們在進行強制expunge時，所觀察到的CPU和磁碟I/O的使用情況。該叢集執行在微軟的Azure雲平臺IaaS虛擬機器上，所有的資料節點都採用 D13 虛擬機器，資料儲存在本地的SSD磁碟中。該叢集是一個備份叢集，為了保證合併順利進行，在此期間暫停了所有對其進行的寫操作，僅有少量的讀操作。這裡需要注意: expunge操作是一種不得已而為之的操作，即在Elasticsearch不能有效自動清除刪除檔案的情況下才執行該操作。同時建議在此操作期間，最好停止對叢集的所有讀/寫操作，並暫停止shard的自動分配 (cluster.routing.allocation.enable

       下面兩個設定可以用於控制清除時的處理速度，其中給出值是預設值，可以根據需求進行調整，具體請參見Merge。此外， 還可以臨時將所有索引的replica設定為0，這樣只用針對Primary進行expunge，以減小I/O壓力。

PUT /{index}/_settings
{
    "settings": {
        "index.merge.policy.expunge_deletes_allowed": "10",
        "index.merge.policy.max_merge_at_once_explicit" : "30"
    }
}

參考資料