提升 Elasticsearch 性能的關(guān)鍵優(yōu)化技巧，50ms提升到1ms！！！
在微服務(wù)架構(gòu)中，速度和效率至關(guān)重要，每一毫秒都可能產(chǎn)生巨大影響。最近，我們?cè)谝粋€(gè)使用 Elasticsearch 來查找商品列表的微服務(wù)上深有體會(huì)。起初，每個(gè) Elasticsearch 查詢 大約需要 50-60 毫秒才能完成——在某些情況下還算可以，但在處理大量請(qǐng)求和頻繁更新時(shí)，這就成了瓶頸。即使是微小的延遲也會(huì)影響系統(tǒng)性能和用戶滿意度。
認(rèn)識(shí)到需要改進(jìn)后，我們開始進(jìn)行重大更改。我們的目標(biāo)是減少延遲，同時(shí)確保服務(wù)能夠高效地處理大量請(qǐng)求。經(jīng)過一系列調(diào)整和優(yōu)化 Elasticsearch 查詢 后，我們將延遲降低到 1 毫秒以下。這一重大改進(jìn)不僅使服務(wù)速度大幅提升，還增強(qiáng)了其處理大量請(qǐng)求的能力。
在本文中，我們將逐步介紹實(shí)現(xiàn)這一性能提升的步驟。我們將涵蓋從調(diào)整查詢到架構(gòu)更新的具體更改和策略。
1、背景介紹
在 Trendyol（阿里巴巴旗下土耳其電商平臺(tái)），我們始終關(guān)注賣家和買家，努力使國際銷售盡可能順暢高效。我的團(tuán)隊(duì)在這個(gè)過程中發(fā)揮著關(guān)鍵作用，使賣家只需點(diǎn)擊一下就能接觸到國際買家。這意味著賣家無需手動(dòng)更新新市場(chǎng)的價(jià)格或庫存水平。他們可以輕松地向全球客戶銷售商品，以最小的努力開拓新的機(jī)會(huì)。
這一操作的核心是一個(gè) 微服務(wù)，負(fù)責(zé)更新國際銷售的產(chǎn)品價(jià)格。系統(tǒng)中的每個(gè)商品列表都屬于一個(gè)“內(nèi)容（content）”。當(dāng)產(chǎn)品在其他國家銷售時(shí)，必須考慮多個(gè)因素來設(shè)定正確的價(jià)格，例如賣家的貨幣和運(yùn)費(fèi)。一個(gè)詳細(xì)的算法會(huì)計(jì)算出一個(gè)“系數(shù)率（coefficient rate）”，該系數(shù)率與價(jià)格相乘以計(jì)算新價(jià)格，針對(duì)每個(gè)內(nèi)容與相應(yīng)的“店面（storefront）”（即國家），然后將此信息發(fā)送到一個(gè) Kafka 主題。
圖片
我們的微服務(wù)監(jiān)聽該 Kafka 主題 上的更新，處理傳入的數(shù)據(jù)，并使用 Elasticsearch 查找相關(guān)的商品列表。為此，我們創(chuàng)建了一個(gè) Elasticsearch 查詢 來找到需要根據(jù)新系數(shù)調(diào)整的相關(guān)商品列表。找到這些列表后，服務(wù)將包含系數(shù)率的修訂列表發(fā)布到另一個(gè) Kafka 主題，在那里進(jìn)一步處理以設(shè)置新價(jià)格。
如果該系統(tǒng)出現(xiàn)任何延遲，價(jià)格更新可能無法立即應(yīng)用。這意味著價(jià)格調(diào)整可能需要更長時(shí)間才能反映出來，可能會(huì)影響一致性。因此，系統(tǒng)中的每一毫秒都很重要。
2、性能測(cè)試方法
在深入探討性能調(diào)優(yōu)細(xì)節(jié)之前，了解我們?nèi)绾螠y(cè)試和評(píng)估微服務(wù)和 Elasticsearch 查詢 的性能非常重要。為了測(cè)試，我們使用了公司內(nèi)部開發(fā)和維護(hù)的工具 Ares。Ares 使我們能夠?qū)?yīng)用程序進(jìn)行全面的負(fù)載測(cè)試，包括 Elasticsearch 查詢 和整體系統(tǒng)性能。
銘毅備注：關(guān)于性能測(cè)試工具，咱們可以使用 Elasticsearch 平替的開源方案 esrally，或者我們通用的方案：JMeter 等。
JMeter 如何實(shí)現(xiàn) Elasticsearch 8.X 性能測(cè)試？
首先，我們從生產(chǎn)環(huán)境中選擇大量樣本。通常，我們會(huì)檢索一份包含 10,000 個(gè)內(nèi)容的列表，代表我們需要測(cè)試的數(shù)據(jù)。然后，我們?cè)跍y(cè)試工具中創(chuàng)建一個(gè) Elasticsearch 任務(wù)，使用這個(gè)內(nèi)容列表。此設(shè)置有助于我們模擬真實(shí)世界的條件，并有效地對(duì) Elasticsearch 索引施加壓力。
以下是我們用于測(cè)試的查詢示例：
{
"query": {
"bool": {
"filter": [
{
"term": {
"contentId": 10863010
}
},
{
"terms": {
"storefrontId": [
"50",
"35",
"36",
"43",
"48",
"49"
]
}
}
]
}
},
"_source": [
"storefrontId",
"listingId"
],
"sort": [
{
"storefrontId": "asc",
"listingId": "asc"
}
]
}該查詢基于特定的 contentId 和一組 storefrontId 檢索文檔。它使用 bool 查詢 和 filter 子句 來選擇匹配給定內(nèi)容 ID 的文檔。此外，它過濾 storefrontId 以確保結(jié)果與目標(biāo)市場(chǎng)相關(guān)。
3、性能優(yōu)化策略
3.1. 減少分片數(shù)量
在 Elasticsearch 中，分片是存儲(chǔ)的基本單位，將索引拆分為更小的部分，使系統(tǒng)能夠在多個(gè)節(jié)點(diǎn)上分配數(shù)據(jù)和查詢。我們?cè)?Elasticsearch 集群中進(jìn)行的第一個(gè)優(yōu)化是減少過多的分片數(shù)量。
最初，我們的集群有超過 100 個(gè)分片，導(dǎo)致系統(tǒng)資源的低效使用。
為了解決這個(gè)問題，我們將分片數(shù)量減少到與節(jié)點(diǎn)數(shù)量相匹配，這不僅降低了資源開銷，還顯著提高了查詢速度和集群穩(wěn)定性。
以下是減少分片數(shù)量后集群的分片分布情況：
圖片
3.2. 限制段數(shù)量
我們的第二個(gè)優(yōu)化是解決隨著索引操作而增加的段（segment）數(shù)量。
段是分片內(nèi)更小的不可變數(shù)據(jù)單元，隨著段的累積，搜索延遲會(huì)增加，因?yàn)?Elasticsearch 需要搜索更多的段。
為了解決這個(gè)問題，我們實(shí)施了一個(gè)段合并策略來控制并逐步減少段的數(shù)量，優(yōu)化搜索性能。
起初，我們嘗試在段數(shù)量增加時(shí)強(qiáng)制段合并，但這種方法不足以限制段數(shù)量。為了解決這個(gè)問題，我們實(shí)施了一個(gè)段合并策略來控制并逐步減少段的數(shù)量，優(yōu)化搜索性能。以下是我們應(yīng)用的策略字段：
- max_merge_at_once_explicit: "4"：控制顯式合并操作中一次可以合并的最大段數(shù)，限制為 4 可以防止在手動(dòng)合并期間過度使用資源。
- max_merge_at_once: "4"：限制自動(dòng)合并時(shí)一次可以合并的段數(shù)，保持在 4 以確保受控的合并，維持系統(tǒng)穩(wěn)定性。
- max_merged_segment: "30gb"：定義合并段的最大大小，限制為 30GB 可以避免創(chuàng)建過大的段，導(dǎo)致內(nèi)存和性能問題。
- segments_per_tier: "2"：限制每個(gè)合并層允許的段數(shù)，限制為 2 有助于保持較低的段數(shù)量，通過優(yōu)化 Elasticsearch 必須搜索的段數(shù)來降低搜索延遲。
- floor_segment: "20gb"：設(shè)置有資格合并的最小段大小，小于 20GB 的段將首先被合并，防止大量小段的累積，可能會(huì)降低搜索性能。
圖片
3.3. 類型轉(zhuǎn)換優(yōu)化
我們實(shí)施的下一個(gè)優(yōu)化是將用于 term 查詢 的字段類型更改為 keyword。
keyword 存儲(chǔ)在倒排索引中，使查找速度極快，非常適合 term 或精確匹配查詢。
鑒于我們只需要這些字段進(jìn)行精確匹配，我們決定將其轉(zhuǎn)換為 keyword 類型，并重新索引了所有文檔。
在轉(zhuǎn)換字段類型后，我們重新索引了所有文檔，并再次進(jìn)行了負(fù)載測(cè)試。
結(jié)果令人印象深刻：搜索速率飆升至每秒約 50,000 個(gè)查詢，而延遲降至 1 毫秒以下。
類型轉(zhuǎn)換前的集群性能：
圖片
類型轉(zhuǎn)換后的集群性能：
圖片
這一優(yōu)化不僅提升了查詢性能，還展示了在 Elasticsearch 中為特定查詢用例選擇正確字段類型的重要性。
3.4. 啟用請(qǐng)求緩存
我們實(shí)施的另一個(gè)性能改進(jìn)是啟用 Elasticsearch 集群中的 request_cache。此緩存對(duì)于處理重復(fù)查詢非常有用，例如重試或從 Kafka 多次攝取同一事件的情況。通過在索引上啟用請(qǐng)求緩存，我們確保了這些重復(fù)查詢的響應(yīng)時(shí)間更快。
Elasticsearch 的緩存特別有效之處在于，每當(dāng)刷新間隔觸發(fā)時(shí)，它會(huì)自動(dòng)失效緩存數(shù)據(jù)，這意味著緩存的數(shù)據(jù)始終接近實(shí)時(shí)，避免了一致性問題。
盡管這可以顯著提高查詢速度，但需要考慮它可能導(dǎo)致的內(nèi)存使用增加。因此，啟用 request_cache 是一個(gè)強(qiáng)大的優(yōu)化，但應(yīng)與內(nèi)存考慮保持平衡。
要在 Elasticsearch 中為索引啟用請(qǐng)求緩存，可以使用以下命令：
PUT /your_index_name/_settings
{
"index": {
"requests.cache.enable": true
}
}3.5. 優(yōu)化排序
在 Elasticsearch 中查詢超過 10,000 個(gè)文檔時(shí)，我們使用了 Point In Time (PIT)。
干貨 | 全方位深度解讀 Elasticsearch 分頁查詢
PIT 允許我們通過捕獲索引在特定時(shí)刻的快照來執(zhí)行一致的搜索，確保查詢不受正在進(jìn)行的索引操作影響。所有的 PIT 搜索請(qǐng)求都會(huì)自動(dòng)包含一個(gè)隱式的排序斷點(diǎn)字段 _shard_doc，有助于保持一致的分頁。如果無法使用 PIT，確保在排序子句中包含一個(gè)唯一的斷點(diǎn)字段至關(guān)重要，以防止分頁結(jié)果中出現(xiàn)遺漏或重復(fù)。
在我們的案例中，原始查詢按 listingId 和 storefrontId 對(duì)結(jié)果進(jìn)行排序。然而，由于我們主要關(guān)注的是避免重復(fù)，而不是使用特定的排序字段，我們從查詢中刪除了這些排序字段。
取而代之的是，我們按照建議使用 _shard_doc 對(duì)結(jié)果進(jìn)行排序。
搜索響應(yīng)中，每個(gè)命中都會(huì)包含一個(gè)排序值數(shù)組。使用 PIT 時(shí)，每個(gè)命中的最后一個(gè)排序值包含斷點(diǎn) _shard_doc。該值在 PIT 的上下文中對(duì)每個(gè)文檔都是唯一的，由分片索引和 Lucene 的內(nèi)部文檔 ID 組合而成。這種方法確保我們高效地管理文檔分頁，而不會(huì)引入重復(fù)。
4、總結(jié)
通過針對(duì)性的優(yōu)化，我們將 Elasticsearch 查詢 的延遲從 50-60 毫秒降低到 1 毫秒以下，顯著提升了系統(tǒng)性能。
這些優(yōu)化包括降低分片數(shù)量、有效管理 段合并、啟用 請(qǐng)求緩存 和為精確查詢優(yōu)化 字段類型。
這些經(jīng)驗(yàn)表明，在 Elasticsearch 中進(jìn)行針對(duì)性的優(yōu)化可以帶來速度和整體系統(tǒng)響應(yīng)能力的顯著提升。
原文地址：https://medium.com/trendyol-tech/unlocking-speed-key-optimizations-for-elasticsearch-performance-20af2cb4ac87
原文作者：Mert Oz
