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

單次獲取過(guò)多數(shù)據(jù)不僅增加了網(wǎng)絡(luò)傳輸?shù)呢?fù)擔(dān)，還會(huì)使查詢(xún)過(guò)程復(fù)雜化，降低響應(yīng)速度。

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

1. 誤區(qū)背景：?jiǎn)未潍@取大量數(shù)據(jù)

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

圖片

——來(lái)源：https://t.zsxq.com/cYUnx

圖片

問(wèn)題來(lái)源：https://articles.zsxq.com/id_qvaduu4ejgns.html

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

具體表現(xiàn)為：

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

2. 真實(shí)場(chǎng)景：電商平臺(tái)用戶(hù)查詢(xún)

2.1 場(chǎng)景描述：

某電商平臺(tái)的用戶(hù)數(shù)據(jù)存儲(chǔ)在一個(gè)包含數(shù)百萬(wàn)條用戶(hù)記錄的 Elasticsearch 索引中。

業(yè)務(wù)部門(mén)需要查詢(xún)用戶(hù)數(shù)據(jù)進(jìn)行分析，但開(kāi)發(fā)團(tuán)隊(duì)直接通過(guò) match_all 查詢(xún)所有用戶(hù)，并設(shè)置 size 參數(shù)為 10000，試圖一次性獲取大量數(shù)據(jù)。

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

2.2 問(wèn)題描述：

該查詢(xún)一次性返回 10000 條完整的用戶(hù)數(shù)據(jù)，導(dǎo)致以下問(wèn)題：

• 問(wèn)題1：網(wǎng)絡(luò)延遲

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

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

具體限制的設(shè)置項(xiàng)是：

index.mapping.total_fields.limit

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

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

• 問(wèn)題2：查詢(xún)性能問(wèn)題

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

• 問(wèn)題3：用戶(hù)體驗(yàn)差

由于查詢(xún)響應(yīng)緩慢，業(yè)務(wù)人員在使用系統(tǒng)時(shí)感覺(jué)卡頓，影響日常工作效率。

3、錯(cuò)誤原因分析

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

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

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

• 可能原因2：未使用字段過(guò)濾

默認(rèn)情況下，Elasticsearch 返回每個(gè)文檔的所有字段，而業(yè)務(wù)部門(mén)往往只需要幾個(gè)關(guān)鍵字段。

• 可能原因3：未分頁(yè)處理

沒(méi)有采用分頁(yè)機(jī)制來(lái)分批獲取數(shù)據(jù)，而是直接獲取整個(gè)結(jié)果集。

4、改進(jìn)方案

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

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

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

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

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

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

這里深度分頁(yè)的弊端關(guān)注一下，如下兩幅圖（建議放大查看）所示：Elasticsearch 中的深分頁(yè)問(wèn)題是一個(gè)常見(jiàn)的性能陷阱，因?yàn)樵缴畹姆猪?yè)需要對(duì)越多的數(shù)據(jù)進(jìn)行處理，這可能導(dǎo)致大量的資源消耗。

假設(shè)不斷在這個(gè)邊緣試探，會(huì)導(dǎo)致內(nèi)存耗盡甚至有宕機(jī)風(fēng)險(xiǎn)。

圖片

圖片

問(wèn)題參見(jiàn)：https://t.zsxq.com/RNWdK

4.2 使用源過(guò)濾（_source filtering）

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

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

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

4.3 利用部分更新

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

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

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

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

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

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

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

滾動(dòng)查詢(xún)需要使用 scroll_id 獲取接下來(lái)的批次，直到所有數(shù)據(jù)被檢索完。

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

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

5.1 合理設(shè)置查詢(xún)條件

避免使用過(guò)于寬泛的查詢(xún)條件，如 match_all，可以通過(guò)精確條件限定查詢(xún)結(jié)果集的大小。

5.2 使用聚合功能

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

5.3 索引優(yōu)化

定期優(yōu)化索引，確保分片和副本的設(shè)置合理，避免查詢(xún)時(shí)的熱點(diǎn)問(wèn)題。

6. 小結(jié)

在使用 Elasticsearch 時(shí)，合理設(shè)計(jì)查詢(xún)是提升系統(tǒng)性能的關(guān)鍵。

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

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

Elasticsearch 的強(qiáng)大功能需要合理使用，開(kāi)發(fā)者應(yīng)根據(jù)實(shí)際業(yè)務(wù)需求設(shè)計(jì)高效的查詢(xún)方案，以充分發(fā)揮其優(yōu)勢(shì)。