如果面試的時候碰到這樣一個面試題：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%的人在訪問熱數據，也無所謂了。

四、document 模型設計

對于MySQL，我們經常有一些復雜的關聯查詢。在ES里該怎么玩兒，ES里面的復雜的關聯查詢盡量別用，一旦用了性能一般都不太好。

***是先在Java系統里就完成關聯，將關聯好的數據直接寫入ES中。搜索的時候，就不需要利用ES的搜索語法來完成join之類的關聯搜索了。

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頁，不能隨意亂跳頁。

所以現在很多產品，都是不允許你隨意翻頁的，app，也有一些網站，做的就是你只能往下拉，一頁一頁的翻。

初始化時必須指定scroll參數，告訴ES要保存此次搜索的上下文多長時間。你需要確保用戶不會持續不斷翻頁翻幾個小時，否則可能因為超時而失敗。

除了用scroll api，你也可以用search_after來做。search_after的思想是使用前一頁的結果來幫助檢索下一頁的數據，顯然，這種方式也不允許你隨意翻頁，你只能一頁頁往后翻。初始化時，需要使用一個唯一值的字段作為sort 字段。