es結構和工作原理概述
阿新 • • 發佈：2019-01-08
啟動過程
當ElasticSearch的節點啟動後，它會利用多播(multicast)(或者單播，如果使用者更改了配置)尋找叢集中的其它節點，並與之建立連線。這個過程如下圖所示
在叢集中，一個節點被選舉成主節點(master node)。這個節點負責管理叢集的狀態，當群集的拓撲結構改變時把索引分片分派到相應的節點上。
從使用者的角度來看，主節點在ElasticSearch中並沒有佔據著重要的地位，這與其它的系統(比如資料庫系統)是不同的。實際上使用者並不需要知道哪個節點是主節點；所有的操作需求可以分發到任意的節點，ElasticSearch內部會完成這些讓使用者感到不明覺歷的工作。在必要的情況下，任何節點都可以併發地把查詢子句分發到其它的節點，然後合併各個節點返回的查詢結果。最後返回給使用者一個完整的資料集。所有的這些工作都不需要經過主節點轉發(節點之間通過P2P的方式通訊)。 
與ElasticSearch進行通訊
我們已經探討了ElasticSearch是如何構建起來的，但是歸根到底，最重要的是如何往ElasticSearch中新增資料以及如何查詢資料。為了實現上述的需求，ElasticSearch提供了精心設計的API。
ElasticSearch認為資料應該伴隨在URL中，或者作為請求的主體(request body)，以一種JSON格式(http://en.wikipedia.org/wiki/JSON )的文件傳送給伺服器。如果讀者用Java或者其它執行在JVM虛擬機器上的語言，應該關注一下Java
API，它除了是群集中內建的REST風格API外，功能與URL請求是一樣的。 
資料查詢
我們能夠與叢集中的任何節點通訊，包括主節點。任何一個節點互相知道文件存在於哪個節點上，它們可以轉發請求到我們需要資料所在的節點上。我們通訊的節點負責收集各節點返回的資料，最後一起返回給客戶端。這一切都由Elasticsearch透明的管理。
關於資料查詢，其核心點在於查詢過程不是一個簡單、單一的流程。通常這個過程分為兩個階段：查詢分發階段和結果彙總階段。在查詢分發階段，會從各個分片中查詢資料；在結果彙總階段，會把從各個分片上查詢到的結果進行合併、排序等其它處理過程，然後返回給使用者。
使用者可以通過指定搜尋型別來控制查詢的分發和彙總過程：
QUERY_THEN_FETCH
是針對所有的塊執行的，但返回的是足夠的資訊，而不是文件內容（Document）。結果會被排序和分級，基於此，只有相關的塊的文件物件會被返回。由於被取到的僅僅是這些，故而返回的hit的大小正好等於指定的size。這對於有許多塊的index來說是很便利的（返回結果不會有重複的，因為塊被分組了）。
QUERY_AND_FETCH
最原始（也可能是最快的）實現就是簡單的在所有相關的shard上執行檢索並返回結果。每個shard返回一定尺寸的結果。由於每個shard已經返回了一定尺寸的hit，這種型別實際上是返回多個shard的一定尺寸的結果給呼叫者。最快，但不準確
DFS_QUERY_THEN_FETCH
與QUERY_THEN_FETCH相同，預期一個初始的散射相伴用來為更準確的score計算分配了的term頻率。
DFS_QUERY_AND_FETCH
與QUERY_AND_FETCH相同，預期一個初始的散射相伴用來為更準確的score計算分配了的term頻率。SCAN被用來檢索大量的結果（甚至所有的結果），就像在傳統資料庫中使用的遊標.全域性排序，若禁止排序,無法查詢實時資料。官網3.0會棄用
查詢API在ElasticSearch中有著很大的比重。通過使用Query DSL(基於JSON，用來構建複雜查詢的語言) ，我們能夠：
在叢集中，一個節點被選舉成主節點(master node)。這個節點負責管理叢集的狀態，當群集的拓撲結構改變時把索引分片分派到相應的節點上。
從使用者的角度來看，主節點在ElasticSearch中並沒有佔據著重要的地位，這與其它的系統(比如資料庫系統)是不同的。實際上使用者並不需要知道哪個節點是主節點；所有的操作需求可以分發到任意的節點，ElasticSearch內部會完成這些讓使用者感到不明覺歷的工作。在必要的情況下，任何節點都可以併發地把查詢子句分發到其它的節點，然後合併各個節點返回的查詢結果。最後返回給使用者一個完整的資料集。所有的這些工作都不需要經過主節點轉發(節點之間通過P2P的方式通訊)。
與ElasticSearch進行通訊
我們已經探討了ElasticSearch是如何構建起來的，但是歸根到底，最重要的是如何往ElasticSearch中新增資料以及如何查詢資料。為了實現上述的需求，ElasticSearch提供了精心設計的API。
ElasticSearch認為資料應該伴隨在URL中，或者作為請求的主體(request body)，以一種JSON格式(http://en.wikipedia.org/wiki/JSON )的文件傳送給伺服器。如果讀者用Java或者其它執行在JVM虛擬機器上的語言，應該關注一下Java
API，它除了是群集中內建的REST風格API外，功能與URL請求是一樣的。
資料查詢
我們能夠與叢集中的任何節點通訊，包括主節點。任何一個節點互相知道文件存在於哪個節點上，它們可以轉發請求到我們需要資料所在的節點上。我們通訊的節點負責收集各節點返回的資料，最後一起返回給客戶端。這一切都由Elasticsearch透明的管理。
關於資料查詢，其核心點在於查詢過程不是一個簡單、單一的流程。通常這個過程分為兩個階段：查詢分發階段和結果彙總階段。在查詢分發階段，會從各個分片中查詢資料；在結果彙總階段，會把從各個分片上查詢到的結果進行合併、排序等其它處理過程，然後返回給使用者。
使用者可以通過指定搜尋型別來控制查詢的分發和彙總過程：
QUERY_THEN_FETCH
是針對所有的塊執行的，但返回的是足夠的資訊，而不是文件內容（Document）。結果會被排序和分級，基於此，只有相關的塊的文件物件會被返回。由於被取到的僅僅是這些，故而返回的hit的大小正好等於指定的size。這對於有許多塊的index來說是很便利的（返回結果不會有重複的，因為塊被分組了）。
QUERY_AND_FETCH
最原始（也可能是最快的）實現就是簡單的在所有相關的shard上執行檢索並返回結果。每個shard返回一定尺寸的結果。由於每個shard已經返回了一定尺寸的hit，這種型別實際上是返回多個shard的一定尺寸的結果給呼叫者。最快，但不準確
DFS_QUERY_THEN_FETCH
與QUERY_THEN_FETCH相同，預期一個初始的散射相伴用來為更準確的score計算分配了的term頻率。
DFS_QUERY_AND_FETCH
與QUERY_AND_FETCH相同，預期一個初始的散射相伴用來為更準確的score計算分配了的term頻率。SCAN被用來檢索大量的結果（甚至所有的結果），就像在傳統資料庫中使用的遊標.全域性排序，若禁止排序,無法查詢實時資料。官網3.0會棄用
查詢API在ElasticSearch中有著很大的比重。通過使用Query DSL(基於JSON，用來構建複雜查詢的語言) ，我們能夠：
- 使用各種型別的查詢方式，包括：簡單的關鍵詞查詢(termquery) ,短語(phrase)、區間(range)、布林(boolean)、模糊(fuzzy)、跨度(span)、萬用字元(wildcard)、地理位置(spatial)等其它型別的查詢方式。
- 通過組合簡單查詢構建出複雜的查詢。
- 過濾文件，去除不符合標準的文件而且不影響打分排序。
- 查詢給定文件的相似文件。
- 查詢給定短語的搜尋建議和查詢短語修正。
- 通過faceting構建動態的導航和資料統計
- 使用prospective search而且找到匹配文件的查詢語句。(關於prospective search，似乎是一種推送方式。即把使用者的查詢語句儲存到索引中，如果新的文件新增到索引中，就把文件關聯到匹配的查詢語句中。這種查詢適合於新聞、部落格等會定時更新的應用場景)