一文帶你瞭解elasticsearch

時間  2019-12-23
標籤 一文 瞭解 elasticsearch 欄目 日誌分析 简体版
原文   原文鏈接

elasticsearch

es基本概念

es術語介紹

  • 文檔Document
    • 用戶存儲在es中的數據文檔
  • 索引Index
    • 由具備相同字段的文檔列表組成
  • 節點node
    • 一個Elasticsearch的運行實例，是集羣的構成單元
  • 集羣Cluster
    • 由一個或多個節點組成，對外提供服務

document介紹

  • json object，由字段(field)組成，常見數據類型以下:
    • 字符串：text，keyword
    • 數值型：long,integer,short,byte,double,float,half_float,scaled_float
    • 布爾：boolean
    • 日期：date
    • 二進制：binary
    • 範圍類型：integer_range,float_range,long_range,double_range,date_range
  • 每一個文檔有惟一的id標識
    • 自行指定
    • es自動生成
  • 元數據，用於標註文檔的相關信息
    • _index：文檔所在的索引名
    • _type：文檔所在的類型名
    • _id：文檔惟一id
    • _uid：組合id，由_type和_id組成(6.x _type再也不起做用，同_id同樣)
    • _source：文檔的原始json數據，能夠從這裏獲取每一個字段的內容
    • _all：整合全部字段內容到該字段，默認禁用

Index介紹

  • 索引中存儲具備相同結構的文檔（Document）
    • 每一個索引都有本身的mapping定義，用於定義字段名和類型
  • 一個集羣能夠有多個索引，好比：
    • nginx日誌存儲的時候能夠按照日期天天生成一個索引來存儲

rest api

  • elasticsearch集羣對外提供restful api
    • rest-representational state transfer
    • uri指定資源，如index、document等
    • http method指明資源操做類型，如GET、POST、PUT、DELETE等
  • 經常使用兩種交互方式
    • curl命令行
    • Kibana Devtools

索引API

  • es有專門的index api，用於建立、更新、刪除索引配置等
    • 建立索引api以下： 
      PUT /test_index

文檔api

  • es有專門的Document API
    • 建立文檔
    • 查詢文檔
    • 更新文檔
    • 刪除文檔
  • 建立文檔
    • 指定id建立文檔api以下： 
      PUT /test_index/doc/1
{
"username":"alfred",
"age":1
}

      建立文檔時，若是索引不存在，es會自動建立對應的index和typehtml

    • 不指定id建立文檔api以下： 
      POST /test_index/doc
{
"username":"tom",
"age":20
}
  • 查詢文檔
    • 指定要查詢的文檔id 
      GET /test_index/doc/1
    • 搜索全部文檔，用到_search，以下：
GET /test_index/doc/_search
{
    "query":{
      "term":{
        "_id":"1"
      }
    }
}

查詢語句，json格式，放在http body中發送到esjava

批量建立文檔api

  • es容許一次建立多個文檔，從而減小網絡傳輸開銷，提高寫入速率
    • endpoint爲_bulk，以下： 
      POST _bulk
{"index":{"_index":"test_index","_type":"doc","_id":"3"}}
{"username":"alfred","age":10}
{"delete":{"_index":"test_index","_type":"doc","_id":"1"}}

批量查詢文檔API

  • es容許一次查詢多個文檔
    • endpoint爲_mget，以下： 
      GET /_mget
{
"doc":[
{
"_index":"test_index",
"_type":"doc",
"_id":"1"
},
{
"_index":"test_index",
"_type":"doc",
"_id":"2"
}
]
}

索引

正排索引與倒排索引

  • 正排索引
    • 文檔id到文檔內容、單詞的關聯關係
文檔id 文檔內容
1 elasticsearch是最流行的搜索引擎
2 PHP是世界上最好的語言
3 搜索引擎是如何誕生的
  • 倒排索引
    • 單詞到文檔id的關聯關係
單詞 文檔ID列表
elasticsearch 1
流行 1
搜索引擎 1,3
世界 2

倒排索引-查詢流程

  • 查詢包含"搜索引擎"的文檔
    • 經過倒排索引得到"搜索引擎"對應的文檔ID有1和3
    • 經過正排索引查詢1和3的完整內容
    • 返回用戶最終結果

倒排索引詳解

  • 倒排索引是搜索引擎的核心，主要包含兩部分：
    • 單詞字典(Term Dictionary)
    • 倒排列表(Posting List)
  • es存儲的是一個json格式的文檔，其中包含多個字段，每一個字段會有本身的倒排索引

單詞詞典

  • 單詞字典(Term Dictionary)是倒排索引的重要組成部分
    • 記錄全部文檔的單詞，通常都比較大
    • 記錄單詞到倒排列表的關聯信息
  • 單詞字典的實現通常是用B+ Tree

倒排列表

  • 倒排列表記錄了單詞對應的文檔集合，由倒排索引項組成
  • 倒排索引項主要包含以下信息：
    • 文檔ID，用於獲取原始信息
    • 單詞頻率，記錄該單詞在該文檔中的出現次數，用於後續相關性算分
    • 位置，記錄單詞在該文檔中的分詞位置(多個)，用於作詞語搜索
    • 偏移，記錄單詞在文檔的開始和結束位置，用於作高亮顯示

分詞

  • 分詞是指將文本轉換成一系列單詞的過程，也叫做文本分析，在es裏面稱爲analysis

分詞器

  • 分詞器是es中專門處理分詞的組件，英文爲analy，它的組成以下：
    • Character Filters
      • 針對原始文本進行處理，好比去除HTML特殊標記符
    • Tokenizer
      • 將原始文本按照必定規則切分爲單詞
    • Token Filters
      • 針對tokenizer處理的單詞進行再加工，好比轉小寫、刪除或新增等處理

        Analyize API

    • es提供了一個測試分詞的api接口，方便驗證分詞效果，endpoint是_analyze
      • 能夠直接指定analyzer進行測試
      • 能夠直接指定索引中的字段進行測試
      • 能夠自定義分詞器進行測試
  • 直接指定analyzer進行測試，接口以下： 
    POST _analyze
{
"analyzer":"standard", #分詞器
"text":"hello,world"  #測試文本
}
  • 自定義分詞器進行測試，接口以下： 
    POST _analyze
{
"tokenizer":"standard",
"filterf":["lowercase"],  #自定義analyzer
"text":"hello world"
}

預約義的分詞器

  • es自帶以下的分詞器
    • Standard
    • Simple
    • Whitespace
    • Stop
    • Keyword
    • Pattern
    • Language
  • Standard Analyzer
    • 默認分詞器
    • 其組成以下，特性爲：
      • 按詞切分，支持多語言
      • 小寫處理
  • Simple Analyzer
    • 其組成以下，特性爲：
      • 按照非字母切分
      • 小寫處理
  • Whitespace Analyzer
    • 其組成以下，特性爲：
      • 按照空格切分
  • Stop Analyzer
    • Stop Word指語氣助詞等修飾性的詞語，好比the、an、的、這等等
    • 其組成如圖，特性爲：
      • 相比Simple Analyzer多了stop Word處理
  • Keyword Analyzer
    • 其組成以下，特性爲：
      • 不分詞，直接將輸入做爲一個單詞輸出
  • Pattern Analyze
    • 其組成以下，特性爲：
      • 經過正則表達式自定義分隔符
      • 默認是\W+，即非字詞的符號做爲分隔符
  • language Analyze
    • 提供了30+常見語言的分詞器
    • Arabic，Armenian，basque，bengali，Brazilian，Bulgarian，catAlan，cjk，Czech，Danish，Dutch，English...

中文分詞

  • 難點
    • 中文分詞指的是將一個漢字序列切分紅一個一個單獨的詞。在英文中，單詞之間是以空格做爲天然分界符，漢語中沒有一個形式上的分界符
    • 上下文不一樣，分詞結果迥異，好比交叉歧義問題，好比下面兩種分詞都合理
      • 乒乓球拍/賣/完了
      • 乒乓球/拍賣/完了
  • 經常使用分詞系統
  • 基於天然語言處理的分詞系統

自定義分詞

  • 當自帶的分詞沒法知足需求時，能夠自定義分詞
    • 經過自定義Character Filters、Tokenizer Filter實現
  • Character Filters
    • 在Tokenizer以前對原始文本進行處理，好比增長、刪除或替換字符等
    • 自帶的以下：
      • HTML Strip去除html標籤和轉換html實體
      • Mapping進行字符替換操做
      • Pattern Replace進行正則匹配替換
    • 會影響後續Tokenizer解析的position和offset信息
  • Character Filters測試時能夠採用以下api： 
    POST _analyze
{
"tokenizer":"keyword", #keyword類型的Tokenizer能夠直接看到輸出結果
"char_filter":["html_strip"], #指明要使用的char_filter
"text":"<p>I'm so
<b>happy</b>!</p>"
}
  • Tokenizer
    • 將原始文本按照必定規則且分爲單詞(term or token)
    • 自帶的以下：
      • standard按照單詞進行分割
      • letter按照非字符類進行分割
      • whitespace按照空格進行分割
      • UAX URL Email按照standard分割，但不會分割郵箱和url
      • NGram和Edge NGram連詞分割
      • Path Hierarchy按照文件路徑進行分割
    • Tokenizer測試時能夠採用以下api： 
      POST _analyze
{
"tokenizer":"path_hierarchy",
"text":"/one/two/three"
}
  • Token Filters
    • 對於Tokenizer輸出的單詞(term)進行增長、刪除、修改等操做
    • 自帶的以下：
      • lowercase將全部term轉換爲小寫
      • stop刪除stop words
      • NGram和Edge NGram連詞分割
      • Synonym添加近義詞的term
    • Filter測試時能夠採用以下api： 
      POST _analyze
{
"text":"a hello world",
"tokenizer":"standard",
"filter":[
"stop",
"lowercase",
{
"type":"ngram",
"min_gram":4,
"max_gram":4
}
]
}

自定義分詞的api

  • 自定義分詞的api
    • 自定義分詞須要在索引的配置中設定，以下所示： 
      PUT test_index
{
"settings":{
"analysis":{
"char_filter":{},
"tokenizer":{},
"filter":{},
"analyzer":{}
}
}
}

分詞使用說明

  • 分詞會在以下兩個時機使用：
    • 建立或更新文檔時(Index Time)，會對相應的文檔進行分詞處理
    • 查詢時(Search Time)，會對查詢語句進行分詞
  • 索引時分詞是經過配置Index Mapping中每一個字段的analyzer屬性實現的，以下：
    • 不指定分詞時，默認使用standard 
      PUT test_index
{
"mappings":{
"doc":{
"properties":{
"title":{
  "type":"text",
  "analyzer":"whitespace" #指定分詞器
}
}
}
}
}

  • 查詢時分詞的指定方式有以下幾種：node

    • 查詢時經過analyzer指定分詞器 
      POST test_index/_search
{
"query":{
"match":{
"message":{
"query":"hello",
"analyzer":"standard"
}
}
}
}
  • 經過index mapping設置search_analyzer實現 
