爲何說Elasticsearch搜索是近實時的？

經過前面兩篇文章的介紹，咱們大概已經知道了 Elasticsearch處理數據的流程，其中在Elasticsearch和磁盤之間還有一層稱爲FileSystem Cache的系統緩存，正是因爲這層cache的存在才使得es可以擁有更快搜索響應能力。

咱們都知道一個index是由若干個segment組成，隨着每一個segment的不斷增加，咱們索引一條數據後可能要通過分鐘級別的延遲才能被搜索，爲何有種這麼大的延遲，這裏面的瓶頸點主要在磁盤。

持久化一個segment須要fsync操做用來確保segment可以物理的被寫入磁盤以真正的避免數據丟失，可是fsync操做比較耗時，因此它不能在每索引一條數據後就執行一次，若是那樣索引和搜索的延遲都會很是之大。

因此這裏須要一個更輕量級的處理方式，從而保證搜索的延遲更小。這就須要用到上面提到的FileSystem Cache，因此在es中新增的document會被收集到indexing buffer區後被重寫成一個segment而後直接寫入filesystem cache中，這個操做是很是輕量級的，相對耗時較少，以後通過必定的間隔或外部觸發後纔會被flush到磁盤上，這個操做很是耗時。但只要sengment文件被寫入cache後，這個sengment就能夠打開和查詢，從而確保在短期內就能夠搜到，而不用執行一個full commit也就是fsync操做，這是一個很是輕量級的處理方式並且是能夠高頻次的被執行，而不會破壞es的性能。

以下圖：

在elasticsearch裏面，這個輕量級的寫入和打開一個cache中的segment的操做叫作refresh，默認狀況下，es集羣中的每一個shard會每隔1秒自動refresh一次，這就是咱們爲何說es是近實時的搜索引擎而不是實時的，也就是說給索引插入一條數據後，咱們須要等待1秒才能被搜到這條數據，這是es對寫入和查詢一個平衡的設置方式，這樣設置既提高了es的索引寫入效率同時也使得es可以近實時檢索數據。

refresh的用法以下：

POST /_refresh   //刷新全部的索引
POST /blogs/_refresh  //刷新指定的索引

refresh操做相比commit操做是很是輕量級的可是它仍然會耗費必定的性能，因此不建議在每插入一條數據後就執行一次refresh命令，es默認的1秒的延遲對於大多數場景基本均可以接受。

固然並非全部的業務場景都須要每秒都refresh一次，若是你短期內要索引大量的數據，爲了優化索引的寫入速度，咱們能夠設置更大的refresh間隔，從而提高寫入性能，命令以下：

PUT /my_logs
{
  "settings": {
    "refresh_interval": "30s" 
  }
}

上面的參數是能夠隨時動態的設置到一個存在的索引裏面，若是咱們正在插入超大索引時，咱們徹底能夠先關閉掉這個refresh機制，等寫入完畢以後再從新打開，這樣以來就能大大提高寫入速度。

命令以下：

PUT /my_logs/_settings
{ "refresh_interval": -1 }  //禁用刷新機制

PUT /my_logs/_settings
{ "refresh_interval": "1s" }  //設置每秒刷新一次

注意refresh_interval的參數是能夠帶時間週期的，若是你只寫了個1，那就表明每隔1毫秒刷新一次索引，因此設置這個參數時務必要謹慎。