https://www.sohu.com/a/220443841_467759

Elasticsearch 是一個基於 Apache Lucene 的開源搜尋和分析引擎，允許使用者近實時地儲存、搜尋和分析資料。Pronto 是 eBay 託管 Elasticsearch 叢集的平臺，使 eBay 內部客戶易於部署、運維和擴充套件 Elasticsearch 以進行全文搜尋、實時分析和日誌事件監控。今天 Pronto 管理著 60 多個 Elasticsearch 叢集，達 2000 多個節點。日採集資料量達到 180 億個文件，日均查詢量達到 35 億。該平臺提供了建立、修復、安全、監控、告警和診斷的一整套功能。

雖然 Elasticsearch 專為快速查詢而設計，但其效能在很大程度上取決於應用程式的場景、索引的資料量以及應用程式和使用者查詢資料的速度。本文總結了 Pronto 團隊面臨的挑戰以及應對挑戰所構建的流程和工具，還給出了對幾種配置進行基準測試的一些結果。

挑戰

迄今遇到的 Pronto/Elasticsearch 使用場景所面臨的挑戰包括：

• 高吞吐量：一些叢集每天採集的資料高達 5TB，一些叢集每天的搜尋請求超過 4 億。如果 Elasticsearch 無法及時處理這些請求，上游的請求將發生積壓。
• 低搜尋延遲：對於效能比較關鍵的叢集，尤其是面向線上的系統，低搜尋延遲是必需的，否則使用者體驗將受到影響。
• 由於資料或查詢是可變的，所以最佳設定也是變化的。不存在所有情況都是最佳的設定。例如，將索引拆分成更多的分片對於費時的查詢是有好處的，但是這可能會影響其他查詢效能。

解決方案

為了幫助我們的客戶應對這些挑戰，Pronto 團隊為使用者案例上線和整個叢集生命週期，針對性能測試、調優和監控構建了一套策略方法。

1. 預估叢集大小：在新的使用者案例上線之前，收集客戶提供的資訊，如吞吐量、文件大小、文件數量和搜尋型別，以估計 Elasticsearch 叢集的初始大小。
2. 優化索引設計：與客戶一起評估索引設計。
3. 索引效能調優：根據使用者場景進行索引效能和搜尋效能調優。
4. 搜尋效能調優：使用使用者真實資料 / 查詢執行效能測試，比較和分析不同 Elasticsearch 配置引數的測試結果。
5. 執行效能測試：在使用者案例上線後，叢集將受到監控，並且每當資料發生變化，查詢更改或流量增加時，使用者都可以自由地重新執行效能測試。

預估叢集大小

Pronto 團隊為每種型別的機器和每個支援的 Elasticsearch 版本執行基準測試，收集效能資料，然後結合客戶提供的資訊，估算群集初始大小，包括：

• 索引吞吐量
• 文件大小
• 搜尋吞吐量
• 查詢型別
• 熱點索引文件數量
• 保留策略
• 響應時間需求
• SLA 級別

優化索引設計

在開始索引資料和執行查詢之前，我們先考慮一下。索引到底表示什麼？Elastic 的官方答案是“具有某種相似特徵的文件集合”。因此，下一個問題是“應該使用哪些特徵來對資料進行分組？應該把所有文件放入一個索引還是多個索引？”，答案是，這取決於使用的查詢。以下是關於如何根據最常用的查詢組織索引的一些建議。

如果查詢有一個過濾欄位並且它的值是可列舉的，那麼把資料分成多個索引。例如，你有大量的全球產品資訊被採集到 Elasticsearch 中，大多數查詢都有一個過濾條件“地區”，並且很少有機會執行跨地區查詢。如下查詢體可以被優化：

{ "query": { "bool": { "must": { "match": { "title": "${title}" } }, "filter": { "term": { "region": "US" } } } }}

在這種情況下，如果索引按照美國、歐盟等地區分成幾個較小的索引，可以從查詢中刪除過濾子句，查詢效能會更好。如果我們需要執行一個跨地區查詢，我們可以將多個索引或萬用字元傳遞給 Elasticsearch。

如果查詢有一個過濾欄位並且它的值是不可列舉的，建議使用路由。通過使用過濾欄位值作為路由鍵，我們可以將具有相同過濾欄位值的文件索引至同一個分片，並移除過濾子句。

