• 自動秒收錄
  • 軟件:1972
  • 資訊:54969|
  • 收錄網站:109042|

IT精英團

JD.COM面試問題:ElasticSearch如何解決深度分頁的問題?

JD.COM面試問題:ElasticSearch如何解決深度分頁的問題?

瀏覽次數:
評論次數:
編輯: 陽煦
信息來源: ITPUB
更新日期: 2022-03-21 18:33:30
摘要

前言Elasticsearch是一個實時的分布式搜索與分析引擎,在使用過程中,有一些典型的使用場景,比如分頁、遍歷等。在使用關系型數據庫中,我們被告知要注意甚至被明確禁止使用深度分頁,同理,在Elasticsearch中,也應該盡量避免使用深度分頁。這篇文章主要介紹Elasticsearch中分頁相

  • 正文開始
  • 相關閱讀
  • 推薦作品

Elasticsearch是一個實時分布式搜索和分析引擎。在使用的過程中,有一些典型的使用場景,比如分頁、遍歷等。

在關系數據庫的使用中,我們被告知要注意甚至明確禁止深度分頁的使用。同樣,在Elasticsearch中,也要盡量避免使用深度分頁。

本文主要介紹Elasticsearch中分頁相關的內容!

From/Size參數

在ES中,缺省情況下分頁查詢返回前10個匹配的命中結果。

如果需要分頁,您需要使用from和size參數。

from參數定義需要跳過的命中次數,默認值為0;

size參數定義要返回的最大命中數。

基本的ES查詢語句是這樣的:

帖子/我的索引/我的類型/_搜索

{

查詢' :{'match_all':{},

從:100開始,

尺寸' :10

}

上面的查詢表示從搜索結果的第100條開始的10條數據。

那么,這個查詢語句在ES集群內部是怎么執行的呢?

在ES中,搜索一般包括兩個階段,查詢和提取階段,可以簡單理解。查詢階段決定取哪張單據,取貨階段取具體的單據。

查詢階段

如上圖所示,描述了搜索請求的查詢階段:

客戶端發送搜索請求,node1接收該請求。然后,node1創建一個優先級隊列,其大小為size,用于存儲結果。我們稱節點1為協調節點。

協調節點將請求廣播給相關的分片,每個分片在內部執行搜索請求,然后在內部將結果存儲在與from size大小相同的優先級隊列中,可以理解為包含前N個結果的列表。

每個碎片將臨時存儲在自己的優先級隊列中的數據返回給協調節點。在得到每個shard返回的結果后,協調節點將結果合并一次,生成一個全局優先級隊列,并存儲在自己的優先級隊列中。

在上面的例子中,協調節點獲得(來自size) * 6條數據,然后對它們進行合并和排序,然后從size中選擇前面的幾條數據存儲在優先級隊列中,以便在fetch階段使用。

此外,每個切片返回給協調節點的數據用于從size數據中選擇第一個,因此只需要返回唯一標記doc的_id和用于排序的_score,這也可以保證返回的數據足夠小。

在協調節點計算出自己的優先級隊列后,查詢階段結束,進入獲取階段。

獲取階段

查詢階段知道要獲取哪些數據,但它不獲取特定的數據,這是獲取階段要做的事情。

上圖顯示了獲取過程:

l>
  • coordinating node 發送 GET 請求到相關shards。
  • shard 根據 doc 的_id取到數據詳情,然后返回給 coordinating node。
  • coordinating node 返回數據給 Client。

coordinating node 的優先級隊列里有from + size_doc _id,但是,在 fetch 階段,并不需要取回所有數據,在上面的例子中,前100條數據是不需要取的,只需要取優先級隊列里的第101到110條數據即可。

需要取的數據可能在不同分片,也可能在同一分片,coordinating node 使用 multi-get 來避免多次去同一分片取數據,從而提高性能。

這種方式請求深度分頁是有問題的:

我們可以假設在一個有 5 個主分片的索引中搜索。當我們請求結果的第一頁(結果從 1 到 10 ),每一個分片產生前 10 的結果,并且返回給 協調節點 ,協調節點對 50 個結果排序得到全部結果的前 10 個。

