Elasticsearch 使用誤區—單次請求獲取大量數據
在使用 Elasticsearch 進行數據查詢時，很多開發者、讀者會遇到這樣的問題：一次性檢索大量數據，導致查詢速度緩慢、網絡延遲增加，甚至影響系統的整體性能。
單次獲取過多數據不僅增加了網絡傳輸的負擔，還會使查詢過程復雜化，降低響應速度。
本文將深入探討該誤區的常見場景、錯誤原因以及優化方案，幫助大家有效避免這個常見的性能陷阱。
1. 誤區背景：單次獲取大量數據
許多開發者在使用 Elasticsearch 進行數據查詢時，往往試圖一次性獲取大量文檔，認為可以減少查詢次數并加速開發流程。
圖片
——來源：https://t.zsxq.com/cYUnx
圖片
問題來源：https://articles.zsxq.com/id_qvaduu4ejgns.html
然而，Elasticsearch 是為分布式環境設計的，單次大規模的數據檢索會對系統的性能造成負面影響，
具體表現為：
- 網絡延遲增加。 大量數據的傳輸會占用帶寬資源，導致網絡延遲加大。
- 查詢性能下降。系統需要消耗更多的內存和 CPU 來處理大規模結果集，進而拖慢查詢速度。
- 系統負載增加。在負載高峰期，多個大查詢可能導致節點資源過載。
2. 真實場景：電商平臺用戶查詢
2.1 場景描述：
某電商平臺的用戶數據存儲在一個包含數百萬條用戶記錄的 Elasticsearch 索引中。
業務部門需要查詢用戶數據進行分析，但開發團隊直接通過 match_all 查詢所有用戶，并設置 size 參數為 10000，試圖一次性獲取大量數據。
GET /users/_search
{
"query": {
"match_all": {}
},
"size": 10000
}2.2 問題描述：
該查詢一次性返回 10000 條完整的用戶數據，導致以下問題：
- 問題1：網絡延遲
10,000 條數據中包含許多不必要的字段，增大了網絡傳輸的數據量，導致響應時間延長。
大家知道， Elasticsearch 非 MySQL 等關系型數據庫，字段不需要提前設定，如果 Mapping 不設置 strict 而是 默認值，意味著字段可以無限擴充，直到接近默認值 1000。
具體限制的設置項是：
index.mapping.total_fields.limit此參數決定一個索引中可以包含的字段的最大數量。默認值是 1000。
https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-settings-limit.html
- 問題2：查詢性能問題
處理如此多的數據占用了系統資源，使得查詢速度減慢，影響了其他業務請求。
- 問題3：用戶體驗差
由于查詢響應緩慢，業務人員在使用系統時感覺卡頓，影響日常工作效率。
3、錯誤原因分析
出現這種性能問題的主要原因是：
- 可能原因1：一次性獲取過多數據
在大量數據場景中，單次獲取 10000 條數據會顯著增加負載。
- 可能原因2：未使用字段過濾
默認情況下，Elasticsearch 返回每個文檔的所有字段，而業務部門往往只需要幾個關鍵字段。
- 可能原因3：未分頁處理
沒有采用分頁機制來分批獲取數據，而是直接獲取整個結果集。
4、改進方案
要優化這種場景下的查詢，以下幾種策略可以顯著提升性能：
4.1 限制返回的文檔數量
通過分頁機制限制每次查詢返回的文檔數量，避免一次性獲取過多數據。
分頁不僅能減小單次查詢的負載，還能提升整體查詢的穩定性。
GET /users/_search
{
"query": {
"match_all": {}
},
"size": 10,
"from": 0
}這個查詢一次性只返回 10條文檔，并且可以通過 from 參數進行分頁查詢，避免單次查詢獲取過多數據。
這里深度分頁的弊端關注一下，如下兩幅圖（建議放大查看）所示：Elasticsearch 中的深分頁問題是一個常見的性能陷阱，因為越深的分頁需要對越多的數據進行處理，這可能導致大量的資源消耗。
假設不斷在這個邊緣試探，會導致內存耗盡甚至有宕機風險。
圖片
圖片
問題參見：https://t.zsxq.com/RNWdK
4.2 使用源過濾（_source filtering）
在業務場景中，并非所有字段都是必要的，因此通過源過濾功能只返回特定字段可以減少數據傳輸量，進而提升查詢效率。
GET /users/_search
{
"query": {
"match_all": {}
},
"_source": ["name", "email"],
"size": 10,
"from": 0
}這個查詢只返回用戶的 name 和 email 字段，減少了不必要的字段傳輸，降低了網絡延遲和系統資源的消耗。
4.3 利用部分更新
如果需要更新用戶文檔，你可以只提供更新的字段，Elasticsearch 會重新索引整個文檔，但不需要在請求中提交完整文檔。部分更新減少了請求體的大小，但重新索引整個文檔的操作仍會發生。
POST /users/_update/1
{
"doc": {
"email": "new_email@example.com"
}
}4.4 使用 Scroll API 或 search_after 處理大量數據
對于確實需要處理大量數據的場景，Scroll API 是更好的解決方案。Scroll API 允許你分批檢索大量文檔而不會影響集群性能。
GET /users/_search?scroll=1m
{
"query": {
"match_all": {}
},
"size": 100
}
POST /_search/scroll
{
"scroll": "1m",
"scroll_id": "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAPnMWSU5tbk5Za1NsVEd..."
}初始查詢的時候，設置 scroll 參數并指定時間窗口，初次檢索 100 條數據。
滾動查詢需要使用 scroll_id 獲取接下來的批次，直到所有數據被檢索完。
Scroll API 保持了上下文信息，允許高效地分批處理數據，適用于一次性處理大量數據的批處理任務。
5. 進一步優化建議
5.1 合理設置查詢條件
避免使用過于寬泛的查詢條件，如 match_all，可以通過精確條件限定查詢結果集的大小。
5.2 使用聚合功能
如果你只關心統計數據而不是具體文檔，利用 Elasticsearch 的聚合功能可以直接返回統計結果，避免大量數據傳輸。
5.3 索引優化
定期優化索引，確保分片和副本的設置合理，避免查詢時的熱點問題。
6. 小結
在使用 Elasticsearch 時，合理設計查詢是提升系統性能的關鍵。
通過限制返回文檔數量、使用源過濾和部分更新等技術，可以有效減少數據傳輸量，提高查詢效率。
對于需要檢索大量數據的情況，利用 Scroll API 和分頁機制，可以進一步優化查詢性能，避免一次性獲取大量數據帶來的性能問題。
Elasticsearch 的強大功能需要合理使用，開發者應根據實際業務需求設計高效的查詢方案，以充分發揮其優勢。
