目錄

普通分頁

解除查詢限制

scroll查詢

search_after

官方改進(jìn)

輕量級試圖（pit，Point in time）

總結(jié)

項(xiàng)目中用到了?elasticsearch，發(fā)現(xiàn)有幾種查詢方式不太一樣，思考了一下，總結(jié)如下

普通分頁

等同于關(guān)系數(shù)據(jù)庫的分頁查詢，例如 mysql 的 limit，如下 sql

select * from test limit 100000,10

這種查詢方式有一個(gè)問題，需要查詢?1000010 條數(shù)據(jù)到內(nèi)存中，然后篩選出最后的 10 條數(shù)據(jù)進(jìn)行返回，這樣就會造成一個(gè)問題，對內(nèi)存大大浪費(fèi)。

對于?elasticsearch 也是這樣，所以針對分頁數(shù)量大于 10000 的數(shù)據(jù)做了限制，需要手動(dòng)開啟參數(shù)?track_total_hits 為 true 才行，如果這樣做了會產(chǎn)生一個(gè)問題，就是大量數(shù)據(jù)加載 jvm 中（elasticsearch使用java開發(fā)，使用的lucene也是），內(nèi)存吃緊開銷大，造成頻繁的 gc。

解除查詢限制

PUT _all/_settings
{
  "index" : {"max_result_window" : 1000000}
}

這種方式是治標(biāo)不治本，不建議修改

需要確保如下要求

from + size < max_result_window

為了解決這個(gè)深分頁的問題，滾動(dòng)查詢出現(xiàn)了

scroll查詢

https://www.elastic.co/guide/en/elasticsearch/reference/5.0/search-request-scroll.html

從 5.0 版本開始添加。

scroll API 可用于從單個(gè)搜索請求檢索大量結(jié)果（甚至所有結(jié)果），這與在傳統(tǒng)數(shù)據(jù)庫上使用游標(biāo)的方式大致相同。
scroll?并不是為了實(shí)時(shí)用戶請求，而是為了處理大量數(shù)據(jù)，只能往下查詢。

通過第一次查詢后返回一個(gè)scroll?id，往后每次查詢都基于這個(gè)scroll id，直到查詢不到數(shù)據(jù)為止。

開始查詢時(shí)形成一個(gè)快照，連續(xù)查詢過程中，不會將新增加或修改的數(shù)據(jù)添加到查詢結(jié)果中，也不支持跳頁查詢。

初始化時(shí)將所有符合搜索條件的搜索結(jié)果緩存起來，可以想象成快照，在遍歷時(shí)，從這個(gè)快照里取數(shù)據(jù)，也就是說，在初始化后對索引插入、刪除、更新數(shù)據(jù)都不會影響遍歷結(jié)果。

如果想要在查詢過程中某些數(shù)據(jù)修改了，需要查詢到最新的數(shù)據(jù)。需要使用?search_after 來實(shí)現(xiàn)。

類似于mysql事務(wù)隔離級別中的?REPEATABLE READ，每個(gè)事務(wù)只會在第一次執(zhí)行查詢語句時(shí)生成一個(gè) ReadView，即數(shù)據(jù)修改了不影響本次查詢的結(jié)果。

search_after

https://www.elastic.co/guide/en/elasticsearch/reference/5.0/search-request-search-after.html

和 scroll 查詢一樣，從 5.0 版本開始添加。使用的場景不同。

search_after不是自由跳轉(zhuǎn)到隨機(jī)頁面的解決方案，而是并行滾動(dòng)許多查詢的解決方案。

它與 API 非常相似，與 scroll 不同的是，search_after參數(shù)是無狀態(tài)的，它總是根據(jù)搜索器的最新版本進(jìn)行解析。因此，排序順序可能會在步行過程中發(fā)生變化，具體取決于索引的更新和刪除。

在查詢過程中至少指定一個(gè)唯一不重復(fù)字段來排序。

類似于mysql事務(wù)隔離級別中的?READ COMMITTED，每個(gè)事務(wù)在每次查詢開始時(shí)都會生成一個(gè)獨(dú)立的 ReadView，即數(shù)據(jù)修改了每次執(zhí)行查詢了數(shù)據(jù)都是不同的。

官方改進(jìn)

輕量級試圖（pit，Point in time）

https://www.elastic.co/guide/en/elasticsearch/reference/7.10/point-in-time-api.html

從 7.10 版本中開始添加。

https://www.elastic.co/guide/en/elasticsearch/reference/7.10/scroll-api.html

在這個(gè)文檔上，指出了不推薦使用 scroll 查詢，使用?search_after 和 pit 來代替。即針對快照數(shù)據(jù)建議使用這種方式。

對于search_after 和 pit 結(jié)合使用與?scroll 的到底有什么區(qū)別，官方文檔也沒做說明，也沒找到對應(yīng)的性能對比測試。

總結(jié)

參考鏈接

https://blog.csdn.net/liaomingwu/article/details/117323936

https://blog.csdn.net/weixin_46097842/article/details/107889284

https://cloud.tencent.com/developer/article/1825190

https://juejin.cn/post/7088110134076899365

https://blog.csdn.net/UbuntuTouch/article/details/119926953

?文章來源地址http://www.zghlxwxcb.cn/news/detail-801126.html

到了這里，關(guān)于elasticsearch的查詢方式和mysql數(shù)據(jù)庫事務(wù)隔離級別的思考的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！