現在假設我們請求第 1000 頁—結果從 10001 到 10010 。所有都以相同的方式工作除了每個分片不得不產生前10010個結果以外。然后協調節點對全部 50050 個結果排序最后丟棄掉這些結果中的 50040 個結果。

對結果排序的成本隨分頁的深度成指數上升。

注意1:

size的大小不能超過index.max_result_window這個參數的設置,默認為10000。

如果搜索size大于10000,需要設置index.max_result_window參數

PUT _settings
{
    "index": {
        "max_result_window": "10000000"
    }
}  

注意2:

_doc將在未來的版本移除,詳見:

  • https://www.elastic.co/cn/blog/moving-from-types-to-typeless-apis-in-elasticsearch-7-0
  • https://elasticsearch.cn/article/158

深度分頁問題

Elasticsearch 的From/Size方式提供了分頁的功能,同時,也有相應的限制。

舉個例子,一個索引,有10億數據,分10個 shards,然后,一個搜索請求,from=1000000,size=100,這時候,會帶來嚴重的性能問題:CPU,內存,IO,網絡帶寬。

在 query 階段,每個shards需要返回 1000100 條數據給 coordinating node,而 coordinating node 需要接收10 * 1000,100 條數據,即使每條數據只有 _doc _id_score,這數據量也很大了?

在另一方面,我們意識到,這種深度分頁的請求并不合理,因為我們是很少人為的看很后面的請求的,在很多的業務場景中,都直接限制分頁,比如只能看前100頁。

比如,有1千萬粉絲的微信大V,要給所有粉絲群去發消息,或者給某省粉絲群fa,這時候就需要取得所有符合條件的粉絲,而最容易想到的就是利用 from + size 來實現,不過,這個是不現實的,這時,可以采用 Elasticsearch 提供的其他方式來實現遍歷。

深度分頁問題大致可以分為兩類:

  • 隨機深度分頁:隨機跳轉頁面
  • 滾動深度分頁:只能一頁一頁往下查詢

下面介紹幾個官方提供的深度分頁方法

Scroll

Scroll遍歷數據

我們可以把scroll理解為關系型數據庫里的cursor,因此,scroll并不適合用來做實時搜索,而更適合用于后臺批處理任務,比如群fa

這個分頁的用法,不是為了實時查詢數據,而是為了一次性查詢大量的數據(甚至是全部的數據)。

因為這個scroll相當于維護了一份當前索引段的快照信息,這個快照信息是你執行這個scroll查詢時的快照。在這個查詢后的任何新索引進來的數據,都不會在這個快照中查詢到。

但是它相對于from和size,不是查詢所有數據然后剔除不要的部分,而是記錄一個讀取的位置,保證下一次快速繼續讀取。

不考慮排序的時候,可以結合SearchType.SCAN使用。

scroll可以分為初始化和遍歷兩部,初始化時將所有符合搜索條件的搜索結果緩存起來(注意,這里只是緩存的doc_id,而并不是真的緩存了所有的文檔數據,取數據是在fetch階段完成的),可以想象成快照。

在遍歷時,從這個快照里取數據,也就是說,在初始化后,對索引插入、刪除、更新數據都不會影響遍歷結果。

基本使用

POST /twitter/tweet/_search?scroll=1m
{
    "size": 100,
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    }
}

初始化指明 index 和 type,然后,加上參數 scroll,表示暫存搜索結果的時間,其它就像一個普通的search請求一樣。

會返回一個_scroll_id,_scroll_id用來下次取數據用。

遍歷

POST /_search?scroll=1m
{
    "scroll_id":"XXXXXXXXXXXXXXXXXXXXXXX I am scroll id XXXXXXXXXXXXXXX"
}

這里的scroll_id即 上一次遍歷取回的_scroll_id或者是初始化返回的_scroll_id,同樣的,需要帶 scroll 參數。

重復這一步驟,直到返回的數據為空,即遍歷完成。

注意,每次都要傳參數 scroll,刷新搜索結果的緩存時間。另外,不需要指定 index 和 type。

