查詢億級資料毫秒級傳回！ElasticSearch是如何做到的,為什麼那麼快？

一道面試題的引入：

如果面試的時候碰到這樣一個面試題：ElasticSearch（以下簡稱ES） 在資料量很大的情況下（數十億級别）如何提高查詢效率？

這個問題說白了，就是看你有沒有實際用過 ES，因為啥？其實 ES 性能并沒有你想象中那麼好的。

很多時候資料量大了，特别是有幾億條資料的時候，可能你會懵逼的發現，跑個搜尋怎麼一下 5~10s，坑爹了。

第一次搜尋的時候，是 5~10s，後面反而就快了，可能就幾百毫秒。

然後你就很懵，每個使用者第一次通路都會比較慢，比較卡麼？是以你要是沒玩兒過 ES，或者就是自己玩玩兒 Demo，被問到這個問題容易懵逼，顯示出你對 ES 确實玩的不怎麼樣？

說實話，ES 性能優化是沒有銀彈的。啥意思呢？就是不要期待着随手調一個參數，就可以萬能的應對所有的性能慢的場景。

也許有的場景是你換個參數，或者調整一下文法，就可以搞定，但是絕對不是所有場景都可以這樣。

性能優化的殺手锏：Filesystem Cache

你往 ES 裡寫的資料，實際上都寫到磁盤檔案裡去了，查詢的時候，作業系統會将磁盤檔案裡的資料自動緩存到 Filesystem Cache 裡面去。

整個過程，如下圖所示：

ES 的搜尋引擎嚴重依賴于底層的 Filesystem Cache，你如果給 Filesystem Cache 更多的記憶體，盡量讓記憶體可以容納所有的 IDX Segment File 索引資料檔案，那麼你搜尋的時候就基本都是走記憶體的，性能會非常高。

性能差距究竟可以有多大？我們之前很多的測試和壓測，如果走磁盤一般肯定上秒，搜尋性能絕對是秒級别的，1 秒、5 秒、10 秒。

但如果是走 Filesystem Cache，是走純記憶體的，那麼一般來說性能比走磁盤要高一個數量級，基本上就是毫秒級的，從幾毫秒到幾百毫秒不等。

來看一個真實的案例：某個公司 ES 節點有 3 台機器，每台機器看起來記憶體很多 64G，總記憶體就是 64 * 3 = 192G。

每台機器給 ES JVM Heap 是 32G，那麼剩下來留給 Filesystem Cache 的就是每台機器才 32G，總共叢集裡給 Filesystem Cache 的就是 32 * 3 = 96G 記憶體。

而此時，整個磁盤上索引資料檔案，在 3 台機器上一共占用了 1T 的磁盤容量，ES 資料量是 1T，那麼每台機器的資料量是 300G。

這樣性能好嗎？ 

Filesystem Cache 的記憶體才 100G，十分之一的資料可以放記憶體，其他的都在磁盤，然後你執行搜尋操作，大部分操作都是走磁盤，性能肯定差。

歸根結底，你要讓 ES 性能好，最佳的情況下，就是你的機器的記憶體，至少可以容納你的總資料量的一半。

根據我們自己的生産環境實踐經驗，最佳的情況下，是僅僅在 ES 中就存少量的資料。

也就是說，你要用來搜尋的那些索引，如果記憶體留給 Filesystem Cache 的是 100G，那麼你就将索引資料控制在 100G 以内。這樣的話，你的資料幾乎全部走記憶體來搜尋，性能非常之高，一般可以在1秒以内。

比如說你現在有一行資料：id，name，age .... 30 個字段。但是你現在搜尋，隻需要根據 id，name，age 三個字段來搜尋。

如果你傻乎乎往 ES 裡寫入一行資料所有的字段，就會導緻 90% 的資料是不用來搜尋的。

但是呢，這些資料硬是占據了 ES 機器上的 Filesystem Cache 的空間，單條資料的資料量越大，就會導緻 Filesystem Cahce 能緩存的資料就越少。

其實，僅僅寫入 ES 中要用來檢索的少數幾個字段就可以了，比如說就寫入 es id，name，age 三個字段。

然後你可以把其他的字段資料存在 MySQL/HBase 裡，我們一般是建議用 ES + HBase 這麼一個架構。

HBase是列式資料庫，其特點是适用于海量資料的線上存儲，就是對 HBase 可以寫入海量資料，但是不要做複雜的搜尋，做很簡單的一些根據 id 或者範圍進行查詢的這麼一個操作就可以了。

從 ES 中根據 name 和 age 去搜尋，拿到的結果可能就 20 個 doc id，然後根據 doc id 到 HBase 裡去查詢每個 doc id 對應的完整的資料，給查出來，再傳回給前端。

而寫入 ES 的資料最好小于等于，或者是略微大于 ES 的 Filesystem Cache 的記憶體容量。

然後你從 ES 檢索可能就花費 20ms，然後再根據 ES 傳回的 id 去 HBase 裡查詢，查 20 條資料，可能也就耗費個 30ms。

如果你像原來那麼玩兒，1T 資料都放 ES，可能會每次查詢都是 5~10s，而現在性能就會很高，每次查詢就是 50ms。

資料預熱

假如你就按照上述的方案去做了，ES 叢集中每個機器寫入的資料量還是超過了 Filesystem Cache 一倍。

比如說你寫入一台機器 60G 資料，結果 Filesystem Cache 就 30G，還是有 30G 資料留在了磁盤上。

這種情況下，其實可以做資料預熱。舉個例子，拿微網誌來說，你可以把一些大 V，平時看的人很多的資料，提前在背景搞個系統。

