ElasticSearch 系列文章
1 ES 入門之一 安裝ElasticSearcha
2 ES 記錄之如何創建一個索引映射
3 ElasticSearch 學習記錄之Text keyword 兩種基本類型區別
4 ES 入門記錄之 match和term查詢的區別
5 ElasticSearch 學習記錄之ES幾種常見的聚合操作
6 ElasticSearch 學習記錄之父子結構的查詢
7 ElasticSearch 學習記錄之ES查詢添加排序字段和使用missing或existing字段查詢
8 ElasticSearch 學習記錄之ES高亮搜索
9 ElasticSearch 學習記錄之ES短語匹配基本用法
10 ElasticSearch 學習記錄之 分布式文檔存儲往ES中存數據和取數據的原理
11 ElasticSearch 學習記錄之集群分片內部原理
12 ElasticSearch 學習記錄之ES如何操作Lucene段
13 ElasticSearch 學習記錄之如任何設計可擴容的索引結構
14 ElasticSearch之 控制相關度原理講解
近實時搜索
-
提交（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"//每秒自動刷新
}
}
持久化變更
在沒有 fsync 把數據從內存刷新到硬盤中，我們不能保證數據在斷電或程序退出時之后依然存在
- 即時每秒刷新，也不能實現近實時搜索。我們任然有另外的方法確保從失敗中回復數據
- ES 增加一個translog，或者叫做事務日志。在每次操作是均進行日志記錄
- 整個流程是如下的操作
-
一個文檔被索引之后，就會被添加到內存緩沖區，並且 追加到了 translog
-
-
刷新（refresh）使分片處於緩存被清空，但是事務日志不會的狀態
- 內存緩沖區的文檔被寫入新的段中，但是沒有進行fsync
- 段被打開，且可被搜索到
- 內存緩沖區被清空
-
進程繼續進行，更多的文檔被添加到內存緩沖區和追加的事務日志中
-
每隔一段時間，translog太大 或 索引被刷新。一個新的translog被創建，並且被全量提交
-
- 所有內存緩沖區的文檔都被寫入一個新的段中
- 緩沖區內清空
- 一個提交點被寫入硬盤
- 文件系統緩存通過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 //刷新索引並等待所有的刷新結果返回
-
段合並
-
段合並的時候會將那些舊的已刪除的文檔從文件系統中刪除，被刪除或者被更新的文檔不會被復制到新的大段中
-
段合並的流程
-
- 當索引的時候，刷新（refresh）操作會創建新的段
- 合並的時候會選擇一部分大小相似的段，並且將其合並到更大的段中
- 段的合並結束，老的段就要被刪除
-
optimized API 的作用
- optimize API大可看做是 強制合並 API 。