ElasticSearch 分頁查詢

在預設情況下， elasticsearch 查詢返回前10條匹配的文件。

為了對大批量查詢結果分頁，最簡單方式是在查詢api中新增from和size引數，from表示需要返回的滿足查詢條件的數量，size表示查詢起始資料在全量結果集中的偏移量。

建立實驗索引：

put linked_blog}}
}}}}

get
/linked_blog/
default
/_search},
"from":3
,"size":2
}

預設情況下，使用from+size引數不能分頁查詢超過10,000的文件。該限制可以通過索引設定index.max_result_window更改。

深度分頁可能造成慢查詢。查詢結果在返回之前會被排序。但查詢通常會跨越多個分片，每個分片先自各執行查詢，並各自排序，再將各個分片查詢結果合併以保證最終查詢結果順序正確。

為了避免該問題，elasticsearch官方推薦使用scroll或者search_after替代from+size實現分頁。

elasticsearch的查詢是分2個階段進行的，即query階段和fetch階段。 query階段比較輕量級，通過查詢倒排索引，獲取滿足查詢結果的文件id列表。而fetch階段比較重，需要將每個shard的結果取回。

scroll查詢，先做輕量級的query階段以後，免去了繁重的全域性排序過程。它只是將查詢結果集，也就是文件id列表保留在乙個上下文裡，之後分批fetch。

scroll查詢方式類似於傳統資料庫的游標查詢和redis的scan查詢。如果使用過twitter開發者api會發現，這種方式和使用twitter開發者api獲取博文也很類似。

為了使用scroll，只需在首次分頁查詢時加上scroll引數，其值為該查詢上下文存活時間。例如：

get
/linked_blog/
default
/_search?scroll=1m}
,"size":3
}

上面的查詢結果中回包含_scroll_id字段。


,"hits":}
,},}
]}}

後面的分頁使用scroll查詢，並帶上上次查詢結果的_scroll_id字段。直到hits陣列空，即表示所有資料查詢完成。

post /_search/scroll

結果如下


,"hits":}
,},}
]}}

初次分頁和後面每次分頁均返回_scroll_id。儘管_scroll_id在兩次請求之間可能會發生變化，但並非總是會發生變化。在任何情況下，都應使用最近收到的_scroll_id。

scroll 在首次分頁時就已經將所有滿足查詢條件的文件確定了，並忽略後續對這些文件的修改（可以理解，elasticsearch使用版本號區分修改）。並在首次分頁時，查詢上下文也已經建立了，在後續分頁中可以通過scroll_id 區分該查詢上下文，並使其保持存活狀態。

scroll 引數的值告訴elasticsearch 查詢上下文存活時間。該值並非處理所有分頁資料所需時間，而是處理當前頁所需時間，每次分頁都會重新設定查詢上下文過期時間。如果乙個scroll 請求沒有設定scroll 引數，則表示該查詢上下文將會被釋放。

使用如下介面，可以查詢每個節點開啟了多少scroll 查詢上下文。

get

/_nodes/stats/indices/search

scroll 查詢上下文在存活時間到達後會被自動刪除。因為scroll 查詢上下文需要消耗資源，所以當分頁結束或者不再需要分頁時，需要及時手動關閉。手動關閉api如下：

delete /_search/scroll

關閉多個scroll 查詢上下文可用如下api：

delete /_search/scroll

如下api可以清除所有scroll 查詢上下文：

delete

/_search/scroll/_all