深入淺出spring-data-elasticsearch之ElasticSearch架構(gòu)初探
本文目錄
一、Elasticsearch 基本術(shù)語
1.1 文檔(Document)、索引(Index)、類型(Type)文檔三要素
1.2 集群(Cluster)、節(jié)點(Node)、分片(Shard)分布式三要素
二、Elasticsearch 工作原理
2.1 文檔存儲的路由
2.2 如何健康檢查
2.3 如何水平擴容
三、小結(jié)
一、Elasticsearch 基本術(shù)語
1.1 文檔(Document)、索引(Index)、類型(Type)文檔三要素
文檔(Document)
文檔，在面向?qū)ο笥^念就是一個對象。在 ES 里面，是一個大 JSON 對象，是指定了唯一 ID 的***層或者根對象。文檔的位置由 _index、_type 和 _id 唯一標識。
索引(Index)
索引，用于區(qū)分文檔成組，即分到一組的文檔集合。索引，用于存儲文檔和使文檔可被搜索。比如項目存索引 project 里面，交易存索引 sales 等。
類型(Type)
類型，用于區(qū)分索引中的文檔，即在索引中對數(shù)據(jù)邏輯分區(qū)。比如索引 project 的項目數(shù)據(jù)，根據(jù)項目類型 ui 項目、插畫項目等進行區(qū)分。
和關(guān)系型數(shù)據(jù)庫 MySQL 做個類比：
Document 類似于 Record
Type 類似于 Table
Index 類似于 Database
1.2 集群(Cluster)、節(jié)點(Node)、分片(Shard)分布式三要素
集群(Cluster)
服務(wù)器集群大家都知道，這里 ES 也是類似的。多個 ElasticSearch 運行實例(節(jié)點)組合的組合體是 ElasticSearch 集群。
ElasticSearch 是天然的分布式，通過水平擴容為集群添加更多節(jié)點。
集群是去中心化的，有一個主節(jié)點(Master)。主節(jié)點是動態(tài)選舉，因此不會出現(xiàn)單點故障。
那分片和節(jié)點的配置呢?
節(jié)點(Node)
一個 ElasticSearch 運行實例就是節(jié)點。順著集群來，任何節(jié)點都可以被選舉成為主節(jié)點。主節(jié)點負責集群內(nèi)所以變更，比如索引的增加、刪除等。所以集群不會因為主節(jié)點流量的增大成為瓶頸。因為任何節(jié)點都會成為主節(jié)點。
下面有 3 個節(jié)點，第 1 個節(jié)點有：2 個主分片和 1 個副分片。如圖：
那么，只有一個節(jié)點的 ElasticSearch 服務(wù)會存在瓶頸。如圖：
分片(Shard)
分片，是 ES 節(jié)點中最小的工作單元。分片僅僅保存全部數(shù)據(jù)的一部分，分片的集合是 ES 的索引。分片包括主分片和副分片，主分片是副分片的拷貝。主分片和副分片地工作基本沒有大的區(qū)別。
在索引中全文搜索，然后會查詢到每個分片，將每個分配的結(jié)果進行全局地收集處理，并返回。
二、Elasticsearch 工作原理
2.1 文檔存儲的路由
當索引到一個文檔(如：報價系統(tǒng))，具體的文檔數(shù)據(jù)(如：報價數(shù)據(jù))會存儲到一個分片。具體文檔數(shù)據(jù)會被切分，并分別存儲在分片 1 或者 分片 2 …
那么如何確定存在哪個分片呢?
存儲路由過程由下面地公式?jīng)Q定：
- shard = hash(routing) % number_of_primary_shards
routing 是可變值，支持自定義，默認文檔 _id。
hash 函數(shù)生成數(shù)字，經(jīng)過取余算法得到余數(shù)，那么這個余數(shù)就是分片的位置。
這是不是有點負載均衡的類似。
2.2 如何健康檢查
集群名，集群的健康狀態(tài)
- 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 字段是需要我們關(guān)心的。狀態(tài)可能是下列三個值之一：
- green所有的主分片和副本分片都已分配。你的集群是 100% 可用的。
- yellow
- 所有的主分片已經(jīng)分片了，但至少還有一個副本是缺失的。不會有數(shù)據(jù)丟失，所以搜索結(jié)果依然是完整的。高可用會弱化把 yellow 想象成一個需要及時調(diào)查的警告。
- red
- 至少一個主分片(以及它的全部副本)都在缺失中。這意味著你在缺少數(shù)據(jù)：搜索只能返回部分數(shù)據(jù)，而分配到這個分片上的寫入請求會返回一個異常。
active_primary_shards 集群中的主分片數(shù)量
active_shards 所有分片的匯總值
relocating_shards 顯示當前正在從一個節(jié)點遷往其他節(jié)點的分片的數(shù)量。通常來說應(yīng)該是 0，不過在 Elasticsearch 發(fā)現(xiàn)集群不太均衡時，該值會上漲。比如說：添加了一個新節(jié)點，或者下線了一個節(jié)點。
initializing_shards 剛剛創(chuàng)建的分片的個數(shù)。
unassigned_shards 已經(jīng)在集群狀態(tài)中存在的分片。
2.3 如何水平擴容
主分片在索引創(chuàng)建已經(jīng)確定。讀操作可以同時被主分片和副分片處理。因此，更多的分片，會擁有更高的吞吐量。自然，需要增加更多的硬件資源支持吞吐量。
說明，這里無法提高性能，因為每個分片獲得的資源會變少。
動態(tài)調(diào)整副本分片數(shù)，按需伸縮集群，比如把副本數(shù)默認值為 1 增加到 2：
- PUT /blogs/_settings
- { "number_of_replicas" : 2}
三、小結(jié)
簡單初探了下 ElasticSearch 的相關(guān)內(nèi)容。后面會主要落地到實戰(zhàn)，關(guān)于 spring-data-elasticsearch 這塊的實戰(zhàn)。
【本文為51CTO專欄作者“李強強”的原創(chuàng)稿件，轉(zhuǎn)載請通過51CTO聯(lián)系作者獲取授權(quán)】
