ElasticSearch 學習記錄之分布式文檔存儲往ES中存數據和取數據的原理

green 主副分片均正常
yellow 主都正常，不是所有的副都正常
red 所有主分片都不正常
分片的特點
- Elasticsearch 是利用分片將數據分發到集群內各處
- 分片是數據的容器，文檔保存在分片內
- 分片又被分配到集群內的各個節點里
- 當集群規模變動，ES會自動在各個節點中遷移分片。使得數據任然均勻分布在集群中
- 副分片是主分片的一個拷貝，作為硬件故障時的備份。並提供返回文檔讀操作
- 在創建索引時，確定主分片數，但是副分片可以在后面進行更改

在更新一個文檔時的ES內部操作

Elasticsearch 已將舊文檔標記為已刪除，並增加一個全新的文檔。
盡管你不能再對舊版本的文檔進行訪問，但它並不會立即消失。
當繼續索引更多的數據，Elasticsearch 會在后台清理這些已刪除文檔

ES如何處理沖突

使用樂觀並發控制
利用 _version 號來確保應用中相互沖突的變更不會導致數據丟失
通過外部系統使用版本控制

文檔的部分更新

文檔不能被修改，只能被替換

如何路由一個文檔到一個分片中

當索引一個文檔時，我們怎么知道這個文檔在什么位置
使用下面的這個路由選擇公式

1.shard = hash(routing) % number_of_primary_shards

下面將對這個公式每個字段進行分析
- shard 哪個分片，也就是分片id
- routing 一個可變值，默認是文檔的id
- hash 一個哈希函數，對rounting字段進行哈希計算生成一個數字
- number_of_primary_shards 主分片的數量，routing字段經過hash函數計算之后的值，將對主分片的數量也就是 number_of_primary_shards 進行取與，之后得到的shard就是我們文檔所在的分片的位置

`主分片和副分片如何交互`

假設一個集群由三個節點組成。有一個索引，這個索引有兩個主分片，每個主分片有兩個副分片，相同的分片的副本不會放在同一個節點上。
請求發送到集群任意節點，每個節點都有能力處理請求。每個節點都知道集群中任一文檔的位置，所以可以將請求轉發到需求節點上。

`新建、索引和刪除單個文檔時的流程`

1. 先向 node 1 來一個請求這個請求可能是發送新建，索引或者刪除文檔等。
2. node 1 節點根據文檔的_id 確定文檔屬於分片0，請求被轉發到node3 節點
3. node 3 在主分片執行了請求，如果主分片執行成功了，它將請求轉發給node1 和node 2 節點。當所有的副分片都執行成功，node 3 將協調節點報告成功，並向客戶端報告完成
consistency 參數的值可以設為 one （只要主分片狀態 ok 就允許執行寫操作）,all（必須要主分片和所有副本分片的狀態沒問題才允許執行_寫_操作）, 或quorum 。默認值為 quorum , 即大多數的分片副本狀態沒問題就允許執行寫操作
在執行一個寫操作時，主分片都需要必須有一個規定數量的（quorum），也就是在大多數主副分片處於活躍狀態。這樣是防止在網絡分區故障是執行寫操作會導致數據不一致

1.quorum = int( (primary + number_of_replicas) / 2 ) + 1

`取回一個文檔`

可以從主分片或者任意副本分片檢索文檔
1. 某個請求向node 1 發送獲取請求節點使用
2. 節點使用節點文檔_ID來確定文檔屬於分片0，分片0 的副本分片存在於所有的三個節點上，在這種情況下，他將請求轉發到node 2
3. node 2 將文檔返回給node 1 ，然后將文檔返回給客戶端
在每次處理讀取請求時，協調結點在每次請求的時候都會輪訓所有的副本片來達到負載均衡

`局部更新文檔`

部分更新一個文檔的步驟
1. 客戶端向node1 發送一個請求
2. 它將請求轉發到主分片這個文檔所在的Node 3
3. node 3從主分片檢索文檔，修改_Source json ，並且嘗試重新索引主分片的文檔。如果文檔被另一個進程修改，他會重復步驟3 知道超過retry_on_conflict 次后放棄
4. node 3 成功更新文檔，它將新版本的文檔並行轉發到node 1 和node 2 的副本分片，重新建立索引。所有副本分片都返回成功，node 3 向協調節點也返回成功，協調節點向客戶端返回成功
5. update 操作也支持新建索引的時的那些參數 routing 、 replication 、 consistency 和 timeout

`多文檔模式`

mget 和 bulk API 的模式類似於單文檔模式。協調節點知道每個文檔的位置，將多個文檔分解成每個文檔的的多文檔請求，並且將這些請求並行的轉發到每個參與節點中。
使用 mget 取回多個文檔
1. 客戶端向node 1 發送一個mget請求
2. node 1 向每個分片構建多文檔請求，並行的轉發這些請求到托管在每個所需的主分盤或者副分片的節點上一旦收到所有的額回復，node 1 構建響應並將其返回給客戶端
使用 bulk 修改多個文檔
1. 一個bulk請求請求到node 1
2. node 1 為每個節點創建一個批量請求，並將這些請求並行轉發到每個包含主分片的節點
3. 主分片一個接一個按順序執行每個操作。當每個操作成功時，主分片並行轉發新文檔（或刪除）到副本分片，然后執行下一個操作。一旦所有的副本分片報告所有操作成功，該節點將向協調節點報告成功，協調節點將這些響應收集整理並返回給客戶端

`搜索—–最基本的工具`

ElastcSearch 的三個基本概念
1. 映射 Mapping 描述數據在每個字段是如何存儲的
2. 分析 Analysis 全文如何處理使之可以被搜索到
3. Query DSL ES中強大靈活的查詢語言
空搜索
- GET /_search 沒有指定任何查詢的搜索包括沒有指定索引

1.**查詢獲取之后**

**查詢獲取之后**

2.
3. {
4. "took": 8, //請求耗費多少毫秒
5. "timed_out": false,//是否超時
6. "_shards": {//在查詢中參與分片的總數，成功多少，失敗多少
7. "total": 42,//總分片數
8. "successful": 42,//成功數
9. "skipped": 0,//跳過數
10. "failed": 0//失敗數
11. },
12. "hits": {//hits指返回的結果集
13. "total": 6184,//總文檔數量
14. "max_score": 1,
15. "hits": [
16. {
17. "_index": ".kibana", //索引名稱
18. "_type": "config",//索引type
19. "_id": "5.6.3",//文檔在這個索引下的id
20. "_score": 1,//索引得分，是查詢后的計算得來的
21. "_source": {
22. "buildNum": 15554
23. }
24. },

xxxxxxxxxxxxxxxxxx

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 （0.12）elasticsearch分布式集群原理（ES7.9） es學習（二）：elasticsearch 數據存儲 Elasticsearch核心技術（四）：分布式存儲架構與索引原理分析 GlusterFS分布式存儲學習筆記 GlusterFS分布式存儲學習筆記 ES的分布式架構原理（ES如何實現分布式）分布式文檔存儲數據庫之MongoDB索引管理分布式文檔存儲數據庫之MongoDB副本集分布式文檔存儲數據庫之MongoDB分片集群分布式文檔存儲數據庫之MongoDB基礎入門

ElasticSearch 系列文章

分布式文檔存儲

ES分布式特性

ES集群特點

在更新一個文檔時的ES內部操作

ES如何處理沖突

文檔的部分更新

如何路由一個文檔到一個分片中

主分片和副分片如何交互

新建、索引和刪除單個文檔 時的流程

取回一個文檔

局部更新文檔

多文檔模式

搜索—–最基本的工具