MongoDB 分頁查詢的skip方法及效能
廢話不多說,關於入門的資料、安裝以及其他請拉到文章末尾,我附上了一些資料,以後如有必要再來分享。這篇文章著重的講講MongoDB的分頁查詢,為啥?分頁可是常見的頭號殺手,弄不好了,客戶罵,經理罵。
傳統的SQL分頁
傳統的sql分頁,所有的方案几乎是繞不開row_number的,對於需要各種排序,複雜查詢的場景,row_number就是殺手鐗。另外,針對現在的web很流行的poll/push載入分頁的方式,一般會利用時間戳來實現分頁。 這兩種分頁可以說前者是通用的,連Linq生成的分頁都是row_number,可想而知它多通用。後者是無論是效能和複雜程度都是最好的,因為只要簡單的一個時間戳即可。
MongoDB分頁
進入到Mongo的思路,分頁其實並不難,那難得是什麼?其實倒也沒啥,看明白了也就那樣,和SQL分頁的思路是一致的。
首先來看看分頁需要的引數以及結果,一般的分頁需要的引數是:
- PageIndex 當前頁
- PageSize 每頁記錄數
- QueryParam[] 其他的查詢欄位
所以按照row_number的分頁思想,也就是說取第(pageIndex*pageSize)到第(pageIndex*pageSize + pageSize),我們用Linq表達就是:
1 |
query.Where(xxx...xxx).Skip(pageIndex*pageSize |
查找了資料,還真有skip函式,而且還有Limit函式 見參考資料1、2,於是輕易地實現了這樣的分頁查詢:
1 | db.test.find({xxx...xxx}).sort({"amount":1}).skip(10).limit(10)//這裡忽略掉查詢語句 |
相當的高效,幾乎是幾毫秒就出來了結果,果然是NoSql效率一流。但是慢,我這裡使用的資料只是10條而已,並沒有很多資料。我把資料加到100000,效率大概是20ms。如果這麼簡單就研究結束了的話,那真的是太辜負了程式猿要鑽研的精神了。sql分頁的方案,方案可是能有一大把,效率也是不一的,那Mongo難道就這一種,答案顯然不是這樣的。另外是否效率上,效能上會有問題呢?Redis篇裡,就吃過這樣的虧,亂用Keys。
在查看了一些資料之後,發現所有的資料都是這樣說的:
不要輕易使用Skip來做查詢,否則資料量大了就會導致效能急劇下降,這是因為Skip是一條一條的數過來的,多了自然就慢了。
這麼說Skip就要避免使用了,那麼如何避免呢?首先來回顧SQL分頁的後一種時間戳分頁方案,這種利用欄位的有序性質,利用查詢來取資料的方式,可以直接避免掉了大量的數數。也就是說,如果能附帶上這樣的條件那查詢效率就會提高,事實上是這樣的麼?我們來驗證一下:
這裡我們假設查詢第100001條資料,這條資料的Amount值是:2399927,我們來寫兩條語句分別如下:
db.test.sort({"amount":1}).skip(100000).limit(10)//183ms db.test.find({amount:{$gt:2399927}}).sort({"amount":1}).limit(10)//53ms |
結果已經附帶到註釋了,很明顯後者的效能是前者的三分之一,差距是非常大的。也印證了Skip效率差的理論。
MongoDB會根據查詢,來載入文件的索引和元資料到記憶體裡,並且建議文件元資料的大小始終要保持小於機器記憶體,否則效能會下降。
總結
這篇文章,基於Skip分頁和有序欄位查詢分頁兩種方案進行的對比。後者說白了只是利用查詢結果不用依次數數來提高了效能。Skip雖然效率低一些但是通用一些,有序欄位的查詢,需要在設計分頁的時候對這個欄位做一些處理,起碼要點了頁碼能獲取到這個欄位。這裡我附加一個方式,就是兩者的結合,我們可以拿每次展示的那頁資料上的最後一個,結合Skip來處理分頁,這樣的話,相對來說更好一些。這裡就不具體實現了。其他方式的效能比較和實現,歡迎大牛們來分享,十分感謝。另外本篇中如有紕漏和不足請留言指教。