大位移量下Redis、MongoDB分頁/排名效能比較,redismongodb

來源:互聯網
上載者:User

大位移量下Redis、MongoDB分頁/排名效能比較,redismongodb

題目其實並不太準確,因為資料庫並不會提供分頁、排名等功能,提供的只是資料的存取,分頁排名這些都是我們基於資料庫的實用案例而已。然而無論是Redis還是MongoDB,通常都有一些常規的做分頁和排名的方法。本文就通過一些測試資料來向大家介紹Redis和MongoDB(以及傳統關係型資料庫)在這方面的效能差別。

分頁

首先我們來做一個分頁,在MongoDB中樣本資料如下所未:

db.scores.find();{lid: ObjectId("4fe506dabb2bfa742d000001"), score: 1, name: 'user_1'}{lid: ObjectId("4fe506dabb2bfa742d000001"), score: 2, name: 'user_2'}{lid: ObjectId("4fe506dabb2bfa742d000001"), score: 3, name: 'user_3'}{lid: ObjectId("4fe506dabb2bfa742d000001"), score: 4, name: 'user_4'}

其中lid欄位用於區分不同的緯度,主要用在篩選上,在測試collection中,一共有五個不同的lid值,每一個對應1,200,000條資料,一共6,000,000條資料。索引在lid 和 score上。(下面的查詢能使用到索引)

然後我們進行下面的效能測試:

collection = Mongo::Connection.new.db('test').collection('scores')Benchmark.bmbm do |x|  x.report("mongo small") do    100.times do |i|      collection.find({:lid => lids.sample}, {:fields => {:_id => false, :score => true, :user => true}}).sort({:score => -1}).limit(20).skip(i * 20).to_a    end  end  x.report("mongo medium") do    100.times do |i|      collection.find({:lid => lids.sample}, {:fields => {:_id => false, :score => true, :user => true}}).sort({:score => -1}).limit(20).skip(i * 1000).to_a    end  end  x.report("mongo large") do    100.times do |i|      collection.find({:lid => lids.sample}, {:fields => {:_id => false, :score => true, :user => true}}).sort({:score => -1}).limit(20).skip(i * 10000).to_a    end  endend

上面分別對skip條數比較小,中等大小和非常大三種情況進行了測試。而limit指定擷取的資料都一樣是20條。這三種情況下的測試結果分別是:0.6 秒, 17 秒,173 秒。

我們可以看到,對MongoDB來說,skip的大小嚴重影響效能,應該嚴格避免特別大的skip操作。

下面我們將類似的資料用Redis的Sorted Sets進行儲存。並進行相應的效能測試

redis = Redis.new(:driver => :hiredis)Benchmark.bmbm do |x|  x.report("redis small") do    100.times do |i|      start = i * 20      redis.zrevrange(lids.sample, start, start + 20, :with_scores => true)    end  end  x.report("redis medium") do    100.times do |i|      start = i * 1000      redis.zrevrange(lids.sample, start, start + 20, :with_scores => true)    end  end  x.report("redis large") do    100.times do |i|      start = i * 10000      redis.zrevrange(lids.sample, start, start + 20, :with_scores => true)    end  end

這裡skip的值和上面MongoDB中是一樣的,那麼Redis的表現如何呢。這三種情況下的測試結果分別是:0.028 秒, 0.025 秒, 0.028 秒。

採用類似於MongoDB的資料結構儲存在PostgreSQL中並進行相同的測試,其結果比MongoDB還要差一點。具體結果如下:

mongo small   0.6
mongo medium   17
mongo large   173
redis small   0.028
redis medium   0.025
redis large   0.028
pg small   1
pg medium   122
pg large   650

排名

排名功能與分頁功能類似,不同的是排名是通過計算大於某個值的條數來做的。

比如:

//sqlselect count(*) from scores where lid = $1 and score > $2//mongodb.scores.find({lid: lid, score: {$gt: score}}).count()

由於排名和分頁實現原理上類似,所以結果實際上差不多。測試結果如下:

mongo top rank   1.155847
mongo average    22.291007

redis top rank   0.169442
redis average    0.162205

pg top rank      0.714144
pg average       21.771570

結論

上面做了對比,那麼本文要說一個什麼問題呢?

首先,在MongoDB中,盡量避免進行比較大的skip操作,比如在分頁中,如果你能知道需要擷取資料的上一條score是多少,那麼可能能夠用下面的方法來擷取你要的資料,而不是通過一次很大的skip操作。

  db.scores.find({lid: lid, score: {$lt: last_score}}).sort({score: -1}).limit(20)

另外,如果你需要進行比較大的skip操作或者count比較大的數量,那麼可以考慮採用Redis的Sorted Sets來做。

後記

本文在微博上引起了一些技術朋友的討論,對於對比的問題這裡做一個說明。

我 們知道,Redis是記憶體資料庫,而MongoDB不是,所以有朋友質疑這裡的對比是否只是記憶體與磁碟的對比。實際上這一說法不無道理,上面的測試資料出 自原作者文章,其文章也並未提及MongoDB是否都在記憶體中。根據我個人的實驗結果,當資料全部能夠在記憶體中時,確實不會出現如本文中所說的 MongoDB效能嚴重差異。但是,隨著skip的變大,操作時間還是在顯著變長,而Redis的Sorted Sets則相對穩定。

同時也歡迎更多實驗對比資料和原理分析的討論。感謝大家。


相關文章

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.