查詢億級數據毫秒級返回！牛逼哄哄的ElasticSearch是如何做到的？
作者：石杉的架構筆記
原文鏈接：http://mp.weixin.qq.com/s?__biz=MzU0OTk3ODQ3Ng==&mid=2247485379&idx=1&sn=d254376a5f8287d03eefc8c4351f20a1
目錄：
1. 一道面試題的引入：
2. 性能優化的殺手鐧： Filesystem Cache
3. 數據預熱
4. 冷熱分離
5. ElasticSearch 中的關聯查詢
6. Document 模型設計
7. 分頁性能優化
一道面試題的引入：
如果面試的時候碰到這樣一個面試題：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 欄位。
推薦閱讀：
