【3.工程開發】-ES

咱們用ES做日誌檢索和簡單分析，它適用於全文搜索，近實時分析，也能夠做爲nosql存儲（訂單的冷庫接入ES），須要關注架構，單機的功能（搜索原理，動態索引），性能(索引和數據組織)，分佈式的可靠性，可擴展，一致性。

概述

搜索引擎和NoSQL數據庫功能，用於全文搜索，結構化搜索，近實時分析[競品：Solr 在傳統的搜索應用中表現好於 Elasticsearch，但在處理實時搜索應用時效率明顯低於 Elasticsearch
]
指南：https://es.xiaoleilu.com/020_...
經常使用：E（存儲和索引）L（數據轉換和解析Beat採集過來）K(可視化)
邏輯架構圖：

Local FileSystem等。存儲：索引信息，集羣內信息，mapping,transaction log
lucene directory lucene不一樣存儲層服務發現的抽象，FSDirectory,RAWDirectory 控制索引文件的位置
discovery Zen 服務發現+選主
river：數據源 mq等
memcached協議：get/set/delete/quit

高可用、可擴展、一致性

• 集羣發現與故障處理：
  服務發現+選主，ping,rsp包含節點基本信息和該節點認爲的master節點，支持非奇數，信息不對等時會有腦裂，要求ping全部節點。返回其餘節點認爲的主節點，也返回候選主節點（配置中master!=false）。若是第一個不爲空，直接選節點最小的，若爲空，候選節點>discovery.zen.minimum_master_nodes則選一個狀態+nodeid最小的，不然失敗。思想就是有舊的master活着儘可能用，投票都要達到法定人數。
  主節點是羣集中惟一能夠更改羣集狀態的節點。主節點一次處理一個羣集狀態更新，應用所需的更改並將更新的羣集狀態發佈到羣集中的全部其餘節點。每一個節點接收發布消息，ack，但不將改變同步到本地的集羣狀態。若是主服務器discovery.zen.minimum_master_nodes在必定時間內沒有從至少節點收到確認（由discovery.zen.commit_timeout設置控制並默認爲30秒），則拒絕集羣狀態更改，從新選主。
  無主時默認不能寫
• 一致性
  上述主節點有變動時，等待從節點的ack,收到大多數則變動，同步從節點，等待全部從節點的確認才返回客戶端。這裏全部從節點指的是Allocation IDs中的節點。從節點不可用時，主分片所在節點命令主節點將差別分片的Allocation IDs從同步集合（in-sync set）中刪除。而後，主分片所在節點等待主節點刪除成功的確認消息，這個確認消息意味着集羣一致層（consensus layer）已成功更新，以後，才向客戶端確認寫請求。這樣確保只有包含了全部已確認寫入的分片副本纔會被主節點選爲主分片。
  節點的從新加入：Translog+checkpoint
  每一個寫操做都會分配兩個值，Term和SequenceNumber.LocalCheckpoint表明本Shard中全部小於該值的請求都已經處理完畢。GlobalCheckpoint會由Primary進行維護，每一個Replica會向Primary彙報本身的LocalCheckpoint，Primary根據這些信息來提高GlobalCheckpoint。GlobalCheckpoint是一個全局的安全位置，表明其前面的請求都被全部Replica正確處理了，能夠應用在節點故障恢復後的數據回補。
• 分片機制：索引鍵值hash%分片數量。主分片+副本分片
  水平擴展（分片數量不能改變，只能改變每一個節點有幾個分片，每一個分片副本分散到哪些節點）
  單節點存儲瓶頸等時擴展：
  
  處理瓶頸時擴展：
  
  master和節點統一。master只負責索引的建立和刪除
• 負載均衡:輪詢

數據處理過程

節點對等寫入和讀取。寫入只能在P分片而後同步複製到R分片，讀寫轉發到主節點或副本節點

• 更新過程：
  

• 搜索：須要先查詢排序再取回排序中想要的數據
  
  其中查詢：
  1）node3建立from+size優先隊列
  2）請求轉發個每一個分片，每一個分片本身獲取from+size本地優先隊列
  3）返回給node3合併產生全局排序
  搜索有兩種：基於短語的、全文索引
  1）基於短語的：低級查詢，沒有分析，精確查找（加not_analyzed）
  2）match,query_string這種高級查詢，會產生短語列表和低級查詢結合，獲得文檔相關度。
  Elasticsearch經過下面的步驟執行match查詢：

  GET /my_index/my_type/_search
  {
      "query": {
          "match": {
              "title": "QUICK!"
          }
      }
  }
  
  1.檢查field類型,title字段是一個字符串(analyzed)，因此該查詢字符串也須要被分析(analyzed)
  2.分析查詢字符串,查詢詞QUICK!通過標準分析器的分析後變成單詞quick。由於咱們只有一個查詢詞，所以match查詢能夠以一種低級別term查詢的方式執行。
  3.找到匹配的文檔
  term查詢在倒排索引中搜索quick，而且返回包含該詞的文檔。
  4.爲每一個文檔打分
  term查詢綜合考慮詞頻（每篇文檔title字段包含quick的次數）、逆文檔頻率（在所有文檔中title字段包含quick的次數）、包含quick的字段長度（長度越短越相關）來計算每篇文檔的相關性得分_score。
  由於match查詢須要查詢兩個關鍵詞："brown"和"dog"，在內部會執行兩個term查詢並綜合兩者的結果獲得最終的結果。match的實現方式是將兩個term查詢放入一個bool查詢
  https://es.xiaoleilu.com/100_Full_Text_Search/05_Match_query.html

數據組織

關係數據庫       ⇒ 數據庫 ⇒     表    ⇒ 行    ⇒ 列(Columns)
Elasticsearch  ⇒ 索引(=》分片=》segment) ⇒ 類型  ⇒ 文檔   ⇒ 字段(Fields)

• 索引
  只是一個用來指向一個或多個分片(shards)的「邏輯命名空間(logical namespace)」.
• 分片
  就是一個Lucene實例，文檔存儲在分片中，而且在分片中被索引
  每一個分片上包含此分片的全部數據索引和數據，咱們的elk，天天都是一個新庫（index），爲其創建traceid，urlkey索引的含義只是建立索引，並不對全部詞都創建倒排索引，雖然自己es每一個詞均可搜索
• 詞=》倒排索引
  包含每一個filed（term）在每一個文檔中的值
  寫入磁盤的倒排索引是不可變的.不須要加鎖，不須要重建任何緩存，能夠壓縮數據

• 動態索引、近實時索引：
  

  Luence per-segment search 索引：段的集合+提交點（包含全部段的文件）

  1.當一個文檔被索引，它被加入到內存緩存，同時加到事務日誌。
  2.refresh使得分片的進入以下圖描述的狀態。每秒分片都進行refeash：
  內存緩衝區的文檔寫入到段中，但沒有fsync。
  段被打開，使得新的文檔能夠搜索。
  緩存被清除
  3.隨着更多的文檔加入到緩存區，寫入日誌，這個過程會繼續
  4.不時地，好比日誌很大了，新的日誌會建立，會進行一次全提交：
      內存緩存區的全部文檔會寫入到新段中。
      清除緩存
      一個提交點寫入硬盤
      文件系統緩存經過fsync操做flush到硬盤
      事務日誌被清除