圖解 Elasticsearch 原理
摘要
先自上而下，後自底向上的介紹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。
Document Values為了排序，聚合
即使這樣，我們發現以上結構仍然無法解決諸如：排序、聚合、facet，因為我們可能會要讀取大量不需要的資訊。
所以，另一種資料結構解決了此種問題：Document Values。這種結構本質上就是一個列式的儲存，它高度優化了具有相同型別的資料的儲存結構。
為了提高效率，ElasticSearch可以將索引下某一個Document Value全部讀取到記憶體中進行操作，這大大提升訪問速度，但是也同時會消耗掉大量的記憶體空間。
總之，這些資料結構Inverted Index、Stored Fields、Document Values及其快取，都在segment內部。
搜尋發生時
搜尋時，Lucene會搜尋所有的segment然後將每個segment的搜尋結果返回，最後合併呈現給客戶。
Lucene的一些特性使得這個過程非常重要：
-
Segments是不可變的（immutable）
-
Delete? 當刪除發生時，Lucene做的只是將其標誌位置為刪除，但是檔案還是會在它原來的地方，不會發生改變
-
Update? 所以對於更新來說，本質上它做的工作是：先刪除，然後重新索引（Re-index）
-
隨處可見的壓縮
Lucene非常擅長壓縮資料，基本上所有教科書上的壓縮方式，都能在Lucene中找到。
-
快取所有的所有
Lucene也會將所有的資訊做快取，這大大提高了它的查詢效率。
快取的故事
當ElasticSearch索引一個檔案的時候，會為檔案建立相應的快取，並且會定期（每秒）重新整理這些資料，然後這些檔案就可以被搜尋到。
隨著時間的增加，我們會有很多segments，
所以ElasticSearch會將這些segment合併，在這個過程中，segment會最終被刪除掉
這就是為什麼增加檔案可能會使索引所佔空間變小，它會引起merge，從而可能會有更多的壓縮。
舉個栗子
有兩個segment將會merge
這兩個segment最終會被刪除，然後合併成一個新的segment
這時這個新的segment在快取中處於cold狀態，但是大多數segment仍然保持不變，處於warm狀態。
以上場景經常在Lucene Index內部發生的。
在Shard中搜索
ElasticSearch從Shard中搜索的過程與Lucene Segment中搜索的過程類似。
與在Lucene Segment中搜索不同的是，Shard可能是分佈在不同Node上的，所以在搜尋與返回結果時，所有的資訊都會通過網路傳輸。
需要注意的是：
1次搜尋查詢2個shard ＝ 2次分別搜尋shard
對於日誌檔案的處理
當我們想搜尋特定日期產生的日誌時，通過根據時間戳對日誌檔案進行分塊與索引，會極大提高搜尋效率。
當我們想要刪除舊的資料時也非常方便，只需刪除老的索引即可。
在上種情況下，每個index有兩個shards
如何Scale
shard不會進行更進一步的拆分，但是shard可能會被轉移到不同節點上
所以，如果當叢集節點壓力增長到一定的程度，我們可能會考慮增加新的節點，這就會要求我們對所有資料進行重新索引，這是我們不太希望看到的，所以我們需要在規劃的時候就考慮清楚，如何去平衡足夠多的節點與不足節點之間的關係。
節點分配與Shard優化
-
為更重要的資料索引節點，分配效能更好的機器
-
確保每個shard都有副本資訊replica
路由Routing
每個節點，每個都存留一份路由表，所以當請求到任何一個節點時，ElasticSearch都有能力將請求轉發到期望節點的shard進一步處理。
一個真實的請求
Query
Query有一個型別filtered，以及一個multi_match的查詢
Aggregation
根據作者進行聚合，得到top10的hits的top10作者的資訊
請求分發
這個請求可能被分發到叢集裡的任意一個節點
上帝節點
這時這個節點就成為當前請求的協調者（Coordinator），它決定：
-
根據索引資訊，判斷請求會被路由到哪個核心節點
-
以及哪個副本是可用的
-
等等
路由
在真實搜尋之前
ElasticSearch 會將Query轉換成Lucene Query
然後在所有的segment中執行計算
對於Filter條件本身也會有快取
但queries不會被快取，所以如果相同的Query重複執行，應用程式自己需要做快取
所以，
-
filters可以在任何時候使用
-
query只有在需要score的時候才使用
返回
搜尋結束之後，結果會沿著下行的路徑向上逐層返回。
參考
SlideShare: Elasticsearch From the Bottom Up
Youtube: Elasticsearch from the bottom up
Wiki: Document-term matrix
Wiki: Search engine indexing
Skip list
Standford Edu: Faster postings list intersection via skip pointers
StackOverflow: how an search index works when querying many words?
StackOverflow: how does lucene calculate intersection of documents so fast?
Lucene and its magical indexes
misspellings 2.0c: A tool to detect misspellings