ElasticSearch 學習記錄之ES如何操做Lucene段

提交（Commiting）一個新的段到磁盤須要一個 fsync 來確保段被物理性地寫入磁盤，這樣在斷電的時候就不會丟失數據。可是每次提交的一個新的段都fsync 這樣操做代價過大。可使用下面這種更輕量的方式
在內存緩衝區中包含了新文檔的 Lucene 索引
- Lucene 容許新段被寫入和打開--使其包含的文檔在未進行一次完整提交時便對搜索可見
緩衝區的內容已經被寫入一個可被搜索的段中，但尚未進行提交
- 這裏新段會被先寫入到文件系統緩存--這一步代價會比較低，稍後再被刷新到磁盤--這一步代價比較高
默認狀況下每一個分片會每秒自動刷新一次
- 近實時搜索: 文檔的變化並非當即對搜索可見，但會在一秒以內變爲可見
- POST /_refresh // 刷新Refresh 全部的索引
- POST /blogs/_refresh // 只刷新Refresh blogs 索引
  能夠在settings 設置對定時刷新頻率的大小
PUT /my_logs
{
"settings": {
"refresh_interval": "30s" //30秒刷新一次
"refresh_interval": "-1" //關閉自動刷新
"refresh_interval": "1s"//每秒自動刷新
}
}html

持久化變動
在沒有 fsync 把數據從內存刷新到硬盤中，咱們不能保證數據在斷電或程序退出時以後依然存在
即時每秒刷新，也不能實現近實時搜索。咱們任然有另外的方法確保從失敗中回覆數據
ES 增長一個translog，或者叫作事務日誌。在每次操做是均進行日誌記錄
整個流程是以下的操做
1. 一個文檔被索引以後，就會被添加到內存緩衝區，而且追加到了 translog
  -緩存
2. 刷新（refresh）使分片處於緩存被清空，可是事務日誌不會的狀態
  - 內存緩衝區的文檔被寫入新的段中，可是沒有進行fsync
  - 段被打開，且可被搜索到
  - 內存緩衝區被清空
3. 進程繼續進行，更多的文檔被添加到內存緩衝區和追加的事務日誌中
4. 每隔一段時間，translog太大或索引被刷新。一個新的translog被建立，而且被全量提交
  -elasticsearch
  - 全部內存緩衝區的文檔都被寫入一個新的段中
  - 緩衝區內清空
  - 一個提交點被寫入硬盤
  - 文件系統緩存經過fsync被刷新
  - 老的translog 被刪除
translog 提供全部沒有被刷新到磁盤操做的一個持久化記錄。當ES啓動時，會根據最後一個提交點去恢復已知的段
translog 也可供用來提供實時的CRUD。但咱們進行一些CRUD操做時，它會首先檢查translog任何最近的變動。
flush API 執行一次提交，並截斷translog的操做
- 分片默認每30M自動flush一次。translog太大也會自動flush
- 可經過本身執行flush API操做分佈式
  
  POST /blogs/_flush //刷新索引學習
  
  POST /_flush?wait_for_ongoing //刷新索引並等待全部的刷新結果返回設計

段合併

段合併的時候會將那些舊的已刪除的文檔從文件系統中刪除，被刪除或者被更新的文檔不會被複制到新的大段中
段合併的流程
-3d
- 當索引的時候，刷新（refresh）操做會建立新的段
- 合併的時候會選擇一部分大小類似的段，而且將其合併到更大的段中
- 段的合併結束，老的段就要被刪除
optimized API 的做用
- optimize API大可看作是強制合併 API 。