Elasticsearch基本概念和索引原理
我是啤酒就辣條。
但行好事，莫問前程。
Elasticsearch是什麼？
Elasticsearch是一個基於文件的NoSQL資料庫，是一個分散式、RESTful風格的搜尋和資料分析引擎，同時也是Elastic Stack的核心，集中儲存資料。Elasticsearch、Logstash、Kibana經常被用作日誌分析系統，俗稱ELK。
說白了，就是一個數據庫，搜尋賊快(但是插入更新較慢，要不然其他資料庫別玩了)。速度快，還可以進行分詞，非常適合做搜尋，例如商城的商品搜尋。為什麼快，後面講原理的時候會說，不單單是快取的問題，原理非常精彩。而且它是nosql的，資料格式可以隨便造。Elasticsearch還為我們提供了豐富的RESTful風格的API，寫程式碼的成本極低。最後它支援分散式，高效能(搜尋快)，高可用(某些節點宕機可以接著用)，可伸縮(可以方便的增加節點，解決實體記憶體上線問題)，適合分散式系統開發。
Elasticsearch基本概念
為了快速瞭解Elasticsearch(後面可能會簡稱為ES)，可以與mysql幾個概念做個對比。
| Elasticsearch | Mysql |
|---|---|
| 欄位(Filed) | 屬性(列) |
| 文件(Document) | 記錄(行) |
| 型別(Type) | 表 |
| 索引(Index) | 資料庫 |
是不是清楚多了？我們說Elasticsearch是基於文件的，就是因為記錄元素(被搜尋的最小單位)是文件。例如下面就是一個文件，
{ "email": "[email protected]", "first_name": "John", "last_name": "Smith", "info": { "bio": "Eco-warrior and defender of the weak", "age": 25, "interests": [ "dolphins", "whales" ] }, "join_date": "2014/05/01" }
文件格式看起來很像Json吧。email、first_name等等就是Filed。由於結構是Json，所以value值就很方便放任意型別，這就是nosql的好處。
文件(Document)
ES中的一個物件將來會和Java程式碼中的一個物件對應。文件的每一個Filed可以是任意型別，但是一旦某索引(Index)(我們描述的時候，略過Type，但是Type依然存在)中插入了一個文件，某Filed被第一次使用，ES就會設定好此Filed的型別。例如你插入user的name是字串型別，以後再插入文件，name欄位必須是字串型別。所以，建議在插入文件之前，先設定好每個Filed的型別。
如果插入文件的時候，不指定id，ES會幫助我們自動生成一個id，建議id是數字型別，這樣搜尋會快速很多。商城系統中的商品id建議使用雪花演算法生成，這樣既避免了自增id的安全性問題，又解決了字串id檢索慢的問題。
型別(Type)
關於Type，型別概念,在6.x版本中，一個索引(Index)可以擁有多個Type。在7.x版本(目前最新版本)，一個索引只能擁有一個Type，預設的type就是_doc，在7.x版本中，已經建議刪除了。在未來的8.x版本會徹底刪除。但是在7.x版本中，一個文件還必須歸屬於一個型別。
索引(Index)
都說ES中的索引類似於mysql中的資料庫，我覺得未來索引有成為mysql中表概念的潛質。我們把相同特徵(Filed數量和型別基本相同)的文件放到同一個索引(index)裡面。這樣方便提前通過mapping來規定各個Filed的型別。另外，索引名稱必須全部小寫，所以不建議寫成駝峰式。
節點(Node)與分片(Shard)
由於生產環境下ES基本都是叢集部署的，所以一定少不了節點的概念，一個節點就是一個ES例項，就是一個Java程序，這些Java程序部署在不同的伺服器上，增加ES可用性。
ES節點根據功能可以分為三種：
- 主節點：職責是和叢集操作相關的內容，如建立或刪除索引，跟蹤哪些節點是群集的一部分，並決定哪些分片分配給相關的節點。每個節點都可訪問叢集的狀態，但是隻有主節點可以修改叢集的狀態。
- 資料節點：資料節點主要是儲存資料的節點，對文件進行增刪改查，聚合操作等等，資料節點對cpu，記憶體，io要求較高，當資源不夠的時候，可以增加新的節點，很方便的進行資料拓展。
- 客戶端節點：本節點主要處理路由請求，分發索引的操作。實際上主節點和資料節點也有路由轉發的功能，但是為了提高效率，還是建議生產環境單獨建立客戶端節點。
分片類似於mysql中的分表，在一個索引拆分成幾個小索引，分佈在不同的節點(不同伺服器)上，每個小索引都具有完備的功能，當客戶端發來請求的時候，客戶端節點找到合適的分片上的小索引，進行資料查詢，這一過程對於使用者來說都是透明的，使用者表面上看只是在操作一個索引。利用分片，可以避免單個節點的物理限制，還可以增加吞吐量。建議最開始一個索引要用多少分片設計好，因為修改分片數量是個相當麻煩的過程。
作為分散式的資料庫，ES必須為咱們提供資料冗餘功能，這就是分片副本，就是將某個分片copy一份放到其他節點上。注意，這裡分片和分片副本必須在不同的節點上！分片副本也可以提高吞吐量。分片副本不同於分片，可以很方便的進行修改。
說完了所有概念，再去看本節最開始那張圖，有一個索引，分了3分片在三個節點上，並且每個分片在不同的節點上有分片副本。
Elasticsearch索引原理
看完上面的內容，你對Elasticsearch有了基本的認識，再去看基本操作(我後面要寫一篇基操部落格)，就可以在專案中使用Elasticsearch了。此刻你可以喘口氣，以放鬆的心態看後面的內容。下面我們就講講索引為什麼快？
首先，我們知道mysql底層資料結構使用的是B+Tree，這種BTree，將搜尋時間複雜度變成了logN，已經很快了，我們Elasticsearch要比它還快。Elasticsearch是怎麼做的呢？首先儲存結構要優化，然後再提高下和磁碟的互動效率。
先說Elasticsearch索引結構，叫做倒排索引，啥是倒排索引呢？它的大概邏輯如下：
為了講清楚這個概念，我們先看個例子，如下為我們user的資料：
| ID | Name | Age |
|---|---|---|
| 1 | Kate | 24 |
| 2 | John | 24 |
| 3 | Bill | 29 |
| 4 | Kate | 26 |
| 5 | Brand | 29 |
Elasticsearch會為以上資料建立兩個索引樹:
| Term | Posting List |
|---|---|
| Kate | 1,4 |
| Brand | 5 |
| John | 2 |
| Bill | 3 |
| Term | Posting List |
|---|---|
| 24 | 1,2 |
| 26 | 4 |
| 29 | 3,5 |
以上的索引樹就叫做倒排索引，每個Filed欄位對應著一組Term，每個Term後面跟著的id(還記著嗎，這個主鍵使用者不指定就會自動生成，所以一定存在)就是Posting List，它是一組id，有了id再去磁碟中對應的文件就so fast了。
你有沒有發現，Term如果按序找會快點，將Term按序排，在進行二分查詢，是不是速度就跟BTree一樣了，時間複雜度為LogN。這個有序的Term組就是Term Dictionary。
那麼問題又來了，比如說資料庫中有name字首為A的同學1000萬個，字首為Z的同學有3個，我要查字首為Z的同學，那二分查詢不也很多次嗎，所以，Elasticsearch把每個開頭的地方標記一下，拿出來，再放到一顆樹裡，速度不是就快了嘛。這棵樹就是Term Index。Term Index字首不一定是第一個字元，比如A、Ab、Abz，這種都可以在Term Index樹裡。並且Term Dictionary可能會太大，會被放到磁碟中，避免記憶體佔用太多。
再看下面這張結構圖是不是清楚多了。
由於Term Index被放到記憶體中，所以最好壓縮一下，減少記憶體使用，壓縮使用的是FST，這個東西講起來比較複雜，反正就是能壓縮，記憶體變小就好了。
Term壓縮完了，那麼Posting List是不是也可以壓縮一下，省省空間啊？既然都是id，使用過redis的同學瞬間會想到bitMap，就是有個巨大的陣列，儲存著0或1，有就是1，沒有就是0。例如上面的3、5放在BitMap中就是 1，0，1，0，0，0。雖說空間已經明顯小多了，但是如果一個Posting List只儲存著1，10000001這兩個id，最後產生的數字是不是過大呢。於是乎，Roaring bitmaps就出來了，進行了一次指數降級，簡單點說就是取商和餘數儲存，被除數是65535。例如 1000，62101，131385，196658， 這幾個id，首先分組，分組規則就是商一樣，例如上面id可分組為[(0,1000),(0,62101)],[],[(2,6915)],[(3,53)]。注意，沒有商為1的值，我用空陣列表示。此時，將某個組中的數字放到一個bitmap中。