PUT test_index
{
  "mappings":{
    "doc":{
      "properties":{
        "title":{
          "type":"text",
          "analyzer":"whitespace",
         "search_analyzer":"standard"
        }
      }
    }
  }
}
  • 通常不須要特別指定查詢時分詞器，直接使用索引時分詞器便可，不然會出現沒法匹配的狀況下

分詞使用建議

  • 明確字段是否須要分詞，不須要分詞的字段就將type設置爲keyword，能夠節省空間和提升寫性能
  • 善用_analyze API，查看文檔的具體分詞結果
  • 動手測試

Mapping

  • 相似數據庫中的表結構定義，主要做用以下：
    • 定義Index下的字段名(Field Name)
    • 定義字段的類型，好比數值型、字符串型、布爾型等
    • 定義倒排索引相關的配置，好比是否索引、記錄position等。

自定義mapping

  • 自定義mapping的api以下所示： 
    PUT my_index
{
"mappings":{
"doc":{
  "properties":{
    "title":{
      "type":"text"
    },
    "name":{
      "type":"keyword"
    },
    "age":{
      "type":"integer"
    }
  }
}
}
}
  • Mapping中的字段類型一旦設定後，禁止直接修改，緣由以下：
    • Lucene實現的倒排索引生成後不容許修改
  • 從新創建新的索引，而後作reindex操做
  • 容許新增字段
  • 經過dynamic參數來控制字段的新增
    • true(默認)容許自動新增字段
    • false不容許自動新增字段，可是文檔能夠正常寫入，但沒法對字段進行查詢等操做
    • strict文檔不能寫入，報錯

copy_to參數

  • copy_to
    • 將該字段的值複製到目標字段，實現相似_all的做用
    • 不會出如今_source中，只用來搜索 
      PUT my_index
{
"mappings":{
"doc":{
"properties":{
"first_name":{
  "type":""text",
  "copy_to":"full_name"
},
"last_name":{
  "type":"text",
  "copy_to":"full_name"
},
"full_name":{
  "type":"text"
}
}
}
}
}

index參數

  • index
    • 控制當前字段是否索引，默認爲true，即記錄索引，false不記錄，即不可搜索 
      PUT my_index
{
"mappings":{
"doc":{
"properties":{
"cookie":{
  "type":"text",
  "index":"false"
}
}
}
}
}

index_options參數

  • index_options用於控制倒排索引記錄的內容，有以下4中配置
    • docs只記錄doc id
    • freqs記錄doc id和term frequencies
    • positions記錄doc id、term frequencies和term position
    • offsets記錄doc id、term frequencies、term position和character offsets
  • text類型默認配置爲positions，其餘默認爲docs
  • 記錄內容越多，佔用空間越大
  • indexoptions設定以下所示： 
    PUT my_index
{
"mappings":{
"doc":{
  "properties":{
    "cookies":{
      "type":"text",
      "index_options":"offsets"
    }
  }
}
}
}
  • null_value
    • 當字段遇到null值時的處理策略，默認爲null，即空值，此時es會忽略該值。能夠經過設定該值設定字段的默認值 
      PUT my_index
{
"mappings":{
"my_type":{
"properties":{
"status_code":{
  "type":"keyword",
  "null_value":"NULL"
}
}
}
}
}

數據類型

  • 核心數據類型
    • 字符串：text，keyword
    • 數值型：long,integer,short,byte,double,float,half_float,scaled_float
    • 布爾：boolean
    • 日期：date
    • 二進制：binary
    • 範圍類型：integer_range,float_range,long_range,double_range,date_range
  • 複雜數據類型
    • 數組類型array
    • 對象類型object
    • 嵌套類型nested object
  • 地理位置數據類型
    • geo_point
    • geo_shape
  • 專用類型
    • 記錄ip地址ip
    • 實現自動補全completion
    • 記錄分詞數token_count
    • 記錄字符串hash值murmur3
    • percolator
    • join
  • 多字段特性
    • 容許對同一個字段採用不一樣的配置，好比分詞，常見例子如對人名實現拼音搜素，只須要在人名中新增一個子字段爲pinyin便可 
      {
"test_index":{
"mappings":{
"doc":{
"properties":{
  "username":{
    "type":"text",
    "fields":{
      "pinyin":{
        "type":"text",
        "analyzer":"pinyin"
      }
    }
  }
}
}
}
}
}

Dynamic Mapping

  • es能夠自動識別文檔字段類型，從而下降用戶使用成本
  • es是依靠json文檔的字段類型來實現自動識別字段類型，支持的類型以下：
JSON類型 es類型
null 忽略
Boolean Boolean
浮點類型 float
整數 long
object object
array 有第一個非null值的類型決定
string 匹配爲日期則設爲date類型(默認開啓)，匹配爲數字的話設爲float或long類型(默認關閉)，設爲text類型，並附帶keyword的子字段

dynamic日期與數字識別

  • 日期的自動識別能夠自行配置日期格式，以知足各類需求
    • 默認是["strict_date_optional_time","yyyy/MM/dd HH:mm:ss Z||yyyy /MM/dd Z"]
    • strict_date_optional_time是ISO datetime的格式，完整格式相似下面：
      • YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-20T15;30:50 +01:00)
    • dynamic_date_formats能夠自定義日期類型
    • date_detection能夠關閉日期自動識別的機制 
      PUT mu_index
{
"mappings":{
"my_type":{
"dynamic_date_formats":["MM/dd/yyyy"],
"date_detection":false
}
}
}
  • 字符串是數字時，默認不會自動識別爲整型，由於字符串中出現數字是徹底合理的
    • numeric_detection能夠開啓字符串中數字的自動識別，以下所示： 
      PUT my_index
{
"mappings":{
"my_type":{
"numeric_detection":true
}
}
}

Dynamic Templates

  • 容許根據es自動識別的數據類型、字段名等來動態設定字段類型，能夠實現以下效果：
    • 全部字符串類型都設定爲keyword類型，即默認不分詞
    • 全部以message開頭的字段都設定爲text類型，即分詞
    • 全部以long_開頭的字段都設定爲long類型
    • 全部自動分配爲double類型的都設定爲float類型，以節省空間
  • API以下所示： 
    PUT test_index
{
"mappings":{
"doc":{
  "dynamic_templates":[#數組，可指定多個匹配規則
    {
      "strings":{ #模板名稱
        "match_mapping_type":"string",#匹配規則
        "mapping":{
          "type":"keyword"
        }
      }
    }
  ]
}
}
}
    • 匹配規則通常有以下幾個參數：
      • match_mapping_type匹配es自動識別的字段類型，如Boolean，long，string等
      • match,unmatch匹配字段名
      • path_match,path_unmatch匹配路徑

自定義mapping的建議

  • 自定義Mapping的操做步驟以下：
    1. 寫入一條文檔到es的臨時索引中，獲取es自動生成的mapping
    2. 修改步驟1獲得的mapping，自定義相關配置
    3. 使用步驟2的mapping建立實際所需索引

首先建立一個文檔python

PUT my_index/doc/1
{
  "referrer": "-",
  "response":"200",
  "remote_ip":"171.22.12.14",
  "method":"POST",
  "user_name":"-",
  "http_version":"1.1",
  "body_sent":{
    "bytes":"0"
  },
  "url":"/analyzeVideo"
}

es會根據建立的文檔動態生成映射，能夠直接將動態生成的映射直接複製到須要自定義的mapping中nginx

PUT test_index
{
  "mappings": {
      "doc": {
        "properties": {
          "body_sent": {
            "properties": {
              "bytes": {
                "type": "long"

              }
            }
          },
          "http_version": {
            "type": "keyword"

          },
          "method": {
            "type": "keyword"
          },
          "referrer": {
            "type": "keyword"

          },
          "remote_ip": {
            "type": "keyword"

          },
          "response": {
            "type": "long"
          },
          "url": {
            "type": "text"
          },
          "user_name": {
            "type": "keyword"
          }
        }
      }
  }
}

這樣定義的映射仍是比較多餘，能夠利用動態模板將string類型直接替換成keywordgit

DELETE test_index
PUT test_index
{
  "mappings": {
      "doc": {
        "dynamic_templates":[
          {
            "strings":{
              "match_mapping_type":"string",
              "mapping":{
                "type":"keyword"
              }
            }
          }  
        ],
        "properties": {
          "body_sent": {
            "properties": {
              "bytes": {
                "type": "long"

              }
            }
          },
          "response": {
            "type": "long"
          },
          "url": {
            "type": "text"
          }
        }
      }
  }
}

索引模板

  • 索引模板，主要用於在新建索引時自動應用預先設定的配置，簡化索引建立的操做步驟
    • 能夠設定索引的配置和mapping
    • 能夠有多個模板，根據order設置，order搭的覆蓋小的配置

索引模板API以下所示：github

PUT _template/test_template
{
  "index_patterns":["te*","bar*"],
  "order":0,
  "settings":{
   "number_of_shards":1,
   "number_of_replicas":0
  },
  "mappings":{
    "doc":{
      "_source":{
        "enabled":false
      },
      "properties":{
        "name":{
          "type":"keyword"
        }
      }
    }
  }
}
  • "index_paterns":匹配的索引名稱
  • "order":匹配的優先級
  • "settings":索引的配置

search API

  • 查詢有兩種形式:
    • URI search
      • 操做簡單，方便經過命令行測試
      • 僅包含部分查詢語法
    • Request Body Search
      • es提供完備的查詢語法Query DSL

URI Search

  • 經過url query參數來實現搜索，經常使用參數以下：
    • q 指定查詢的語句，語法爲Query String Syntax
    • df q中不指定字段時默認查詢的字段，若是不指定es會查詢全部字段
    • sort 排序
    • timeout 指定超時時間，默認不超時
    • from,size用於分頁

