面臨問題:
很多時候資料量大了,特别是有幾億條資料的時候,可能你會發現,跑個搜尋怎麼一下 5~10s。
第一次搜尋的時候,是 5~10s,後面反而就快了,可能就幾百毫秒。
說實話,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 字段。