然後每隔一會兒，自己的背景系統去搜尋一下熱資料，刷到 Filesystem Cache 裡去，後面使用者實際上來看這個熱資料的時候，他們就是直接從記憶體裡搜尋了，很快。

或者是電商，你可以将平時檢視最多的一些商品，比如說 iPhone 8，熱資料提前背景搞個程式，每隔 1 分鐘自己主動通路一次，刷到 Filesystem Cache 裡去。

總之，就是對于那些你覺得比較熱的、經常會有人通路的資料，最好做一個專門的緩存預熱子系統。

然後對熱資料每隔一段時間，就提前通路一下，讓資料進入 Filesystem Cache 裡面去。這樣下次别人通路的時候，性能一定會好很多。

冷熱分離

ES 可以做類似于 MySQL 的水準拆分，就是說将大量的通路很少、頻率很低的資料，單獨寫一個索引，然後将通路很頻繁的熱資料單獨寫一個索引。

最好是将冷資料寫入一個索引中，然後熱資料寫入另外一個索引中，這樣可以確定熱資料在被預熱之後，盡量都讓他們留在 Filesystem OS Cache 裡，别讓冷資料給沖刷掉。

還是來一個例子，假設你有 6 台機器，2 個索引，一個放冷資料，一個放熱資料，每個索引 3 個 Shard。3 台機器放熱資料 Index，另外 3 台機器放冷資料 Index。

這樣的話，你大量的時間是在通路熱資料 Index，熱資料可能就占總資料量的 10%，此時資料量很少，幾乎全都保留在 Filesystem Cache 裡面了，就可以確定熱資料的通路性能是很高的。

但是對于冷資料而言，是在别的 Index 裡的，跟熱資料 Index 不在相同的機器上，大家互相之間都沒什麼聯系了。

如果有人通路冷資料，可能大量資料是在磁盤上的，此時性能差點，就 10% 的人去通路冷資料，90% 的人在通路熱資料，也無所謂了。

ES中的關聯查詢

對于 MySQL，我們經常有一些複雜的關聯查詢，在 ES 裡該怎麼玩兒？

ES 裡面的複雜的關聯查詢盡量别用，一旦用了性能一般都不太好。最好是先在 Java 系統裡就完成關聯，将關聯好的資料直接寫入 ES 中。搜尋的時候，就不需要利用 ES 的搜尋文法來完成 Join 之類的關聯搜尋了。

Document 模型設計

Document 模型設計是非常重要的，很多操作，不要在搜尋的時候才想去執行各種複雜的亂七八糟的操作。

ES 能支援的操作就那麼多，不要考慮用 ES 做一些它不好操作的事情。如果真的有那種操作，盡量在 Document 模型設計的時候，寫入的時候就完成。

另外對于一些太複雜的操作，比如 join/nested/parent-child 搜尋都要盡量避免，性能都很差的。

分頁性能優化

ES 的分頁是較坑的，為啥呢？舉個例子吧，假如你每頁是 10 條資料，你現在要查詢第 100 頁，實際上是會把每個 Shard 上存儲的前 1000 條資料都查到一個協調節點上。

如果你有 5 個 Shard，那麼就有 5000 條資料，接着協調節點對這 5000 條資料進行一些合并、處理，再擷取到最終第 100 頁的 10 條資料。

由于是分布式的，你要查第 100 頁的 10 條資料，不可能說從 5 個 Shard，每個 Shard 就查 2 條資料，最後到協調節點合并成 10 條資料吧？

你必須得從每個 Shard 都查 1000 條資料過來，然後根據你的需求進行排序、篩選等等操作，最後再次分頁，拿到裡面第 100 頁的資料。

你翻頁的時候，翻的越深，每個 Shard 傳回的資料就越多，而且協調節點處理的時間越長，非常坑爹。是以用 ES 做分頁的時候，你會發現越翻到後面，就越是慢。

我們之前也是遇到過這個問題，用 ES 作分頁，前幾頁就幾十毫秒，翻到 10 頁或者幾十頁的時候，基本上就要 5~10 秒才能查出來一頁資料了。

有什麼解決方案嗎？兩個思路：

一、不允許深度分頁（預設深度分頁性能很差）。跟産品經理說，你系統不允許翻那麼深的頁，預設翻的越深，性能就越差。

二、類似于 App 裡的推薦商品不斷下拉出來一頁一頁的；類似于微網誌中，下拉刷微網誌，刷出來一頁一頁的，你可以用 Scroll API，關于如何使用，大家可以自行上網搜尋學習一下。

Scroll是如何做的呢？它會一次性給你生成所有資料的一個快照，然後每次滑動向後翻頁就是通過遊标 scroll_id 移動，擷取下一頁、下一頁這樣子，性能會比上面說的那種分頁性能要高很多很多，基本上都是毫秒級的。

但是，唯一的一點就是，這個适合于那種類似微網誌下拉翻頁的，不能随意跳到任何一頁的場景。也就是說，你不能先進入第 10 頁，然後去第 120 頁，然後又回到第 58 頁，不能随意亂跳頁。

是以現在很多産品，都是不允許你随意翻頁的，你隻能往下拉，一頁一頁的翻。

使用時需要注意，初始化必須指定 Scroll 參數，告訴 ES 要儲存此次搜尋的上下文多長時間。你需要確定使用者不會持續不斷翻頁翻幾個小時，否則可能因為逾時而失敗。

除了用 Scroll API，你也可以用 search_after 來做。search_after 的思想是使用前一頁的結果來幫助檢索下一頁的資料。

顯然，這種方式也不允許你随意翻頁，你隻能一頁頁往後翻。初始化時，需要使用一個唯一值的字段作為 Sort 字段。