例如，Elasticsearch 叢集中存有數以百萬記的訂單資料，大多數查詢都包含有買方 ID 作為限定從句。為每個買家建立索引是不可能的，所以我們不能通過買方 ID 將資料拆分成多個索引。一個合適的解決方案是，使用路由將具有相同買方 ID 的所有訂單放入相同分片中。然後幾乎所有的查詢都可以在匹配路由鍵的分片內完成。

如果查詢具有日期範圍過濾子句，則按日期建立資料。這適用於大多數日誌記錄和監控場景。我們可以按天、周或月組織索引，然後可以獲得指定的日期範圍內的索引列表，這樣，Elasticsearch 只需要查詢一個較小的資料集而不是整個資料集。另外，當資料過期時，刪除舊的索引也很容易。

明確設定對映。雖然 Elasticsearch 可以動態建立對映，但建立的對映可能並不適用於所有場景。例如，Elasticsearch 5.x 中的預設字串欄位對映是“keyword”和“text”型別。這在很多情況下是沒有必要的。

如果文件使用使用者定義的 ID 或路由進行索引，要避免造成分片不平衡。 Elasticsearch 使用隨機 ID 生成器和雜湊演算法來確保文件均勻地分配給分片。當使用使用者定義的 ID 或路由時，ID 或路由鍵可能不夠隨機，造成一些分片明顯比其他分片大。在這種情況下，這個分片上的讀 / 寫操作會比其他的慢得多。我們可以優化 ID/ 路由鍵或使用 index.routing_partition_size（5.3 和更高版本中可用）。

確保分片均勻分佈在節點上。一個節點如果比其他節點的分片多，則會比其他節點承擔更多的負載，成為整個系統的瓶頸。

索引效能調優

對於日誌記錄和監控等重度索引場景，索引效能是關鍵指標。這裡有一些建議：

• 使用批量請求。
• 使用多執行緒傳送請求。
• 增加重新整理時間間隔。每次重新整理事件發生時，Elasticsearch 都會建立一個新的 Lucene 段，並在稍後進行合併。增加重新整理時間間隔將降低建立和合並的開銷。請注意，文件只有在重新整理後才能搜尋到。

效能和重新整理時間間隔之間的關係

從上圖可以看出，隨著重新整理時間間隔的增加，吞吐量增加，響應時間減少。我們可以使用下面的請求來檢查我們有多少段以及重新整理和合並花了多少時間。

Index/_stats?filter_path= indices..refresh,indices..segments,indices.**.merges

減少副本數量。對於每個索引請求，Elasticsearch 需要將文件寫入主分片和所有副本分片。顯然，副本過多會減慢索引速度，但另一方面，這將提高搜尋效能。我們將在本文後面討論這個問題。

效能和副本數之間的關係

從上圖可以看出，隨著副本數增加，吞吐量下降，響應時間增加。

儘可能使用自動生成的 ID。 Elasticsearch 自動生成的 ID 保證是唯一的，能避免版本查詢。如果客戶真的需要使用自定義的 ID，我們建議選擇一個對 Lucene 友好的 ID，比如零填充順序 ID、UUID-1 或者納秒級時間。這些 ID 具有一致的順序模式，能良好壓縮。相比之下，像 UUID-4 這樣的 ID 本質上是隨機的，壓縮率低，會降低 Lucene 的速度。

搜尋效能調優

使用 Elasticsearch 的主要原因是支援搜尋資料。使用者應該能夠快速找到他們正在尋找的資訊。搜尋效能取決於很多因素。

儘可能使用過濾器上下文（Filter）替代查詢上下文（Query）。 查詢子句用於回答“這個文件與此子句相匹配的程度”，而過濾器子句用於回答“這個文件是否匹配這個子句”，Elasticsearch 只需要回答“是”或“否”，不需要為過濾器子句計算相關性分數，而且過濾器結果可以快取。有關詳細資訊，請參閱查詢和過濾上下文。

查詢和過濾器效能比較

增加重新整理時間間隔。正如我們在索引效能調優中所提到的，Elasticsearch 每次重新整理時都會建立一個新的段。增加重新整理時間間隔將有助於減少段數並降低搜尋的 IO 成本。並且，一旦發生重新整理並且資料改變，快取將會失效。增加重新整理時間間隔可以使 Elasticsearch 更高效地利用快取。