設置scroll的時候,需要使搜索結果緩存到下一次遍歷完成,同時,也不能太長,畢竟空間有限。

優缺點

缺點:

  1. scroll_id會占用大量的資源(特別是排序的請求)
  2. 同樣的,scroll后接超時時間,頻繁的發起scroll請求,會出現一些列問題。
  3. 是生成的歷史快照,對于數據的變更不會反映到快照上。

優點:

適用于非實時處理大量數據的情況,比如要進行數據遷移或者索引變更之類的。

Scroll Scan

ES提供了scroll scan方式進一步提高遍歷性能,但是scroll scan不支持排序,因此scroll scan適合不需要排序的場景

基本使用

Scroll Scan 的遍歷與普通 Scroll 一樣,初始化存在一點差別。

POST /my_index/my_type/_search?search_type=scan&scroll=1m&size=50
{
 "query": { "match_all": {}}
}

需要指明參數:

  • search_type:賦值為scan,表示采用 Scroll Scan 的方式遍歷,同時告訴 Elasticsearch 搜索結果不需要排序。
  • scroll:同上,傳時間。
  • size:與普通的 size 不同,這個 size 表示的是每個 shard 返回的 size 數,最終結果最大為 number_of_shards * size。

Scroll Scan與Scroll的區別

  1. Scroll-Scan結果沒有排序,按index順序返回,沒有排序,可以提高取數據性能。
  2. 初始化時只返回 _scroll_id,沒有具體的hits結果
  3. size控制的是每個分片的返回的數據量,而不是整個請求返回的數據量。

Sliced Scroll

如果你數據量很大,用Scroll遍歷數據那確實是接受不了,現在Scroll接口可以并發來進行數據遍歷了。

每個Scroll請求,可以分成多個Slice請求,可以理解為切片,各Slice獨立并行,比用Scroll遍歷要快很多倍。

POST /index/type/_search?scroll=1m
{
    "query": { "match_all": {}},
    "slice": {
        "id": ,
        "max": 5
    }   
}
 
POST ip:port/index/type/_search?scroll=1m
{
    "query": { "match_all": {}},
    "slice": {
        "id": 1,
        "max": 5
    }   
}

上邊的示例可以單獨請求兩塊數據,最終五塊數據合并的結果與直接scroll scan相同。

其中max是分塊數,id是第幾塊。

官方文檔中建議max的值不要超過shard的數量,否則可能會導致內存爆炸。

Search After

Search_after是 ES 5 新引入的一種分頁查詢機制,其原理幾乎就是和scroll一樣,因此代碼也幾乎是一樣的。

基本使用:

第一步:

POST twitter/_search
{
    "size": 10,
    "query": {
        "match" : {
            "title" : "es"
        }
    },
    "sort": [
        {"date": "asc"},
        {"_id": "desc"}
    ]
}

返回出的結果信息 :

{
      "took" : 29,
      "timed_out" : false,
      "_shards" : {
        "total" : 1,
        "successful" : 1,
        "skipped" : ,
        "failed" : 
      },
      "hits" : {
        "total" : {
          "value" : 5,
          "relation" : "eq"
        },
        "max_score" : null,
        "hits" : [
          {
            ...
            },
            "sort" : [
              ...
            ]
          },
          {
            ...
            },
            "sort" : [
              124648691,
              "624812"
            ]
          }
        ]
      }
    }

上面的請求會為每一個文檔返回一個包含sort排序值的數組。

這些sort排序值可以被用于search_after參數里以便抓取下一頁的數據。

比如,我們可以使用最后的一個文檔的sort排序值,將它傳遞給search_after參數:

GET twitter/_search
{
    "size": 10,
    "query": {
        "match" : {
            "title" : "es"
        }
    },
    "search_after": [124648691, "624812"],
    "sort": [
        {"date": "asc"},
        {"_id": "desc"}
    ]
}

若我們想接著上次讀取的結果進行讀取下一頁數據,第二次查詢在第一次查詢時的語句基礎上添加search_after,并指明從哪個數據后開始讀取。

基本原理

es維護一個實時游標,它以上一次查詢的最后一條記錄為游標,方便對下一頁的查詢,它是一個無狀態的查詢,因此每次查詢的都是最新的數據。

