目錄

1、面試題

2、面試官心裡分析

3、面試題剖析

（1）效能優化的殺手鐗——filesystem cache

（2）資料預熱

（3）冷熱分離

（4）document模型設計

（5）分頁效能優化

1、面試題

es在資料量很大的情況下（數十億級別）如何提高查詢效率啊？

2、面試官心裡分析

問這個問題，是肯定的，說白了，就是看你有沒有實際幹過es，因為啥？es說白了其實效能並沒有你想象中那麼好的。很多時候資料量大了，特別是有幾億條資料的時候，可能你會懵逼的發現，跑個搜尋怎麼一下5秒~10秒，坑爹了。第一次搜尋的時候，是5~10秒，後面反而就快了，可能就幾百毫秒。

你就很懵，每個使用者第一次訪問都會比較慢，比較卡麼？

所以你要是沒玩兒過es，或者就是自己玩玩兒demo，被問到這個問題容易懵逼，顯示出你對es確實玩兒的不怎麼樣

3、面試題剖析

說實話，es效能優化是沒有什麼銀彈的，啥意思呢？就是不要期待著隨手調一個引數，就可以萬能的應對所有的效能慢的場景。也許有的場景是你換個引數，或者調整一下語法，就可以搞定，但是絕對不是所有場景都可以這樣。

一塊一塊來分析吧

在這個海量資料的場景下，如何提升es搜尋的效能，也是我們之前生產環境實踐經驗所得

（1）效能優化的殺手鐗——filesystem cache

os cache，作業系統的快取

你往es裡寫的資料，實際上都寫到磁碟檔案裡去了，磁碟檔案裡的資料作業系統會自動將裡面的資料快取到os cache裡面去

es的搜尋引擎嚴重依賴於底層的filesystem cache，你如果給filesystem cache更多的記憶體，儘量讓記憶體可以容納所有的indx 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記憶體

我就問他，ok，那麼就是你往es叢集裡寫入的資料有多少資料量？

如果你此時，你整個，磁碟上索引資料檔案，在3臺機器上，一共佔用了1T的磁碟容量，你的es資料量是1t，每臺機器的資料量是300g

你覺得你的效能能好嗎？filesystem cache的記憶體才100g，十分之一的資料可以放記憶體，其他的都在磁碟，然後你執行搜尋操作，大部分操作都是走磁碟，效能肯定差

當時他們的情況就是這樣子，es在測試，弄了3臺機器，自己覺得還不錯，64G記憶體的物理機。自以為可以容納1T的資料量。

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

比如說，你一共要在es中儲存1T的資料，那麼你的多臺機器留個filesystem cache的記憶體加起來綜合，至少要到512G，至少半數的情況下，搜尋是走記憶體的，效能一般可以到幾秒鐘，2秒，3秒，5秒

如果最佳的情況下，我們自己的生產環境實踐經驗，所以說我們當時的策略，是僅僅在es中就存少量的資料，就是你要用來搜尋的那些索引，記憶體留給filesystem cache的，就100G，那麼你就控制在100gb以內，相當於是，你的資料幾乎全部走記憶體來搜尋，效能非常之高，一般可以在1秒以內

比如說你現在有一行資料

id name age ....30個欄位

但是你現在搜尋，只需要根據id name age三個欄位來搜尋

如果你傻乎乎的往es裡寫入一行資料所有的欄位，就會導致說70%的資料是不用來搜尋的，結果硬是佔據了es機器上的filesystem cache的空間，單挑資料的資料量越大，就會導致filesystem cahce能快取的資料就越少

僅僅只是寫入es中要用來檢索的少數幾個欄位就可以了，比如說，就寫入es id name age三個欄位就可以了，然後你可以把其他的欄位資料存在mysql裡面，我們一般是建議用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~10秒，現在可能效能就會很高，每次查詢就是50ms。

elastcisearch減少資料量僅僅放要用於搜尋的幾個關鍵欄位即可，儘量寫入es的資料量跟es機器的filesystem cache是差不多的就可以了；其他不用來檢索的資料放hbase裡，或者mysql。

所以之前有些學員也是問，我也是跟他們說，儘量在es裡，就儲存必須用來搜尋的資料，比如說你現在有一份資料，有100個欄位，其實用來搜尋的只有10個欄位，建議是將10個欄位的資料，存入es，剩下90個欄位的資料，可以放mysql，hadoop hbase，都可以

這樣的話，es資料量很少，10個欄位的資料，都可以放記憶體，就用來搜尋，搜尋出來一些id，通過id去mysql，hbase裡面去查詢明細的資料

（2）資料預熱

假如說，哪怕是你就按照上述的方案去做了，es叢集中每個機器寫入的資料量還是超過了filesystem cache一倍，比如說你寫入一臺機器60g資料，結果filesystem cache就30g，還是有30g資料留在了磁碟上。

舉個例子，就比如說，微博，你可以把一些大v，平時看的人很多的資料給提前你自己後臺搞個系統，每隔一會兒，你自己的後臺系統去搜索一下熱資料，刷到filesystem cache裡去，後面使用者實際上來看這個熱資料的時候，他們就是直接從記憶體裡搜尋了，很快。

