ELK-ElasticSearch-官方文檔note

時間 2019-12-22

標籤 elk elasticsearch 官方文檔 note 欄目日誌分析简体版

原文原文鏈接

1、getting started

use case 1.1 存儲大數據，作查詢 1.2 存儲日誌 1.3 從第三方收集數據，進行分析、查詢 1.4 分析聚合數據，利用kibana展現node
基本概念 2.1 near realtime 近實時正則表達式

2.2 cluster（集羣）有多個node，每一個cluster有惟一的一個名字，默認是‘elasticsearch’sql

2.3 node（節點）一個集羣中的其中一個服務節點，默認名字是一個uuid，能夠指定它加入的集羣的名字數據庫

2.4 index（索引）是具備稍微相似特徵文檔的集合，至關於數據庫中的一個數據庫實例。json

一個索引也有一個名字，它在對document（文檔）執行 indexing（索引），search（搜索），update（更新）和 delete（刪除）等操做時會被涉及到。一個集羣中能夠有多個索引。api

你也許已經注意到索引這個詞在 Elasticsearch 語境中包含多重意思，因此有必要作一點兒說明：索引（名詞）：如前所述，一個索引相似於傳統關係數據庫中的一個數據庫，是一個存儲關係型文檔的地方。索引 (index) 的複數詞爲 indices 或 indexes 。索引（動詞）：索引一個文檔就是存儲一個文檔到一個索引（名詞）中以便它能夠被檢索和查詢到。這很是相似於 SQL 語句中的 INSERT 關鍵詞，除了文檔已存在時新文檔會替換舊文檔狀況以外。倒排索引：關係型數據庫經過增長一個索引好比一個 B樹（B-tree）索引到指定的列上，以便提高數據檢索速度。Elasticsearch 和 Lucene 使用了一個叫作倒排索引的結構來達到相同的目的。數組

默認的，一個文檔中的每個屬性都是被索引的（有一個倒排索引）和可搜索的。一個沒有倒排索引的屬性是不能被搜索到的。咱們將在倒排索引討論倒排索引的更多細節。

2.5 type （類型）至關於數據庫中的一個表。緩存

在 Index（索引）中，能夠定義一個或多個類型。一個類型是索引中一個邏輯的種類/分區，它的語義徹底取決於您本身。

通常狀況下，一個類型被定義成一組常見字段的文檔。例如，假設您運行着一個博客平臺而且在一個單獨的索引中存儲了全部的數據。在這個索引中，您也許定義了一個用戶數據類型，博客數據類型，和評論數據類型。在高版本中會被移除。

2.6 document （文檔）    是索引信息的基本單位，至關於數據庫中的一條數據

例如，您有一存儲 customer（客戶）數據的文檔，另外一個是存儲 product（產品）數據的文檔，還有一個是存儲 order（訂單）數據的文檔。該文檔可使用 JSON 來表示，它是一種無處不在的互聯網數據交換格式。在索引/類型中，您能夠存儲許多文檔。

注意，儘管一個文檔物理的存在於索引中，實際上一個文檔必須被 索引/分配 給索引內的類型。

3. exploring cluster 探索集羣

3.1 集羣健康：Cluster Health安全

curl -XGET 'localhost:9200/_cat/health?v&pretty'網絡

能夠得到 green，yellow，或者 red 的 status。Green 表示一切正常（集羣功能齊全）， yellow 表示全部數據可用，可是有些副本還沒有分配（集羣功能齊全），red 意味着因爲某些緣由有些數據不可用。注意，集羣是 red，它仍然具備部分功能（例如，它將繼續從可用的分片中服務搜索請求），可是您可能須要儘快去修復它，由於您已經丟失數據了。

3.2 操做索引：Create an Index

curl -XGET 'localhost:9200/_cat/indices?v&pretty' 列出全部索引

curl -XPUT 'localhost:9200/customer?pretty' 添加索引

curl -XDELETE 'localhost:9200/customer?pretty' 刪除索引

3.3 操做文檔：Modifying Your Data

PUT：

curl -XPUT 'localhost:9200/customer/external/1?pretty&pretty' -d'{ "name": "John Doe"}'

添加文檔，若是文檔已存在，則更新。其中external是type（類型），其中 1 是類型的ID

POST：

curl -XPOST 'localhost:9200/customer/external/1/_update?pretty&pretty' -d'{ "doc": { "name": "Jane Doe" }}'

_update 更新文檔

curl -XDELETE 'localhost:9200/customer/external/2?pretty&pretty' 刪除文檔

curl -XGET 'localhost:9200/customer/external/1?pretty' 獲取文檔

curl -XPOST 'localhost:9200/customer/external/_bulk?pretty&pretty' -d'

_bulk 批量處理：

POST /customer/_doc/_bulk?pretty
{"update":{"_id":"1"}}
{"doc": { "name": "John Doe becomes Jane Doe" } }
{"delete":{"_id":"2"}}

將 HTTP 命令由 PUT 改成 GET 能夠用來檢索文檔，一樣的，可使用 DELETE 命令來刪除文檔，以及使用 HEAD 指令來檢查文檔是否存在。若是想更新已存在的文檔，只需再次 PUT 。 PUT 和 POST 區別：他們均可以用來提交和更新資源，可是PUT的接口是冪等的。

2、查詢操做：The Search API ----> _search

1.REST request URI 根據uri查詢

GET bank/account/_search?q=age:39&pretty&pretty
對index爲bank，type爲account進行檢索

Multi-Index, Multi-Type : 多index、多type查詢

