前言
1：查詢的過程是怎樣的（結合架構分析）
2：索引過程是怎樣的（結合架構分析）
3：ES索引的存儲結構是怎樣的
本文只介紹索引
正文
1： 索引過程
文檔只有在segment中才能被查詢，建索引的時候是放在內存中，此內存不是一個segment。
refresh操作是生成新segment，fsync是將translog刷新到磁盤，flush相當於一次segment落盤。
a： 更新的doc，先會被放在mem-buffer中，即在建完的正倒排信息放在內存中，並且將此次id的操作追加到translog緩存中（內存）
b： 執行refresh，一個新segment生成，上述內存索引的數據會放入到此新segment中，此次新建的文檔都可以查詢 @hxx 類似esearch 3s段生成，ES默認refresh間隔是1s（可設置）。
c：執行完b的refresh後，正倒排的mem-buffer清空，而translog緩存還不會被清空
d：5s間隔執行一個fsync操作，將translog緩存寫入translog文件（落盤了，但是segment還在內存中）
d： flush 操作，translog和新segment均落盤 @hxx 類似6h，ES是默認30m
相同點： 與esearch有很多相似的地方，更新的文檔在老端中存在，也是被標記刪除的，等到merge的時候會被真正的刪除。
不同點： translog爲了保證在30min內segment還未落盤宕機產生的丟數據風險，保證最多丟5s的文檔。flush會有兩個操作，將segment落盤和translog緩存中的數據落盤，translog緩存中的數據會5s自動落盤。
數據持久化步驟如下：write -> refresh -> flush -> merge
設置實時性：
PUT /my_logs { "settings": { "refresh_interval": "30s" ## 實時性是30s可見！ } }