熟悉 MySQL 的同學一定都知道，MySQL 對于複雜條件查詢的支援并不好。MySQL 最多使用一個條件涉及的索引來過濾，然後剩餘的條件隻能在周遊行過程中進行記憶體過濾，對這個過程不了解的同學可以先行閱讀一下 《MySQL複雜where條件分析》 。
上述這種處理複雜條件查詢的方式因為隻能通過一個索引進行過濾，是以需要進行大量的 I/O 操作來讀取行資料，并消耗 CPU 進行記憶體過濾，導緻查詢性能的下降。
而 ElasticSearch 因其特性，十分适合進行複雜條件查詢，是業界主流的複雜條件查詢場景解決方案，廣泛應用于訂單和日志查詢等場景。
下面我們就一起來看一下，為什麼 ElasticSearch 适合進行複雜條件查詢。
ElasticSearch 簡介
Elasticsearch 是開源的實時分布式搜尋分析引擎，内部使用 Lucene 做索引與搜尋。它提供"準實時搜尋"能力，并且能動态叢集規模，彈性擴容。
Elasticsearch 使用 Lucene 作為其全文搜尋引擎，用于處理純文字的資料，但 Lucene 隻是一個庫，提供建立索引、執行搜尋等接口，但不包含分布式服務，這些正是 Elasticsearch 做的。
下面，我們來介紹一下 ElasticSearch 的相關概念。為了便于初學者了解，我們先将 ElasticSearch 中的概念和 MySQL 中的概念大緻地進行對應。但是二者在具體細節上還是有很多差異的，大家深入了解 ElasticSearch 就會将二者區厘清楚，不能強行對比等同。
- ElasticSearch 中的索引 Index 類似于 MySQL 中的資料庫 Database；
- ElasticSearch 中的類型 Type 類似于 MySQL 中的表 Table；需要注意，這個概念在 7.x 版本中被完全删除，而且概念上和 Table 也有較大差異；
- ElasticSearch 中的文檔 Document 類似于 MySQL 中的資料行 Row，每個文檔由多個字段 Filed 組成，這個Filed 就類似于 MySQL 的 Column；
- ElasticSearch 中的映射 Mapping 是對索引庫中的索引字段及其資料類型進行定義，類似于關系型資料庫中的表結構 Schema；
- ElasticSearch 使用自己的領域語言 Query DSL 來進行增删改查，而 MySQL 使用 SQL 語言進行上訴操作。
ElasticSearch 還有一系列有關其分布式特性的概念，我們這裡就暫不介紹了，等後續學習到其分布式特性時在進行介紹。
反向索引
MySQL 有 B+ 樹索引，而 ElasticSearch 則是反向索引 (Inverted Index)，它通過反向索引來實作比 MySQL 更快的過濾和複雜條件的查詢，此外，全文搜尋功能也是依賴反向索引才能實作。下面，我們就具體來看一下何為反向索引。
反向索引按照維基百科的描述，是存儲文檔内容到文檔位置映射關系的資料庫索引結構。不過隻看定義，我是有點迷惑，這不是和 MySQL 的非主鍵索引類似嘛，為什麼要叫它“倒排”呢？這個問題我目前也為搞清楚，可能要等到後續了解了其具體實作才能了解。
我們還是以書籍檢索為例，假設有以下資料，每一行就是一個 Document，每個 Document 由 id，ISBN 号，作者名稱和評分組成。
給上述資料按照 ISBN 和 Author 建立的反向索引如下所示。反向索引是每個字段分開建立的，互相獨立。有兩個專門的術語，分别是索引 Term 和倒排表 Posting List。字段的值就是 Term，比如 N0007，而 Term 對應的文檔 ID 的清單就是 Posting List，對應圖中紅色的部分。
一般 Term 都是按照順序排序的，比如 Author 名稱就是按照字母序進行了排序，排序之後，當我們搜尋某一個 Term 時，就不需要從頭周遊，而是采用二分查找。一系列排序後的 Term 就組成了索引表 Term Dictionary。
但是 Term Dictionary 往往很大，無法完整放入記憶體，這是為了更快的查詢，還需要再給它建立索引，也就是 Term Index 。
ElasticSearch 使用 Burst-Trie 結構來實作 Term Index，它是一種字首樹 Trie 的一種變種，它主要是将字尾進行了壓縮，降低了Trie的高度，進而擷取更好查詢性能。
Term Index 并不需要像 MySQL 的索引一樣，包含所有的 Term，而是包含的是這些 Term 的字首。它就類似于字典的查詢目錄，可以進行快速定位到 Term Dictionary 的某一位置，然後再從這個位置向後查詢。
綜上， Alice，Alf，Arlan，Bob，Tom 等詞的反向索引如下所示。綠色部分是 Term Index，藍色部分是 Term Dictionary，紅色部分是 Posting List。
一般來說，Term Index 都是全部緩存在記憶體中，查詢時，先通過其快速定位到 Term Dictionary 對應的大緻範圍，然後再進行磁盤讀取查找對應的 Term，這樣就大大減少了磁盤 I/O 的次數。
聯合索引查詢
了解了 ElasticSearch 的反向索引後，我們再來看看其如何處理複雜的聯合索引查詢。比如上述書籍例子中，我們需要查詢評分等于2.2并且作者名稱叫 Tom的書籍。
理論上，我們隻需要分别按照 Score 和 Author 字段的反向索引進行查詢，擷取響應的 Posting List，再将其做交集合并即可。
這裡又要吐槽一下 MySQL，它是不支援這個合并操作的，它隻能按照一個字段的索引進行查詢，然後根據另外一個字段的條件做記憶體過濾。順便說一下，MySQL 的 join 功能也弱爆了，感興趣的同學可以了解一下
這篇文章而 ElasticSearch 則支援使用跳表 Skip List和 Bitset 的方式将資料集進行合并。
- 使用 Skip List 結構，同時周遊 Score 和 Author 查詢出來的 Posting List，利用其 Skip List 結構，互相跳躍對比，得出合集。
- 使用 Bitset 結構，對 Score 和 Author 查詢出來的 Posting List 的值計算出各自的 Bitset，然後進行 AND 操作。
跳表合并政策
ElasticSearch 在存儲 Posting List 資料時，就儲存了對應的多級跳表結構響應的資料，這也展現了其空間換時間的基本思想。
這裡先介紹一下跳表的基本概念，它其實是一種可以進行二分查找的有序連結清單。跳表在原有的有序連結清單上面增加了多級索引，通過索引來實作快速查找。首先在最進階索引上查找最後一個小于目前查找元素的位置，然後再跳到次進階索引繼續查找，直到跳到最底層為止，通過這種方式，加快了查詢的速度。
比如，按照 Score 查出來的 Posting List 為[2,3,4,5,7,9,10,11]，按照 Author 查出來的結果為 [3,8,9,12,13]，則二者的跳表結構如下圖所示。
具體合并過程則是先選最短的 posting list，也就是 Author 的結果集，從其最小的一個 id 開始，将其作為目前最大值。然後依次剩餘 posting list 中查找大于或等于該值的位置。
比如上述結果集中，先去 Score 結果集中查找 3，找到後，就表明 3是二者的合集元素之一；然後再重新開啟一輪，選取 Author 結果集中 3 的下一個值 8 ，去 Score 結果集查詢 8，發現了大于等于 8 的最小的值是 9 ，是以不可能有共同的值 8，然後再去 Author 結果集查找 9 ，發現其大于等于 9 的最小值是 12，是以再去 Score 結果集中查找大于等于 12的值，發現并不存在；最終得出二者的合集就隻有[3]。
在查詢過程中，每個 posting list 都可以根據目前 id 通過 skip list 快速跳過不符合的 id 值，加速整個合并取交集的過程。
ElasticSearch 對于較長的 posting list 也會使用 Frame Of Reference 進行壓縮編碼，減少了磁盤占用，減少了索引尺寸。有關具體存儲結構的實作我們後續再進行細聊。
Bitset 合并政策
ElasticSearch除了使用 skipList 來進行資料磁盤讀取時的合并操作外，還會将一些查詢條件對應的結果集 posting list 進行記憶體緩存，也就是所謂的 Filter Cache，為了後續再次複用。
為了減少記憶體緩存所消耗的記憶體空間大小，ElasticSearch 沒有使用單純的數組和 bitset 來存儲 posting list，而是使用要壓縮效率更高的 Roaring Bitmap。
我們可以先來講一下單純數組或 bitset 資料結構為什麼并不使用。比如如下一道較為常見的面試題目：
給定含有40億個不重複的位于[0, 2^32 - 1]區間内的整數的集合，如何快速判定某個數是否在該集合内？
如果我們要使用 unsigned long 數組來存儲它的話，也就需要消耗 40億 * 32 位 = 160 Byte，大緻是 16000 MB。
如果要使用位圖 Bitset 來存儲的話，即某個數位于原集合内，就将它對應的位圖内的比特置為1，否則保持為0。這樣隻需要消耗 2 ^ 32 位 = 512 MB，這可隻有原來的 3.2 % 左右。
但是，Bitset 也有其缺陷，也就是稀疏存儲的問題，比如上述集合并不是 40億，而是隻有2，3個，那麼 Bitset 中隻有少數幾位是1，其他位都是 0，但是它仍然占用了 512 MB。
而 RoaringBitmap 就是為了解決稀疏存儲的問題。下圖就是 RoaringBitmap 的基本原理示意圖。
首先，如上圖所示，計算出32位無符号整數和 65536 的除數和餘數。其含義表示，将32位無符号整數按照高16位分桶，即最多可能有2^16=65536個桶，術語懲治為 container。存儲資料時，按照資料的高16位找到 container（找不到就會建立一個），再将低16位放入container中。也就是說，一個 RoaringBitmap 就是很多container的集合。
然後 container 内具體的存儲結構要根據存入其内資料的基數來決定。
- 基數小于 2 ^ 12 次方即 4096時，使用unsigned short類型的有序數組來存儲，最大消耗空間就是 8 KB。
- 基數大于 4096 時，則使用大小為 2 ^ 16 次方的普通 bitset 來存儲，固定消耗 8 KB。當然，有些時候也會對 bitset 進行行程長度編碼（RLE）壓縮，進一步減少空間占用。
ElasticSearch 就是使用 Roaring Bitmap 來緩存不同條件查詢出來的 posting list，然後再進行與操作計算出最終結果集。
後記
至此，我們也算了解了 ElasticSearch 為什麼比 MySQL 更适合複雜條件查詢，但是有好就有弊，因為為了查詢做了這麼多的準備工作，ElasticSearch 的插入速度就會慢于 MySQL，而且資料存入ES後并不是立馬就能檢索到。
歡迎持續關注曆小冰，後續繼續為大家分享 MySQL、Redis 和 ElasticSearch 等資料庫相關的原理和實踐經驗。