Elasticsearch 動態創建mapping

如果在創建index的時候不指定mapping，那么ES會幫我們動態創建mapping，那么String數據類型的數據會被映射成text類型(這種類型默認是分詞的，在搜索的時候只需要指定部分內容就可以搜到結果)。如果不動態創建mapping，指定字段類型是keyword，那么在搜索的時候需要精確匹配內容，才可以把結果搜出來(底層依然使用倒排索引，只不過索引的字段是整個內容)

Elasticsearch Object數據類型

我們新建一個index：

PUT article {"mappings": {"type": {"properties": {"title": {"type": "keyword"},"author": {"properties": {"name": {"type": "keyword"},"age": {"type": "long"}}}}}} }

這里面的author字段屬于Object類型，下面有name和age字段。
當我們添加一條數據時：

POST article/type {"title": "hello world","author": {"name": "Bill Gates","age": 50} }

Object數據類型的底層存儲形式：

{"title": ["hello world"],"author.name": ["Bill Gates],"author.age": [50] }

當添加的數據是如下形式：

POST article/type {"title": "CS","author": [{"name":"Tuling","age":70},{"name":"yaoqizhi","age":65}] }

那么Object的存儲形式是：

{"title": "CS","author.name": ["Tuling", "yaoqizhi"],"author.age": [70, 65] }

Term/Terms

term/terms查詢會去倒排索引中查詢確切的關鍵詞，并不知道分詞器的存在，這種查詢適合keyword、date、numeric類型

Match

match 會對我們這個搜索的字段進行分詞，然后在倒排索引中進行查找。同時所查找的字段的數據類型不能是keyword。
例如下面的index：

PUT article2 {"mappings": {"type": {"properties": {"title": {"type": "text"},"author": {"properties": {"name": {"type": "keyword"},"age": {"type": "long"}}}}}} }

添加數據

POST article2/type {"title": "system","author": {"name": "Tom","age": 52} }POST article2/type {"title": "operator","author": {"name": "jerry","age": 12} }

使用match搜索：

GET article2/_search {"query": {"bool": {"must": [{"match": {"title": "system operator"}}]}} }

搜索結果如下：

"hits": {"total": 2,"max_score": 0.2876821,"hits": [{"_index": "article2","_type": "type","_id": "Dgu-oW0BKTSW7lTxmSgP","_score": 0.2876821,"_source": {"title": "system","author": {"name": "Tom","age": 52}}},{"_index": "article2","_type": "type","_id": "Dwu-oW0BKTSW7lTxoyhT","_score": 0.2876821,"_source": {"title": "operator","author": {"name": "jerry","age": 12}}}]}

此時，當title的類型是text時，使用match才會生效。
如果使用term查詢：

GET article2/_search {"query": {"bool": {"must": [{"term": {"title": {"value": "system operator"}}}]}} }

這樣是查詢不到的，因為要精確匹配system operator，而文檔中沒有這個詞。

Multi_match

可以指定多個字段，matc只能指定一個字段

match_phrase

短語匹配，類似于英語中的短語

ik分詞器

帶有兩個分詞器：

• ik_max_word: 會將文本做最細粒度的拆分；盡可能多的拆分出詞語
• ik_smart: 會做最粗粒度的拆分；已經被分出的詞語將不會被其他詞語占用

Filter

filter不計算相關性的，同時可以緩存，因此速度快與query。
新建index，并插入數據：

PUT order {"mappings": {"type": {"properties": {"customsID": {"type": "keyword"},"price": {"type": "keyword"},"orderID": {"type": "keyword"}}}} }POST order/type/_bulk {"index":{}} {"customsID":"001","price":"100", "orderID":"10000"} {"index":{}} {"customsID":"002","price":"40", "orderID":"10002"} {"index":{}} {"customsID":"002","price":"75", "orderID":"10003"}

查詢價格是40的數據：

GET order/_search {"query": {"bool": {"filter": {"term": {"price": "40"}}}} }

查詢結果如下：

"hits": {"total": 1,"max_score": 0,"hits": [{"_index": "order","_type": "type","_id": "EgvxoW0BKTSW7lTx3iiD","_score": 0,"_source": {"customsID": "002","price": "40","orderID": "10002"}}]}

既然可以用term，那么就可以使用terms

constant_score

當我們不關心檢索詞頻率TF（Term Frequency）對搜索結果排序的影響時，可以使用constant_score將查詢語句query或者過濾語句filter包裝起來。
檢索詞頻率：檢索詞在該字段出現的頻率。出現頻率越高，相關性也越高。字段中出現過5次要比只出現過1次的相關性高。
假設存在如下類型的文檔：

{ "description": "wifi wifi garden pool" }

查詢語句如下：

{"query":{"bool":{"should": [{ "constant_score": {"query": { "match": { "description": "wifi" }}}},{ "constant_score": {"query": { "match": { "description": "garden" }}}},{ "constant_score": {"query": { "match": { "description": "pool" }}}}]}} }

因為不考慮檢索詞頻率，所以匹配文檔的score等于該文檔含有的不同檢索詞匯的個數。
score受到協調因子boost的影響：

{ "constant_score": {"boost":2,"query": { "match": { "description": "pool" }} }}

出現pool的文檔score加2。
score還需要考慮反向文檔頻率IDF的影響，最后得分可以不是整數。
反向文檔頻率：每個檢索詞在索引中出現的頻率。頻率越高，相關性越低。 檢索詞出現在多數文檔中會比出現在少數文檔中的權重更低， 即檢驗一個檢索詞在文檔中的普遍重要性。

Rebalance

當新增一個節點時，ES集群會自動把一些shard分配到這個新的節點

節點對等

每一個節點（包括master節點和data節點）都可以接收請求，如果要查詢的數據在當前節點的shard中不存在，那么會將請求路由到其他節點，其他節點查詢后將結果返回給原來的節點，最后返回給應用程序。

primary shard和replica shard

每一個document肯定只存在于一個primary shard和對應的replica shard中，不可能存在多個primary shard中。
primary shard在創建index時之后就不可以改變了，而replica shard可以在后續更改

ES容錯機制

當es集群中有一個節點宕機，并且這個節點包含primary shard，那么會把其余節點上對應的replica shard提升為primary shard

ES更新

es更新文檔時，當出現并發問題時，內部使用樂觀鎖，也就是說通過版本控制（也就是說version）的方式，解決并發沖突的問題。此外如果使用retry_on_confict=次數時會從新獲取最新版本的文檔數據，然后再去進行更新，如果失敗之后，會再次嘗試這一步驟，次數自己指定。

ES數據路由的原理

一個索引由多個primary shard構成。此時如果添加一個document，那么這個document一定會存儲在某一個primary shard中的，ES通過數據路由機制確定這個document存儲在那個shard中。
路由算法：
shard=hash(routing) % number_of_primary_shards
示例：一個索引，3個primary shard

當每次增刪改查時，有一個routing值，默認是文檔doc_id值

對這個routing值使用hash函數進行計算

算出的值再和primary_shards個數取余數
余數肯定在0~(number_of_primary_shards-1)之間，文檔就在對應的shard上
如果手動指定doc_id對負載均衡和提高批量讀寫的性能都有幫助

ES增刪改原理

示例：一個索引，三個分片，一個副本。
如下圖：當我們往ES中添加一條數據時，可以任選一個節點進行添加數據操作，假設我們往node1中添加數據，那么此時node1被稱為協調節點，因為我們要添加節點時，這個文檔不一定是要存在node1中，而是需要根據數據路由算法來決定這個數據應該往哪個分片存。

協調節點會根據數據路由算法，算出文檔應該存在哪個primary shard中。假設經過計算這條數據應該存在P1上。然后協調節點會將數據進行轉發，將數據轉發到node2中的P1上，到達P1后存儲數據，并把數據同步到副本R1上。
一系列操作之后，由協調節點對應用程序進行響應。

寫一致性原理和quorum機制

對es進行增刪改都數據寫操作，當進行寫操作時，可以使用參數consistency=
consistency的取值有以下三種：

• one：(primary shard) 只要有一個primary shard是活躍的就可以執行
• all：(all shard)所有的primary shard和replica shard都是活躍的才能執行
• quorum：(default)默認值，大部分shards是活躍的才能執行，(例如共有6個shard，至少有3個shard活躍時才能執行寫操作)

quorum機制：int((number_of_primary_shard + number_of_replica)/2) + 1
例如: 3個primary shard，1個replica
int((3+1)/2) + 1=3，因此至少要3個shard活躍時才可以寫操作。
案例：當只有一個node，一個primary shard，一個replica時，此時集群狀態時yellow，只有一個primary shard活躍，而quorum=(1+1)/2 + 1 = 2，因此此時無法進行增刪改操作。
案例：當我們有兩個node，一個primary shard，三個replica時，此時集群狀態是yellow，而quorum=(1+3)/2 + 1 = 3，因此此時同樣能無法進行增刪改操作。
當活躍的shard的個數沒有達到要求時，es默認會等待一分鐘，如果在等待時間內活躍的shard數量沒有增加，則顯示timeout。

文檔查詢原理

第一步：查詢請求發給任意一個節點，該節點就成了協調節點(coodinating node)，然后該節點使用路由算法算出文檔所在的primary shard
第二步：協調節點把請求轉發給primary shard也可以轉發給replica shard(使用輪訓算法(Round-Robin-Schedule)把請求平均分配給primary shard和replica shard)
第三步：處理請求的節點把結果返回給協調節點，協調節點再返回給應用程序
特殊情況：請求的文檔還在建立的過程中，primary shard上存在，而replica shard上不存在，但是請求被轉發到了replica shard中，這時就會提示找不到文檔。

返回數據根據設置的timeout來返回

當數據量比較大時，用戶可以設置返回多長時間的數據。雖然不能返回所有的數據，但是可以提高響應速度。不至于讓用戶等待太長時間，而返回所有數據。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的Elasticsearch kibana一些基本概念的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。