It also support wildcards, for example: test* or test or tet or test, and the ability to "add" (+) and "remove" (-), for example: +test*,-test3. 更多語法查詢官網

/_search 在全部的索引中搜索全部的類型

/gb/_search 在 gb 索引中搜索全部的類型

/gb,us/_search 在 gb 和 us 索引中搜索全部的文檔

/g*,u*/_search 在任何以 g 或者 u 開頭的索引中搜索全部的類型

/gb/user/_search 在 gb 索引中搜索 user 類型

/gb,us/user,tweet/_search 在 gb 和 us 索引中搜索 user 和 tweet 類型

/_all/user,tweet/_search 在全部的索引中搜索 user 和 tweet 類型

參數：

q ----> map to query string query !!! 看完query string query回過頭來看！！!？？？
df 當沒有指定查詢的字段時，指定默認查詢字段。
analyzer 指定查詢分析器？？？
analyze_wildcard(通配符) 是否應分析通配符和前綴查詢。默認爲false。
batched_reduce_size 減小每一個分片查詢的數據量。若是每次查詢分片數大的話，減小這個值能夠用來避免機器佔用過多內存。
default_operator 默認的操做符爲 OR ，還能夠是AND。
lenient 寬容的。若是是true，則字段類型是敏感的，如向數字字段提供字符串查詢，則會致使失敗，默認是false
explain 解釋對命中的得分。
_source 是否顯示_source ，默認true。也可使用_source_include 或者_source_exclude選擇顯示的字段。
timeout
from
size
search_type
stored_fields ???
sort 排序：sort=age:asc，好像也能夠根據分數來排序？？？
track_scores: ??? When sorting, set to true in order to still track scores and return them as part of each hit.
track_total_hits: ??? Set to false in order to disable the tracking of the total number of hits that match the query
terminate_after
search_type ：要執行的搜索操做的類型。能夠是 dfs_query_then_fetch 或 query_then_fetch。默認爲 query_then_fetch。有關能夠執行的不一樣類型搜索的更多詳細信息，請參閱搜索類型。

舉例：

curl -XGET 'localhost:9200/bank/_search?q=*&sort=account_number:asc&pretty'

在響應中，咱們能夠看到如下幾個部分 :

took - Elasticsearch 執行搜索的時間（毫秒）

time_out - 告訴咱們搜索是否超時

_shards - 告訴咱們多少個分片被搜索了，以及統計了成功/失敗的搜索分片

hits - 搜索結果

hits.total - 搜索結果

hits.hits - 實際的搜索結果數組（默認爲前 10 的文檔）

sort - 結果的排序 key（鍵）（沒有則按 score 排序）

score 和 max_score -如今暫時忽略這些字段

2.REST request body( 全文搜索編輯 ) : DSL

query: 使用DSL查詢，具體查看DSL語法
from/size：
sort：
_source：
stored_fields ：存儲字段。stored_fields 參數是關於顯式標記爲存儲在映射中的字段，默認狀況下關閉，？？？？
script: 腳本。看Modules » Scripting？？？
docvalue_fields ： Mapping » Mapping parameters » doc_values？？？？
filter/post_filter： filter先過濾再聚合，post_filter先聚合再過濾。
highlight：高亮
rescoring: ??? 從新計算分數
search_type:
scroll API : 滾動api
preference：控制要對其執行搜索請求的分片副本的首選項
explain: 啓用每次匹配對其評分計算方式的說明。
version: 返回每一個搜索匹配的版本。
index_boost: 容許在跨多個索引搜索時爲每一個索引配置不一樣的查詢級別。好比更但願從indexA中命中，則：

"indices_boost" : {
        "index1" : 1.4,
        "index2" : 1.3
    }

min_score：排除 _score 小於 min_score 中指定的最小值的文檔
named queries : ????
inner hits: ???
search_after：分頁深度太深。search_after 參數經過提供活動光標來規避此問題。這個想法是使用前一頁的結果來幫助檢索下一頁。
field collapsing：字段摺疊。容許基於字段對結果進行摺疊。?????

Count API

_count 返回計數值

validate API

_validate 驗證查詢是否有效

Search 模板？？？

/_search/template

Search Shards API 查詢分片API ？？？

_search_shards

suggesters ？？？

Multi Search API ？？？

_msearch 一次有多個query

Expliain API ： Explain API 計算查詢和特定文檔的分數說明

_explain

Profile API

在_search中，添加參數："profile": true 顯示查詢詳細過程，能夠用來判斷爲什麼比較慢

3、聚合Aggregations：每一個聚合都是一個或者多個桶和零個或者多個指標的組合

Bucket：桶，知足特定條件的文檔的集合，相似於sql中的group by。它也能夠嵌套使用。有各類構造桶的方式，如：
1. terms桶：會爲每一個碰到的惟一詞項動態建立新的桶。由於咱們告訴它使用 color 字段，因此 terms 桶會爲每一個顏色動態建立新桶。其實就是當作一個分詞是一個組。

"aggs" : { "popular_colors" : { 桶的名字 "terms" : { terms構建桶 "field" : "color" 構建的屬性 } } }

2. date_histogram
	3. date_range
	4. Missing Aggregation
	5. range aggregation
	6.  "size":0    ,  去掉匹配的數據，只留aggregations
