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 , 即大多數的分片副本狀態沒問題就容許執行寫操做node
在執行一個寫操做時，主分片都須要必須有一個規定數量的（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. },