URI Search - Query String Syntax

  • term與phrase
    • alfred way 等效於Alfred OR way
    • "alfred way" 詞語查詢，要求前後順序
  • 泛查詢
    • alfred 等效於在全部字段去匹配該term
  • 指定字段
    • name:alfred
  • Group分組設定，使用括號指定匹配的規則
    • （quick OR brown） AND fox
    • status:(active OR pending) title:(full text search)
  • 布爾操做符
    • AND(&&),OR(||),NOT(!)
      • name:(tom NOT lee)
      • 注意大寫，不能小寫
    • +—分別對應must和must_not
      • name:(tom +lee -alfred) #返回必定包含lee，能夠包含tom，必定不包含alfred的文檔
      • name:((lee && !alfred)) || (tom && lee && !alfred)
      • +在url中會被解析爲空格，要使用encode後的結果才能夠，爲%2B
  • 範圍查詢，支持數值和日期
    • 區間寫法，閉區間用[]，開區間用{}
      • age:[1 TO 10] 意爲1<=age<=10
      • age:[1 TO 10} 意爲1<=age<10
      • age:[1 TO] 意爲age>=1
      • age:[* TO 10] 意爲age<=10
    • 算數符號寫法
      • age:>=1
      • age:(>=1 && <=10) 或者age:(+>=1 +<=10)
  • 通配符查詢
    • ？表明1個字符，*表明0或多個字符
      • name:t?m
      • name:tom*
      • name:t*m
    • 通配符匹配執行效率低，且佔用較多內存，不建議使用
    • 如無特殊需求，不要將？/*放在最前面
  • 正則表達式匹配
    • name:/[mb]oat/
  • 模糊匹配fuzzy query
    • name:roam~1
    • 匹配與roam差一個character的詞，好比foam roams等
  • 近似度查詢 proximity search
    • "fox quick" ~5
    • 以term爲單位進行差別比較，好比"quick fox" "quick brown fox"都會被匹配

Query DSL

  • 基於json定義的查詢語句，主要包含以下兩種類型：
    • 字段類查詢：
      • 如term,match,range等，只針對某一個字段進行查詢
    • 複合查詢
      • 如bool查詢等，包含一個或多個字段類查詢或者複合查詢語句

Query DSL 字段類查詢

  • 字段類查詢主要包括如下兩類：
    • 全文匹配
      • 針對text 類型的字段進行全文檢索，會對查詢語言先進行分詞處理，如match，match_phrase等query類型
    • 單詞匹配
      • 不會對查詢語句作分詞處理，直接去匹配字段的倒排索引，如term.terms,range等query類型
Match Query
  • 對字段做全文檢索，最基本和經常使用的查詢類型，API示例以下： 
    GET test_index/_search
{
"query":{
"match":{   #關鍵詞
  "remote_ip":"171.22.12.14" #字段名
}
}
}

    響應結果以下：正則表達式

    {
"took": 4, #查詢總用時
"timed_out": false, #是否超時
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 1, #匹配文檔總數
"max_score": 0.2876821,
"hits": [  #返回文檔列表
  {
    "_index": "test_index_index",
    "_type": "doc",
    "_id": "1",
    "_score": 0.2876821,  #文檔相關度得分
    "_source": { #文檔原始內容
      "referrer": "-",
      "response": "200",
      "remote_ip": "171.22.12.14",
      "method": "POST",
      "user_name": "-",
      "http_version": "1.1",
      "body_sent": {
        "bytes": "0"
      },
      "url": "/analyzeVideo"
    }
  }
]
}
}
  • 經過operator參數能夠控制單詞間的匹配關係，可選項爲or和and
  • 經過minimum_should_match參數能夠控制須要匹配的單詞數
Match Query -流程

首先對查詢語句進行分詞，分詞後分別根據字段的倒排索引進行匹配算分，並會匹配到一個或多個文檔，再將匹配到的文檔進行彙總得分，根據得分排序返回多個文檔算法

Match Phrase Query
  • 對字段作檢索，有順序要求，API示例以下： 
    GET test_index_index/_search
{
"query":{
"match_phrase":{
  "remote_ip":"171.22.12.14"
}
}
}
  • 經過slop參數能夠控制單詞間的間隔
Query String Query

  • 相似於URI Search中的q參數查詢sql

    GET test_index_index/_search
{

"query":{
"query_string":{
  "default_field":"remote_ip",
  "query":"171.22.12.14"     
}
}
}
Simple Query String Query
  • 相似Query String,可是會忽略錯誤的查詢語法，而且僅支持部分查詢語法

  • 其經常使用的邏輯符號以下，不能使用AND、OR、NOT等關鍵詞：

    • +代指AND
    • |代指OR
    • -代指NOT
      經常使用API以下所示： 
      GET test_index_index/_search
{

    "query":{
    "simple_query_string":{
    "fields":["remote_ip"],
    "query":"alfred +way"
    }
    }
    }

     
    •  
 
 
 
Term Query
 
 
     
  
  •  
    將查詢語句做爲整個單詞進行查詢，即不對查詢語句作分詞處理，以下所示：
     
    GET test_index_index/_search
{

"query":{
"term":{
  "remote_ip":"171.22.12.14"
}
}
}
     
    •  
 
 
 
Range Query
 
 
     
  
  •  
    範圍查詢主要針對數值和日期類型，以下所示：
     
    GET test_index_index/_search
{

"query":{
"range":{
  "response":{#找出響應狀態碼大於10，小於300的文檔
    "gt": 10,
    "lte":300
  }
}
}
}
     
    針對日期的查詢以下所示：
     
    GET test_index_index/_search
{
"query":{
"range":{
  "birth":{
    "gt": "1990-01-01",
    "lte":"now-2h",
    "gt":"2019-01-01||+1M/d"
  }
}
}
}
     
    •  
 
 
 
相關性算分
 
 
     
  
  • 相關性算分是指文檔與查詢語句間的相關度，英文爲relevance 
   
       
    
    • 經過倒排索引能夠獲取與查詢語句相匹配的文檔列表，那麼如何將最符合用戶查詢需求的文檔放到前列呢？
      •  
    
    • 本質是一個排序問題，排序的依據是相關性算分
      •  
   
    •  
  
  •  
    相關性算分的幾個重要概念以下：
     
   
       
    
    • Term Frequency(TF)詞頻，即單詞在該文檔中出現的次數。詞頻越高，相關度越高
      •  
    
    • Document Frequency(DF)文檔頻率，即單詞出現的文檔數
      •  
    
    • Inverse document Frequency(IDF)逆向文檔頻率，與文檔頻率相反，簡單理解爲1/DF。即單詞出現的文檔數越少，相關度越高
      •  
    
    • Field-length Norm 文檔越短，相關性越高
      •  
   
     
    •  
  
  • ES目前主要有兩個相關性算分模型，以下： 
   
       
    
    • TF/IDF模型
      •  
    
    • BM25模型 5.x以後的默認模型
      •  
   
    •  
 
 
 
TF/IDF模型
 
 
     
  
  • 能夠經過explain參數來查看具體的計算方法，但要注意： 
   
       
    
    • es的算分是按照shard進行的，即shard的分數計算是相互獨立的，因此在使用explain的時候注意分片數
      •  
    
    • 能夠經過設置索引的分片數爲1來避免這個問題 
      GET test_index_index/_search
{
"explain": true, 
"query":{
"match":{
"remote_ip":"171.22.12.14"
}
}
}
      •  
   
    •  
 
 
 
BM25模型
 
 
     
  
  • BM25模型中BM指Best Match,25指迭代了25次才計算方法，是針對TF/IDF的一個優化。
    •  
  
  • BM25相比TF/IDF的一大優化是下降了tf在過大時的權重 
    •  
 
 
 
Query DSL 複合查詢
 
 
     
  
  • 複合查詢是指包含字段類查詢或符合查詢的類型，主要包括如下幾類： 
   
       
    
    • constant_score query
      •  
    
    • bool query
      •  
    
    • dis_max query
      •  
    
    • function_score query
      •  
    
    • boosting query 
      Constant Score Query
      •  
   
    •  
  
  • 該查詢將其內部的查詢結果文檔得分都設定爲1或者boost的值 
   
       
    
    • 多用於結合bool查詢實現自定義部分 
      GET test_index_index/_search
{
"query":{
"constant_score":{
"filter":{
"match": {
  "response":200
}
}
}
}
}
       
      響應以下：
       
      {
"took": 7,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 1,
"max_score": 1,
"hits": [
{
"_index": "test_index_index",
"_type": "doc",
"_id": "1",
"_score": 1,
"_source": {
  "referrer": "-",
  "response": "200",
  "remote_ip": "171.22.12.14",
  "method": "POST",
  "user_name": "-",
  "http_version": "1.1",
  "body_sent": {
    "bytes": "0"
  },
  "url": "/analyzeVideo"
}
}
]
}
}
      •  
   
    •  
 
 
 
Bool Query
 
 
     
  
  • 布爾查詢由一個或多個布爾子句組成，主要包含以下四個：
    •  
 
 
 
 
   
   
 
    子句 
    內容 
   
 
   
   
   
 
    filter 
    只過濾符合條件的文檔，不計算相關性得分 
   
 
   
 
    must 
    文檔必須符合must中的全部條件，會影響相關性得分 
   
 
   
 
    must_not 
    文檔必須不符合must_not中的全部條件 
   
 
   
 
    should 
    文檔能夠符合should中的條件，會影響相關性得分 
   
 
   
 
 
 
     
  
  • Bool查詢的API以下所示 
    GET test_index_index/_search
{
"query":{
"bool":{
  "filter":[
    {}
  ],
  "should":[
    {}  
  ],
  "must":[
    {}  
  ],
  "must_not": [
    {}
  ]
}
}
}
     
    查詢response爲200，ip爲"171.22.12.14"的值
     
    GET test_index_index/_search
{
"query":{
"bool":{
  "must":[
    {
      "match":{
        "response":200
      }
    },
    {  
      "match":{
        "remote_ip": "171.22.12.14"
      } 
    }  
  ]
}
}
}
    •  
 
 
 
查詢上下文與過濾器上下文
 
 
     
  
  • 當一個查詢語句位於Query或者Filter上下文時，es執行的結果會不一樣，對好比下：
    •  
 
 
 
 
   
   
 
    上下文類型 
    執行類型 
    使用方式 
   
 
   
   
   
 
    Query 
    查詢與查詢語句最匹配的文檔，對全部文檔進行相關性算分並排序 
    1.query 2. bool中的must和should 
   
 
   
 
    Filter 
    查找與查詢語句相匹配的文檔，只過濾不算分,常用過濾器，ES會自動的緩存過濾器的內容，這對於查詢來講，會提升不少性能 
    1.bool中的filter與must_not 2.constant_score中的filter 
   
 
   
 
 
 
GET /_search
{
  "query": { 
    "bool": { 
      "must": [
        { "match": { "title":   "Search"        }}, 
        { "match": { "content": "Elasticsearch" }}  
      ],
      "filter": [ 
        { "term":  { "status": "published" }}, 
        { "range": { "publish_date": { "gte": "2015-01-01" }}} 
      ]
    }
  }
}
 
 
Count API
 
 
     
  
  • 只返回符合條件的文檔數，endpoint爲_count，不返回文檔內容
    API示例以下： 
    GET test_index_index/_count
{
"query":{
"match":{
  "response":200   
} 
}
}
     
    響應以下：
     
    {
"count": 1,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
}
}
    •  
 
 
 
Source Filter
 
 
     
  
  • 過濾返回結果中_source中的字段，主要有以下幾種方式：
    不返回_source 
    GET test_index/_search
{
"_source":false
}
     
    返回部分字段
     
    GET test_index/_search
{
"_source":["response","name"]
}
GET test_index/_search
{
"_source":{
    "includes":"*i*",
    "excludes":"remote_ip"
}
}
    •  
 
 
 
es分佈式
 
 
分佈式特性
 
 
     
  
  • es支持集羣模式，是一個分佈式系統，其好處主要有兩個： 
   
       
    
    • 增大系統容量，如內存、磁盤，使得es集羣能夠支持PB級的數據
      •  
    
    • 提升系統可用性，即便部分節點中止服務，整個集羣依然能夠正常服務
      •  
   
    •  
  
  • es集羣由多個es實例組成 
   
       
    
    • 不一樣集羣經過集羣名字來區分，可經過cluster.name進行修改
      •  
    
    • 每一個es實例本質上是一個JVM進程，且有本身的名字，經過node.name進行修改
      •  
   
    •  
 
 
 
Master Node
 
 
     
  
  • 能夠修改cluster state的節點稱爲master節點，一個集羣只能有一個
    •  
  
  • cluster state存儲在每一個節點上，master維護最新版本並同步給其餘節點
    •  
  
  • master節點是經過集羣中全部節點選舉產生的，能夠被選舉的節點稱爲master-eligible節點，相關配置以下： 
   
       
    
    • node.master：true
      •  
   
    •  
 
 
 
Coordinating Node
 
 
     
  
  • 處理請求的節點即爲coordinating節點，該節點爲全部節點的默認角色，不能取消 
   
       
    
    • 路由請求到正確的節點處理，好比建立索引的請求到master節點
      •  
   
    •  
 
 
 
Data Node
 
 
     
  
  • 存儲數據的節點即爲data節點，默認節點都是data類型，相關配置以下： 
   
       
    
    • node.data:true
      •  
   
    •  
 
 
 
副本與分片
 
 
     
  
  • 如何將數據分佈於全部節點上？ 
   
       
    
    • 引入分片解決問題
      •  
   
    •  
  
  • 分片是es支持PB級數據的基石 
   
       
    
    • 分片存儲了部分數據，能夠分部於任意分片上
      •  
    
    • 分片數在索引建立時指定且後續不容許再更改，默認爲5個
      •  
    
    • 分片有主分片和副本分片之分，以實現數據的高可用
      •  
    
    • 副本分片的數據由主分片同步，能夠有多個，從而提升讀取的吞吐量
      •  
   
    •  
  
  • 分片數的設定很重要，須要提早規劃好 
   
       
    
    • 太小會致使後續沒法經過增長節點實現水平擴容
      •  
    
    • 過大會致使一個節點上分佈過多過多分片，形成資源浪費，同時會影響查詢性能
      •  
   
    •  
 
 
 
故障轉移
 
 
     
  
  • node1所在機器宕機致使服務終止，此時集羣會如何處理？ 
   
       
    
    1. node2和node3發現node1沒法響應一段時間後會發起master選舉，好比這裏選擇node2爲master節點。此時因爲主分片P0下線，集羣狀態變爲Red。
      2.  
    
    2. node2發現主分片P0未分配，將R0提高爲主分片。此時因爲全部主分片都正常分配，集羣狀態變爲yellow。
      3.  
    
    3. node2爲P0和P1生成新的副本，集羣狀態變爲綠色
      4.  
   
    •  
 
 
 
文檔分佈式存儲
 
 
     
  
  • document1是如何存儲到分片P1的？選擇P1的依據是什麼？ 
   
       
    
    • 須要文檔到分片的映射算法
      •  
   
    •  
  
  • 目的
    -使得文檔均與分佈在全部分片上，以充分利用資源
    •  
  
  • 算法 
   
       
    
    • shard=hash(routing)% number_of_primary_shards
      •  
    
    • hash算法保證能夠將數據均勻的分散在分片中
      •  
    
    • routing是一個關鍵參數，默認是文檔id，也能夠自行指定
      •  
    
    • number_of_primary_shards 是主分片
      •  
   
    •  
  
  • 該算法與主分片相關，這也是分片一旦肯定後便不能更改的緣由
    •  
 
 
 
文檔建立的流程
 
 
     
  
  1. client向node3發起建立文檔的請求
    2.  
  
  2. node3經過routing計算該文檔應該存儲在shard1上，查詢cluster state後確認主分片P1在node2上，而後轉發建立文檔的請求到node2
    3.  
  
  3. P1接收並執行建立文檔請求後，將一樣的請求發送到副本分片R1
    4.  
  
  4. R1接收並執行建立文檔請求後，通知P1成功的結果
    5.  
  
  5. P1接收副本分片結果後，通知node3建立成功
    6.  
  
  6. node3返回結果到client
    7.  
 
 
 
文檔讀取的流程
 
 
     
  
  1. client向node3發起獲取文檔1的請求
    2.  
  
  2. node3經過routing計算該文檔在shard1上，查詢cluster state後獲取shard1的主副分片列表，而後以輪詢的機制獲取一個shard，好比這裏是R1，而後轉發讀取文檔的請求到node1
    3.  
  
  3. R1接收並執行讀取文檔請求後，將結果返回node3
    4.  
  
  4. node3返回結果給client
    5.  
 
 
 
批量建立文檔的流程
 
 
     
  
  1. client向node3發起批量建立文檔的請求
    2.  
  
  2. node3經過routing計算全部文檔對應的shard，而後按照主shard分配對應執行的操做，同時發送請求到涉及的主shard，好比這裏3個主shard都須要參與
    3.  
  
  3. 主shard接收並執行請求後，將一樣的請求發送到對應的副本shard
    4.  
  
  4. 副本shard執行結果後返回結果到主shard，主shard再返回node3
    5.  
  
  5. node3整合結果返回client
    6.  
 
 
 
批量讀取文檔的流程
 
 
     
  
  1. client向node3發起批量獲取文檔的請求(mget)
    2.  
  
  2. node3經過routing計算全部文檔對應的shard，而後以輪詢的機制獲取要參與shard，按照shard構建mget請求，同時發送請求到涉及的shard，好比這裏有兩個shard須要參與
    3.  
  
  3. R一、R2返回文檔結果
    4.  
  
  4. node3返回結果給client
    5.  
 
 
 
搜索數據的流程
 
 
     
  
  1. 客戶端發送請求到一個coordinate node
    2.  
  
  2. 協調節點將搜索請求轉發到全部的shard對應的primary shard或replica shard也能夠
    3.  
  
  3. query phase：每一個shard將本身的搜索結果（其實就是一些doc id），返回給協調節點，由協調節點進行數據的合併、排序、分頁等操做，產出最終結果
    4.  
  
  4. fetch phase：接着由協調節點，根據doc id去各個節點上拉取實際的document數據，最終返回給客戶端
    5.  
 
 
 
腦裂問題
 
 
     
  
  • 腦裂問題，英文爲split-brain，是分佈式系統中的經典網絡問題 
   
       
    
    • 當node1故障時，node2與node3會從新選舉master，好比node2成爲了新的master，此時會更新cluster state
      •  
    
    • node1本身組成集羣后，也會更新cluster state
      •  
   
    •  
  
  • 同一個集羣有兩個master，並且維護不一樣的cluster state，網絡恢復後沒法選擇正確的master
    •  
  
  • 解決方案爲僅可在選舉master-eligible節點數大於等於quorum時才能夠進行master選舉 
   
       
    
    • quorum=master-eligible節點數/2+1，例如三個master-eligible節點時，quorum爲2
      •  
    
    • 設定discovery.zen.minimum_master_nodes爲quorum便可避免腦裂
      •  
   
    •  
 
 
 
shard詳解
 
 
倒排索引的不可變動
 
 
     
  
  • 倒排索引一旦生成，不能更改
    •  
  
  • 好處以下： 
   
       
    
    • 不用考慮併發寫文件的問題，杜絕了鎖機制帶來的性能問題
      •  
    
    • 因爲文件再也不更改，能夠充分利用文件系統緩存，只需載入一次，只要內存足夠，對該文件的讀取都會從內存讀取，性能高
      •  
    
    • 利於生成緩存數據
      •  
    
    • 利於對文件進行壓縮存儲，節省磁盤和內存存儲空間
      •  
   
    •  
  
  • 壞處爲須要寫入新文檔時，必須從新構建倒排索引文件，而後替換老文件後，新文檔才能被檢索，致使文檔實時性差
    •  
 
 
 
文檔搜索實時性
 
 
     
  
  • 解決方案是新文檔直接生成新的倒排索引文件，查詢的時候同時查詢全部的倒排文件，而後作結果的彙總便可
    •  
  
  • Lucene即是採用了這種方案，它構建的單個倒排索引稱爲segment，合在一塊兒稱爲index，與ES中的index概念不一樣。ES中的一個shard對應一個Lucene index
    •  
  
  • Lucene會有一個專門的文件來記錄全部的segment信息，稱爲commit point
    •  
 
 
 
文檔搜索實時性-refresh
 
 
     
  
  • segment寫入磁盤的過程依然很耗時，能夠藉助文件系統緩存的特性，先將segment在緩存中建立並開放查詢來進一步提高實時性，該過程在es中被稱爲refresh
    •  
  
  • 在refresh以前文檔會先存儲在一個buffer中，refresh時將buffer中的全部文檔清空並生成segment
    •  
  
  • es默認每一秒執行一次refresh，所以文檔的實時性被提升到1秒，這也是es被稱爲近實時的緣由
    •  
  
  • refresh發生的時機主要有以下幾種狀況： 
   
       
    
    • 間隔時間達到時，經過index.settings.refresh_interval來設定，默認是一秒
      •  
    
    • index.buffer佔滿時，其大小經過indices.memory.index_buffer_size設置，默認爲jvm heap的10%，全部shard共享
      •  
    
    • flush發生時也會發生refresh
      •  
   
    •  
 
 
 
文檔搜索實時性-translog
 
 
     
  
  • 若是在內存中的segment尚未寫入磁盤前發生了宕機，name其中的文檔就沒法恢復了。 
   
       
    
    • es引入translog機制。寫入文檔到buffer時，同時將該操做寫入translog
      •  
    
    • translog文件會即時寫入磁盤(fsync)，6.x默認每一個請求都會落盤，能夠修改成每五秒寫一次，這樣風險即是丟失5秒內的數據，相關配置爲index.translog.*
      •  
    
    • es啓動時會檢查translog文件，並從中恢復數據
      •  
   
    •  
 
 
 
文檔搜索實時性-flush
 
 
     
  
  • flush負責將內存中的segment寫入磁盤，主要作以下的工做： 
   
       
    
    • 將translog寫入磁盤，造成translog文件
      •  
    
    • 將index buffer清空，其中的文檔生成一個新的segment，至關於一個refresh操做
      •  
    
    • 更新commit point並寫入磁盤
      •  
    
    • 執行fsync操做，將內存中的segment寫入磁盤
      •  
    
    • 刪除舊的translog文件
      •  
   
    •  
  
  • flush發生的時機主要有以下幾種狀況： 
   
       
    
    • 間隔時間達到時，默認是30分鐘，5.x以前能夠經過index.translog.flush_threshold_period修改，以後沒法修改
      •  
    
    • translog佔滿時，其大小能夠經過index.translog.flush_threshold_size控制，默認是512mb，每一個index有本身的translog
      •  
   
    •  
 
 
 
文檔搜索實時性- 刪除與更新文檔
 
 
     
  
  • segment一旦生成就不能更改，那麼若是你要刪除文檔該如何操做？ 
   
       
    
    • Lucene專門維護一個.del的文件，記錄全部已經刪除的文檔，注意.del上記錄的是文檔在Lucene內部的id
      •  
    
    • 在查詢結果返回前會過濾掉.del中的全部文檔
      •  
   
    •  
  
  • 更新文檔如何進行 
   
       
    
    • 首先刪除文檔，而後再建立新文檔
      •  
   
    •  
 
 
 
Segment Merging
 
 
     
  
  • 隨着segment的增多，因爲一次查詢的segment數增多，查詢速度會變慢
    •  
  
  • es會定時在後臺進行segment merge的操做，減小segment的數量
    •  
  
  • 經過force_merge api能夠手動強制作segment merge的操做
    •  
 
 
 
search 運行機制
 
 
     
  
  • search 執行的時候實際分兩個步驟運做的 
   
       
    
    • Query階段
      •  
    
    • fetch階段
      •  
   
    •  
  
  • Query-Then-Fetch
    •  
 
 
 
Query階段
 
 
     
  
  • node3在接收到用戶的search請求後，會先進行Query階段
    •  
  
  • node3在6個主副分片中隨機選擇三個分片，發送search request
    •  
  
  • 被選中的3個分片會分別進行查詢並排序，返回from+size個文檔Id和排序值
    •  
  
  • node3整合3個分片返回的from+size個文檔Id，根據排序值排序後選取from到from+size的文檔Id
    •  
 
 
 
Fetch階段
 
 
     
  
  • node3根據Query階段獲取的文檔Id列表去對應的shard上獲取文檔詳情數據 
   
       
    
    1. node3向相關的分片發送multi_get請求
      2.  
    
    2. 3個分片返回文檔詳細數據
      3.  
    
    3. node3拼接返回的結果並返回客戶端
      4.  
   
    •  
 
 
 
相關性算分
 
 
     
  
  • 相關性算分在shard與shard之間是相互獨立的，也就意味着同一個Term的IDF等值在不一樣shard上是不一樣的。文檔的相關性算分和他所處的shard相關
    •  
  
  • 在文檔數量很少時，會致使相關性算分嚴重不許的狀況發生
    •  
  
  • 解決思路： 
   
       
    
    • 一是設置分片數爲1個，從根本上排除問題，在文檔數量很少的時候能夠考慮該方案，好比百萬到千萬級別的文檔數量
      •  
    
    • 二是使用DFS Query-then-Fetch查詢方式
      •  
   
    •  
  
  • DFS Query-then-fetch是在拿到全部文檔後再從新完整的計算一次相關性算分，耗費更多的CPU和內存，執行性能也比較低下，通常不建議使用。使用方式以下： 
    GET test_index/_search?search_type=dfs_query_then_fetch
    •  
 
 
 
排序
 
 
     
  
  • es默認會採用相關性算分排序，用戶能夠經過設定sorting參數來自行設定排序規則 
    GET test_search_index/_search
{
"sort":[ #關鍵字
  {
    "birth":"desc"
  },
  {
    "_score":"desc"
  },
  {
    "_doc":"desc"
  }
]
}
     
   
       
    
    • 按照字符串排序比較特殊，由於es有text和keyword兩種類型，針對text類型排序，以下所示： 
      GET test_search_index/_search
{
"sort":{
"username":"desc"
}   
}
#會產生報錯
      •  
   
    •  
  
  • 針對keyword類型排序，能夠返回預期結果 
    GET test_search_index/_search
{
"sort":{
  "username.keyword":"desc"
}
}
    •  
  
  • 排序的過程實質是對字段原始內容排序的過程，這個過程當中倒排索引沒法發揮做用（term->document），須要用到正排索引，也就是經過文檔id和字段能夠快速獲得字段原始內容。
    •  
  
  • es對此提供了兩種實現方式： 
   
       
    
    • fielddata默認禁用
      •  
    
    • doc values默認啓用，除了text類型
      •  
   
    •  
 
 
 
 
   
   
 
    文檔ID 
    字段值 
   
 
   
   
   
 
    1 
    100 
   
 
   
 
    2 
    89 
   
 
   
 
    3 
    129 
   
 
   
 
 
 
fielddata vs DocValues
 
 
 
   
   
 
    對比 
    fielddata 
    DocValues 
   
 
   
   
   
 
    建立時機 
    搜索時即時建立 
    索引時建立，與倒排索引建立時機一致 
   
 
   
 
    建立位置 
    JVM Heap 
    磁盤 
   
 
   
 
    優勢 
    不會佔用額外的磁盤空間 
    不會佔用Heap內存 
   
 
   
 
    缺點 
    文檔過多時，即時建立會花過多時間，佔用過多Heap內存 
    減慢索引的速度，佔用額外的磁盤資源 
   
 
   
 
 
 
Fielddata
 
 
     
  
  • Fielddata默認是關閉的，能夠經過以下api開啓： 
   
       
    
    • 此時字符串是按照分詞後的term排序，每每結果很難符合預期
      •  
    
    • 通常是在對分詞作聚合分析的時候開啓 
      PUT test_search_index/_mapping/doc
{
"properties":{
"username":{
"type":"text",
"fileddata":"true"
} 
}
}
      •  
   
    •  
 
 
 
Doc Values
 
 
     
  
  • Doc Values默認是啓用的，能夠在建立索引的時候關閉： 
   
       
    
    • 若是後面要再開啓doc values,須要作reindex操做 
      PUT test_doc_value/
{
"mappings":{
"doc":{
"properties":
}
}
}
      •  
   
    •  
 
 
 
docvalue_fields
 
 
     
  
  • 能夠經過該字段獲取fielddata或者doc values中存儲的內容 
    GET test_search_index/_search
{
"docvalue_fields":[
  "username",
  "username.keyword",
  "age"
]
}
    •  
 
 
 
分頁與遍歷
 
 
From/Size
 
 
     
  
  • 最經常使用的分頁方案 
   
       
    
    • from指明開始位置
      •  
    
    • size指明獲取總數
      •  
   
    •  
  
  • 深度分頁是一個經典問題：在數據分片存儲的狀況下如何獲取前1000個文檔? 
   
       
    
    • 獲取從990-1000的文檔時，會在每一個分片上都先獲取1000個文檔，而後再由coordinating node局和全部分片的結果後再排序選取前1000個文檔
      •  
    
    • 頁數越深，處理文檔越多，佔用內存越多，耗時越長。儘可能避免深度分頁，es經過index.max_result_window限定最多到10000條數據 
      total_page=(total+page_size-1)/page_size
total爲文檔總數
      •  
   
    •  
 
 
 
Scroll
 
 
     
  
  • 遍歷文檔集的api,以快照的方式來避免深度分頁的問題 
   
       
    
    • 不能用來作實時搜索，由於數據不是實時的，是以快照的方式作的
      •  
    
    • 儘可能不要使用複雜的sort條件，使用_doc最高效
      •  
    
    • 使用稍嫌複雜
      •  
   
    •  
  
  • 第一步須要發起1個scroll search，以下所示： 
   
       
    
    • es在收到該請求後會根據查詢條件建立文檔id合計的快照 
      GET test_search_index/_search?scrol=5m  #該scroll快照有效時間
{
"size":1  #指明每次scroll返回的文檔數
}
      •  
   
    •  
  
  • 第二步調用scroll search的api，獲取文檔集合，以下所示： 
   
       
    
    • 不斷迭代調用直到返回hits.hits數組爲空時中止 
      post _search/scroll
{
"scroll":"5m", #指明有效時間
"scroll_id":"..."  #上一步返回的id
}
      •  
   
    •  
  
  • 過多的scroll調用會佔用大量內存，能夠經過clear api刪除過多的scroll快照： 
    DELETE /_search/scroll
{
"scroll_id":[
  "DXFZAD....",
  "DESGRHRH..."
]
}
DELETE /_search/scroll/_all
    •  
 
 
 
search_after
 
 
     
  
  • 避免深度分頁的性能問題，提供實時的下一頁文檔獲取功能 
   
       
    
    • 缺點是不能使用from參數，即不能指定頁數
      •  
    
    • 只能下一頁，不能上一頁
      •  
    
    • 使用簡單
      •  
   
    •  
  
  • 第一步爲正常的搜索，但要指定sort值，並保證值惟一
    •  
  
  • 第二步爲使用上一步最後一個文檔的sort值進行查詢 
    GET test_search_index/_search
{
"size":1,
"sort":{
  "age":"desc",
  "_id":"desc"
}
}
GET test_search_index/_search
{
"size":1,
"search_after":[28,"2"],
"sort":{
  "age":"desc",
  "_id":"desc"
}
}
    •  
  
  • search_after如何避免深度分頁問題 
   
       
    
    • 經過惟一排序值定位將每次要處理的文檔數都控制在size內 
      •  
   
    •  
 
 
 
應用場景
 
 
 
   
   
 
    類型 
    場景 
   
 
   
   
   
 
    from/size 
    須要實時獲取頂部的部分文檔，且須要自由翻頁 
   
 
   
 
    scroll 
    須要所有文檔，如導出全部數據的功能 
   
 
   
 
    search_after 
    須要所有文檔，不須要自由翻頁 
   
 
   
 
 
 
聚合分析
 
 
     
  
  • 聚合分析，英文爲aggregation，是es除搜索功能外提供的針對es數據作統計分析的功能 
   
       
    
    • 功能豐富，提供bucket、metric。pipeline等多種分析方式，能夠知足大部分的分析需求
      •  
    
    • 實時性高，全部的計算都是即時返回的，而Hadoop等大數據系統通常都是T+1級別的(today+1,次日)
      •  
   
    •  
  
  • 聚合分析做爲search的一部分，api以下所示： 
    GET test_search_index/_search
{
"size":0,
"aggs":{ #關鍵詞，與query同級
  "<aggregation_name>":{#定義聚合名稱
    "<aggregation_type>":{#定義聚合類型
      <aggregation_body>
    },
    [,"aggs":{[<sub_aggregation>]+}]? #子查詢
  }
  [,"<aggregation_name_2>":{...}]*  #能夠包含多個聚合分析
}
}
    •  
 
 
 
聚合分析分類
 
 
     
  
  • 爲了便於理解，es將聚合分析主要分爲以下四類 
   
       
    
    • Bucket,分桶類型，相似sql中的group by語法
      •  
    
    • Metric,指標分析模型，如計算最大值、最小值、平均值等等
      •  
    
    • pipline，管道分析類型，基於上一級的聚合分析結果進行再分析
      •  
    
    • Matrix，矩陣分析類型 
      •  
   
    •  
 
 
 
Metric聚合分析
 
 
     
  
  • 主要分以下兩類： 
   
       
    
    • 單值分析，只輸出過一個分析結果 
     
         
      
      • min,max,avg,sum
        •  
      
      • cardinality
        •  
     
      •  
    
    • 多值分析，輸出多個分析結果 
     
         
      
      • stats,extended stats
        •  
      
      • percentile,percentile rank
        •  
      
      • top hits
        •  
     
      •  
   
    •  
  
  • 返回數值類字段的最小值 
    GET test_search_index/_search
{
"size":0,   #不須要返回文檔列表
"aggs":{
  "min_age":{
    "min":{  #關鍵詞
      "field":"age"
    }
  }
}
}
    •  
  
  • 返回數值類字段的最大值 
    GET test_search_index/_search
{
"size":0,
"aggs":{
  "max_age":{
    "max":{
      "field":"age"
    }
  }
}
}
    •  
  
  • cardinality，意爲集合的勢，或者基數，是指不一樣數值的個數，相似sql中的distinct count概念 
    GET test_search_index/_search
{
"size":0,
"aggs":{
  "count_of_job":{
    "cardinality":{ #關鍵詞
      "field":"job.keyword"
    }
  }
}
}
    •  
  
  • 返回一系列數值類型的統計值，包含min、max、avg、sum和count 
    GET test_search_index/_search
{
"size":0,
"aggs":{
  "stats_age":{
    "stats":{
        "field":"age"
    }
  }
}
}
    •  
  
  • 對stats的擴展，包含了更多的統計數據，如方差、標準差等 
    GET test_search_index/_search
{
"size":0,
"aggs":{
  "stats_age":{
    "extended_status":{
      "field":"age"
    }
  }
}
}
    •  
  
  • 百分位數統計percentile 
    GET  test_search_index/_search
{
"size":0,
"aggs":{
  "per_age":{
    "percentiles":{ #關鍵詞
      "field":"salary"
    }
  }
}
}
    •  
  
  • top hits通常用於分桶後獲取該桶內最匹配的頂部文檔列表，即詳情數據 
    GET test_search_index/_search
{
"size":0,
"aggs":{
  "jobs":{
    "terms":{
      "field":"job.keyword",
      "size":10
    },
    "aggs":{
      "top_employee":{
        "top_hits":{
          "size":10,
          "sort":[
            {
              "age":{
                "order":"desc"
              }
            }
          ]
        }
      }
    }
  }
}
}
    •  
 
 
 
bucket聚合分析
 
 
     
  
  • Bucket，意爲桶，即按照必定的規則將文檔分配到不一樣的桶中，達到分類分析的目的
    •  
  
  • 按照Bucket的分桶策略，常見的Bucket聚合分析以下： 
   
       
    
    • Terms
      •  
    
    • Range
      •  
    
    • Date Range
      •  
    
    • Histogram
      •  
    
    • Date Histogram 
      •  
   
    •  
 
 
 
Terms
 
 
     
  
  • 該分桶策略最簡單，直接按照term來分桶，若是是text類型，則按照分詞後的結果分桶 
    GET test_search_index/_search
{
"size":0,
"aggs":{
  "jobs":{
    "terms":{  #關鍵詞
      "field":"job.keyword",#指明term字段
      "size":5  #指定返回數目
    }
  }
}
}
    •  
 
 
 
Range
 
 
     
  
  • 經過指定數值的範圍來設定分桶規則 
    GET test_search_index/_search
{
"size":0,
"aggs":{
  "salary_range":{
    "range":{ #關鍵詞
      "field":"salary",\
      "ranges":[ #指定每一個range的範圍
        {
          "to":1000
        },
        {
          "from":1000,
          "to":2000
        }       
      ]
    }
  }
}
}
    •  
 
 
 
Date Range
 
 
     
  
  • 經過指定日期的範圍來設定分桶規則
    •  
 
 
 
GET test_search_index/_search
{
  "size":0,
  "aggs":{
    "date_range":{
      "range":{ #關鍵詞
        "field":"birth",
        "format":"yyyy",#指定返回結果的日期格式
        "ranges":[
          {
            "from":"1980",#指定日期，可使用date math 
            "to":"1990"
          },
          {
            "from":"1990",
            "to":"2000"
          }
        ]
      }
    }
  }

}
 
 
historgram
 
 
     
  
  • 直方圖，以固定間隔的策略來分隔數據
    •  
 
 
 
GET test_search_index/_search
{
    "size":0,
    "aggs":{
      "salary_hist":{
        "histogram":{ #關鍵詞
          "field":"salary",
          "interval":5000, #指定間隔大小
          "extended_bounds":{ #指定數據範圍
            "min":0,
            "max":40000
          }
        }
      }
    }
}
 
 
Date Historgram
 
 
     
  
  • 針對日期的直方圖或者柱形圖，是時序分析中經常使用的聚合分析類型 
    Get test_search_index/_search
{
"size":0,
"aggs":{
"by_year":{
  "date_historgram":{ #關鍵詞
    "field":"birth",
    "interval":"year", #指定間隔大小
    "format":"yyyy" #指定日期格式化
  }
}
}
}
    •  
 
 
 
bucket和metric聚合分析
 
 
bucket+metric聚合分析
 
 
     
  
  • bucket聚合分析容許經過添加子分析來進一步進行分析，該子分析能夠是bucket也能夠是metric。這也使得es的聚合分析能力變得異常強大
    •  
  
  • 分桶後再分桶 
    GET test_search_index/_search
{
"size":0,
"aggs":{
  "jobs":{
    "terms":{
      "field":"job.keyword",
      "size":10
    },
    "aggs"
  }
}
}
    •  
  
  • 分桶後進行數據分析 
    GET test_search_index/_search
{
"size":0,
"aggs":{
"jobs":{ #第一層聚合
  "terms":{
    "field":"job.keyword",
    "size":10
  },
  "aggs":{
    "salary":{ #第二層聚合
      "stats":{
        "field":"salary"
      }
    }
  }
}
}
}
    •  
 
 
 
pipeline聚合分析
 
 
     
  
  • 針對聚合分析的結果再次進行聚合分析，並且支持鏈式調用，能夠回答以下問題： 
   
       
    
    • 訂單月平均銷售額是多少? 
      POST order/_search
{
"size":0,
"aggs":{
"sales_per_month":{
"date_histogram":{
"field":"date",
"interval":"month"
},
"aggs":{
"sales":{
  "sum":{
    "field":"price"
  }
}
}
},
"avg_monthly_sales":{
"avg_bucket":{
"bucket_path":"sales_per_month>sales"
}
}
}
}
      •  
   
    •  
  
  • Pipeline的分析結果會輸出到原結果中，根據輸出位置的不一樣，分爲如下兩類: 
   
       
    
    • Parent 結果內嵌到現有的聚合分析結果中 
     
         
      
      • Derivative
        •  
      
      • Moving Average
        •  
      
      • Cumulative Sum
        •  
     
      •  
    
    • Sibling 結果與現有聚合分析結果同級 
     
         
      
      • Max/Min/Avg/Sum Bucket
        •  
      
      • Stats/Extended Stats Bucket
        •  
      
      • Percentiles Bucket
        •  
     
      •  
   
    •  
 
 
 
Pipeline 聚合分析Sibling-Min Bucket
 
 
     
  
  • 找出全部Bucket中值最小的的Bucket名稱和值 
    GET test_search_index/_search
{
"size":0,
"aggs":{
"jobs":{
  "terms":{
    "field":"job.keyword",
    "size":10
  },
  "aggs":{
    "avg_salary":{
      "avg":{
        "field":"salary"
      }
    }
  }
},
"min_salary_by_job":{
  "min_bucket":{ #關鍵詞 
    "buckets_path":"jobs>avg_salary"
  }
}
}
}
    •  
 
 
 
Pipeline聚合分析 Sibling-Max Bucket
 
 
     
  
  • 找出全部Bucket中值最大的Bucket名稱和值 
    GET test_search_index/_search
{
"size":0,
"aggs":{
"jobs":{
  "terms":{
    "field":"job.keyword",
    "size":10
  },
  "aggs":{
    "avg_salary":{
      "avg":{
        "field":"salary"
      }
    }
  }
},
"max_salary_by_job":{
  "max_bucket":{
    "buckets_path":"jobs>avg_salary"
  }
}
}
}
    •  
 
 
 
Pipeline 聚合分析Parent-Derivative
 
 
     
  
  • 計算Bucket值的導數 
    GET test_search_index/_search
{
"size":0,
"aggs":{
"birth":{
  "date_histogram":{
    "field":"birth",
    "interval":"year",
    "min_doc_count":0
  },
  "aggs":{
    "avg_salary":{
      "avg":{
        "field":"salary"
      }
    },
    "derivative_avg_salary":{
      "derivative":{ #關鍵詞
        "bucket_path":"avg_salary"
      }
    }
  }
}
}
}
    •  
 
 
 
Pipeline 聚合分析Parent-Moving Average
 
 
     
  
  • 計算Bucket值的移動平均值 
    GET test_search_index/_search
{
"size":,
"aggs":{
"birth":{
  "date_histogram":{
    "field":"birth",
    "interval":"year",
    "min_doc_count":0
  },
  "aggs":{
    "avg_salary":{
      "avg":{
        "field":"salary"
      }
    },
    "mavg_salary":{
      "moving_avg":{ #關鍵詞
        "buckets_path":"avg_salary"
      }
    }
  }
}
}
}
    •  
 
 
 
做用範圍
 
 
     
  
  • es聚合分析默認做用範圍是query的結果集，能夠經過以下的方式改變其做用範圍: 
   
       
    
    • filter
      •  
    
    • post_filter
      •  
    
    • global 
      GET test_search_index/_search
{
"size":0,
"query":{
"match":{#aggs做用域該query的結果集
"username":"alfred"
}
},
"aggs":{
"jobs":{
"terms":{
"field":"job.keyword",
"size":10
}
}
}
}
      •  
   
    •  
 
 
 
做用範圍-filter
 
 
     
  
  • 爲某個聚合分析設定過濾條件，從而在不更改總體語句的狀況下修改了做用範圍 
    GET test_search_index/_search
{
"size":0,
"aggs":{
"jobs_salary_small":{
  "filter":{
    "range":{
      "salary":{
        "to":10000
      }
    }
  },
  "aggs":{
    "jobs":{
      "terms":{
        "field":"job.keyword"
      }
    }
  }
},
"jobs":{
  "terms":{
    "field":"job.keyword"
  }
}
}
}
    •  
 
 
 
做用範圍 - post-filter
 
 
     
  
  • 做用於文檔過濾但在聚合分析後生效 
    GET test_search_index/_search
{
"aggs":{
"jobs":{
  "terms":{
    "field":"job.keyword"
  }
}
},
"post_filter":{#過濾條件
"match":{
  "job.keyword":"java engineer"
}
}
}
    •  
 
 
 
做用範圍-global
 
 
     
  
  • 無視query過濾條件，基於所有文檔進行分析 
    GET test_search_index/_search
{
"query":{
"match":{
  "job.keyword":"java engineer"
}
},
"aggs":{
"java_avg_salary":{
  "avg":{
    "field":"salary"
  }
},
"all":{
  "global":{},
  "aggs":{
    "avg_salary":{#過濾條件
      "avg":{
        "field":"salary"
      }
    }
  }
}
}
}
    •  
 
 
 
排序
 
 
     
  
  • 可使用自帶的關鍵數據進行排序，好比： 
   
       
    
    • _count文檔數
      •  
    
    • _key按照key值排序 
      GET test_search_index/_search
{
"size":0,
"aggs":{
"jobs":{
"terms":{
"field":"job.keyword",
"size":10,
"order":[
  {
    "count":"asc"
  },
  {
    "_key":"desc"
  }
]
}
}
}
}
      •  
   
    •  
 
 
 
數據精準度問題
 
 
terms不許確的緣由
 
 
     
  
  • 數據分散在多shard上，coordinating node沒法得悉數據全貌
    •  
 
 
 
terms不許確的解決方法
 
 
     
  
  • 設置shard數爲1，消除數據分散的問題，但沒法承載大數據量
    •  
  
  • 合理設置shard_size的大小，即每次從shard上額外多獲取數據，以提高準確度 
    GET test_search_index/_search
{
"size":0,
"aggs":{
"jobs":{
  "terms":{
    "field":"job.keyword",
    "size":1,
    "shard_size":10
  }
}
}
}
    •  
 
 
 
shard_size大小的設定方法
 
 
     
  
  • terms聚合返回結果中有以下兩個統計值： 
   
       
    
    • doc_count_error_upper_bound被遺漏的term可能的最大值
      •  
    
    • sum_other_doc_count返回結果bucket的term外其餘term的文檔總數 
      •  
   
    •  
  
  • 設定show_term_doc_count_error能夠查看每一個bucket誤算的最大值 
    GET test_search_index/_search
{
"size":0,
"aggs":{
"jobs":{
  "terms":{
    "field":"job.keyword",
    "size":2,
    "show_term_doc_count_error":true
  }
}
}
}
    •  
  
  • shard_size默認大小以下： 
   
       
    
    • shard_size=(sizex1.5)+10
      •  
   
    •  
  
  • 經過調整shard_size的大小下降doc_count_error_upper_bound來提高準確度 
   
       
    
    • 增大了總體的計算量，從而下降了響應時間
      •  
   
    •  
 
 
 
近似統計算法
 
 
     
  
  • 追求海量數據的準確度，用做離線計算，失去了實時性
    •  
  
  • 追求海量數據的實時性，用做近似統計算法，失去了數據的準確度
    •  
  
  • 追求數據的準確度和實時性，只是做爲有限的數據計算，分析的數據只是片面的
    •  
  
  • 在es的聚合分析中，cardinality和percentile分析使用的是近似統計算法 
   
       
    
    • 結果是近似準確的，但不必定精準
      •  
    
    • 能夠經過參數的調整使其結果精準，但同時也意味着更多的計算時間和更大的性能消耗 
      •  
   
    •  
 
 
 
數據建模
 
 
     
  
  • 英文爲data modeling，爲建立數據模型的過程
    •  
  
  • 數據模型(Data Model) 
   
       
    
    • 對現實世界進行抽象描述的一種工具和方法
      •  
    
    • 經過抽象的實體及實體之間聯繫的形式去描述業務規則，從而實現對現實世界的映射
      •  
   
    •  
 
 
 
數據建模的過程
 
 
     
  
  • 概念模型 
   
       
    
    • 肯定系統的核心需求和範圍邊界，設計實體和實體間的關係
      •  
   
    •  
  
  • 邏輯模型 
   
       
    
    • 進一步梳理業務需求，肯定每一個實體的屬性、關係和約束等
      •  
   
    •  
  
  • 物理模型 
   
       
    
    • 結合具體的數據庫產品，在知足業務讀寫性能等需求的前提下肯定最終的定義
      •  
    
    • Mysql、MongoDB、elasticsearch等
      •  
    
    • 第三範式
      •  
   
    •  
 
 
 
ES中的數據建模
 
 
     
  
  • ES是基於Lucene以倒排索引爲基礎實現的存儲體系，不遵循關係型數據庫中的範式約定
    •  
 
 
 
Mapping字段的相關配置
 
 
     
  
  • enabled 
   
       
    
    • true | false
      •  
    
    • 僅存儲，不作搜索或聚合分析
      •  
   
    •  
  
  • index 
   
       
    
    • true | false
      •  
    
    • 是否構建倒排索引
      •  
   
    •  
  
  • index_options 
   
       
    
    • docs | freqs |positions | offsets
      •  
    
    • 存儲倒排索引的哪些信息
      •  
   
    •  
  
  • norms 
   
       
    
    • true | false
      •  
    
    • 是否存儲歸一化相關參數，若是字段僅用於過濾和聚合分析，可關閉
      •  
   
    •  
  
  • doc_values 
   
       
    
    • true | false
      •  
    
    • c是否啓用doc_values，用於排序和聚合分析
      •  
   
    •  
  
  • field_data 
   
       
    
    • false | true
      •  
    
    • 是否爲text類型啓用fielddata，實現排序和聚合分析
      •  
   
    •  
  
  • store 
   
       
    
    • false | true
      •  
    
    • 是否存儲該字段值
      •  
   
    •  
  
  • coerce 
   
       
    
    • true |false
      •  
    
    • 是否開啓自動數據類型轉換功能，好比字符串轉爲數字、浮點轉爲×××等
      •  
   
    •  
  
  • multifields多字段 
   
       
    
    • 靈活使用多字段特性來解決多樣的業務需求
      •  
   
    •  
  
  • dynamic 
   
       
    
    • true | false |strict
      •  
    
    • 控制mapping自動更新
      •  
   
    •  
  
  • date_detection 
   
       
    
    • true | false
      •  
    
    • 是否自動識別日期類型
      •  
   
    •  
 
 
 
Mapping字段屬性的設定流程
 
 
     
  
  • 是何種類型
    •  
  
  • 是否須要檢索
    •  
  
  • 是否須要排序和聚合分析
    •  
  
  • 是否須要另行存儲
    •  
 
 
 
是何種類型
 
 
     
  
  • 字符串類型 
   
       
    
    • 須要分詞則設定爲text類型，不然設定爲keyword類型
      •  
   
    •  
  
  • 枚舉類型 
   
       
    
    • 基於性能考慮將其設定爲keyword類型，即使該數據爲整性
      •  
   
    •  
  
  • 數值類型 
   
       
    
    • 儘可能選擇貼近的類型，好比byte便可表示全部數值時，即選用byte，不要用long
      •  
   
    •  
  
  • 其餘類型 
   
       
    
    • 好比布爾類型、日期、地理位置數據等
      •  
   
    •  
 
 
 
是否須要檢索
 
 
     
  
  • 徹底不須要檢索、排序、聚合分析的字段 
   
       
    
    • enabled設置爲false
      •  
   
    •  
  
  • 不須要檢索的字段 
   
       
    
    • index設置爲false
      •  
   
    •  
  
  • 須要檢索的字段，能夠經過以下配置設定須要的存儲粒度 
   
       
    
    • index_options結合須要設定
      •  
    
    • norms不須要歸一化數據時關閉便可
      •  
   
    •  
 
 
 
是否須要排序和聚合分析
 
 
     
  
  • 不須要排序或者聚合分析功能 
   
       
    
    • doc_values設定爲false
      •  
    
    • fielddata設定爲false
      •  
   
    •  
 
 
 
是否須要另行存儲
 
 
     
  
  • 是否須要專門存儲當前字段的數據? 
   
       
    
    • store設定爲true，便可存儲該字段的原始內容(與_source中的不相關)
      •  
    
    • 通常結合_source的enabled設定爲false時使用 
      •  
   
    •  
 
 
 
關聯關係處理
 
 
     
  
  • ES不擅長處理關係型數據庫中的關聯關係，好比文章表blog與評論表comment之間經過blog_id關聯，在ES中能夠經過以下兩種手段變相解決 
   
       
    
    • Nested Object 
      •  
    
    • Parent/Child
      •  
   
    •  
  
  • ES 還提供了相似關係數據庫中join的實現方式，使用join數據類型實現 
    PUT blog_index_parrent_child
{
"mappings":{
"doc":{
  "properties":{
    "join":{
      "type":"join",#指明類型
      "relations":{#指明父子關係
        "blog":"comment"
      }
    }
  }
}
}
}
    •  
 
 
 
關聯關係處理之Parent/Child
 
 
#建立父文檔
PUT blog_index_parent_child/doc/1
{
  "title":"blog",
  "join":"blog"
}
#建立子文檔
PUT blog_index_parent_child/doc/comment-1?routing=1 #指定routing值，確保父子文檔在一個分片上，通常使用父文檔id
{
  "comment":"comment world",
  "join":{
    "name":"comment", #指明子類型
    "parent":1 #指明父文檔id
  }
}
 
 
     
  
  • 常見query語法包括以下幾種: 
   
       
    
    • parent_id返回某父文檔的子文檔 
      GET blog_index_parent/_search
{
"query":{
"parent_id":{#關鍵詞
"type":"comment",#指明子文檔類型
"id":"2" #指明父文檔id
}
}
}
      •  
    
    • has_child返回包含某子文檔的父文檔 
      GET blog_index_parent/_search
{
"query":{
"has_child":{#關鍵詞
"type":"comment",#指明子文檔類型
"query":{
"match":{
  "comment":"world"
}
}
}
}
}
      •  
    
    • has_parent返回某父文檔的子文檔 
      GET blog_index_parent/_search
{
"query":{
"has_parent":{
"has_parent":"blog",#指定父文檔類型
"query":{#指明父文檔查詢條件
"match":{
  "title":"blog"
}
}
}  
}
}
      •  
   
    •  
 
 
 
Nested Object vs Parent/Child
 
 
 
   
   
 
    對比 
    Nested Object 
    Parent/Child 
   
 
   
   
   
 
    優勢 
    文檔存儲在一塊兒，所以讀取性能高 
    父子文檔能夠獨立更新，互不影響 
   
 
   
 
    缺點 
    更新父或子文檔時須要更新整個文檔 
    爲了維護join的關係，須要佔用部份內存，讀取性能較差 
   
 
   
 
    場景 
    子文檔偶爾更新，查詢頻繁 
    子文檔更新頻繁 
   
 
   
 
 
 
Reindex
 
 
     
  
  • 指重建全部數據的過程，通常發生在以下狀況: 
   
       
    
    • mapping設置變動，好比字段類型變化、分詞器字典更新等
      •  
    
    • index設置變動，好比分片數更改
      •  
    
    • 遷移數據
      •  
   
    •  
  
  • ES提供了現成的API用於完成該工做 
   
       
    
    • _update_by_query在現有索引上重建
      •  
    
    • _reindex在其餘索引上重建
      •  
   
    •  
 
 
 
Reindex- _update_by_query
 
 
POST blog_index/_update_by_query?conflicts=proceed #若是遇到版本衝突，覆蓋並繼續執行
POST blog_index/_update_by_query
{
  "script":{ #更新文檔的字段值
    "source":"ctx._source.likes++",
    "lang":"painless"
  },
  "query":{ #能夠更新部分文檔
    "term":{
      "user":"tom"
    } 
  }
}
 
 
Reindex - _reindex
 
 
POST _reindex
{
  "source":{
    "index":"blog_index"
  },
  "dest":{
    "index":"blog_new_index"
  }
}
 
 
POST _reindex
{
  "conflicts":"proceed",#衝突時覆蓋並繼續
  "source":{
    "index":"blog_index",
    "query":{
      "term":{
        "user":"tom"
      }
    }
  },
  "dest":{
    "index":"blog_new_index"
  }
}
 
 
Reindex - Task
 
 
     
  
  • 數據重建的時間受源索引文檔規模的影響，當規模越大時，所需時間越多，此時須要經過設定url參數wait_for_completion爲false來異步執行，ES以task來描述此類執行任務
    •  
  
  • ES提供了Task API來查看任務的執行進度和相關數據 
    POST blog_index/_update_by_query?wait_for_completion=false #獲取task ID
GET _tasks/_qkdskglrfodsm(task ID)
    •  
 
 
 
數據建模的建議
 
 
數據模型版本管理
 
 
     
  
  • 對Mapping進行版本管理 
   
       
    
    • 包含在代碼或者以專門的文件進行管理，添加好註釋，並加入Git等版本管理倉庫中，方便回顧
      •  
    
    • 爲每一個增長一個metadata字段，在其中維護一些文檔相關的元數據，方便對數據進行管理 
      •  
   
    •  
 
 
 
防止字段過多
 
 
     
  
  • 通常字段過多的緣由是因爲沒有高質量的數據建模致使的，好比dynamic設置爲true
    •  
  
  • 考慮拆分多個索引來解決問題
    •  
  
  • 字段過多主要由如下壞處： 
   
       
    
    • 難於維護，當字段成百上千時，基本很難有人能明確知道每一個字段的含義
      •  
    
    • mapping的信息存儲在cluster state裏面，過多的字段會致使mapping過大，最終致使更新變慢
      •  
   
    •  
  
  • 經過設置index.mapping.total_fields.limit能夠限定索引中最大字段數，默認是1000
    •  
  
  • 能夠經過key/value的方式解決字段過多的問題，但並不完美 
    Key/Value方式詳解
    •  
  
  • 雖然經過這種方式能夠極大地減小field數目，但也有一些明顯的壞處 
   
       
    
    • query語句複雜度飆升，且有一些可能沒法實現，好比聚合分析相關的
      •  
    
    • 不利於在kibana中作可視化分析
      •  
   
    •  
 
 
 
集羣調優建議
 
 
生產環境部署建議
 
 
     
  
  • 遵守官方建議設置全部的系統參數
    •  
  
  • 參見文檔「setup Elasticsearch -> Important System Configuration" 
    ES設置儘可能簡潔
    •  
  
  • elasticsearch.yml中儘可能只寫必備的參數，其餘能夠經過api動態設置的參數都經過api來設定
    •  
  
  • 隨着ES版本的升級，不少網絡流傳的配置參數已經再也不支持，所以不要隨便複製別人的集羣配置參數 
    elasticsearch.yml中建議設定的基本參數
    •  
  
  • cluster.name
    •  
  
  • node.name
    •  
  
  • node.master/node.data/node.ingest
    •  
  
  • network.host建議顯示指定爲內網ip，不要偷懶直接設爲0.0.0.0
    •  
  
  • discovery.zen.ping.unicast.hosts 設定集羣其餘節點地址
    •  
  
  • discovery.zen.minimum_master_nodes通常設定爲2
    •  
  
  • path.data/path.log
    •  
  
  • 動態設定的參數有transient和persistent兩種設置，前者在集羣重啓後會丟失，後者不會，但兩種設定都會覆蓋elasticsearch.yml中的配置 
    PUT /_cluster/settings
{
"persistent":{
"discovery.zen.minimum_master_nodes":2
},
"transient":{
"indices.store.throttle.max_bytes_per_sec":"50mb"
}
}
    •  
 
 
 
jvm內存設定
 
 
     
  
  • 不要超過31GB
    •  
  
  • 預留一半內存給操做系統，用來作文件緩存
    •  
  
  • 具體大小根據該node要存儲的數據量來估算，爲了保證性能，在內存和數據量間有一個建議的比例 
   
       
    
    • 搜索類項目的比例建議在1:16之內
      •  
    
    • 日誌類項目的比例建議在1:48~1:96
      •  
   
    •  
  
  • 假設總數據量大小爲1TB，3個node，1個副本，那麼每一個node要存儲的數據量爲2TB/3=666TB，即700GB左右，作20%的預留空間，每一個node要存儲大約850GB的數據 
   
       
    
    • 若是是搜索類項目，每一個node內存大小爲850GB/16=53GB，大於31GB。31*16=496，即每一個node最多存儲496GB數據，因此須要至少5個node
      •  
    
    • 若是是日誌類型項目，每一個node內存大小爲850GB/48=18GB，所以3個節點足夠 
      •  
   
    •  
 
 
 
寫數據優化
 
 
寫數據過程
 
 
     
  
  • refresh
    •  
  
  • translog
    •  
  
  • flush
    •  
 
 
 
ES寫數據 - refresh
 
 
     
  
  • segment寫入磁盤的過程依然很耗時，能夠藉助文件系統緩存的特性，先將segment在緩存中建立並開放查詢來進一步提高實時性，該過程在es中稱爲refresh
    •  
  
  • 在refresh以前文檔會先存儲在一個buffer中，refresh時將buffer中的全部文檔清空並生成segment
    •  
  
  • es默認每一秒執行一次refresh，所以文檔的實時性被提升到一秒，這也是es被稱爲近實時的緣由
    •  
 
 
 
ES寫數據 - translog
 
 
     
  
  • 若是在內存中的segment尚未寫入磁盤前發生了宕機，那麼其中的文檔就沒法恢復了，如何解決這個問題？ 
   
       
    
    • es引入translog機制。寫文檔到buffer時，同時將該操做寫入translog
      •  
    
    • translog文件會即時寫入磁盤，6.x默認每一個請求都會落盤，能夠修改成每五秒寫一次，這樣風險即是丟失5秒內的數據，相關配置爲index.translog.*
      •  
    
    • es啓動時會檢查translog文件，並從中恢復數據
      •  
   
    •  
 
 
 
ES寫數據 - flush
 
 
     
  
  • flush負責將內存中的segment寫入磁盤，主要作以下的工做： 
   
       
    
    • 將translog寫入磁盤
      •  
    
    • 將index buffer清空，其中的文檔生成一個新的segment，至關於一個refresh操做
      •  
    
    • 更新commit point並寫入磁盤
      •  
    
    • 執行fsync操做，將內存中的segment寫入磁盤
      •  
    
    • 刪除舊的translog文件 
      •  
   
    •  
 
 
 
寫性能優化
 
 
     
  
  • 目標是增大寫吞吐量-EPS（Events Per Second）越高越好
    •  
  
  • 優化方案 
   
       
    
    • 客戶端：多線程寫，批量寫
      •  
    
    • ES：在高質量數據建模的前提下，主要是在refresh、translog和flush之間作文章
      •  
   
    •  
 
 
 
寫性能優化 - refresh
 
 
     
  
  • 目標爲下降refresh的頻率 
   
       
    
    • 增大refresh_interval，下降實時性，以增大一次refresh的文檔數，默認是1秒，設置爲-1直接禁止自動refresh
      •  
    
    • 增大index buffer size，參數爲indices.memory.index_buffer_size(靜態參數，須要設定在配置文件中)，默認爲10%
      •  
   
    •  
 
 
 
寫性能優化 - translog
 
 
     
  
  • 目標是下降translog寫磁盤的頻率，從而提升寫效率，但會下降容災能力 
   
       
    
    • index.tranlog.durability設置爲async,index.translog.sync_interval設置須要的大小，好比120s，那麼translog會改成每120s寫一次磁盤
      •  
    
    • index.translog.flush_threshold_size默認爲512mb，即translog超過該大小時會觸發一次flush，那麼調大該大小能夠避免flush的發生
      •  
   
    •  
 
 
 
寫性能優化 - flush
 
 
     
  
  • 目標爲下降flush的次數，在6.x可優化的點很少，多爲es自動完成
    •  
 
 
 
寫性能優化 - 其餘
 
 
     
  
  • 副本設置爲0，寫入完畢再增長
    •  
  
  • 合理地設計shard數，並保證shard均勻的分配在全部node上，充分利用全部node的資源 
   
       
    
    • index.routing.allocation.total_shards_per_node限定每一個索引在每一個node上可分配的總主副分片數
      •  
    
    • 5個node，某索引有10個分片，1個副本，上述值應該設置爲多少？ 
     
         
      
      • (10+10)/5=4
        •  
      
      • 實際要設置爲5個，防止在某個node下線時，分片遷移失敗的問題
        •  
     
      •  
   
    •  
 
 
 
讀性能優化
 
 
     
  
  • 讀性能主要受如下幾方面影響： 
   
       
    
    • 數據模型是否符合業務模型
      •  
    
    • 數據規模是否過大
      •  
    
    • 索引配置是否優化
      •  
    
    • 查詢語句是否優化
      •  
   
    •  
 
 
 
讀性能優化 - 數據建模
 
 
     
  
  • 高質量的數據建模是優化的基礎 
   
       
    
    • 將須要經過script腳本動態計算的值提早算好做爲字段存到文檔中
      •  
    
    • 儘可能使得數據模型貼近業務模型
      •  
   
    •  
  
  • 根據不一樣的數據規模設定不一樣的sla 
   
       
    
    • 上萬條數據與上千萬條數據性能確定存在差別
      •  
   
    •  
 
 
 
讀性能優化 - 索引配置調優
 
 
     
  
  • 索引配置優化主要包括以下： 
   
       
    
    • 根據數據規模設置合理的主分片數，能夠經過測試獲得最適合的分片數
      •  
    
    • 設置合理的副本數目，不是越多越好
      •  
   
    •  
 
 
 
讀性能優化 - 查詢語句調優
 
 
     
  
  • 查詢語句調優主要有如下幾種常見手段: 
   
       
    
    • 儘可能使用filter上下文，減小算分的場景，因爲filter有緩存機制，能夠極大提高查詢性能
      •  
    
    • 儘可能不使用script進行字段計算或者算分排序等
      •  
    
    • 結合profile、explain api分析慢查詢語句的癥結所在，而後再去優化數據模型
      •  
   
    •  
 
 
 
如何設定shard數
 
 
     
  
  • ES的性能基本是線性擴展的，所以咱們只要測出一個shard的性能指標，而後根據實際性能需求就算出須要的shard數。好比單shard寫入eps是10000，而線上eps需求是50000，那麼你須要五個shard（實際還要考慮副本的狀況）
    •  
  
  • 測試一個shard的流程以下： 
   
       
    
    • 搭建與生產環境相同配置的單節點集羣
      •  
    
    • 設定一個單分片零副本的索引
      •  
    
    • 寫入實際生產數據進行測試，獲取寫性能指標
      •  
    
    • 針對數據進行查詢請求，獲取讀性能指標
      •  
   
    •  
  
  • 壓測工具能夠採用esrally
    •  
  
  • 壓測的流程仍是比較複雜，能夠根據經驗來設定。若是是搜索引擎場景，單shard大小不要超過15GB，若是是日誌場景，單shard大小不要超過50GB（shard越大，查詢性能越低）
    •  
  
  • 此時只要估算出你索引的總數據大小，而後再除以上面的單shard大小也能夠獲得分片數 
    •  
 
 
 
 
 
歡迎各位關注個人公衆號「沒有故事的陳師傅」
一文帶你瞭解elasticsearch
 



        

            

        	





    

		

            
相關文章

            

                

                

                    

                

            


            
相關標籤/搜索

            
        


    

        

            

        

        

        
        

        

        

    




	

    





    

    	

    

        每日一句
    

    
    
    	每一个你不满意的现在，都有一个你没有努力的曾经。
    







    

    


    



    

        本站公眾號
    

    

           歡迎關注本站公眾號,獲取更多信息

        
    




    

    




	


	







    

        聯繫我們
        最近搜索
        最新文章
        
        沪ICP备13005482号-10

            MyBatis教程
            SQL 教程
            MySQL教程
            Java 教程
            Thymeleaf 教程
            Hibernate教程
            Spring教程 
            Redis教程