2023年Q2用戶偏好榜：12+256G版本成新主流
3月份的性能榜、性價(jià)比榜和好評榜之后，就要輪到2023年的第二季度偏好榜了，上半年的新機(jī)潮已經(jīng)過去，最明顯的肯定就是大內(nèi)存和存儲(chǔ)的機(jī)型了，另外部分中端機(jī)也取消了屏幕塑料支架
在使用 Elasticsearch 進(jìn)行數(shù)據(jù)查詢時(shí)，很多開發(fā)者、讀者會(huì)遇到這樣的問題：一次性檢索大量數(shù)據(jù)，導(dǎo)致查詢速度緩慢、網(wǎng)絡(luò)延遲增加，甚至影響系統(tǒng)的整體性能。
單次獲取過多數(shù)據(jù)不僅增加了網(wǎng)絡(luò)傳輸?shù)呢?fù)擔(dān)，還會(huì)使查詢過程復(fù)雜化，降低響應(yīng)速度。
本文將深入探討該誤區(qū)的常見場景、錯(cuò)誤原因以及優(yōu)化方案，幫助大家有效避免這個(gè)常見的性能陷阱。
許多開發(fā)者在使用 Elasticsearch 進(jìn)行數(shù)據(jù)查詢時(shí)，往往試圖一次性獲取大量文檔，認(rèn)為可以減少查詢次數(shù)并加速開發(fā)流程。
圖片
——來源：https://t.zsxq.com/cYUnx
圖片
問題來源：https://articles.zsxq.com/id_qvaduu4ejgns.html
然而，Elasticsearch 是為分布式環(huán)境設(shè)計(jì)的，單次大規(guī)模的數(shù)據(jù)檢索會(huì)對系統(tǒng)的性能造成負(fù)面影響，
具體表現(xiàn)為：
某電商平臺(tái)的用戶數(shù)據(jù)存儲(chǔ)在一個(gè)包含數(shù)百萬條用戶記錄的 Elasticsearch 索引中。
業(yè)務(wù)部門需要查詢用戶數(shù)據(jù)進(jìn)行分析，但開發(fā)團(tuán)隊(duì)直接通過 match_all 查詢所有用戶，并設(shè)置 size 參數(shù)為 10000，試圖一次性獲取大量數(shù)據(jù)。
GET /users/_search{"query": {"match_all": {}},"size": 10000}該查詢一次性返回 10000 條完整的用戶數(shù)據(jù)，導(dǎo)致以下問題：
10,000 條數(shù)據(jù)中包含許多不必要的字段，增大了網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量，導(dǎo)致響應(yīng)時(shí)間延長。
大家知道， Elasticsearch 非 MySQL 等關(guān)系型數(shù)據(jù)庫，字段不需要提前設(shè)定，如果 Mapping 不設(shè)置 strict 而是 默認(rèn)值，意味著字段可以無限擴(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
處理如此多的數(shù)據(jù)占用了系統(tǒng)資源，使得查詢速度減慢，影響了其他業(yè)務(wù)請求。
由于查詢響應(yīng)緩慢，業(yè)務(wù)人員在使用系統(tǒng)時(shí)感覺卡頓，影響日常工作效率。
出現(xiàn)這種性能問題的主要原因是：
在大量數(shù)據(jù)場景中，單次獲取 10000 條數(shù)據(jù)會(huì)顯著增加負(fù)載。
默認(rèn)情況下，Elasticsearch 返回每個(gè)文檔的所有字段，而業(yè)務(wù)部門往往只需要幾個(gè)關(guān)鍵字段。
沒有采用分頁機(jī)制來分批獲取數(shù)據(jù)，而是直接獲取整個(gè)結(jié)果集。
要優(yōu)化這種場景下的查詢，以下幾種策略可以顯著提升性能：
通過分頁機(jī)制限制每次查詢返回的文檔數(shù)量，避免一次性獲取過多數(shù)據(jù)。
分頁不僅能減小單次查詢的負(fù)載，還能提升整體查詢的穩(wěn)定性。
GET /users/_search{ "query": { "match_all": {} }, "size": 10, "from": 0}這個(gè)查詢一次性只返回 10條文檔，并且可以通過 from 參數(shù)進(jìn)行分頁查詢，避免單次查詢獲取過多數(shù)據(jù)。
這里深度分頁的弊端關(guān)注一下，如下兩幅圖（建議放大查看）所示：Elasticsearch 中的深分頁問題是一個(gè)常見的性能陷阱，因?yàn)樵缴畹姆猪撔枰獙υ蕉嗟臄?shù)據(jù)進(jìn)行處理，這可能導(dǎo)致大量的資源消耗。
假設(shè)不斷在這個(gè)邊緣試探，會(huì)導(dǎo)致內(nèi)存耗盡甚至有宕機(jī)風(fēng)險(xiǎn)。
圖片
圖片
問題參見：https://t.zsxq.com/RNWdK
在業(yè)務(wù)場景中，并非所有字段都是必要的，因此通過源過濾功能只返回特定字段可以減少數(shù)據(jù)傳輸量，進(jìn)而提升查詢效率。
GET /users/_search{ "query": { "match_all": {} }, "_source": ["name", "email"], "size": 10, "from": 0}這個(gè)查詢只返回用戶的 name 和 email 字段，減少了不必要的字段傳輸，降低了網(wǎng)絡(luò)延遲和系統(tǒng)資源的消耗。
如果需要更新用戶文檔，你可以只提供更新的字段，Elasticsearch 會(huì)重新索引整個(gè)文檔，但不需要在請求中提交完整文檔。部分更新減少了請求體的大小，但重新索引整個(gè)文檔的操作仍會(huì)發(fā)生。
POST /users/_update/1{ "doc": { "email": "new_email@example.com" }}對于確實(shí)需要處理大量數(shù)據(jù)的場景，Scroll API 是更好的解決方案。Scroll API 允許你分批檢索大量文檔而不會(huì)影響集群性能。
GET /users/_search?scroll=1m{ "query": { "match_all": {} }, "size": 100}POST /_search/scroll{ "scroll": "1m", "scroll_id": "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAPnMWSU5tbk5Za1NsVEd..."}初始查詢的時(shí)候，設(shè)置 scroll 參數(shù)并指定時(shí)間窗口，初次檢索 100 條數(shù)據(jù)。
滾動(dòng)查詢需要使用 scroll_id 獲取接下來的批次，直到所有數(shù)據(jù)被檢索完。
Scroll API 保持了上下文信息，允許高效地分批處理數(shù)據(jù)，適用于一次性處理大量數(shù)據(jù)的批處理任務(wù)。
避免使用過于寬泛的查詢條件，如 match_all，可以通過精確條件限定查詢結(jié)果集的大小。
如果你只關(guān)心統(tǒng)計(jì)數(shù)據(jù)而不是具體文檔，利用 Elasticsearch 的聚合功能可以直接返回統(tǒng)計(jì)結(jié)果，避免大量數(shù)據(jù)傳輸。
定期優(yōu)化索引，確保分片和副本的設(shè)置合理，避免查詢時(shí)的熱點(diǎn)問題。
在使用 Elasticsearch 時(shí)，合理設(shè)計(jì)查詢是提升系統(tǒng)性能的關(guān)鍵。
通過限制返回文檔數(shù)量、使用源過濾和部分更新等技術(shù)，可以有效減少數(shù)據(jù)傳輸量，提高查詢效率。
對于需要檢索大量數(shù)據(jù)的情況，利用 Scroll API 和分頁機(jī)制，可以進(jìn)一步優(yōu)化查詢性能，避免一次性獲取大量數(shù)據(jù)帶來的性能問題。
Elasticsearch 的強(qiáng)大功能需要合理使用，開發(fā)者應(yīng)根據(jù)實(shí)際業(yè)務(wù)需求設(shè)計(jì)高效的查詢方案，以充分發(fā)揮其優(yōu)勢。
本文鏈接：http://www.tebozhan.com/showinfo-26-112731-0.htmlElasticsearch 使用誤區(qū)—單次請求獲取大量數(shù)據(jù)
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)