電商，你可以將平時檢視最多的一些商品，比如說iphone 8，熱資料提前後臺搞個程式，每隔1分鐘自己主動訪問一次，刷到filesystem cache裡去。

對於那些你覺得比較熱的，經常會有人訪問的資料，最好做一個專門的快取預熱子系統，就是對熱資料，每隔一段時間，你就提前訪問一下，讓資料進入filesystem cache裡面去。這樣期待下次別人訪問的時候，一定效能會好一些。

（3）冷熱分離

關於es效能優化，資料拆分，我之前說將大量不搜尋的欄位，拆分到別的儲存中去，這個就是類似於後面我最後要講的mysql分庫分表的垂直拆分。

es可以做類似於mysql的水平拆分，就是說將大量的訪問很少，頻率很低的資料，單獨寫一個索引，然後將訪問很頻繁的熱資料單獨寫一個索引

你最好是將冷資料寫入一個索引中，然後熱資料寫入另外一個索引中，這樣可以確保熱資料在被預熱之後，儘量都讓他們留在filesystem os cache裡，別讓冷資料給沖刷掉。

你看，假設你有6臺機器，2個索引，一個放冷資料，一個放熱資料，每個索引3個shard

3臺機器放熱資料index；另外3臺機器放冷資料index

然後這樣的話，你大量的時候是在訪問熱資料index，熱資料可能就佔總資料量的10%，此時資料量很少，幾乎全都保留在filesystem cache裡面了，就可以確保熱資料的訪問效能是很高的。

但是對於冷資料而言，是在別的index裡的，跟熱資料index都不再相同的機器上，大家互相之間都沒什麼聯絡了。如果有人訪問冷資料，可能大量資料是在磁碟上的，此時效能差點，就10%的人去訪問冷資料；90%的人在訪問熱資料。

（4）document模型設計

有不少同學問我，mysql，有兩張表

訂單表：id order_code total_price

1 測試訂單 5000

訂單條目表：id order_id goods_id purchase_count price

1 1 1 2 2000

2 1 2 5 200

我在mysql裡，都是select * from order join order_item on order.id=order_item.order_id where order.id=1

1 測試訂單 5000 1 1 1 2 2000

1 測試訂單 5000 2 1 2 5 200

在es裡該怎麼玩兒，es裡面的複雜的關聯查詢，複雜的查詢語法，儘量別用，一旦用了效能一般都不太好

設計es裡的資料模型

寫入es的時候，搞成兩個索引，order索引，orderItem索引

order索引，裡面就包含id order_code total_price

orderItem索引，裡面寫入進去的時候，就完成join操作，id order_code total_price id order_id goods_id purchase_count price

寫入es的java系統裡，就完成關聯，將關聯好的資料直接寫入es中，搜尋的時候，就不需要利用es的搜尋語法去完成join來搜尋了

document模型設計是非常重要的，很多操作，不要在搜尋的時候才想去執行各種複雜的亂七八糟的操作。es能支援的操作就是那麼多，不要考慮用es做一些它不好操作的事情。如果真的有那種操作，儘量在document模型設計的時候，寫入的時候就完成。另外對於一些太複雜的操作，比如join，nested，parent-child搜尋都要儘量避免，效能都很差的。

很多同學在問我，很多複雜的亂七八糟的一些操作，如何執行

兩個思路，在搜尋/查詢的時候，要執行一些業務強相關的特別複雜的操作：

1）在寫入資料的時候，就設計好模型，加幾個欄位，把處理好的資料寫入加的欄位裡面

2）自己用java程式封裝，es能做的，用es來做，搜尋出來的資料，在java程式裡面去做，比如說我們，基於es，用java封裝一些特別複雜的操作

（5）分頁效能優化

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秒才能查出來一頁資料了

1）不允許深度分頁/預設深度分頁效能很慘

你係統不允許他翻那麼深的頁，pm，預設翻的越深，效能就越差

2）類似於app裡的推薦商品不斷下拉出來一頁一頁的

類似於微博中，下拉刷微博，刷出來一頁一頁的，你可以用scroll api，自己百度

scroll會一次性給你生成所有資料的一個快照，然後每次翻頁就是通過遊標移動，獲取下一頁下一頁這樣子，效能會比上面說的那種分頁效能也高很多很多

針對這個問題，你可以考慮用scroll來進行處理，scroll的原理實際上是保留一個數據快照，然後在一定時間內，你如果不斷的滑動往後翻頁的時候，類似於你現在在瀏覽微博，不斷往下重新整理翻頁。那麼就用scroll不斷通過遊標獲取下一頁資料，這個效能是很高的，比es實際翻頁要好的多的多。

但是唯一的一點就是，這個適合於那種類似微博下拉翻頁的，不能隨意跳到任何一頁的場景。同時這個scroll是要保留一段時間內的資料快照的，你需要確保使用者不會持續不斷翻頁翻幾個小時。

無論翻多少頁，效能基本上都是毫秒級的

因為scroll api是隻能一頁一頁往後翻的，是不能說，先進入第10頁，然後去120頁，回到58頁，不能隨意亂跳頁。所以現在很多產品，都是不允許你隨意翻頁的，app，也有一些網站，做的就是你只能往下拉，一頁一頁的翻