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