一、宏觀設置
- 注意CPU核數，CPU的核數將影響Thread Pool，也就是和檢索與索引的線程池有關，建議CPU在16核+；
- 根據需要設置索引和type，因爲高版本（6.0+）index裏面只能有一個type，所以建議在低版本里面即採用這一設定，並且這裏也要考慮到版本迭代裏面的父子文檔。
- 合理設置分片和副本，分片一般大於等於節點數，副本根據需要進行設置，分片容量一般不要大於30GB。
- 冷熱數據分離
二、索引優化
- 犧牲近實時搜索，修改refresh的時間。一般情況下refresh_interval設置爲1s,表示1秒後即可搜索。如果設置時間長，或者-1(-1表示關閉自動刷新)，可以優化索引。
- 減少副本，在索引前將副本設置爲0，生成後將其還原。
- 能批量就不要單條插入，儘量多使用bulk。
三、搜索優化
-
少用wildcard進行查詢，TB+的數據上，很容易卡死。
-
中文使用match匹配是不準確的，使用matchPhrace短語匹配更加準確，其實使用term的查詢代價更小，只是對於中文搜索不太準確。
-
如果該字段不需要計算相關度評分，使用filter更加迅速。
query和Filter對比：
query是有兩個操作：查詢和計算相關度，而filter是僅僅是判斷是否滿足條件，並且Es會自動緩存過濾器的內容。
過濾上下文是在使用filter參數時候的執行環境，比如在bool查詢中使用Must_not或者filter。
- 儘可能避免深度分頁。
深度分頁的問題在於數據時存儲在分片上的，也就是說查第100頁的10條數據，必須在5個分頁上查出前1000條的數據，將這些5000數據進行排序，取其前10條數據，可想而知，分頁越往後效率越低。
並且當 from + size > max_result_window （Es設置，默認10000）時，es 將返回錯誤。 - 聚合分頁size的合理設置。Es處於性能考慮，不支持聚合分頁。
方案一：每次取聚合結果，拿到內存中分頁返回。
方案二：scroll結合scroll after集合redis實現。
- 不要使用腳本