#近實時搜索 因為`per-segment search`機制，索引和搜索一個文檔之間是有延遲的。新的文檔會在幾分鐘內可以搜索，但是這依然不夠快。 磁盤是瓶頸。提交一個新的段到磁盤需要`fsync`操作，確保段被物理地寫入磁盤，即時電源失效也不會丟失數據。但是`fsync`是昂貴的，它不能在每個文檔被索引的時就觸發。 所以需要一種更輕量級的方式使新的文檔可以被搜索，這意味這移除`fsync`。 位于Elasticsearch和磁盤間的是文件系統緩存。如前所說，在內存索引緩存中的文檔（圖1）被寫入新的段（圖2），但是新的段首先寫入文件系統緩存，這代價很低，之后會被同步到磁盤，這個代價很大。但是一旦一個文件被緩存，它也可以被打開和讀取，就像其他文件一樣。 **圖1：內存緩存區有新文檔的Lucene索引**  Lucene允許新段寫入打開，好讓它們包括的文檔可搜索，而不用執行一次全量提交。這是比提交更輕量的過程，可以經常操作，而不會影響性能。 **圖2：緩存內容已經寫到段中，但是還沒提交**  ##refeash API 在Elesticsearch中，這種寫入打開一個新段的輕量級過程，叫做refresh。默認情況下，每個分片每秒自動刷新一次。這就是為什么說Elasticsearch是近實時的搜索了：文檔的改動不會立即被搜索，但是會在一秒內可見。 這會困擾新用戶：他們索引了個文檔，嘗試搜索它，但是搜不到。解決辦法就是執行一次手動刷新，通過API: ```Javascript POST /_refresh <1> POST /blogs/_refresh <2> ``` - &lt;1> refresh所有索引 - &lt;2> 只refresh 索引`blogs` >雖然刷新比提交更輕量，但是它依然有消耗。人工刷新在測試寫的時有用，但是不要在生產環境中每寫一次就執行刷新，這會影響性能。相反，你的應用需要意識到ES近實時搜索的本質，并且容忍它。 不是所有的用戶都需要每秒刷新一次。也許你使用ES索引百萬日志文件，你更想要優化索引的速度，而不是進實時搜索。你可以通過修改配置項`refresh_interval`減少刷新的頻率： ```Javascript PUT /my_logs { "settings": { "refresh_interval": "30s" <1> } } ``` - &lt;1> 每30s refresh一次`my_logs` `refresh_interval`可以在存在的索引上動態更新。你在創建大索引的時候可以關閉自動刷新，在要使用索引的時候再打開它。 ```Javascript PUT /my_logs/_settings { "refresh_interval": -1 } <1> PUT /my_logs/_settings { "refresh_interval": "1s" } <2> ``` - &lt;1> 禁用所有自動refresh - &lt;2> 每秒自動refresh