建站
咨詢
售后
建站咨詢
新聞中心
不再需要擔(dān)心數(shù)據(jù)庫(kù)性能優(yōu)化的日子已經(jīng)一去不復(fù)返了。
隨著時(shí)代的進(jìn)步，每一個(gè)新的創(chuàng)業(yè)者都想打造下一個(gè)Facebook，再加上收集每一個(gè)可能的數(shù)據(jù)點(diǎn)以提供更好的機(jī)器學(xué)習(xí)預(yù)測(cè)的心態(tài)，作為開發(fā)者，我們需要準(zhǔn)備好我們的API，比以往任何時(shí)候都要好，以提供可靠而高效的終端，應(yīng)該能夠在海量數(shù)據(jù)中游刃有余。
如果你做過(guò)一段時(shí)間的后臺(tái)或者數(shù)據(jù)庫(kù)架構(gòu)，你可能已經(jīng)做過(guò)分頁(yè)查詢了，比如這樣。
對(duì)吧?
但是，如果你確實(shí)建立了這樣的分頁(yè)，我很抱歉的跟你說(shuō)，你已經(jīng)做錯(cuò)了。
你不同意我的觀點(diǎn)?你不需要。Slack、Shopify和Mixmax都在用我們今天要講的這個(gè)概念來(lái)分頁(yè)他們的API。
我想請(qǐng)你說(shuō)出一個(gè)沒有處理過(guò)分頁(yè)OFFSET和LIMIT的后端開發(fā)人員，對(duì)于MVP和低數(shù)據(jù)列表中的分頁(yè)，它“有效”。
今天我們要討論的是被廣泛使用的(錯(cuò)誤的)實(shí)現(xiàn)方式存在哪些問題，以及如何實(shí)現(xiàn)高性能的分頁(yè)。
OFFSET和LIMIT有什么問題?
正如我們?cè)谏蠋锥沃泻?jiǎn)要探討的那樣，OFFSET和LIMIT非常適合于數(shù)據(jù)使用量很少甚至沒有的項(xiàng)目。
當(dāng)你的數(shù)據(jù)庫(kù)開始收集的數(shù)據(jù)超過(guò)了服務(wù)器在內(nèi)存中的存儲(chǔ)量時(shí)，問題就出現(xiàn)了，你仍然需要對(duì)這些數(shù)據(jù)進(jìn)行高性能的分頁(yè)。
要做到這一點(diǎn)，數(shù)據(jù)庫(kù)需要在每次請(qǐng)求分頁(yè)時(shí)執(zhí)行一次低效的全表掃描(在此期間可能會(huì)發(fā)生插入和刪除，我們不希望數(shù)據(jù)過(guò)時(shí)!)。
| 什么是全表掃描?全表掃描(又名順序掃描)是指在數(shù)據(jù)庫(kù)中進(jìn)行掃描，順序讀取表中的每一條記錄，然后檢查遇到的列的條件是否有效。這種類型的掃描被認(rèn)為是最慢的，因?yàn)閺拇疟P上讀取的I/O量很大，包括多次尋找以及昂貴的磁盤到內(nèi)存的傳輸。 |
這意味著，如果你有100.000.000個(gè)用戶，而你要求的OFFSET是50.000.000，那么它將需要獲取所有這些記錄(甚至不需要!)，將它們放在內(nèi)存中，然后才會(huì)得到在LIMIT中指定的20個(gè)結(jié)果。
因此，要在網(wǎng)站上顯示這樣的分頁(yè)：
- 50.000 to 50.020 of 100.000
首先需要獲取50.000行，看看這效率低下嗎?
你應(yīng)該使用什么
這是你應(yīng)該使用的：
這是基于游標(biāo)的分頁(yè)。
你應(yīng)該存儲(chǔ)最后接收到的主鍵(通常是一個(gè)ID)和Limit，而不是在本地存儲(chǔ)當(dāng)前offset和limit將其與每個(gè)請(qǐng)求一起傳遞，這樣查詢最終可能與此類似。
為什么?因?yàn)橥ㄟ^(guò)顯式傳遞最新的讀取行，你可以根據(jù)有效的索引鍵告訴數(shù)據(jù)庫(kù)確切從哪里開始搜索，而不必考慮該范圍之外的任何行。
以下面的比較為例：
針對(duì)我們的優(yōu)化版本：
接收到的記錄完全相同，但是第一個(gè)查詢花費(fèi)了12.80秒，第二個(gè)查詢花費(fèi)了0.01秒。你能體會(huì)到差異嗎?
注意事項(xiàng)
為了使游標(biāo)分頁(yè)能夠無(wú)縫地工作，你需要有一個(gè)獨(dú)特的、有順序的列(或列)，比如一個(gè)獨(dú)特的整數(shù)ID，在某些特定的情況下，這可能是一個(gè)問題。
和以往一樣，我的建議是一定要考慮每個(gè)表架構(gòu)的優(yōu)缺點(diǎn)，以及你需要在每個(gè)表中執(zhí)行哪種查詢。如果你需要在查詢中處理大量相關(guān)數(shù)據(jù)，Rick James的“Lists article”文章可能會(huì)為你提供更深入的指導(dǎo)。
如果我們手中的問題與沒有主鍵有關(guān)，比如我們有一個(gè)多對(duì)多的關(guān)系表，傳統(tǒng)的OFFSET/LIMIT的方法在這些情況下總是可以使用的，然而這將重新引入潛在的較慢的查詢。因此，我建議在要分頁(yè)的表中使用自動(dòng)遞增的主鍵，即使只是出于分頁(yè)的目的。
總結(jié)
這其中最主要的啟示應(yīng)該是，無(wú)論你的查詢是用1k行還是用1M行，都要時(shí)刻檢查你的查詢性能如何?？蓴U(kuò)展性是極其重要的，如果從一開始就能正確地實(shí)施，肯定可以避免未來(lái)許多頭痛的問題。
哦。而且，請(qǐng)不要忘記學(xué)習(xí)索引并explain queries。
如果你正在尋找如何在ElasticSearch上實(shí)現(xiàn)光標(biāo)分頁(yè)，請(qǐng)隨時(shí)查看文章ElasticSearch--你應(yīng)該這樣分頁(yè)你的結(jié)果。
ElasticSearch--你應(yīng)該這樣分頁(yè)你的結(jié)果：
https://medium.com/@tmateus/elasticsearch-this-is-how-you-should-paginate-your-results-5d1c71bfe060
本文標(biāo)題：為什么不應(yīng)該在分頁(yè)中使用offset和limit
網(wǎng)站地址：http://m.5511xx.com/article/ccejjdj.html
