一. es查詢速度與內存的關係
當我們向es裏面寫數據的時候，實際上都會寫到磁盤文件裏面去，查詢的時候，os會將磁盤文件裏的數據自動緩存到file system cache中去。所以es的性能非常依賴機器的內存，當機器內存比較小的時候查詢速度就會受到限制，如果我們給filesystem cache更多的內存，儘量讓內存可以容納所有的idx segment file索引數據文件，那麼搜索的時候就基本是在走內存的，少了從磁盤隨機io到內存中，查詢速度立馬變成ms級別。
二. 沒有銀彈的優化手段
所以從上面es查詢速度與內存的關係我們知道，其實es性能優化是沒有什麼銀彈的，就是不能期待着隨手調一個參數就可以萬能對應所有性能慢 的場景，但是可以通過一些合理的小技巧來加快es的查詢速度。
1. 不必緩存所有的字段信息
比如用戶信息可能有很多字段，我們只會根據name，age去進行查詢，那麼我們沒必要把其餘的字段也保存到es，我們可以只寫入name，age，存入es，這樣使用filesystem cache內存就大大減少。然後其它字段用doc id關聯存在hbase裏面，hbase的特點適用於海量數據的在線存儲，就是對hbase可以寫入海量數據，但是不要做複雜的搜索，做一些簡單的根據id搜索就很快，所以查詢es的我們根據name，age查詢es的doc id，再去hbase根據doc id裏面查詢所有信息。
之前如果整條消息走的es的磁盤查詢到緩存再返回可能需要幾秒，但是隻根據name或者age查詢doc id走的是filesystem cache緩存 + 根據doc id查詢hbase裏面所有的信息，時間大概就在幾十毫秒。
2. 數據預熱
比如在電商系統裏面，可以將平時查看多的商品，提前用後臺程序主動去訪問es裏面這些數據，這樣數據就進入了filesystem cache裏面，用戶再去訪問的時候性能會好很多。
@[TOC] #### 3.冷熱分離
es可以做類似於mysql中的水平拆分，就是說將訪問很頻繁的熱數據單獨寫入一個索引，將反問很少頻率很低的大量數據單獨寫入一個索引。這樣預熱後讓他們留在filesystem cache，不會被冷數據刷掉。
3. 文檔模型的合理設計
因爲es這種nosql是直接聚合數據的，比如訂單信息文檔，可能就有用戶的大部分信息，也有商品的信息，還有交易的信息，這樣設計是因爲es裏面對複雜的關聯查詢不友好。
所以文檔模型設計是非常重要的，很多操作不要等到在搜索的時候纔去想執行那些複雜關聯查詢的騷操作，而是在寫的時候直接關聯好寫進去。
4.坑爹的深度分頁
因爲es的分佈式屬性，比如我要查第80頁的10條數據，假如我們有10分片，不可能說從各個分片就查1條數據，而是需要從每個分片都查詢800條數據過來，然後根據查詢需求進行排序篩選等操作，翻的頁越多，每個分片返回的數據就越多，所以如果翻前幾頁的時候可能很快就出來了，翻的頁多了，就越來越慢了。
但是可以使用scroll api進行一個下拉分頁，就是類似於微博，向下刷出來一頁一頁的數據。