圖解 Elasticsearch

阿新 • • 發佈：2019-01-10

內容
- 圖解ElasticSearch
- 圖解Lucene
- 搜尋發生時
- 快取的故事
- 在Shard中搜索
- 如何Scale
- 一個真實的請求
參考

摘要

先自上而下，後自底向上的介紹ElasticSearch的底層工作原理，試圖回答以下問題：

為什麼我的搜尋 *foo-bar* 無法匹配 *foo-bar* ？
為什麼增加更多的檔案會壓縮索引（Index）？
為什麼ElasticSearch佔用很多記憶體？

版本

elasticsearch版本: elasticsearch-2.2.0

內容

圖解ElasticSearch

雲上的叢集

叢集裡的盒子

雲裡面的每個白色正方形的盒子代表一個節點——Node。

節點之間

在一個或者多個節點直接，多個綠色小方塊組合在一起形成一個ElasticSearch的索引。

索引裡的小方塊

在一個索引下，分佈在多個節點裡的綠色小方塊稱為分片——Shard。

Shard＝Lucene Index

一個ElasticSearch的Shard本質上是一個Lucene Index。

Lucene是一個Full Text 搜尋庫（也有很多其他形式的搜尋庫），ElasticSearch是建立在Lucene之上的。接下來的故事要說的大部分內容實際上是ElasticSearch如何基於Lucene工作的。

圖解Lucene

Mini索引——segment

在Lucene裡面有很多小的segment，我們可以把它們看成Lucene內部的mini-index。

Segment內部

有著許多資料結構

Inverted Index
Stored Fields
Document Values
Cache

最最重要的Inverted Index

Inverted Index主要包括兩部分：

一個有序的資料字典Dictionary（包括單詞Term和它出現的頻率）。
與單詞Term對應的Postings（即存在這個單詞的檔案）。

當我們搜尋的時候，首先將搜尋的內容分解，然後在字典裡找到對應Term，從而查詢到與搜尋相關的檔案內容。

查詢“the fury”

自動補全（AutoCompletion-Prefix）

如果想要查詢以字母“c”開頭的字母，可以簡單的通過二分查詢（Binary Search）在Inverted Index表中找到例如“choice”、“coming”這樣的詞（Term）。

昂貴的查詢

如果想要查詢所有包含“our”字母的單詞，那麼系統會掃描整個Inverted Index，這是非常昂貴的。

在此種情況下，如果想要做優化，那麼我們面對的問題是如何生成合適的Term。

問題的轉化

對於以上諸如此類的問題，我們可能會有幾種可行的解決方案：

* suffix -> xiffus *

如果我們想以後綴作為搜尋條件，可以為Term做反向處理。
(60.6384, 6.5017) -> u4u8gyykk

對於GEO位置資訊，可以將它轉換為GEO Hash。
123 -> {1-hundreds, 12-tens, 123}

對於簡單的數字，可以為它生成多重形式的Term。

解決拼寫錯誤

一個Python庫為單詞生成了一個包含錯誤拼寫資訊的樹形狀態機，解決拼寫錯誤的問題。

Stored Field欄位查詢

當我們想要查詢包含某個特定標題內容的檔案時，Inverted Index就不能很好的解決這個問題，所以Lucene提供了另外一種資料結構Stored Fields來解決這個問題。本質上，Stored Fields是一個簡單的鍵值對key-value。預設情況下，ElasticSearch會儲存整個檔案的JSON source。