spring-data-elasticsearch 架構初探（一）

本文目錄
1、Elasticsearch 基本術語
1.1 文檔（Document）、索引（Index）、類型（Type）文檔三要素
1.2 集羣（Cluster）、節點（Node）、分片（Shard）分佈式三要素
2、Elasticsearch 工做原理
2.1 文檔存儲的路由
2.2 如何健康檢查
2.3 如何水平擴容
3、小結

1、Elasticsearch 基本術語

1.1 文檔（Document）、索引（Index）、類型（Type）文檔三要素
文檔（Document）
文檔，在面向對象觀念就是一個對象。在 ES 裏面，是一個大 JSON 對象，是指定了惟一 ID 的最底層或者根對象。文檔的位置由 _index、_type 和 _id 惟一標識。

 

索引（Index）
索引，用於區分文檔成組，即分到一組的文檔集合。索引，用於存儲文檔和使文檔可被搜索。好比項目存索引 project 裏面，交易存索引 sales 等。

類型（Type）
類型，用於區分索引中的文檔，即在索引中對數據邏輯分區。好比索引 project 的項目數據，根據項目類型 ui 項目、插畫項目等進行區分。

和關係型數據庫 MySQL 作個類比：
Document 相似於 Record
Type 相似於 Table
Index 相似於 Database

1.2 集羣（Cluster）、節點（Node）、分片（Shard）分佈式三要素
集羣（Cluster）
服務器集羣你們都知道，這裏 ES 也是相似的。多個 ElasticSearch 運行實例（節點）組合的組合體是 ElasticSearch 集羣。
ElasticSearch 是自然的分佈式，經過水平擴容爲集羣添加更多節點。
集羣是去中心化的，有一個主節點（Master）。主節點是動態選舉，所以不會出現單點故障。

那分片和節點的配置呢？

節點（Node）
一個 ElasticSearch 運行實例就是節點。順着集羣來，任何節點均可以被選舉成爲主節點。主節點負責集羣內因此變動，好比索引的增長、刪除等。因此集羣不會由於主節點流量的增大成爲瓶頸。由於任何節點都會成爲主節點。
下面有 3 個節點，第 1 個節點有：2 個主分片和 1 個副分片。如圖：

那麼，只有一個節點的 ElasticSearch 服務會存在瓶頸。如圖：

 

分片（Shard）
分片，是 ES 節點中最小的工做單元。分片僅僅保存所有數據的一部分，分片的集合是 ES 的索引。分片包括主分片和副分片，主分片是副分片的拷貝。主分片和副分片地工做基本沒有大的區別。
在索引中全文搜索，而後會查詢到每一個分片，將每一個分配的結果進行全局地收集處理，並返回。

2、Elasticsearch 工做原理

2.1 文檔存儲的路由
當索引到一個文檔（如：報價系統），具體的文檔數據（如：報價數據）會存儲到一個分片。具體文檔數據會被切分，並分別存儲在分片 1 或者 分片 2 … 那麼如何肯定存在哪一個分片呢?

存儲路由過程由下面地公式決定：

 

shard = hash(routing) % number_of_primary_shards

routing 是可變值，支持自定義，默認文檔 _id。
hash 函數生成數字，通過取餘算法獲得餘數，那麼這個餘數就是分片的位置。
這是否是有點負載均衡的相似。

2.2 如何健康檢查
集羣名，集羣的健康狀態

GET http://127.0.0.1:9200/_cluster/stats
{
"cluster_name": "elasticsearch",
"status": "green",
"timed_out": false,
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"active_primary_shards": 0,
"active_shards": 0,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0
}

status 字段是須要咱們關心的。狀態多是下列三個值之一：
 

green
全部的主分片和副本分片都已分配。你的集羣是 100% 可用的。
yellow
全部的主分片已經分片了，但至少還有一個副本是缺失的。不會有數據丟失，因此搜索結果依然是完整的。高可用會弱化把 yellow 想象成一個須要及時調查的警告。
red
至少一個主分片（以及它的所有副本）都在缺失中。這意味着你在缺乏數據：搜索只能返回部分數據，而分配到這個分片上的寫入請求會返回一個異常。

active_primary_shards 集羣中的主分片數量
active_shards 全部分片的彙總值
relocating_shards 顯示當前正在從一個節點遷往其餘節點的分片的數量。一般來講應該是 0，不過在 Elasticsearch 發現集羣不太均衡時，該值會上漲。好比說：添加了一個新節點，或者下線了一個節點。
initializing_shards 剛剛建立的分片的個數。
unassigned_shards 已經在集羣狀態中存在的分片。

2.3 如何水平擴容
主分片在索引建立已經肯定。讀操做能夠同時被主分片和副分片處理。所以，更多的分片，會擁有更高的吞吐量。天然，須要增長更多的硬件資源支持吞吐量。說明，這裏沒法提升性能，由於每一個分片得到的資源會變少。動態調整副本分片數，按需伸縮集羣，好比把副本數默認值爲 1 增長到 2：

PUT /blogs/_settings
{
"number_of_replicas" : 2
}

 

3、小結

簡單初探了下 ElasticSearch 的相關內容。後面會主要落地到實戰，關於 spring-data-elasticsearch 這塊的實戰。