在使用 Elasticsearch 進行數(shù)據(jù)查詢時，很多開發(fā)者、讀者會遇到這樣的問題：一次性檢索大量數(shù)據(jù)，導致查詢速度緩慢、網(wǎng)絡延遲增加，甚至影響系統(tǒng)的整體性能。

單次獲取過多數(shù)據(jù)不僅增加了網(wǎng)絡傳輸?shù)呢摀€會使查詢過程復雜化，降低響應速度。

本文將深入探討該誤區(qū)的常見場景、錯誤原因以及優(yōu)化方案，幫助大家有效避免這個常見的性能陷阱。

1. 誤區(qū)背景：單次獲取大量數(shù)據(jù)

許多開發(fā)者在使用 Elasticsearch 進行數(shù)據(jù)查詢時，往往試圖一次性獲取大量文檔，認為可以減少查詢次數(shù)并加速開發(fā)流程。

圖片

——來源：https://t.zsxq.com/cYUnx

圖片

問題來源：https://articles.zsxq.com/id_qvaduu4ejgns.html

然而，Elasticsearch 是為分布式環(huán)境設計的，單次大規(guī)模的數(shù)據(jù)檢索會對系統(tǒng)的性能造成負面影響，

具體表現(xiàn)為：

1. 網(wǎng)絡延遲增加。 大量數(shù)據(jù)的傳輸會占用帶寬資源，導致網(wǎng)絡延遲加大。
2. 查詢性能下降。系統(tǒng)需要消耗更多的內存和 CPU 來處理大規(guī)模結果集，進而拖慢查詢速度。
3. 系統(tǒng)負載增加。在負載高峰期，多個大查詢可能導致節(jié)點資源過載。

2. 真實場景：電商平臺用戶查詢

2.1 場景描述：

某電商平臺的用戶數(shù)據(jù)存儲在一個包含數(shù)百萬條用戶記錄的 Elasticsearch 索引中。

業(yè)務部門需要查詢用戶數(shù)據(jù)進行分析，但開發(fā)團隊直接通過 match_all 查詢所有用戶，并設置 size 參數(shù)為 10000，試圖一次性獲取大量數(shù)據(jù)。

GET /users/_search
{
"query": {
"match_all": {}
},
"size": 10000
}

2.2 問題描述：

該查詢一次性返回 10000 條完整的用戶數(shù)據(jù)，導致以下問題：

• 問題1：網(wǎng)絡延遲

10,000 條數(shù)據(jù)中包含許多不必要的字段，增大了網(wǎng)絡傳輸?shù)臄?shù)據(jù)量，導致響應時間延長。

大家知道， Elasticsearch 非 MySQL 等關系型數(shù)據(jù)庫，字段不需要提前設定，如果 Mapping 不設置 strict 而是 默認值，意味著字段可以無限擴充，直到接近默認值 1000。

具體限制的設置項是：

index.mapping.total_fields.limit

此參數(shù)決定一個索引中可以包含的字段的最大數(shù)量。默認值是 1000。

https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-settings-limit.html

• 問題2：查詢性能問題

處理如此多的數(shù)據(jù)占用了系統(tǒng)資源，使得查詢速度減慢，影響了其他業(yè)務請求。

• 問題3：用戶體驗差

由于查詢響應緩慢，業(yè)務人員在使用系統(tǒng)時感覺卡頓，影響日常工作效率。

3、錯誤原因分析

出現(xiàn)這種性能問題的主要原因是：

• 可能原因1：一次性獲取過多數(shù)據(jù)

在大量數(shù)據(jù)場景中，單次獲取 10000 條數(shù)據(jù)會顯著增加負載。

• 可能原因2：未使用字段過濾

默認情況下，Elasticsearch 返回每個文檔的所有字段，而業(yè)務部門往往只需要幾個關鍵字段。

• 可能原因3：未分頁處理

沒有采用分頁機制來分批獲取數(shù)據(jù)，而是直接獲取整個結果集。

4、改進方案

要優(yōu)化這種場景下的查詢，以下幾種策略可以顯著提升性能：