增加副本數。 Elasticsearch 可以在主分片或副本分片上執行搜尋。副本越多，搜尋可用的節點就越多。

搜尋效能和副本數之間的關係

從上圖可以看出，搜尋吞吐量幾乎與副本數量成線性關係。注意在這個測試中，測試叢集有足夠的資料節點來確保每個分片都有一個專有節點。如果這個條件不能滿足，搜尋吞吐量就不會這麼好。

嘗試不同的分片數。“應該為索引設定多少分片呢？”這可能是最常見的問題。遺憾的是，沒有適合所有應用場景的分片數。這完全取決於你的情況。

分片太少會使搜尋無法擴充套件。例如，如果分片數設定為 1，則索引中的所有文件都將儲存在一個分片中。對於每個搜尋，只有一個節點能夠參與計算。如果索引中的檔案數量很多，查詢會很耗時。從另一方面來說，建立的索引分片太多也會對效能造成不利影響，因為 Elasticsearch 需要在所有分片上執行查詢（除非在請求中指定了路由鍵），然後提取併合並所有返回的結果。

根據我們的經驗，如果索引小於 1G，可以將分片數設定為 1。對於大多數場景，我們可以將分片數保留為預設值 5，但是如果分片大小超過 30GB，我們應該增加分片 ，將索引分成更多的分片。建立索引後，分片數不能更改，但是我們可以建立新的索引並使用 reindex API 遷移資料。

我們測試了一個擁有 1 億個文件，大約 150GB 的索引。我們使用了 100 個執行緒傳送搜尋請求。

搜尋效能和分片數量之間的關係

從上圖可以看出，最優的分片數量為 11 個。開始時搜尋吞吐量增大（響應時間減少），但隨著分片數量的增加，搜尋吞吐量減小（響應時間增加）。

請注意，在這個測試中，就像在副本數測試中一樣，每個分片都有一個獨佔節點。如果這個條件不能滿足，搜尋吞吐量將不會像這個圖那樣好。

在這種情況下，我們建議你嘗試一個小於最優值的分片數，因為如果分片多，並且使每個分片都有一個獨佔資料節點，那麼就需要很多節點。

節點查詢快取。節點查詢快取只快取過濾器上下文中使用的查詢。與查詢子句不同，過濾子句是“是”或“否”的問題。Elasticsearch 使用位集（bit set）機制來快取過濾結果，以便後面使用相同的過濾器的查詢進行加速。請注意，Elasticsearch 只對儲存超過 10,000（或文件總數的 3％，以較大者為準）個文件的段啟用查詢快取。有關更多詳細資訊，請參閱快取（文末附連結）。

我們可以使用下面的請求來檢查一個節點查詢快取是否生效。

GET index_name/_stats?filter_path=indices.**.query_cache{ "indices": { "index_name": { "primaries": { "query_cache": { "memory_size_in_bytes": 46004616, "total_count": 1588886, "hit_count": 515001, "miss_count": 1073885, "cache_size": 630, "cache_count": 630, "evictions": 0 } }, "total": { "query_cache": { "memory_size_in_bytes": 46004616, "total_count": 1588886, "hit_count": 515001, "miss_count": 1073885, "cache_size": 630, "cache_count": 630, "evictions": 0 } } } }}

分片查詢快取。如果大多數查詢是聚合查詢，我們應該考慮分片查詢快取。分片查詢快取可以快取聚合結果，以便 Elasticsearch 以低開銷直接處理請求。有幾件事情需要注意：

• 設定“size”為 0。分片查詢快取只快取聚合結果和建議。它不會快取命中，因此如果將 size 設定為非零，則無法從快取中獲益。
• 查詢請求的負載（Payload）必須完全相同。分片查詢快取使用請求負載作為快取鍵，因此需要確保後續查詢請求的負載必須和之前的完全一致。由於負載中 JSON 鍵的順序變化會導致負載變化，故建議對負載的鍵進行排序來確保順序一致。
• 處理好日期時間。不要直接在查詢中使用像 Date.now 這樣的變數。否則，每個請求的請求體都不同，從而導致快取始終無效。我們建議將日期時間整理為小時或天，以便更有效地利用快取。

我們可以使用下面的請求來檢查分片查詢快取是否有效。

