239
深入淺出 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_shardsrouting 是可變值，支持自定義，默認文檔 _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 這塊的實戰。
最後，《 深入淺出 spring-data-elasticsearch 》小連載目錄如下：
深入淺出 spring-data-elasticsearch - ElasticSearch 架構初探（一）
深入淺出 spring-data-elasticsearch - 概述（二）
深入淺出 spring-data-elasticsearch - 基本案例詳解（三）
深入淺出 spring-data-elasticsearch - 複雜案例詳解（四）
深入淺出 spring-data-elasticsearch - 架構原理以及源碼淺析（五）
資料：
官方《Elasticsearch: 權威指南》
https://www.elastic.co/guide/c ... .html
本文作者： 泥瓦匠
原文鏈接： https://www.bysocket.com
版權歸作者所有，轉載請注明出處
最後更新：2017-06-06 13:01:32