分散式文件儲存

ES分散式特性

• 遮蔽了分散式系統的複雜性
• 叢集內的原理
• • 垂直擴容和水平擴容
  • 真正的擴容能力是來自於水平擴容–為叢集新增更多的節點，並且將負載壓力和穩定性分散到這些節點中

ES叢集特點

• 一個叢集擁有相同的cluster.name 配置的節點組成， 它們共同承擔資料和負載的壓力
• 主節點負責管理叢集的變更例如增加、刪除索引，或者增加、刪除節點等。 而主節點並不需要涉及到文件級別的變更和搜尋等操作
• 叢集健康

1.GET /_cluster/health

返回值中的status 是我們關注的

• 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. },