GET index_name/_stats?filter_path=indices.**.request_cache{ "indices": { "index_name": { "primaries": { "request_cache": { "memory_size_in_bytes": 0, "evictions": 0, "hit_count": 541, "miss_count": 514098 } }, "total": { "request_cache": { "memory_size_in_bytes": 0, "evictions": 0, "hit_count": 982, "miss_count": 947321 } } } }}

僅檢索必要的欄位。如果文件很大，而你只需要幾個欄位，請使用 stored_fields 檢索需要的欄位而不是所有欄位。

避免搜尋停用詞。諸如“a”和“the”等停用詞可能導致查詢命中結果數暴增。假設你有一百萬個文件。搜尋“fox”可能會返回幾十個命中文件，但搜尋“the fox”可能會返回索引中的所有文件，因為“the”幾乎出現在所有文件中。Elasticsearch 需要對所有命中的結果進行評分和排序，以致像“the fox”這樣的查詢會減慢整個系統。你可以使用停用詞過濾器來刪除停用詞，或使用“and”運算子將查詢更改為“the AND fox”，獲得更精確的結果。

如果某些單詞在索引中經常使用，但不在預設停用詞列表中，則可以使用截止頻率來動態處理它們。

如果不關心文件返回的順序，則按 _doc 排序。 Elasticsearch 預設使用“_score”欄位按評分排序。如果不關心順序，可以使用"sort":"_doc"讓 Elasticsearch 按索引順序返回命中文件，可以節省排序開銷。

避免使用指令碼查詢（ query）計算動態欄位，建議在索引時計算並在文件中新增該欄位。例如，我們有一個包含大量使用者資訊的索引，我們需要查詢以"1234"開頭的所有使用者。你可能執行一個指令碼查詢，如"source":"doc['num'].value.startsWith（'1234'）"。這個查詢非常耗費資源，並且減慢整個系統。索引時考慮新增一個名為“num_prefix”的欄位。然後我們可以查詢"name_prefix":"1234"。

避免使用萬用字元查詢。

執行效能測試

對於每一次變更，都需要執行效能測試來驗證變更是否適用。因為 Elasticsearch 是一個 RESTful 服務，所以可以使用 Rally、Apache Jmeter 和 Gatling 等工具來執行效能測試。因為 Pronto 團隊需要在每種型別的機器和 Elasticsearch 版本上執行大量的基準測試，而且需要在許多 Elasticsearch 叢集上針對不同 Elasticsearch 配置引數執行效能測試，所以這些工具不能滿足我們的要求。

Pronto 團隊建立了基於 Gatling 的線上效能分析服務，幫助客戶和我們執行效能測試和迴歸測試。該服務提供的功能有：

1. 輕鬆新增和編輯測試。使用者無需 Gatling 或 Scala 知識即可根據輸入的查詢或文件結構生成測試。
2. 順序執行多個測試，無需人工干預。該服務可以檢查狀態並在每次測試之前 / 之後更改 Elasticsearch 設定。
3. 幫助使用者比較和分析測試結果。測試期間的測試結果和叢集統計資訊將保留下來，並可以通過預定義的 Kibana 視覺化進行分析。
4. 從命令列或 Web UI 執行測試。該服務提供了與其他系統整合的 Rest API。

架構如下：

效能測試服務架構

使用者可以檢視每個測試的 Gatling 報告，並檢視 Kibana 預定義的視覺化影象，以便進一步分析和比較，如下所示。

總結

本文總結了在設計滿足高期望的採集和搜尋效能的 Elasticsearch 叢集時應該考慮的索引 / 分片 / 副本設計以及一些其他配置，還說明了 Pronto 如何在策略上幫助客戶進行初始規模調整、索引設計和調優以及效能測試。截至今天，Pronto 團隊已經幫助包括訂單管理系統（OMS）和搜尋引擎優化（SEO）在內的眾多客戶實現了苛刻的效能目標，從而為 eBay 的關鍵業務作出了貢獻。

Elasticsearch 的效能取決於很多因素，包括文件結構、文件大小、索引設定 / 對映、請求率、資料集大小和查詢命中次數等等。針對一種情況的建議不一定適用於另一種情況，因此，徹底進行效能測試、收集資料、根據負載調整配置以及優化叢集以滿足效能要求非常重要。

檢視英文原文：https://www.ebayinc.com/stories/blogs/tech/elasticsearch-performance-tuning-practice-at-ebay/