分布式搜尋引擎es原理

分布式架構原理怎麼寫入？

首先呢寫入一條資料，挑選乙個機器，就叫協調節點，協調節點經過hash講資料路由到對應的primary shard 上，primary shard 將資料同步到replica上去，完成以後，協調節點會返回成功響應給客戶端

primary shard會把資料寫在記憶體buffer裡，同時寫在translog日誌檔案裡

如果buffer快滿了，就會將buffer資料先進os cache快取一下然後refresh到乙個新的segment file(磁碟檔案中)

只要buffer中的資料被refresh操作，刷入os cache中，就代表這個資料就可以被搜尋到了

flush=commit全操作

當translog達到一定長度的時候，就會觸發commit操作

commit操作：

1、寫commit point；

2、將os cache資料fsync強刷到磁碟上去；

3、清空translog日誌檔案（自動每隔30分種清空，滿了清空，手動清空）

es第一是準實時的，資料寫入1秒後可以搜尋到；可能會丟失資料的，你的資料有5秒的資料，停留在buffer、translog os cache、segment file os cache中，有5秒的資料不在磁碟上，此時如果宕機，會導致5秒的資料丟失。

es讀資料過程

1）客戶端傳送請求到任意乙個node，成為coordinate node（協調節點）

2）coordinate node對document進行路由，將請求**到對應的node，此時會使用round-robin隨機輪詢演算法，在primary shard以及其所有replica中隨機選擇乙個，讓讀請求負載均衡

3）接收請求的node返回document給coordinate node

4）coordinate node返回document給客戶端

es搜尋資料過程

1）客戶端傳送請求到乙個coordinate node

2）協調節點將搜尋請求**到所有的shard對應的primary shard或replica shard也可以

3）query phase：每個shard將自己的搜尋結果（其實就是一些doc id），返回給協調節點，由協調節點進行資料的合併、排序、分頁等操作，產出最終結果

4）fetch phase：接著由協調節點，根據doc id去各個節點上拉取實際的document資料，最終返回給客戶端

在資料量很大的情況下（億級別）如何提高查詢效率啊？