如果面試的時候碰到這樣一個面試題：ES 在數(shù)據(jù)量很大的情況下（數(shù)十億級別）如何提高查詢效率？

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

很多時候數(shù)據(jù)量大了，特別是有幾億條數(shù)據(jù)的時候，可能你會懵逼的發(fā)現(xiàn)，跑個搜索怎么一下 5~10s？后面反而就快了，可能就幾百毫秒。

說實話，ES 性能優(yōu)化是沒有銀彈的。啥意思呢？就是不要期待著隨手調一個參數(shù)，就可以萬能的應對所有的性能慢的場景。

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

Filesystem Cache

你往 ES 里寫的數(shù)據(jù)，實際上都寫到磁盤文件里去了，查詢的時候，操作系統(tǒng)會將磁盤文件里的數(shù)據(jù)自動緩存到 Filesystem Cache 里面去。

es 的搜索引擎嚴重依賴于底層的 filesystem cache，你如果給 filesystem cache 更多的內存，盡量讓內存可以容納所有的 idx segment file 索引數(shù)據(jù)文件，那么你搜索的時候就基本都是走內存的，性能會非常高。

性能差距究竟可以有多大？我們之前很多的測試和壓測，如果走磁盤一般肯定上秒，搜索性能絕對是秒級別的，1秒、5秒、10秒。但如果是走 filesystem cache，是走純內存的，那么一般來說性能比走磁盤要高一個數(shù)量級，基本上就是毫秒級的，從幾毫秒到幾百毫秒不等。

這里有個真實的案例。某個公司 es 節(jié)點有 3 臺機器，每臺機器看起來內存很多，64G，總內存就是 64 * 3 = 192G。每臺機器給 es jvm heap 是 32G，那么剩下來留給 filesystem cache 的就是每臺機器才 32G，總共集群里給 filesystem cache 的就是 32 * 3 = 96G 內存。而此時，整個磁盤上索引數(shù)據(jù)文件，在 3 臺機器上一共占用了 1T 的磁盤容量，es 數(shù)據(jù)量是 1T，那么每臺機器的數(shù)據(jù)量是 300G。這樣性能好嗎？ filesystem cache 的內存才 100G，十分之一的數(shù)據(jù)可以放內存，其他的都在磁盤，然后你執(zhí)行搜索操作，大部分操作都是走磁盤，性能肯定差。

歸根結底，你要讓 es 性能要好，最佳的情況下，就是你的機器的內存，至少可以容納你的總數(shù)據(jù)量的一半。

根據(jù)我們自己的生產環(huán)境實踐經(jīng)驗，最佳的情況下，是僅僅在 es 中就存少量的數(shù)據(jù)，就是你要用來搜索的那些索引，如果內存留給 filesystem cache 的是 100G，那么你就將索引數(shù)據(jù)控制在 100G 以內，這樣的話，你的數(shù)據(jù)幾乎全部走內存來搜索，性能非常之高，一般可以在 1 秒以內。

比如說你現(xiàn)在有一行數(shù)據(jù)。id,name,age .... 30 個字段。但是你現(xiàn)在搜索，只需要根據(jù) id,name,age 三個字段來搜索。如果你傻乎乎往 es 里寫入一行數(shù)據(jù)所有的字段，就會導致說 90% 的數(shù)據(jù)是不用來搜索的，結果硬是占據(jù)了 es 機器上的 filesystem cache 的空間，單條數(shù)據(jù)的數(shù)據(jù)量越大，就會導致 filesystem cahce 能緩存的數(shù)據(jù)就越少。其實，僅僅寫入 es 中要用來檢索的少數(shù)幾個字段就可以了，比如說就寫入 es id,name,age 三個字段，然后你可以把其他的字段數(shù)據(jù)存在 mysql/hbase 里，我們一般是建議用 es + hbase 這么一個架構。

hbase 的特點是適用于海量數(shù)據(jù)的在線存儲，就是對 hbase 可以寫入海量數(shù)據(jù)，但是不要做復雜的搜索，做很簡單的一些根據(jù) id 或者范圍進行查詢的這么一個操作就可以了。從 es 中根據(jù) name 和 age 去搜索，拿到的結果可能就 20 個 doc id，然后根據(jù) doc id 到 hbase 里去查詢每個 doc id 對應的完整的數(shù)據(jù)，給查出來，再返回給前端。

寫入 es 的數(shù)據(jù)最好小于等于，或者是略微大于 es 的 filesystem cache 的內存容量。然后你從 es 檢索可能就花費 20ms，然后再根據(jù) es 返回的 id 去 hbase 里查詢，查 20 條數(shù)據(jù)，可能也就耗費個 30ms，可能你原來那么玩兒，1T 數(shù)據(jù)都放 es，會每次查詢都是 5~10s，現(xiàn)在可能性能就會很高，每次查詢就是 50ms。

