這裡記錄一些 Elasticsearch 核心概念及機制說明：

Document

一個 document 就是一條數據單元，以 JSON 的格式存在，每一條訊息紀錄、字串、文本內容，經過索引處理後，就會以 Document 形式儲存起來，在 Elasticsearch 主要搜尋索引，在透過搜尋結果找到對應的 Document。

Field

將文本轉換成 Document 後，文檔中每一個欄位就是 Field，可以針對 Field 設定搜尋的規則，以及可以安裝不同 Field 內容適合的分詞器

Field 可以設定兩種屬性： 是否建立索引，是否儲存

通常會有以下幾種情況：

  • 建立索引及儲存，可以在搜尋時同時返回內容；通常建議儲存只設定在標題、標籤等少量文本
  • 建立索引但不儲存，可以搜尋以及知道他的 document ，可以在透過讀取 document 拿到內容；通常對文章內容太大時，就會採取這種方式，避免對整篇文章建立索引
  • 不建立索引但儲存，例如有些欄位不需要搜尋，但在 document 仍需紀錄該值

Term

Term 是 Elasticsearch 搜尋的最小單位，由詞語和所在的 Fiield 組成，在 Field 設定好屬性後，如果屬於索引就會拆分為 Term。

Type

在 ES7 之後默認就不再支援自訂義 type，default type 為 _doc

因為，在 Elasticsearch 索引可以快速搜尋取得相關的 document，不應該在中間在存在 type 這樣的概念。

(備註：5.x 版本支援多種 type, 6.x 只支援一種 type, 7.x 默認不支持自定義 type 而是預設為 _doc)

Shard 分片

一個完整的數據，在 Elasticsearch 可以拆分切割為多個 shard，以及可以做分布式的查詢，提高性能及吞吐量。

這些 shard 的分佈，document 的聚合及搜尋都是完全由 Elasticsearch 管理。

Replicas shards 副本分片

將原有數據另外儲存為副本，作為故障移轉移機制。

在 Elasticsearch 可以將 shard 進行 replicas ，萬一某一個 shard 故障，如果有加入 replicas ，在失敗的情況就可以持續提供服務。此外，replicas 也可以取得數據，因此也可以提高吞吐量。

Allocation 分配

Elasticsearch 分配數據到 shard 主要由 master node 來完成。後面會介紹到。

倒排索引列表

倒排索引是在 Elasticsearch 將儲存的內文進行拆分(稱為 分詞)，在對這些詞條進行編號成索引。

這些索引都會有 ID，以及對應的倒排列表，倒排列表紀錄的是文檔 ID，可以用來找到對應文本內容

搜尋過程會發生什麼事情

在 Elasticsearch 輸入搜尋字串，首先會同樣依照分詞器的邏輯，將搜尋字串拆分，拆分後會得到詞條，再拿這些詞條到倒排索引列表中搜尋這些字串對應的索引，取得對應的文本 ID，最後在找到對應的文本內容。

安裝設定資料結構說明

從安裝結構來了解 Elasticsearch 基本的架構及配製方法，在 Elasticsearch 安裝的資料結構，說明如下：

bin  啟動、關閉相關命令
config   ES, log配置相關文件
   - elasticsearch.yml 主要是 ES 相關的配置
   - options 在啟動或工作相關的記憶體配置
   - log4j2.properties  日誌相關配置
lib    	ES工作所需的 jar 包依賴(json, log4j, lucene...)
logs   日誌
modules   ES依賴的第三方組件，再啟動時會加載
plugins:  我們配置的第三方插件, ex IK 分詞器

Master Node 介紹

Master 選舉機制

在 Elasticsearch 會需要再多個節點中，推舉出一個 master node 負責管理 cluster, node 及 index 。 (Master node 不負責管理 document，Data node 才會負責管理 document）。

在 Elasticsearch 主要透過 ZenDiscovery module 來負責，其中包含兩部分：

Unicast: 單播模組，主要包含主機列表以及需要哪些節點需要執行ping通訊

Ping: 節點之間的通訊機制，主要使用 RPC 來發現彼此

只要節點的設定 node.master: true 就能夠有資格成為 master

當 Data node 訪問不到 master 時，引發 cluster 腦裂問題

節點發生延遲的原因可能有以下幾種：

  • 有些 node 發生網路延遲
  • node 身兼多職，同時為 master node 及 data node
  • JVM 內存回收，造成 Elasticsearch process 遺失

當 cluster 節點因為上述因素，有部分節點無法訪問到 master 時並且誤判 master 掛掉時，會將原本 master shard 及 repleca 標為 red，且推選出新的 master shard，進而導致 cluser 出現多個 master 的情況。

腦裂問題的解決方式

  • 延長等待時間， discovery.zen.ping_timeout 等待時間預設為 3s，可以延長為 6s 減少誤判
  • 選舉觸發， discovery.zen.minimum_master_nodes 預設 master node 數量為 1，建議設定為奇數 （n/2)+1
  • 角色分離，避免 node 同時兼任 master 與 data node，
    • Master 節點應該分配為 node.master: true, node.data:false
    • Slave 節點應該配置為 node.master: false, node.data: true

Elasticsearch 索引文檔的流程

在 Elasticsearch 的 document 是不可變動的，當執行 Delete 或 Update 都會進行寫入操作，也就是說你執行 Delete，事實上是將該紀錄標記在 .del 文檔中，還是可以被搜尋配對，但會被過濾掉、不會被顯示。

ES 搜尋流程：Query then fetch

在 Elasticsearch 搜尋會被分為兩階段：Query then fetch

如何監控 Cluster

可以在 Elasticsearch 安裝監控插件 elasticsearch-head 可以看到 node, shard 訊息都可以看的到。

另外，直接透過 Kibana 也可以即時查看 ES 健康狀態及指標。