es查詢性能優化

1. filesystem cache

2. 數據預熱

3. 冷熱分離

4. document 模型設計

5. 分頁性能優化

一、filesystem cache

往 es 裏寫的數據，實際上都寫到磁盤文件裏去了，**查詢的時候**，操做系統會將磁盤文件裏的數據自動緩存到 `filesystem cache` 裏面去

es 的搜索引擎嚴重依賴於底層的 `filesystem cache`，你若是給 `filesystem cache` 更多的內存，儘可能讓內存能夠容納全部的 `idx segment file ` 索引數據文件，那麼你搜索的時候就基本都是走內存的，性能會很是高。

歸根結底，要讓 es 性能要好，最佳的狀況下，就是你的機器的內存，至少能夠容納你的總數據量的一半。

好比說如今有一行數據。`id,name,age ....` 30 個字段。可是如今搜索，只須要根據 `id,name,age` 三個字段來搜索。僅僅寫入 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

 

二、數據預熱

假如說，哪怕是你就按照上述的方案去作了，es 集羣中每一個機器寫入的數據量仍是超過了 `filesystem cache` 一倍，好比說你寫入一臺機器 60G 數據，結果 `filesystem cache` 就 30G，仍是有 30G 數據留在了磁盤上。

其實能夠作**數據預熱**。

能夠將平時查看最多的一些商品，好比說 iphone 8，熱數據提早後臺搞個程序，每隔 1 分鐘本身主動訪問一次，刷到 `filesystem cache` 裏去。

對於那些你以爲比較熱的、常常會有人訪問的數據，最好**作一個專門的緩存預熱子系統**，就是對熱數據每隔一段時間，就提早訪問一下，讓數據進入 `filesystem cache` 裏面去。這樣下次別人訪問的時候，性能必定會好不少。

 

冷熱分離