具體來說，我使用Elasticsearch來做分頁，但是這個問題可能適用於任何數據庫。當源數據頻繁變化時如何處理分頁
Elasticsearch提供方法paginate search results與方便的from和to參數。
於是我運行一個查詢get me the most recent data from result 1 to 10
這個偉大的工程。
，用戶點擊「下一頁」，查詢是： get me the most recent data from result 11 to 20
的問題是，在這兩個查詢之間的時間，2個新的記錄已被添加到後備數據庫，這意味着分頁結果將重疊（第一頁的最後兩頁顯示爲第二頁的前兩頁）。
什麼是避免這種情況的最佳解決方案？現在，我在查詢中添加一個過濾器，告訴它只包含晚於上一個查詢結果的結果。但它似乎只是一件駭人聽聞的事。
如果您已經爲相關時間戳建立索引，過濾器並不是一個錯誤的選項。您必須跟蹤客戶端的時間戳以正確準備您的查詢。你也必須知道什麼時候擺脫它。但那些不是不可克服的問題。
Scroll API是一個可靠的選項，因爲它有效地在Elasticsearch端快照。 Scroll API的目的是爲深度分頁提供一個穩定的搜索查詢，該查詢必須處理您遇到的確切的變更問題。
通過提供您的查詢和參數scroll開始Scrolling Search，Elasticsearch返回scroll_id。然後您向/_search/scroll發出請求，提供該ID，每個返回一頁結果，併爲下一個請求返回一個新的scroll_id。
（請注意，您不希望scan搜索鍵入這裏。這是用來提取文件集體，並不適用任何排序。）
相比於過濾，你仍然有跟蹤一個值：scroll_id爲您的下一頁結果。這是否比追蹤時間戳更容易取決於您的應用程序。
還有其他潛在的缺點需要考慮。 Elasticsearch在集羣內的單個節點上保留您的搜索上下文。可以想象，這些可能會積聚在您的羣集中，具體取決於您依賴滾動搜索的程度。你會想測試那裏的性能影響。如果我記得正確，滾動搜索也不會持續通過節點故障或重新啓動。
Scroll API的ES文檔提供了以上所有內容的詳細信息。底線：通過時間戳過濾實際上不是一個不錯的選擇。 Scroll API是另一個有效的選項，專爲類似的用例而設計，但並非沒有缺點。
您需要爲此使用掃描API。掃描和滾動API讓你做點時間搜索和分頁。 掃描API -
使用掃描API可能不是這裏要做的正確的事情。它不適用於對結果進行排序。 – bittusarkar 2015-01-15 19:39:38
感謝您的詳細解釋。出於某種原因，我認爲掃描/滾動是同樣的事情，但這顯然不是真的！當你沒有像最新的時間戳那樣過濾時，滾動似乎是一個不錯的選擇。 – bradvido 2015-01-15 21:45:27
時間戳過濾的缺點是，如果有人要刪除文檔，您可能會跳過下一頁結果中返回的文檔？ – writofmandamus 2017-01-10 18:21:19
來自Scroll API文檔的注意事項'Scrolling不適用於實時用戶請求，' – Ben 2017-10-14 08:53:47