4.1 限制返回的文檔數(shù)量

通過分頁機制限制每次查詢返回的文檔數(shù)量，避免一次性獲取過多數(shù)據(jù)。

分頁不僅能減小單次查詢的負載，還能提升整體查詢的穩(wěn)定性。

GET /users/_search
{
  "query": {
    "match_all": {}
  },
  "size": 10,
  "from": 0
}

這個查詢一次性只返回 10條文檔，并且可以通過 from 參數(shù)進行分頁查詢，避免單次查詢獲取過多數(shù)據(jù)。

這里深度分頁的弊端關注一下，如下兩幅圖（建議放大查看）所示：Elasticsearch 中的深分頁問題是一個常見的性能陷阱，因為越深的分頁需要對越多的數(shù)據(jù)進行處理，這可能導致大量的資源消耗。

假設不斷在這個邊緣試探，會導致內存耗盡甚至有宕機風險。

圖片

圖片

問題參見：https://t.zsxq.com/RNWdK

4.2 使用源過濾（_source filtering）

在業(yè)務場景中，并非所有字段都是必要的，因此通過源過濾功能只返回特定字段可以減少數(shù)據(jù)傳輸量，進而提升查詢效率。

GET /users/_search
{
  "query": {
    "match_all": {}
  },
  "_source": ["name", "email"],
  "size": 10,
  "from": 0
}

這個查詢只返回用戶的 name 和 email 字段，減少了不必要的字段傳輸，降低了網(wǎng)絡延遲和系統(tǒng)資源的消耗。

4.3 利用部分更新

如果需要更新用戶文檔，你可以只提供更新的字段，Elasticsearch 會重新索引整個文檔，但不需要在請求中提交完整文檔。部分更新減少了請求體的大小，但重新索引整個文檔的操作仍會發(fā)生。

POST /users/_update/1
{
  "doc": {
    "email": "new_email@example.com"
  }
}

4.4 使用 Scroll API 或 search_after 處理大量數(shù)據(jù)

對于確實需要處理大量數(shù)據(jù)的場景，Scroll API 是更好的解決方案。Scroll API 允許你分批檢索大量文檔而不會影響集群性能。

GET /users/_search?scroll=1m
{
  "query": {
    "match_all": {}
  },
  "size": 100
}

POST /_search/scroll
{
  "scroll": "1m",
  "scroll_id": "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAPnMWSU5tbk5Za1NsVEd..."
}

初始查詢的時候，設置 scroll 參數(shù)并指定時間窗口，初次檢索 100 條數(shù)據(jù)。

滾動查詢需要使用 scroll_id 獲取接下來的批次，直到所有數(shù)據(jù)被檢索完。

Scroll API 保持了上下文信息，允許高效地分批處理數(shù)據(jù)，適用于一次性處理大量數(shù)據(jù)的批處理任務。

5. 進一步優(yōu)化建議

5.1 合理設置查詢條件

避免使用過于寬泛的查詢條件，如 match_all，可以通過精確條件限定查詢結果集的大小。

5.2 使用聚合功能

如果你只關心統(tǒng)計數(shù)據(jù)而不是具體文檔，利用 Elasticsearch 的聚合功能可以直接返回統(tǒng)計結果，避免大量數(shù)據(jù)傳輸。

5.3 索引優(yōu)化

定期優(yōu)化索引，確保分片和副本的設置合理，避免查詢時的熱點問題。

6. 小結

在使用 Elasticsearch 時，合理設計查詢是提升系統(tǒng)性能的關鍵。

通過限制返回文檔數(shù)量、使用源過濾和部分更新等技術，可以有效減少數(shù)據(jù)傳輸量，提高查詢效率。

對于需要檢索大量數(shù)據(jù)的情況，利用 Scroll API 和分頁機制，可以進一步優(yōu)化查詢性能，避免一次性獲取大量數(shù)據(jù)帶來的性能問題。

Elasticsearch 的強大功能需要合理使用，開發(fā)者應根據(jù)實際業(yè)務需求設計高效的查詢方案，以充分發(fā)揮其優(yōu)勢。