由于它采用記錄作為游標,因此SearchAfter要求doc中至少有一條全局唯一變量(每個文檔具有一個唯一值的字段應該用作排序規范)

優缺點

優點:

  1. 無狀態查詢,可以防止在查詢過程中,數據的變更無法及時反映到查詢中。
  2. 不需要維護scroll_id,不需要維護快照,因此可以避免消耗大量的資源。

缺點:

  1. 由于無狀態查詢,因此在查詢期間的變更可能會導致跨頁面的不一值。
  2. 排序順序可能會在執行期間發生變化,具體取決于索引的更新和刪除。
  3. 至少需要制定一個唯一的不重復字段來排序。
  4. 它不適用于大幅度跳頁查詢,或者全量導出,對第N頁的跳轉查詢相當于對es不斷重復的執行N次search after,而全量導出則是在短時間內執行大量的重復查詢。

SEARCH_AFTER不是自由跳轉到任意頁面的解決方案,而是并行滾動多個查詢的解決方案。

總結

分頁方式 性能 優點 缺點 場景
from + size 靈活性好,實現簡單 深度分頁問題 數據量比較小,能容忍深度分頁問題
scroll 解決了深度分頁問題 無法反應數據的實時性(快照版本)維護成本高,需要維護一個 scroll_id 海量數據的導出需要查詢海量結果集的數據
search_after 性能最好不存在深度分頁問題能夠反映數據的實時變更 實現復雜,需要有一個全局唯一的字段連續分頁的實現會比較復雜,因為每一次查詢都需要上次查詢的結果,它不適用于大幅度跳頁查詢 海量數據的分頁

ES7版本變更

參照:https://www.elastic.co/guide/en/elasticsearch/reference/master/paginate-search-results.html#scroll-search-results

7.*版本中,ES官方不再推薦使用Scroll方法來進行深分頁,而是推薦使用帶PIT的search_after來進行查詢;

7.*版本開始,您可以使用SEARCH_AFTER參數通過上一頁中的一組排序值檢索下一頁命中。

使用SEARCH_AFTER需要多個具有相同查詢和排序值的搜索請求。

如果這些請求之間發生刷新,則結果的順序可能會更改,從而導致頁面之間的結果不一致。

為防止出現這種情況,您可以創建一個時間點(PIT)來在搜索過程中保留當前索引狀態。

POST /my-index-000001/_pit?keep_alive=1m

返回一個PIT ID:
{
  "id": "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYwADaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQADaWR5BXV1aWQyKgZub2RlXzIAAAAAAAAAAAwBYgACBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA=="
}

在搜索請求中指定PIT:

GET /_search
{
  "size": 10000,
  "query": {
    "match" : {
      "user.id" : "elkbee"
    }
  },
  "pit": {
     "id":  "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYwADaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQADaWR5BXV1aWQyKgZub2RlXzIAAAAAAAAAAAwBYgACBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA==", 
     "keep_alive": "1m"
  },
  "sort": [ 
    {"@timestamp": {"order": "asc", "format": "strict_date_optional_time_nanos", "numeric_type" : "date_nanos" }}
  ]
}

性能對比

分別分頁獲取1 - 10,49000 - 49010,99000 - 99010范圍各10條數據(前提10w條),性能大致是這樣:

向前翻頁

對于向前翻頁,ES中沒有相應API,但是根據官方說法(https://github.com/elastic/elasticsearch/issues/29449),ES中的向前翻頁問題可以通過翻轉排序方式來實現即:

  1. 對于某一頁,正序search_after該頁的最后一條數據id為下一頁,則逆序search_after該頁的第一條數據id則為上一頁。
  2. 國內論壇上,有人使用緩存來解決上一頁的問題:https://elasticsearch.cn/question/7711

總結

  1. 如果數據量?。╢rom+size在10000條內),或者只關注結果集的TopN數據,可以使用from/size 分頁,簡單粗暴
  2. 數據量大,深度翻頁,后臺批處理任務(數據遷移)之類的任務,使用 scroll 方式
  3. 數據量大,深度翻頁,用戶實時、高并發查詢需求,使用 search after 方式

