近實時搜尋

隨著按段（per-segment）搜尋的發展，

乙個新的文件從索引到可被搜尋的延遲顯著降低了。新文件在幾分鐘之內即可被檢索，但這樣還是不夠快。

磁碟在這裡成為了瓶頸。

提交（commiting）乙個新的段到磁碟需要乙個fsync來確保段被物理性地寫入磁碟，這樣在斷電的時候就不會丟失資料。但是fsync操作代價很大; 如果每次索引乙個文件都去執行一次的話會造成很大的效能問題。

我們需要的是乙個更輕量的方式來使乙個文件可被搜尋，這意味著fsync要從整個過程中被移除。

在elasticsearch和磁碟之間是檔案系統快取。

像之前描述的一樣，在記憶體索引緩衝區

中的文件會被寫入到乙個新的段中

。但是這裡新段會被先寫入到檔案系統快取--這一步代價會比較低，稍後再被重新整理到磁碟--這一步代價比較高。不過只要檔案已經在快取中，就可以像其它檔案一樣被開啟和讀取了。

lucene 允許新段被寫入和開啟--使其包含的文件在未進行一次完整提交時便對搜尋可見。這種方式比進行一次提交代價要小得多，並且在不影響效能的前提下可以被頻繁地執行。

緩衝區的內容已經被寫入乙個可被搜尋的段中，但還沒有進行提交

在 elasticsearch 中，寫入和開啟乙個新段的輕量的過程叫做 refresh

。預設情況下每個分片會每秒自動重新整理一次。這就是為什麼我們說 elasticsearch 是近

實時搜尋: 文件的變化並不是立即對搜尋可見，但會在一秒之內變為可見。

這些行為可能會對新使用者造成困惑: 他們索引了乙個文件然後嘗試搜尋它，但卻沒有搜到。這個問題的解決辦法是用refreshapi 執行一次手動重新整理:

/_refresh

post

/blogs

/_refresh

重新整理（refresh）所有的索引。

只重新整理（refresh）blogs索引。

儘管重新整理是比提交輕量很多的操作，它還是會有效能開銷。

當寫測試的時候，手動重新整理很有用，但是不要在生產環境下每次索引乙個文件都去手動重新整理。相反，你的應用需要意識到 elasticsearch 的近實時的性質，並接受它的不足。

並不是所有的情況都需要每秒重新整理。可能你正在使用 elasticsearch 索引大量的日誌檔案，你可能想優化索引速度而不是近實時搜尋，可以通過設定refresh_interval，降低每個索引的重新整理頻率：

/my_logs

}每30秒重新整理my_logs索引。

refresh_interval可以在既存索引上進行動態更新。在生產環境中，當你正在建立乙個大的新索引時，可以先關閉自動重新整理，待開始使用該索引時，再把它們調回來：

/my_logs

/_settings

put

/my_logs

/_settings

關閉自動重新整理。

每秒自動重新整理。

refresh_interval需要乙個持續時間

值，例如1s（1 秒）或2m（2 分鐘）。乙個絕對值 1

表示的是 1毫秒

--無疑會使你的集群陷入癱瘓。