數(shù)據(jù)預熱

假如說，哪怕是你就按照上述的方案去做了，es 集群中每個機器寫入的數(shù)據(jù)量還是超過了 filesystem cache 一倍，比如說你寫入一臺機器 60G 數(shù)據(jù)，結果 filesystem cache 就 30G，還是有 30G 數(shù)據(jù)留在了磁盤上。

其實可以做數(shù)據(jù)預熱。

舉個例子，拿微博來說，你可以把一些大V，平時看的人很多的數(shù)據(jù)，你自己提前后臺搞個系統(tǒng)，每隔一會兒，自己的后臺系統(tǒng)去搜索一下熱數(shù)據(jù)，刷到 filesystem cache 里去，后面用戶實際上來看這個熱數(shù)據(jù)的時候，他們就是直接從內存里搜索了，很快。

或者是電商，你可以將平時查看最多的一些商品，比如說 iphone 8，熱數(shù)據(jù)提前后臺搞個程序，每隔 1 分鐘自己主動訪問一次，刷到 filesystem cache 里去。

對于那些你覺得比較熱的、經(jīng)常會有人訪問的數(shù)據(jù)，最好做一個專門的緩存預熱子系統(tǒng)，就是對熱數(shù)據(jù)每隔一段時間，就提前訪問一下，讓數(shù)據(jù)進入 filesystem cache 里面去。這樣下次別人訪問的時候，性能一定會好很多。

冷熱分離

es 可以做類似于 mysql 的水平拆分，就是說將大量的訪問很少、頻率很低的數(shù)據(jù)，單獨寫一個索引，然后將訪問很頻繁的熱數(shù)據(jù)單獨寫一個索引。最好是將冷數(shù)據(jù)寫入一個索引中，然后熱數(shù)據(jù)寫入另外一個索引中，這樣可以確保熱數(shù)據(jù)在被預熱之后，盡量都讓他們留在 filesystem os cache 里，別讓冷數(shù)據(jù)給沖刷掉。

你看，假設你有 6 臺機器，2 個索引，一個放冷數(shù)據(jù)，一個放熱數(shù)據(jù)，每個索引 3 個 shard。3 臺機器放熱數(shù)據(jù) index，另外 3 臺機器放冷數(shù)據(jù) index。然后這樣的話，你大量的時間是在訪問熱數(shù)據(jù) index，熱數(shù)據(jù)可能就占總數(shù)據(jù)量的 10%，此時數(shù)據(jù)量很少，幾乎全都保留在 filesystem cache 里面了，就可以確保熱數(shù)據(jù)的訪問性能是很高的。但是對于冷數(shù)據(jù)而言，是在別的 index 里的，跟熱數(shù)據(jù) index 不在相同的機器上，大家互相之間都沒什么聯(lián)系了。如果有人訪問冷數(shù)據(jù)，可能大量數(shù)據(jù)是在磁盤上的，此時性能差點，就 10% 的人去訪問冷數(shù)據(jù)，90% 的人在訪問熱數(shù)據(jù)，也無所謂了。

document模型設計

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

最好是先在 Java 系統(tǒng)里就完成關聯(lián)，將關聯(lián)好的數(shù)據(jù)直接寫入 es 中。搜索的時候，就不需要利用 es 的搜索語法來完成 join 之類的關聯(lián)搜索了。

document 模型設計是非常重要的，很多操作，不要在搜索的時候才想去執(zhí)行各種復雜的亂七八糟的操作。es 能支持的操作就那么多，不要考慮用 es 做一些它不好操作的事情。如果真的有那種操作，盡量在 document 模型設計的時候，寫入的時候就完成。另外對于一些太復雜的操作，比如 join/nested/parent-child 搜索都要盡量避免，性能都很差的。

分頁性能優(yōu)化

es 的分頁是較坑的，為啥呢？舉個例子吧，假如你每頁是 10 條數(shù)據(jù)，你現(xiàn)在要查詢第 100 頁，實際上是會把每個 shard 上存儲的前 1000 條數(shù)據(jù)都查到一個協(xié)調節(jié)點上，如果你有個 5 個 shard，那么就有 5000 條數(shù)據(jù)，接著協(xié)調節(jié)點對這 5000 條數(shù)據(jù)進行一些合并、處理，再獲取到最終第 100 頁的 10 條數(shù)據(jù)。