個人思考

Scroll和search_after原理基本相同,他們都采用了游標的方式來進行深分頁。

這種方式雖然能夠一定程度上解決深分頁問題。但是,它們并不是深分頁問題的終極解決方案,深分頁問題必須避免!!。

對于Scroll,無可避免的要維護scroll_id和歷史快照,并且,還必須保證scroll_id的存活時間,這對服務器是一個巨大的負荷。

對于Search_After,如果允許用戶大幅度跳轉頁面,會導致短時間內頻繁的搜索動作,這樣的效率非常低下,這也會增加服務器的負荷,同時,在查詢過程中,索引的增刪改會導致查詢數據不一致或者排序變化,造成結果不準確。

Search_After本身就是一種業務折中方案,它不允許指定跳轉到頁面,而只提供下一頁的功能。

Scroll默認你會在后續將所有符合條件的數據都取出來,所以,它只是搜索到了所有的符合條件的doc_id(這也是為什么官方推薦用doc_id進行排序,因為本身緩存的就是doc_id,如果用其他字段排序會增加查詢量),并將它們排序后保存在協調節點(coordinate node),但是并沒有將所有數據進行fetch,而是每次scroll,讀取size個文檔,并返回此次讀取的最后一個文檔以及上下文狀態,用以告知下一次需要從哪個shard的哪個文檔之后開始讀取。

這也是為什么官方不推薦scroll用來給用戶進行實時的分頁查詢,而是適合于大批量的拉取數據,因為它從設計上就不是為了實時讀取數據而設計的。

 

標簽:數據 分頁 結果
盤點倉庫|談如何建立指標體系
? 上一篇 2022-03-21
  • 盤點倉庫|談如何建立指標體系
    1閱讀 0條評論 個贊
    寫在前面作為數據研發,開發指標是我們的日常工作。在開發一個具體的指標時,不知道你是否想過以下問題:為什么要開發這些指標指標與指標之前有哪些聯系怎么衡量指標的好與壞一個指標可以拆解嗎...你可能會說,這些都是PD和業務該考慮的問題,我只需要他們提供具體的口徑,然后開發完成就完事了。如果真的是這樣的話……
  • PostgreSQL統計和性能優化深入分析
    1閱讀 0條評論 個贊
    基本關系級別的統計信息存儲在pg_class系統目錄的表中。統計數據包括以下數據:關系的行數(reltuples)。關系的頁面大小(relpages)。在關系的可見性圖中標記的頁面數(relallvisible)。SELECTreltuples,relpages,relallvisibleFROMp……
  • Redis主從 哨兵和集群!
    1閱讀 0條評論 個贊
    今天跟小伙伴們一起學習Redis的主從、哨兵、RedisCluster集群。Redis主從Redis哨兵RedisCluster集群1.Redis主從面試官經常會問到Redis的高可用。Redis高可用回答包括兩個層面,一個就是數據不能丟失,或者說盡量減少丟失;……
  • Linux環境變量配置的六種方法 推薦收藏!
    1閱讀 0條評論 個贊
    Linux環境變量配置在自定義安裝軟件的時候,經常需要配置環境變量,下面列舉出各種對環境變量的配置方法。下面所有例子的環境說明如下:系統:Ubuntu14.0用戶名:uusama需要配置MySQL環境變量路徑……
  • 數據標準和數據規范的區別?
    1閱讀 0條評論 個贊
    彭友們好,我是老彭呀。前兩天有個彭友問我:到底數據標準和數據規范有啥區別?這哥們可不是小白,他是十幾年的老數據人了,最近在做集團數據管理體系設計,寫文檔都寫到使勁揪頭發。原本烏黑濃密的秀發,現在快揪成禿子了?!?/div>
