1、ES基礎概念

• 搜索引擎 search engine

• 近實時 (Near) Real Time Search

• RESTful API

• 分布式、高可用

• 面向文檔存儲，json格式

• 基于Apache Lucene

2、核心概念

• Cluster 集群

• Node 構成集群的單機節點

• Index 索引

• Shard 分片

• Replica 副本

• Segment 分段

• Document 文檔

• Field 字段

• Inverted Index 倒排索引

• Text / Keyword 類型

3、使用全流程

schema(mapping)

es不需要前置的schema定義，在索引doc時確定schema

因為es數據的交互形式是json，所以doc可以開箱即用，在寫入doc時如果沒有預先定義的mapping，doc的每一個field會根據傳過來的json數據確定類型，默認規則（dynamic field mapping）如下：

json類型	es類型
null	不會增加field
boolean	boolean
string	date(通過Date detection)double/long (通過Numeric detection)text(帶keyword的sub field)
number	float/long
object	Object
array	array(array的item類型取決于第一個非null元素的類型)

同時es還支持定義模板 dynamic_template，來對默認的規則進行擴充、修改，例如下例就是修改了默認的string映射：

{"mappings": {"dynamic_templates": [{"strings_as_keywords": {"match_mapping_type": "string","mapping": {"type": "text"}}}]}

如果沒有動態字段的需求，不建議使用es的dynamic mapping，使用不當的話會污染mapping，所以可以指定 dynamic為false來關閉動態mapping。

當然可以使用put mapping api來預定義index的mapping結構，包括字段類型、使用的分析器(text類型)、是否索引等等。

es官方也非常推薦將相同的字段以不同的方式索引到es中，例如一個字符串類型的值可以使用索引成text類型來進行全文檢索，也可以索引成keyword類型進行排序、聚合。

建議使用別名（alias），es對mapping的拓展是開放的，但對mapping的修改是禁止的。例如，可以為mapping增加一個字段，但是不能刪除/修改字段。所以使用alias指向真正的index，這樣，在有field需要修改的場景可以使用reindex api重建索引、再使用alias api更改指向，可以實現無縫的切換。

數據寫入

分布式寫入流程

可以看到，es寫入的總延時等于寫入主節點的時間+max(寫入從節點的時間)。

Shard 寫入流程

比較重要的三個概念

• refresh

• flush

• fsync todo：是否會丟數據

寫入優化

• 使用bulk api批量操作

• 調整refresh_interval的間隔，es在每一次refresh時都會創建lucene的segment，并嘗試進行segment的合并，開銷較大，若對搜索的實時性要求不高，可以適當的調大refresh_interval的大小

• 不需要索引的字段指定index屬性為not_analyzed

• SSD（經典性能不行，硬件來湊）

讀取

Search

使用search api可以很方便的實現數據的檢索。es提供了很多search api，例如match_query,term_query等等，可以很方便的組裝query DSL(Domain Specific Language)，且開發人員不需要考慮DSL中query的順序，dsl中query的順序不會影響最后的執行效率，真正的執行順序會在CBO(Cost Based Optimizer)后進行重排。

• term index 使用FST(Finite State Machines) -> 定位倒排鏈

• SkipList -> 合并倒排鏈

Aggregation

• Metrics 將query命中的數據集進行count,max等操作，是一個單一的數值

• Bucket 將query命中的數據集再按條件分為更小的數據集合，再在這些小集合上執行Metrics，可以類比于sql中的group by

Sort

不要使用text字段作為排序字段，text字段一般用分析器進行分詞，對text字段做排序往往得不到預期的結果

ES返回的doc默認會按照_score（文檔相關性）降序排列，即算分后的分數值，如果指定了其他的Sort字段，就會按照指定的字段排序。同樣支持script，來構造比較復雜的排序規則。

_score，評分的計算依賴于不同的query方式，例如對于fuzzy查詢會計算與檢索詞拼寫的相關程度，term查詢會計算內容和關鍵詞間的百分比等等。但是一般意義上我們說的全文搜索是指計算內容與關鍵詞的相關程度，ElasticSearch的相似度算法使用 TF/IDF，即詞頻/逆文檔頻率，包括以下內容：

• 詞頻：檢索詞在該字段出現的頻率。出現頻率越高，相關性也越高。字段中出現過5次要比只出現過1次的相關性高。

• 逆文檔頻率：每個檢索詞在索引中出現的頻率。頻率越高，相關性越低。檢索詞出現在多數文檔中會比出現在少數文檔中的權重更低， 即檢驗一個檢索詞在文檔中的普遍重要性。

• 字段長度準則?：?字段的長度是多少？長度越長，相關性越低。檢索詞出現在一個短的 title 要比同樣的詞出現在一個長的 content 字段相關性更高。

Page

1.基于offset的分頁

• from + size，from指定偏移量，size指定要取的數據條數

• 執行原理：

client發起請求，收到請求的shard成為協調節點，負責后續請求數據的合并

執行query，取到from+size大小的結果集，協調節點本地構建構建大小為from+size的priority queue ，協調節點將請求分發到其他shard

其他shard 同樣執行query，取到from+size大小的結果集，將集合返給協調節點

協調節點合并結果集，最后得到from+size大小的priority queue，將后size個數據返給client

• 特點：支持隨機分頁訪問 不適合用在feed無限下拉場景，在分頁的邊界可能存在數據重復的可能性 隨著from的增大，開銷也逐漸增大，不適合深度分頁的場景

2.基于cursor的分頁 scroll

• 針對這次請求將符合條件的所有結果匯集到協調節點緩存起來，后續直接從協調節點的緩存中取出

• 由于緩存的存在，文檔后續的變更并不會同步到緩存中，并不適合實時請求

• 同樣因為緩存的數據量為query命中的所有doc，所以scroll的堆內存開銷是非常大的

• 適用于索引的重建/數據的遷移等非實時、低頻的場景

3.search_after

• 使用上一頁的檢索結果來幫助檢索下一頁，排序字段里要包括doc的唯一標識，以保證search_after的一致性

• 每一個shard請求的數據集大小為size

• 不支持隨機分頁訪問

• 實時處理，若doc有變更且影響到了排序因子，有可能出現重復數據

讀取優化

• 沒有范圍查找需求的number類型字段，類型定義為keyword

• 慎用wildcard query，盡量使用分詞后的結果使用match query，有使用wildcard query的需求，注意字符轉義

• 搜索詞的長度要做限制

• feed流場景使用search_after

• 不需要得分的字段用filter context替換query content，query和filter區別

IT技術分享社區

個人博客網站：https://programmerblog.xyz

文章推薦程序員效率：畫流程圖常用的工具程序員效率：整理常用的在線筆記軟件遠程辦公：常用的遠程協助軟件，你都知道嗎？51單片機程序下載、ISP及串口基礎知識硬件：斷路器、接觸器、繼電器基礎知識

總結

以上是生活随笔為你收集整理的ElasticSearch知识点整理，值得收藏！的全部內容，希望文章能夠幫你解決所遇到的問題。

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