倒排索引
首先來了解一下什么是
倒排索引，就是建立詞語與文檔的對應關系（詞語在什么文檔出現，出現了多少次，在什么位置出現）
搜索的時候，根據搜索關鍵詞，直接在索引中找到對應關系，搜索速度快。
doc:表示哪個文檔，
frep：表示出現的頻率
pos：表示出現的位置
1、寫數據過程
-
客戶端通過hash選擇一個node發送請求，這個node被稱做coordinating node（協調節點），
-
協調節點對docmount進行路由，將請求轉發給到對應的primary shard
-
primary shard 處理請求，將數據同步到所有的replica shard
-
此時協調節點，發現primary shard 和所有的replica shard都處理完之后，就反饋給客戶端。
2、寫數據的底層原理
-
在到達primary shard的時候 ，數據先寫入內存buffer ， 此時，在buffer里的數據是不會被搜索到的同時生成一個translog日志文件 ， 將數據寫入translog里
-
如果內存buffer空間快man滿了，就會將數據refresh到一個新的segment file文件中，而且es里每隔1s就會將buffer里的數據寫入到一個新的segment file中，這個segment file就存儲最最近1s中buffer寫入的數據，如果buffer里面沒有數據，就不會執行refresh操作，當建立segment file文件的時候，就同時建立好了倒排索引庫。
-
在buffer refresh到segment之前 ，會先進入到一個叫os cache中，只要被執行了refresh操作，就代表這個數據可以被搜索到了。數據被輸入os cache中，buffer就會被清空了，所以為什么叫es是准實時的？NRT，near real-time，准實時。默認是每隔1秒refresh一次的，所以es是准實時的，因為寫入的數據1秒之后才能被看到。還可以通過es的restful api或者java api，手動執行一次refresh操作，就是手動將buffer中的數據刷入os cache中，讓數據立馬就可以被搜索到。
-
就這樣新的數據不斷進入buffer和translog，不斷將buffer數據寫入一個又一個新的segment file中去，每次refresh完buffer清空，translog保留。隨着這個過程推進，translog會變得越來越大。當translog達到一定長度的時候，就會觸發commit操作。translog也是先進入os cache中，然后每隔5s持久化到translog到磁盤中，
-
commit操作，第一步，就是將buffer中現有數據refresh到os cache中去，清空buffer 每隔30分鍾flush
-
es也有可能會數據丟失 ，有5s的數據停留在buffer、translog os cache, segment file os cache中，有5s的數據不在磁盤上，如果此時宕機，這5s的數據就會丟失，如果項目要求比較高，不能丟失數據，就可以設置參數，每次寫入一條數據寫入buffer，同時寫入translog磁盤文件中，但這樣做會使es的性能降低。
-
如果是刪除操作，commit操作的時候就會生成一個.del文件，將這個document標識為deleted狀態，在搜索的搜索的時候就不會被搜索到了。
-
如果是更新操作，就是將原來的document標識為deleted狀態，然后新寫入一條數據
-
buffer每次refresh一次，就會產生一個segment file，所以默認情況下是1秒鍾一個segment file，segment file會越來越多，當躲到一定程度的時候，es就會自動觸發merge(合並)造作，將所有segment file文件 merge成一個segment file，並同時物理刪除掉標識為deleted的doc，
3、es讀取過程
-
客戶端發送get請求到任意一個node節點，然后這個節點就稱為協調節點，
-
協調節點對document進行路由，將請求轉發到對應的node，此時會使用隨機輪詢算法，在primary shard 和replica shard中隨機選擇一個，讓讀取請求負載均衡，
-
接收請求的node返回document給協調節點，
-
協調節點，返回document給到客戶端
4、 搜索過程
-
客戶端發送請求到協調節點，
-
協調節點將請求大宋到所有的shard對應的primary shard或replica shard ；
-
每個shard將自己搜索到的結果返回給協調節點，返回的結果是dou.id或者自己自定義id，然后協調節點對數據進行合並排序操作，最終得到結果。
-