分幾個方向說幾個點：

　　硬件配置優(yōu)化 包括三個因素：CPU、內(nèi)存和 IO。

　　CPU： 大多數(shù) Elasticsearch 部署往往對 CPU 要求不高; CPUs 和更多的核數(shù)之間選擇，選擇更多的核數(shù)更好。多個內(nèi)核提供的額外并發(fā)遠勝過稍微快一點點的時鐘頻率。

　　內(nèi)存：

　　配置： 由于 ES 構(gòu)建基于 lucene，而 lucene 設(shè)計強大之處在于 lucene 能夠很好的利用操作系統(tǒng)內(nèi)存來緩存索引數(shù)據(jù)，以提供快速的查詢性能。lucene 的索引文件 segements 是存儲在單文件中的，并且不可變，對于 OS 來說，能夠很友好地將索引文件保持在 cache 中，以便快速訪問;因此，我們很有必要將一半的物理內(nèi)存留給 lucene;另一半的物理內(nèi)存留給 ES(JVM heap)。

　　禁止 swap 禁止 swap，一旦允許內(nèi)存與磁盤的交換，會引起致命的性能問題。可以通過在 elasticsearch.yml 中 bootstrap.memory_lock: true，以保持 JVM 鎖定內(nèi)存，保證 ES 的性能。

　　垃圾回收器： 已知JDK 8附帶的HotSpot JVM的早期版本存在一些問題，當啟用G1GC收集器時，這些問題可能導(dǎo)致索引損壞。受影響的版本早于JDK 8u40隨附的HotSpot版本。如果你使用的JDK8較高版本，或者JDK9+，我推薦你使用G1 GC; 因為我們目前的項目使用的就是G1 GC，運行效果良好，對Heap大對象優(yōu)化尤為明顯。

　　磁盤 在經(jīng)濟壓力能承受的范圍下，盡量使用固態(tài)硬盤(SSD)

　　索引方面優(yōu)化

　　批量提交 當有大量數(shù)據(jù)提交的時候，建議采用批量提交(Bulk 操作);此外使用 bulk 請求時，每個請求不超過幾十M，因為太大會導(dǎo)致內(nèi)存使用過大。

　　增加 Refresh 時間間隔 為了提高索引性能，Elasticsearch 在寫入數(shù)據(jù)的時候，采用延遲寫入的策略，即數(shù)據(jù)先寫到內(nèi)存中，當超過默認1秒(index.refresh_interval)會進行一次寫入操作，就是將內(nèi)存中 segment 數(shù)據(jù)刷新到磁盤中，此時我們才能將數(shù)據(jù)搜索出來，所以這就是為什么 Elasticsearch 提供的是近實時搜索功能，而不是實時搜索功能。如果我們的系統(tǒng)對數(shù)據(jù)延遲要求不高的話，我們可以通過延長 refresh 時間間隔，可以有效地減少 segment 合并壓力，提高索引速度。比如在做全鏈路跟蹤的過程中，我們就將 index.refresh_interval 設(shè)置為30s，減少 refresh 次數(shù)。再如，在進行全量索引時，可以將 refresh 次數(shù)臨時關(guān)閉，即 index.refresh_interval 設(shè)置為-1，數(shù)據(jù)導(dǎo)入成功后再打開到正常模式，比如30s。

　　索引緩沖的設(shè)置可以控制多少內(nèi)存分配 indices.memory.index_buffer_size 接受一個百分比或者一個表示字節(jié)大小的值。默認是10%

　　translog 相關(guān)的設(shè)置 控制數(shù)據(jù)從內(nèi)存到硬盤的操作頻率，以減少硬盤 IO?？蓪?sync_interval 的時間設(shè)置大一些。默認為5s。也可以控制 tranlog 數(shù)據(jù)塊的大小，達到 threshold 大小時，才會 flush 到 lucene 索引文件。默認為512m。

　　_id 字段的使用 _id 字段的使用，應(yīng)盡可能避免自定義 _id，以避免針對 ID 的版本管理;建議使用 ES 的默認 ID 生成策略或使用數(shù)字類型 ID 做為主鍵。

　　_all 字段及 _source 字段的使用 _all 字段及 _source 字段的使用，應(yīng)該注意場景和需要，_all 字段包含了所有的索引字段，方便做全文檢索，如果無此需求，可以禁用;_source 存儲了原始的 document 內(nèi)容，如果沒有獲取原始文檔數(shù)據(jù)的需求，可通過設(shè)置 includes、excludes 屬性來定義放入 _source 的字段。

　　合理的配置使用 index 屬性 合理的配置使用 index 屬性，analyzed 和 not_analyzed，根據(jù)業(yè)務(wù)需求來控制字段是否分詞或不分詞。只有 groupby 需求的字段，配置時就設(shè)置成 not_analyzed，以提高查詢或聚類的效率。

　　查詢方面優(yōu)化

　　Filter VS Query

　　深度翻頁 使用 Elasticsearch scroll 和 scroll-scan 高效滾動的方式來解決這樣的問題。也可以結(jié)合實際業(yè)務(wù)特點，文檔 id 大小如果和文檔創(chuàng)建時間是一致有序的，可以以文檔 id 作為分頁的偏移量，并將其作為分頁查詢的一個條件。

　　避免層級過深的聚合查詢， 層級過深的aggregation , 會導(dǎo)致內(nèi)存、CPU消耗，建議在服務(wù)層通過程序來組裝業(yè)務(wù)，也可以通過pipeline的方式來優(yōu)化。

　　通過開啟慢查詢配置定位慢查詢