深入淺出spring-data-elasticsearch之ElasticSearch架構初探
本文目錄
一、Elasticsearch 基本術語
1.1 文檔(Document)、索引(Index)、類型(Type)文檔三要素
1.2 集群(Cluster)、節點(Node)、分片(Shard)分布式三要素
二、Elasticsearch 工作原理
2.1 文檔存儲的路由
2.2 如何健康檢查
2.3 如何水平擴容
三、小結
一、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 的索引。分片包括主分片和副分片，主分片是副分片的拷貝。主分片和副分片地工作基本沒有大的區別。
在索引中全文搜索，然后會查詢到每個分片，將每個分配的結果進行全局地收集處理，并返回。
二、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}
三、小結
簡單初探了下 ElasticSearch 的相關內容。后面會主要落地到實戰，關于 spring-data-elasticsearch 這塊的實戰。
【本文為51CTO專欄作者“李強強”的原創稿件，轉載請通過51CTO聯系作者獲取授權】
