注意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實現。
ElasticSearch 效能優化
getrace系統的所有搜尋都是用elasticsearch來做的，在使用elasticsearch的過程中碰到了一些問題，這裡記錄一下。一 在查詢呼叫鏈的時候。整體資料量大 每天60g 7 420g 但是結果集比較少 只有幾百行 的時候，查詢時間經常會超過1分鐘，慢的甚至需要5，6分鐘.優化1 經...
ElasticSearch 優化配置
索引建立優化 house properties title price area createtime lastupdatetime cityenname regionenname direction distancetosubway subwaylinename subwaystationname...
elasticsearch效能優化
elasticsearch查詢依賴作業系統的頁面快取記憶體 file system cache 因此除了需要給elasticsearch的jvm分配足夠的記憶體以外，還需要給頁快取預留記憶體。例如單機32g記憶體，給jvm配置16g記憶體後，剩餘16g預留記憶體不需要額外配置，也不要讓其他程序占用這...