1. from+size
es 預設採用的分頁方式是 from+ size 的形式，在深度分頁的情況下，這種使用方式效率是非常低的，比如
from = 5000, size=10， es 需要在各個分片上匹配排序並得到5000*10條有效資料，然後在結果集中取最後10條，
es預設是10000條資料，可以通過設定max_result_window 值來改變最大資料量；
2.scroll
為了滿足深度分頁的場景，es 提供了 scroll 的方式進行分頁讀取。原理上是對某次查詢生成乙個游標 scroll_id ， 後續的查詢只需要根據這個游標去取資料，直到結果集中返回的 hits 欄位為空，就表示遍歷結束。scroll_id 的生成可以理解為建立了乙個臨時的歷史快照，在此之後的增刪改查等操作不會影響到這個快照的結果。
scroll方式官方的建議並不是用於實時的請求，因為每乙個 scroll_id 不僅會占用大量的資源（特別是排序的請求），而且是生成的歷史快照，對於資料的變更不會反映到快照上。這種方式往往用於非實時處理大量資料的情況，比如要進行資料遷移或者索引變更之類的。
3.search_after
es深度分頁處理
最近做到es分頁的需求，由於es的from to的分頁只能在10000條以內的資料進行分頁，超過了10000去查詢就會報錯。在網上找了一下都說用scroll，但是沒有乙個完美的解決方案。然後我就開始自擼了。我用了elasticsearch rest high level client 5.6.3。e...
ES 深度分頁 滾動搜尋
深度分頁其實就是搜尋的深淺度，比如第1頁，第2頁，第10頁，第20頁，是比較淺的 第10000頁，第20000頁就是很深了。使用如下操作 from 9990,size 10 from 9999,size 10 我們在獲取第9999條到10009條資料的時候，其實每個分片都會拿到10009條資料，然後...
ES第六天 深度分頁和scroll search
我們由前面知道，es的資料是分片進行儲存的，整體資料會被分布在不同的primary分片上面，因此，如果一次比較深度的分頁且排序的操作，成本將會比較大 假如使用者要查詢5001 5050條資料，按照 由低到高進行排序，那麼es的查詢會發生什麼？因為資料是分片儲存，因此需要每個分片都拿出自身的前5050...