發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
  • Redis主從 哨兵和集群!
    1閱讀 0條評論 個贊
    今天跟小伙伴們一起學習Redis的主從、哨兵、RedisCluster集群。Redis主從Redis哨兵RedisCluster集群1.Redis主從面試官經常會問到Redis的高可用。Redis高可用回答包括兩個層面,一個就是數據不能丟失,或者說盡量減少丟失;……
  • 幾張大圖理清了Kubernetes Ingress的來龍去脈 看完真的很“香”
    1閱讀 0條評論 個贊
    KubernetesIngress只是Kubernetes中的一個普通資源對象,需要一個對應的Ingress控制器來解析Ingress的規則,暴露服務到外部,比如ingress-nginx,本質上來說它只是一個NginxPod,然后將請求重定向到其他內部(Clust" />
    寫下一個在線事件的循環依賴問題
    1閱讀 0條評論 個贊
    前情回顧一探Spring的循環依賴,源碼詳細分析→真的非要三級緩存嗎中講到了循環依賴問題同樣說明了Spring只能解決setter方式的循環依賴,不能解決構造方法的循環依賴重點介紹了Spring是如何解決setter方式的循環依賴,感興趣的可以去看下二探既然Spring不能解決構造方法的循環依賴……
  • PostgreSQL統計和性能優化深入分析
    1閱讀 0條評論 個贊
    基本關系級別的統計信息存儲在pg_class系統目錄的表中。統計數據包括以下數據:關系的行數(reltuples)。關系的頁面大小(relpages)。在關系的可見性圖中標記的頁面數(relallvisible)。SELECTreltuples,relpages,relallvisibleFROMp……
  • 數據湖治理實踐:騰訊云數據湖元數據實踐指南!
    1閱讀 0條評論 個贊
    彭友們好,我是老彭啊。最近數據湖非常的火,但是一旦沒弄好,就會變成“數據沼澤”。如何避免“數據湖”變成“數據沼澤”呢?最好的辦法就是治理先行。今天請到了騰訊數據湖專家吳怡雯給彭友們分享數據湖的元數據治理實踐,一起聊聊騰訊云上DLC數據湖計算產品中統一……
  • 用SQL查找三列異常值的四種方法
    1閱讀 0條評論 個贊
    前兩天在抽一段數據時,碰到一個典型問題,初一想,有很多解法,所以特想做一次歸納?;叵胪?,其實有好些想法,可以深究,因沒及時記錄,事后就再也想不起來,白白浪費好多這樣的機會。所以為了不留遺憾,今天沉下心來,好好復盤下?!?/div>
  • JD.COM面試問題:ElasticSearch如何解決深度分頁的問題?
    2閱讀 0條評論 個贊
    前言Elasticsearch是一個實時的分布式搜索與分析引擎,在使用過程中,有一些典型的使用場景,比如分頁、遍歷等。在使用關系型數據庫中,我們被告知要注意甚至被明確禁止使用深度分頁,同理,在Elasticsearch中,也應該盡量避免使用深度分頁。這篇文章主要介紹Elasticsearch中分頁相……
  • 數據標準和數據規范的區別?
    1閱讀 0條評論 個贊
    彭友們好,我是老彭呀。前兩天有個彭友問我:到底數據標準和數據規范有啥區別?這哥們可不是小白,他是十幾年的老數據人了,最近在做集團數據管理體系設計,寫文檔都寫到使勁揪頭發。原本烏黑濃密的秀發,現在快揪成禿子了?!?/div>
  • Linux環境變量配置的六種方法 推薦收藏!
    1閱讀 0條評論 個贊
    Linux環境變量配置在自定義安裝軟件的時候,經常需要配置環境變量,下面列舉出各種對環境變量的配置方法。下面所有例子的環境說明如下:系統:Ubuntu14.0用戶名:uusama需要配置MySQL環境變量路徑……
  • 盤點倉庫|談如何建立指標體系
    1閱讀 0條評論 個贊
    寫在前面作為數據研發,開發指標是我們的日常工作。在開發一個具體的指標時,不知道你是否想過以下問題:為什么要開發這些指標指標與指標之前有哪些聯系怎么衡量指標的好與壞一個指標可以拆解嗎...你可能會說,這些都是PD和業務該考慮的問題,我只需要他們提供具體的口徑,然后開發完成就完事了。如果真的是這樣的話……
最近發布資訊
更多
十八禁试看120秒做受