K60 Pro官方停產 第三方瞬間漲價
雖然沒有官方宣布，但Redmi的一些高管也已經透露了，Redmi K60 Pro已經停產且不會補貨，這一切都是為了即將到來的K60 Ultra鋪路，屬于廠家的正常操作。但有意思的是該機在停產之后
在使用 Elasticsearch 進行數據查詢時，很多開發者、讀者會遇到這樣的問題：一次性檢索大量數據，導致查詢速度緩慢、網絡延遲增加，甚至影響系統的整體性能。
單次獲取過多數據不僅增加了網絡傳輸的負擔，還會使查詢過程復雜化，降低響應速度。
本文將深入探討該誤區的常見場景、錯誤原因以及優化方案，幫助大家有效避免這個常見的性能陷阱。
許多開發者在使用 Elasticsearch 進行數據查詢時，往往試圖一次性獲取大量文檔，認為可以減少查詢次數并加速開發流程。
圖片
——來源：https://t.zsxq.com/cYUnx
圖片
問題來源：https://articles.zsxq.com/id_qvaduu4ejgns.html
然而，Elasticsearch 是為分布式環境設計的，單次大規模的數據檢索會對系統的性能造成負面影響，
具體表現為：
某電商平臺的用戶數據存儲在一個包含數百萬條用戶記錄的 Elasticsearch 索引中。
業務部門需要查詢用戶數據進行分析，但開發團隊直接通過 match_all 查詢所有用戶，并設置 size 參數為 10000，試圖一次性獲取大量數據。
GET /users/_search{"query": {"match_all": {}},"size": 10000}該查詢一次性返回 10000 條完整的用戶數據，導致以下問題：
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
處理如此多的數據占用了系統資源，使得查詢速度減慢，影響了其他業務請求。
由于查詢響應緩慢，業務人員在使用系統時感覺卡頓，影響日常工作效率。
出現這種性能問題的主要原因是：
在大量數據場景中，單次獲取 10000 條數據會顯著增加負載。
默認情況下，Elasticsearch 返回每個文檔的所有字段，而業務部門往往只需要幾個關鍵字段。
沒有采用分頁機制來分批獲取數據，而是直接獲取整個結果集。
要優化這種場景下的查詢，以下幾種策略可以顯著提升性能：
通過分頁機制限制每次查詢返回的文檔數量，避免一次性獲取過多數據。
分頁不僅能減小單次查詢的負載，還能提升整體查詢的穩定性。
GET /users/_search{ "query": { "match_all": {} }, "size": 10, "from": 0}這個查詢一次性只返回 10條文檔，并且可以通過 from 參數進行分頁查詢，避免單次查詢獲取過多數據。
這里深度分頁的弊端關注一下，如下兩幅圖（建議放大查看）所示：Elasticsearch 中的深分頁問題是一個常見的性能陷阱，因為越深的分頁需要對越多的數據進行處理，這可能導致大量的資源消耗。
假設不斷在這個邊緣試探，會導致內存耗盡甚至有宕機風險。
圖片
圖片
問題參見：https://t.zsxq.com/RNWdK
在業務場景中，并非所有字段都是必要的，因此通過源過濾功能只返回特定字段可以減少數據傳輸量，進而提升查詢效率。
GET /users/_search{ "query": { "match_all": {} }, "_source": ["name", "email"], "size": 10, "from": 0}這個查詢只返回用戶的 name 和 email 字段，減少了不必要的字段傳輸，降低了網絡延遲和系統資源的消耗。
如果需要更新用戶文檔，你可以只提供更新的字段，Elasticsearch 會重新索引整個文檔，但不需要在請求中提交完整文檔。部分更新減少了請求體的大小，但重新索引整個文檔的操作仍會發生。
POST /users/_update/1{ "doc": { "email": "new_email@example.com" }}對于確實需要處理大量數據的場景，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 保持了上下文信息，允許高效地分批處理數據，適用于一次性處理大量數據的批處理任務。
避免使用過于寬泛的查詢條件，如 match_all，可以通過精確條件限定查詢結果集的大小。
如果你只關心統計數據而不是具體文檔，利用 Elasticsearch 的聚合功能可以直接返回統計結果，避免大量數據傳輸。
定期優化索引，確保分片和副本的設置合理，避免查詢時的熱點問題。
在使用 Elasticsearch 時，合理設計查詢是提升系統性能的關鍵。
通過限制返回文檔數量、使用源過濾和部分更新等技術，可以有效減少數據傳輸量，提高查詢效率。
對于需要檢索大量數據的情況，利用 Scroll API 和分頁機制，可以進一步優化查詢性能，避免一次性獲取大量數據帶來的性能問題。
Elasticsearch 的強大功能需要合理使用，開發者應根據實際業務需求設計高效的查詢方案，以充分發揮其優勢。
本文鏈接：http://m.www897cc.com/showinfo-26-112731-0.htmlElasticsearch 使用誤區—單次請求獲取大量數據
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
下一篇： Asp.Net Core實戰-JWT詳解
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號