分幾個(gè)方向說幾個(gè)點(diǎn)：

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

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

　　內(nèi)存：

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

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

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

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

　　索引方面優(yōu)化

　　批量提交 當(dāng)有大量數(shù)據(jù)提交的時(shí)候，建議采用批量提交(Bulk 操作);此外使用 bulk 請求時(shí)，每個(gè)請求不超過幾十M，因?yàn)樘髸?huì)導(dǎo)致內(nèi)存使用過大。

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

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

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

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

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

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

　　查詢方面優(yōu)化

　　Filter VS Query

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

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

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