分布式的，你要查第 100 頁的 10 條數(shù)據(jù)，不可能說從 5 個 shard，每個 shard 就查 2 條數(shù)據(jù)，最后到協(xié)調節(jié)點合并成 10 條數(shù)據(jù)吧？你必須得從每個 shard 都查 1000 條數(shù)據(jù)過來，然后根據(jù)你的需求進行排序、篩選等等操作，最后再次分頁，拿到里面第 100 頁的數(shù)據(jù)。你翻頁的時候，翻的越深，每個 shard 返回的數(shù)據(jù)就越多，而且協(xié)調節(jié)點處理的時間越長，非常坑爹。所以用 es 做分頁的時候，你會發(fā)現(xiàn)越翻到后面，就越是慢。

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

有什么解決方案嗎？

不允許深度分頁（默認深度分頁性能很差）

跟產品經(jīng)理說，你系統(tǒng)不允許翻那么深的頁，默認翻的越深，性能就越差。

類似于 app 里的推薦商品不斷下拉出來一頁一頁的

類似于微博中，下拉刷微博，刷出來一頁一頁的，你可以用 scroll api，關于如何使用，自行上網(wǎng)搜索。

scroll 會一次性給你生成所有數(shù)據(jù)的一個快照，然后每次滑動向后翻頁就是通過游標 scroll_id 移動，獲取下一頁下一頁這樣子，性能會比上面說的那種分頁性能要高很多很多，基本上都是毫秒級的。

但是，唯一的一點就是，這個適合于那種類似微博下拉翻頁的，不能隨意跳到任何一頁的場景。也就是說，你不能先進入第 10 頁，然后去第 120 頁，然后又回到第 58 頁，不能隨意亂跳頁。所以現(xiàn)在很多產品，都是不允許你隨意翻頁的，app，也有一些網(wǎng)站，做的就是你只能往下拉，一頁一頁的翻。

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

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

節(jié)點副本調優(yōu)

ES的性能跟硬件資源有很大關系，當ES集群單獨部署到物理機器上時，集群內部的節(jié)點并不是獨占整臺物理機資源，在集群運行的時候同一物理機上的節(jié)點仍會出現(xiàn)資源搶占的問題。所以在這種情況下，為了讓ES單個節(jié)點能夠使用最大程度的機器資源，采用每個ES節(jié)點部署在單獨一臺物理機上方式。

但緊接著，問題又來了，如果單個節(jié)點出現(xiàn)瓶頸了呢？我們應該怎么再優(yōu)化呢？ES查詢的原理，當請求打到某號分片的時候，如果沒有指定分片類型（preference參數(shù)）查詢，請求會負載到對應分片號的各個節(jié)點上。而集群默認副本配置是一主一副，針對于此，我們想到了擴容副本的方式，由默認的一主一副變?yōu)橐恢鞫?#xff0c;同時增加相應物理機。

整個架設方式通過VIP來負載均衡外部請求，第一層gateway節(jié)點實質為ES中client node，相當于一個智能負載均衡器，充當著分發(fā)請求的角色。第二層為data node，負責存儲數(shù)據(jù)以及執(zhí)行數(shù)據(jù)的相關操作。整個集群有一套主分片，二套副分片（一主二副），從網(wǎng)關節(jié)點轉發(fā)過來的請求，會在打到數(shù)據(jù)節(jié)點之前通過輪詢的方式進行均衡。集群增加一套副本并擴容機器的方式，增加了集群吞吐量，從而提升了整個集群查詢性能。如下是京東到家訂單中心實際性能對比圖

當然分片數(shù)量和分片副本數(shù)量并不是越多越好，在此階段中，對選擇適當?shù)姆制瑪?shù)量做了近一步探索。分片數(shù)可以理解為Mysql中的分庫分表，而當前訂單中心ES查詢主要分為兩類：單ID查詢以及分頁查詢。分片數(shù)越大，集群橫向擴容規(guī)模也更大，根據(jù)分片路由的單ID查詢吞吐量也能大大提升，但對于聚合的分頁查詢性能則將降低。分片數(shù)越小，集群橫向擴容規(guī)模更小，單ID的查詢性能也將下降，但對于分頁查詢，性能將會得到提升。所以如何均衡分片數(shù)量和現(xiàn)有查詢業(yè)務可通過多次測試數(shù)據(jù)進行合理選擇。

歡迎移步搜索關注公眾號：互聯(lián)網(wǎng)架構師之路，獲取最新架構材料。

總結

以上是生活随笔為你收集整理的currenttimemillis 毫秒还是秒_Elasticsearch如何做到数十亿数据查询毫秒级响应？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。