2. Metric(度量、指標)：對桶內的文檔進行統計計算。如：計數：value_count、平均值：avg、最大值max，最小值min。。。
```json
計算age字段的最大值，賦值給max_age。計算age的最小值，賦值給min_age
"aggs":{
    "min_age":{
      "min":{"field":"age"}
    },
    "max_age":{
      "max":{"field":"age"}
    }
  }
  結果：
  "aggregations": {
    "max_age": {
      "value": 40
    },
    "min_age": {
      "value": 20
    }
  }

Matrix: 矩陣，與文件有關
Pipeline：將其餘的聚類方法的輸出結果以及與其相連的度量進行聚合。
Structuring Aggregations：結構化聚合
Values Source

4、索引API

建立、刪除、獲取、存在等。

如下特別重要：

正排索引是從文檔到關鍵字的映射（已知文檔求關鍵字）；

倒排索引是從關鍵字到文檔的映射（已知關鍵字求文檔）。

搜索時，咱們須要一個「詞」到「文檔」列表的映射

排序時，咱們須要一個「文檔」到「詞「列表的映射，換句話說，咱們須要一個在倒排索引的基礎上創建的「正排索引」

在默認狀況下許多字段都是 indexed（被索引的）,這使得它們能夠被搜索.反向索引容許查詢經過惟一性排序的 term（詞根）列表來查詢 term（詞根）,而且能夠當即訪問包含該 term（詞根）的文檔.

這裏的「正排索引」結構一般在其餘系統中（如關係型數據庫）被稱爲「列式存儲」。本質上，它是在數據字段的一列上存儲全部value，這種結構在某些操做上會表現得很高效，好比排序。

在ES裏這種「列式存儲」就是咱們熟悉的「doc values」，默認狀況下它是被啓用的，doc values在index-time（索引期）被建立：當一個字段被索引時，ES會把「詞」加入到倒排索引中，同時把這些詞也加入到面向「列式存儲」的doc values中（存儲在硬盤上）。

搜索須要回答一個問題「哪一個 document（文檔）包含這個 term（詞條）」,然而排序和聚合須要回答一個不一樣的問題 " 這個字段在這個 document（文檔）中的值是多少？".!!!!!!!!!!!!!!!!

5、cat API

將如下信息在終端中顯示的更好看

/_cat/allocation
/_cat/shards
/_cat/shards/{index}
/_cat/master
/_cat/nodes
/_cat/tasks
/_cat/indices
/_cat/indices/{index}
/_cat/segments
/_cat/segments/{index}
/_cat/count
/_cat/count/{index}
/_cat/recovery
/_cat/recovery/{index}
/_cat/health
/_cat/pending_tasks
/_cat/aliases
/_cat/aliases/{alias}
/_cat/thread_pool
/_cat/thread_pool/{thread_pools}
/_cat/plugins
/_cat/fielddata
/_cat/fielddata/{fields}
/_cat/nodeattrs
/_cat/repositories
/_cat/snapshots/{repository}
/_cat/templates

6、集羣API

Cluster Allocation Explain API -> 它的目的是幫助回答這個問題「爲何這個分片沒有被分配」。爲了說明分片的分配（未分配狀態），發出一個這樣的請求 :
Cluster Health
Cluster Reroute 路由
Cluster State 狀態
Cluster Stats 統計
Cluster Update Settings
Nodes hot_threads
Nodes Info （集羣節點信息）API 能夠獲取集羣中一個或多個節點的信息。
Nodes Stats 節點統計信息
Pending cluster tasks -> pending cluster tasks（添加集羣任務）API 返回一個集羣級別中尚未被執行的操做的列表（例如，建立索引，更新映射，分配或故障的分片）。
Task Management API

7、es的各個Module（模塊）

本章節負責介紹Elasticsearch包含的各個模塊的功能，每一個模塊的配置均可以經過以下方式進行配置：

靜態的

這些配置項必須基於節點來進行設置，在啓動節點前能夠經過elasticsearch.yml配置文件、環境變量、命令行參數方式來進行配置。他們必須明確地在集羣中的每一個節點上進行設置。

動態的

這些配置能夠經過羣集的cluster-update-settings API進行動態更新。

本節介紹的模塊有：

Cluster-level routing and shard allocation（集羣級別的路由與分片分配））用來控制在何處、什麼時候、以及如何給節點分配分片。
Discovery（發現）構成一個集羣的節點彼此之間是如何發現的。
Gateway（網關）集羣啓動恢復前須要多少個節點加入。
HTTP 用來控制配置HTTP REST接口。
Indices（索引）全部跟索引相關的設置。
Network（網絡）控制默認的網絡設置。
Node client（節點客戶端）一個加入集羣的Java客戶端節點，但不能保存數據或做爲主節點。
Painless Elasticsearch內置的腳本語言，遵循儘量的安全設計。
Plugins（插件）經過插件來擴展Elasticsearch的功能。
Scripting（腳本）經過Lucene表達式、Groovy、Python、以及Javascript來自定義腳本。你也可使用內置的腳本語言Painless。
Snapshot/Restore（快照/還原）經過快照與還原模塊來備份你的數據。
Thread pools（線程池） Elasticsearch專用的線程池的信息。
Transport（傳輸） Elasticsearch內部各節點之間的網絡傳輸層通訊配置。
Tribe nodes Tribe節點能加入一個或多個集羣，並做爲它們之間的聯合客戶端。
Cross cluster Search（跨集羣搜索）跨集羣搜索功能能夠經過一個不加入集羣、而且能做爲它們之間的聯合客戶端來實現一個以上集羣的搜索。

8、索引模塊

包括索引的各個設置和信息查看 Settings in other index modules（其餘索引模塊的設置）在索引模塊中其餘可用的索引設置 :

Analysis（分析）定義 analyzers（分析器）、tokenizers（分詞器）、token filters（詞元過濾器）和 character filters（字符過濾器）。
Index shard allocation（索引分片分配）控制索引分配給節點的位置、時間、以及分片的方式。
Mapping（映射）啓用或禁用索引的動態映射。
Merging（合併）控制後臺合併線程如何合併分片。
Similarities（類似性）配置自定義類似性設置以自定義搜索結果的計分方式。
Slowlog（慢日誌）控制記錄搜索和索引請求的響應時間。
Store（存儲)）配置用於存儲分片數據的文件系統類型。
Translog（事務日誌）控制事務日誌和後臺刷新操做。

9、查詢DSL

Elasticsearch 提供了一個基於 JSON 的完整的查詢 DSL 來定義查詢。將查詢 DSL 視爲查詢的 AST，由兩種類型的子句組成：

一個查詢語句的典型結構!!!!!!!!!!!!!：

{
    QUERY_NAME: {
        ARGUMENT: VALUE,
        ARGUMENT: VALUE,...
    }
}

若是是針對某個字段，那麼它的結構以下：

{
    QUERY_NAME: {
        FIELD_NAME: {
            ARGUMENT: VALUE,
            ARGUMENT: VALUE,...
        }
    }
}

葉查詢子句 -> 葉查詢子句在特定查詢中查找特定值，例如匹配match、項值term、範圍查詢range。這些查詢均可以給本身使用。
複合查詢子句 -> 主要用於合併其它查詢語句，用於以邏輯方式組合多個查詢（例如 bool 或 dis_max 查詢），或更改其行爲（如 constant_score 查詢）。好比，一個 bool 語句容許在你須要的時候組合其它語句，不管是 must 匹配、 must_not 匹配仍是 should 匹配，同時它能夠包含不評分的過濾器（filters）：

{
    "bool": {
        "must":     { "match": { "tweet": "elasticsearch" }},
        "must_not": { "match": { "name":  "mary" }},
        "should":   { "match": { "tweet": "full text" }},
        "filter":   { "range": { "age" : { "gt" : 30 }} }
    }
}

一條複合語句能夠合併任何其它查詢語句，包括複合語句，瞭解這一點是很重要的。這就意味着，複合語句之間能夠互相嵌套，能夠表達很是複雜的邏輯。

{
    "bool": {
        "must": { "match":   { "email": "business opportunity" }},
        "should": [
            { "match":       { "starred": true }},
            { "bool": {
                "must":      { "match": { "folder": "inbox" }},
                "must_not":  { "match": { "spam": true }}
            }}
        ],
        "minimum_should_match": 1
    }
}

Elasticsearch 使用的查詢語言（DSL）擁有一套查詢組件，這些組件能夠以無限組合的方式進行搭配。這套組件能夠在如下兩種狀況下使用：過濾狀況（filtering context）和查詢狀況（query context）。

當使用於過濾狀況時，查詢被設置成一個「不評分」或者「過濾」查詢。即，這個查詢只是簡單的問一個問題：「這篇文檔是否匹配？」。回答也是很是的簡單，yes 或者 no ，兩者必居其一。最重要的是，filter不須要統計評分，並且es會緩存，所以更快，更高效！！！！

查詢子句的行爲有所不一樣，具體取決於它們是在查詢上下文仍是過濾器上下文中使用。

查詢上下文: query

在查詢上下文中使用的查詢子句回答了問題「此文檔與此查詢子句匹配程度如何？」除了決定文檔是否匹配以外，查詢子句還計算一個得分（ _score ）表示文檔相對於其餘文檔的匹配程度。每當將查詢子句傳遞給 query 參數（例如，search API中的 query 參數）時，查詢上下文都有效。

過濾上下文: filter

在過濾器上下文中，查詢子句回答問題「此文檔是否匹配此查詢子句？」答案是一個簡單的是或否——不計算得分。過濾器上下文主要用於過濾結構化數據，例如：

此 timestamp 是否在2015年至2016年的範圍內？ status 字段是否設置爲 "published"

單個查詢條件 0. match_all / match_none -> match_all 查詢簡單的匹配全部文檔。在沒有指定查詢方式時，它是默認的查詢
1. match -> 匹配查詢（match）用於執行全文查詢的標準查詢，包括模糊匹配和詞組或鄰近程度的查詢。
  - match -> {"query":{"bool":{"must":[{"match":{"age":20}},{"match":{"age":30}}]}}}
2. 短語匹配查詢（match_phrase）與匹配查詢相似，可是是用於更加精確的匹配類似的詞組或單詞。
3. 短語前綴匹配查詢（match_phrase_prefix）這是一種弱類型的查詢，相似短語匹配查詢，可是它對最終要查詢的單詞的前綴進行模糊匹配的查詢
4. 多字段查詢（multi_match）能夠用來對多個字段的版本進行匹配查詢
5. 經常使用術語查詢（common）能夠對一些比較專業的偏門詞語進行的更加專業的查詢
6. 查詢語句查詢（query_string）與lucene查詢語句的語法結合的更加緊密的一種查詢，容許你在一個查詢語句中使用多個特殊條件關鍵字（如：AND|OR|NOT ）對多個字段進行查詢，固然這種查詢僅限專家用戶去使用。
7. 簡單查詢語句（simple_query_string）是一種適合直接暴露給用戶的簡單的且具備很是完善的查詢語法的查詢語句
8. 範圍查詢語句（range） gt大於、gte大於等於、lt小於、lte小於等於
9. 精確匹配 (term / trems) term 查詢對於輸入的文本不分析，因此它將給定的值進行精確查詢。
10. 是否存在查詢 (exists / missing)
11.查詢語句查詢（query_string ）使用查詢解析器爲了解析其內容的查詢。
1. boost -> 咱們能夠經過指定 boost 來控制任何查詢語句的相對的權重， boost 的默認值爲 1 ，大於 1 會提高一個語句的相對權重。boost 參數被用來提高一個語句的相對權重（ boost 值大於 1 ）或下降相對權重（ boost 值處於 0 到 1 之間），可是這種提高或下降並非線性的，換句話說，若是一個 boost 值爲 2 ，並不能得到兩倍的評分 _score 。

{ "match": {
                    "content": {
                        "query": "Lucene",
                        "boost": 2 
                    }
                }
}

組合查詢（將上面多個單查詢組合起來）
1. must 文檔必須匹配這些條件才能被包含進來。
2. must_not 文檔必須不匹配這些條件才能被包含進來。
3. should 若是知足這些語句中的任意語句，將增長 _score ，不然，無任何影響。它們主要用於修正每一個文檔的相關性得分。
4. filter 必須匹配，但它以不評分、過濾模式來進行。這些語句對評分沒有貢獻，只是根據過濾標準來排除或包含文檔。
複合查詢（將上面多個組合查詢組合起來）
1. bool 如：age=30而且gender=F

{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "age": 30
          }
        },
        {
          "match": {
            "gender": "F"
          }
        }
      ]
    }
  }
}

2. constant_score 查詢
這是一個包裝其餘查詢的查詢，而且在過濾器上下文中執行。與此查詢匹配的全部文件都須要返回相同的「常量」 _score 。

3. dis_max 即分離 最大化查詢（Disjunction Max Query）-> 分離（Disjunction）的意思是 或（or） ，這與能夠把結合（conjunction）理解成 與（and） 相對應。分離最大化查詢（Disjunction Max Query）指的是： 將任何與任一查詢匹配的文檔做爲結果返回，但只將最佳匹配的評分做爲查詢的評分結果返回 ：

4. Function_Score -> function_score 容許你修改一個查詢檢索文檔的分數。 

5. boosting 查詢 -> 能夠用來有效地降級能匹配給定查詢的結果

上述基本都是針對整個詞的操做，接下來是部分匹配
1. Term Query（項查詢）查詢包含在指定字段中指定的確切值的文檔。
2. Terms Query（多項查詢）查詢包含任意一個在指定字段中指定的多個確切值的文檔。
3. Range Query（範圍查詢）查詢指定字段包含指定範圍內的值（日期，數字或字符串）的文檔。
4. Exists Query（非空值查詢）查詢指定的字段包含任何非空值的文檔。
5. Prefi Query（前綴查詢）查找指定字段包含以指定的精確前綴開頭的值的文檔。
6. Wildcard Query（通配符查詢）查詢指定字段包含與指定模式匹配的值的文檔，其中該模式支持單字符通配符（？）和多字符通配符（），如："wildcard" : { "user" : "kiy" }
7. Regexp Query（正則表達式查詢）查詢指定的字段包含與指定的正則表達式匹配的值的文檔。如："regexp":{"name.first":"s.*y"}
8. Fuzzy Query（模糊查詢）查詢指定字段包含與指定術語模糊類似的術語的文檔。模糊性測量爲1或2的 Levenshtein。
9. Type Query（類型查詢）查詢指定類型的文檔。
10. Ids Query（ID查詢）查詢具備指定類型和 ID 的文檔。

8、Mapping映射

映射索引myindex中的mytype類型，這個類型中有一個text類型的title屬性和一個text類型的content屬性。
（其餘字段類型見文檔）
PUT myindex
{
  "mappings": {
    "mytype": {
      "properties": {
        "title": {
          "type": "text"
        },
        "content": {
          "type": "text"
        }
      }
    }
  }
}

一個文檔的被映射的字段類型有兩種：元數據類型和屬性(properties)，元數據類型是每一個字段固有的，而屬性是用來描述這個字段的，用法以下：

1、元數據類型(能夠理解成每一個類型都會有的字段！！！！)：Meta-Fields，如

_all
_field_names（字段名）
_id
_index
_meta
_parent
_routing
_source
_type

其中：

_all 該字段容許您搜索文件中的值不知道哪一個字段包含的值。這使其成爲一個有用的選項時,開始使用一種新的數據集。但他須要消耗更多的資源，所以默認是禁用的。例如:

"query": {
    "match": {
      "_all": "john smith 1970"
    }
  }

text 該字段用於索引全文文本，例如電子郵件的正文或產品的描述。對這些字段進行analyzed ，即經過分析器將其轉換成索引以前的各個術語列表。分析過程容許Elasticsearch搜索每一個全文本字段中的單個單詞。文本字段不用於排序，不多用於聚合（儘管重要的術語聚合是一個顯着的例外）。若是您須要索引結構化內容（如電子郵件地址，主機名，狀態代碼或標籤），則可能您應該使用keyword字段。對於代碼或標籤，您也可能應該使用keyword字段。

2、字段(屬性，也就是自定義的，能夠指定類型和參數映射)：Fields or properties。默認狀況下，每一個字段都是被索引的(使用倒排索引)，全部字段是默認被 indexed（被索引的），這使得它們是可搜索的.能夠在腳本中排序,聚合和獲取字段值,可是須要不一樣的搜索模式.

如

analyzer（分析器）
normalizer(歸一化)
boost(提高權重)
Coerce（強制類型轉換）
copy_to（合併參數）
doc_values（文檔值）-> 默認開啓，Doc values 是在 document 索引時間內構建在磁盤上的數據結構,這使得上面所說的數據訪問模式成爲可能.它們存儲與 _source 相同的值,可是以列爲主的方式存儲.這使得排序和聚合效率更高。默認狀況下,支持 doc values 的全部字段都是開啓的.若是你肯定不須要在字段上進行排序和聚合,活從腳本中訪問字段值,則能夠禁用 doc values 來節省磁盤空間.
dynamic（動態設置）-> 默認狀況下,字段會動態的添加到 document 或者 document 的 inner objects（內部對象），只須要經過索引包含這個新字段的 document。
enabled（開啓字段）-> enabled 設置只能夠應用於映射類型和 object 字段,致使 Elasticsearch 徹底跳過字段內容的解析.這個 JSON 仍然能夠從 _source 字段中檢索,可是不能以任何其餘方式搜索或存儲：
fielddata（字段數據）-> 許多字段可使用 index-time，在磁盤上的 doc_values 支持這種數據訪問模式, 可是 text 字段不支持 doc_values。相反,text 字段使用查詢時存在於內存的數據結構 fielddata.這個數據結構是第一次將字段用於聚合,排序,或者腳本時基於需求構建的。它是經過讀取磁盤上的每一個 segment（片斷）的整個反向索引來構建的，將 term（詞條）和 document（文檔）關係反轉,並將結果存儲在內存中,在JVM的堆中.
format （日期格式）
ignore_above（忽略超越限制的字段）
ignore_malformed（忽略格式不對的數據）
include_in_all（是否在 _all 查詢包含該字段）
index_options（索引設置）
index （是否創建索引，若是設置成false，則沒法被搜索）
fields（字段) -> 咱們常常會由於不一樣的目的將同一個字段用不一樣的方式索引。這就至關於實現了 multi-fields。例如，一個 string 類型字段能夠被映射成 text 字段做爲 full-text 進行搜索，同時也能夠做爲 keyword 字段用於排序和聚合：
Norms （標準信息）
null_value（空值）
position_increment_gap（短語位置間隙）
properties （屬性）
search_analyzer （搜索分析器）
similarity （匹配方法）
store（存儲）-> 默認狀況下，字段值會被索引使他們能搜索，但他們不會被 stored（存儲）。意思就是這個字段能查詢，但不能取回他的原始值。
Term_vectors（詞根信息）

fielddata 和 doc_value的比較

4.1 相同點

都要建立正排索引，數據結構相似於列式存儲

都是爲了能夠聚合，排序之類的操做

4.2 不一樣點

存儲索引數據的方式不同：

fielddata: 內存存儲；doc_values: OS Cache+磁盤存儲

對應的字段類型不同

fielddata: 對應的字段類型是text; doc_values：對應的字段類型是keyword

針對的類型，也不同

field_data主要針對的是分詞字段；doc_values針對大是不分詞字段

是否開啓

fielddata默認不開啓；doc_values默認是開啓

fields（字段） 咱們常常會由於不一樣的目的將同一個字段用不一樣的方式索引。這就至關於實現了 multi-fields。例如，一個 string 類型字段能夠被映射成 text 字段做爲 full-text 進行搜索，同時也能夠做爲 keyword 字段用於排序和聚合：

"lastname": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",      -->  由於fieldfata默認是關閉的，因此直接對這個字段聚合會報錯，因此使用.keyword就能夠進行聚合了！！！
                "ignore_above": 256
              }
            }
          }

舉例！！！！：

GET /bank/account/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "prefix": {
            "firstname": "m"
          }
        }
      ]
    }
  },
  "aggs":{
    "gender":{
      "terms":{
        "field":"gender.keyword"
      },
      "aggs":{
        "avg_age":{
          "avg":{
            "field":"age"
          }
        }
      }
    }
  }
}

結果：

"aggregations": {
    "gender": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 0,
      "buckets": [
        {
          "key": "F",
          "doc_count": 59,
          "avg_age": {
            "value": 30.93220338983051
          }
        },
        {
          "key": "M",
          "doc_count": 52,
          "avg_age": {
            "value": 30.23076923076923
          }
        }
      ]
    }
  }

3、Dynamic Mapping（動態映射）

9、管理、監控、部署

10、詞彙表

analysis（分析） Analysis（分析）是將 full text（全文）轉化爲 terms（詞條）的過程。使用不一樣的 analyzer（分詞器）， FOO BAR，Foo-Bar，foo，bar 這些短語可能都會生成 foo 和 bar 兩個詞條，實際的 index（索引）裏面存儲的就是這些 terms（詞條）。針對 FoO:bAR 的 full text query（全文檢索），會先將其分析成爲 foo,bar 這樣的詞條，而後匹配存儲在 index（索引）中的 term（詞條）。正是這個 analysis（分析）的過程（發生在索引和搜索時）使得 elasticsearch 可以執行 full text queries（全文檢索）。也能夠參閱 text（文本）和 term（詞條）瞭解更多細節信息。
term （詞條） term（詞條）是elasticsearch中被索引的確切值。foo, Foo, FOO 這些term（詞條）不相等。term（詞條）能夠經過詞條搜索來檢索。查詢text（文本）和anaylsis（分詞）獲取更多信息。
text （文本） text（文本）（或者說全文）是普通的非結構化文本，如一個段落。默認狀況下，text（文本）會被analyzed（分詞）成term（詞條），term（詞條）是實際存儲在索引中的內容。文本的field（屬性）必須在索引時完成analyzed（分詞）來支持全文檢索的功能，全文檢索使用的關鍵詞也必須在搜索時analyzed（分詞）成索引時產生的相同term（詞條）。查詢term（詞條）和analysis（分詞）獲取更多信息。
cluster （集羣） cluster（集羣）是由擁有同一個集羣名的一個或者多個節點組成。每一個集羣擁有一個主節點，它由集羣自行選舉出來，在當前主節點掛了，能被其餘節點取代。
index （索引） index（索引）相似於關係型數據庫中的表。它有一個mapping（映射）來定義索引中的fields（屬性），這些屬性被分組成多種type（類型）。索引是一個邏輯命名空間，它對應一到多個primary shards（主分片）和零到多個replica shards（副本分片）。
document （文檔） document（文檔）是存儲在elasticsearch中的json文檔。相似於關係型數據庫中的一行記錄。每一個文檔存儲在一個index（索引）中，它具備一個type（類型）和一個id。文檔是包含零到多個fields（屬性）或者鍵值對的json對象（相似於其餘語言中的hash/hashmap/associative array）。當一個文檔被indexed（索引）的時候，它的原始json文檔會被存儲成_source屬性，對該文檔進行get或者search操做時，默認返回的就是改屬性。
term （詞條） term（詞條）是elasticsearch中被索引的確切值。foo, Foo, FOO 這些term（詞條）不相等。term（詞條）能夠經過詞條搜索來檢索。查詢text（文本）和anaylsis（分詞）獲取更多信息。
text （文本） text（文本）（或者說全文）是普通的非結構化文本，如一個段落。默認狀況下，text（文本）會被analyzed（分詞）成term（詞條），term（詞條）是實際存儲在索引中的內容。文本的field（屬性）必須在索引時完成analyzed（分詞）來支持全文檢索的功能，全文檢索使用的關鍵詞也必須在搜索時analyzed（分詞）成索引時產生的相同term（詞條）。查詢term（詞條）和analysis（分詞）獲取更多信息。
type （類型） type（類型）表明文檔的類型，如一封郵件，一個用戶，一條推文。搜索API能夠經過文檔類型來過濾。index（索引）能夠包涵多個類型，每個type（類型）有一系列的fields（屬性）。同一個index（索引）中不一樣type（類型）的同名fields（屬性）必須使用相同的mapping（映射）（定義文檔的屬性如何索引以及是文檔能被搜索）。
id 文檔的ID標識一個文檔。文檔的index/type/id必須惟一。若是沒有提供ID，elasticsearch會自動生成一個ID。（查詢routing（路由）獲取更多信息）
field（屬性）一個文檔包涵一系列的屬性或者鍵值對。它的值能夠是簡單標量值（如字符串，整型數，日期），或者是像數組和對象同樣的嵌套結構。屬性相似於關係型數據庫中的列。每一個屬性的mapping（映射）都有其類型（不一樣於document（文檔）的type（類型）），代表該屬性能存儲成改類型的數據，例如 integer, string, object。mapping（映射）也容許你定義屬性的值是否須要analyzed（分詞）。
mapping （映射） mapping（映射）相似於關係型數據庫中的元數據定義。每個index（索引）對應一個mapping（映射），它定義了index（索引）中的每個type（類型），另外還有一些索引級別的設置。mapping（映射）能夠顯式定義，或者當一個文檔進行索引時自動生成。
node （節點） node（節點）是從屬於一個elasticsearch集羣的正在運行的節點。當以測試爲目的時，能夠在一臺主機上啓動多個節點，可是一般一臺主機最好運行一個節點。在啓動時，節點會使用廣播的方式，自動感知（網絡中）具備相同集羣名的集羣，並嘗試加入它。
primary shard （主分片）每一個文檔存儲在單primary shard （主分片）中。當索引一個文檔時，它會首先被索引到主分片上，而後索引到主分片的全部副本上。默認狀況下，一個index（索引）有5個primary shard （主分片）。根據index（索引）的處理能力，你能夠指定更少或者更多的primary shard （主分片）來擴展文檔數量。當index（索引）建立以後，primary shard （主分片）的數量不可更改。查詢routing（路由）獲取更多信息。
replica shard （副本分片）每個primary shard （主分片）擁有零到多個副本。副本是primary shard （主分片）的拷貝，它的存在有兩個目的：

增長容錯：當主分片失敗時，一個replica shard（副本分片）能夠提高爲primary shard （主分片）
提高性能：primary shard （主分片）和replica shard（副本分片）都能處理get和shearch請求。默認狀況下，每一個primary shard （主分片）有一個副本，副本的個數能夠動態的修改。replica shard（副本分片）不會和primary shard （主分片）分配在同一個節點上。

routing （路由）當你索引一個文檔時，它會被存儲在一個單獨的主分片上。經過對routing值進行哈希計算來決定具體是哪個主分片。默認狀況下，routing值是來自於文檔ID，若是文檔指定了一個父文檔，則經過其父文檔ID（保證父子文檔存儲在同一個分片上）。若是你不想使用默認的文檔ID來做爲routing值,你能夠在索引時直接指定一個routing值，或者在mapping中指定一個字段的值來做爲routing值。
shard （分片）一個Shard就是一個Lucene實例，是一個完整的搜索引擎。一個索引能夠只包含一個Shard，只是通常狀況下會用多個分片，能夠拆分索引到不一樣的節點上，分擔索引壓力。 shard（分片）是一個Lucene實例。它是由elasticsearch管理的低層次的工做單元。index（索引）是指向主分片和副本分片的邏輯命名空間。除了定義index（索引）應該具備的primary shard（主分片）和replica shard（副本分片）的數量以外，你不須要對shard（分片）做其它的工做。相反，你的代碼應該只處理index（索引）。elasticsearch將shards（分片）分配到整個集羣的全部節點上，當節點失敗時能夠自動將分片遷移到其餘節點或者新增的節點上。
segment elasticsearch中的每一個分片包含多個segment，每個segment都是一個倒排索引；在查詢的時，會把全部的segment查詢結果彙總歸併後最爲最終的分片查詢結果返回；在建立索引的時候，elasticsearch會把文檔信息寫到內存bugffer中（爲了安全，也一塊兒寫到translog），定時（可配置）把數據寫到segment緩存小文件中，而後刷新查詢，使剛寫入的segment可查。雖然寫入的segment可查詢，可是尚未持久化到磁盤上。所以，仍是會存在丟失的可能性的。因此，elasticsearch會執行flush操做，把segment持久化到磁盤上並清除translog的數據（由於這個時候，數據已經寫到磁盤上，不在須要了）。當索引數據不斷增加時，對應的segment也會不斷的增多，查詢性能可能就會降低。所以，Elasticsearch會觸發segment合併的線程，把不少小的segment合併成更大的segment，而後刪除小的segment。 segment是不可變的，當咱們更新一個文檔時，會把老的數據打上已刪除的標記，而後寫一條新的文檔。在執行flush操做的時候，纔會把已刪除的記錄物理刪除掉。
source field （源屬性）在默認狀況下，你索引的json document（文檔）會存儲在_source field（屬性）中，get和search請求會返回該field（屬性）。這樣能夠直接在搜索結果中獲取原始文檔對象，不須要經過ID再檢索一次文檔對象。

截止目前的搜索相對都很簡單：單個姓名，經過年齡過濾。如今嘗試下稍微高級點兒的全文搜索——一項傳統數據庫確實很難搞定的任務。

搜索下全部喜歡攀巖（rock climbing）的僱員：

GET /megacorp/employee/_search
{
    "query" : {
        "match" : {
            "about" : "rock climbing"
        }
    }
}

拷貝爲 CURL在 SENSE 中查看顯然咱們依舊使用以前的 match 查詢在about 屬性上搜索「rock climbing」。獲得兩個匹配的文檔：

{
   ...
   "hits": {
      "total":      2,
      "max_score":  0.16273327,
      "hits": [
         {
            ...
            "_score":         0.16273327, 
            "_source": {
               "first_name":  "John",
               "last_name":   "Smith",
               "age":         25,
               "about":       "I love to go rock climbing",
               "interests": [ "sports", "music" ]
            }
         },
         {
            ...
            "_score":         0.016878016, 
            "_source": {
               "first_name":  "Jane",
               "last_name":   "Smith",
               "age":         32,
               "about":       "I like to collect rock albums",
               "interests": [ "music" ]
            }
         }
      ]
   }
}

短語搜索編輯 - match_phrase

找出一個屬性中的獨立單詞是沒有問題的，但有時候想要精確匹配一系列單詞或者短語。好比，咱們想執行這樣一個查詢，僅匹配同時包含「rock」和「climbing」，而且兩者以短語「rock climbing」的形式緊挨着的僱員記錄。

爲此對 match 查詢稍做調整，使用一個叫作 match_phrase 的查詢：

GET /megacorp/employee/_search
{
    "query" : {
        "match_phrase" : {
            "about" : "rock climbing"
        }
    }
}

拷貝爲 CURL在 SENSE 中查看毫無懸念，返回結果僅有 John Smith 的文檔。

{
   ...
   "hits": {
      "total":      1,
      "max_score":  0.23013961,
      "hits": [
         {
            ...
            "_score":         0.23013961,
            "_source": {
               "first_name":  "John",
               "last_name":   "Smith",
               "age":         25,
               "about":       "I love to go rock climbing",
               "interests": [ "sports", "music" ]
            }
         }
      ]
   }
}

3.5 REST request body方法查詢

curl -XGET 'localhost:9200/bank/_search?pretty' -d'

{

  "query": {

    "bool": {

      "must": [

        { "match": { "address": "mill" } },

        { "match": { "address": "lane" } }

過濾:

{

"query": {

"bool": {

  "must": { "match_all": {} },

  "filter": {

    "range": {

      "balance": {

        "gte": 20000,

        "lte": 30000

      }

聚合：

{

"size": 0,

"aggs": {

"group_by_state": {

  "terms": {

    "field": "state.keyword"

  }

}

setup es 暫時跳過，某些生產上的設置相當重要
API 規範

5.1 Multiple Indices（多個索引）
```
/g*,u*/_search      在任何以 g 或者 u 開頭的索引中搜索全部的類型
```
5.2 Date math support in index names（索引名稱對 Date 和 Math 的支持）

Date math 索引名稱解析可讓您搜索一系列 time-series indices（時間序列索引），而不是搜索全部時間序列索引並過濾結果或維護 aliases（別名）。限制搜索的索引數量減小了集羣上的負載，並提升了執行性能。例如，若是您在平常日誌中 searching for errors（搜索錯誤 )，則可使用 date math name 模板將搜索限制爲過去兩天。
document api
search api
aggregation api 聚合api
index api 索引api
cat api
cluster api
查詢 DSL Elasticsearch提供了一個基於JSON的完整的查詢DSL來定義查詢。將查詢DSL視爲查詢的AST，由兩種類型的子句組成：