大偏移量下Redis、MongoDB分页/排名性能比较

题目其实并不太准确,因为数据库并不会提供分页、排名等功能,提供的只是数据的存取,分页排名这些都是我们基于数据库的实用案例而已。然而无论是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
  end
end

上面分别对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

排名

排名功能与分页功能类似,不同的是排名是通过计算大于某个值的条数来做的。

比如:

//sql
select count(*) from scores where lid = $1 and score > $2

//mongo
db.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则相对稳定。

同时也欢迎更多实验对比数据和原理分析的讨论。感谢大家。

时间: 2024-07-31 14:53:24

大偏移量下Redis、MongoDB分页/排名性能比较的相关文章

MongoDB 分页查询的方法及性能

这篇文章着重的讲讲MongoDB的分页查询 传统的SQL分页 传统的sql分页,所有的方案几乎是绕不开 row_number的,对于需要各种排序,复杂查询的场景,row_number就是杀手锏.另外,针对现在的web很流行的poll/push加载分 页的方式,一般会利用时间戳来实现分页. 这两种分页可以说前者是通用的,连Linq生成的分页都是row_number,可想而知它多通用.后者是无论是性能和复杂程度都是最好的,因为只要简单 的一个时间戳即可. MongoDB分页 进入到Mongo的思路,

C#MongoDB 分页查询的方法及性能

传统的SQL分页 传统的sql分页,所有的方案几乎是绕不开row_number的,对于需要各种排序,复杂查询的场景,row_number就是杀手锏.另外,针对现在的web很流行的poll/push加载分页的方式,一般会利用时间戳来实现分页. 这两种分页可以说前者是通用的,连Linq生成的分页都是row_number,可想而知它多通用.后者是无论是性能和复杂程度都是最好的,因为只要简单的一个时间戳即可. MongoDB分页 进入到Mongo的思路,分页其实并不难,那难得是什么?其实倒也没啥,看明白

MongoDB分页处理方案(适用于一般数据库的分页方法)

MongoDB分页处理方案(适用于一般数据库的分页方法) (2012-11-06 17:59:55) 转载▼ 标签: mongodb 分页 数据库 跳转 分类: MongoDB 转载请注明出处:http://blog.sina.com.cn/s/blog_56545fd30101442b.html MongoDB的分页性能是广大使用者所诟病的大问题之一,在大数据量环境下,如果一次跳转的页数过多,如10W多页,可能用户要等上几十秒(瞎掰的数据),有兴趣的可以去看一下这篇文章Paging & Ran

大数据下的数据分析平台架构zz

转自http://www.cnblogs.com/end/archive/2012/02/05/2339152.html 随着互联网.移动互联网和物联网的发展,谁也无法否认,我们已经切实地迎来了一个海量数据的时代,数据调查公司IDC预计2011年的数据总量将达到1.8万亿GB,对这些海量数据的分析已经成为一个非常重要且紧迫的需求. 作为一家互联网数据分析公司,我们在海量数据的分析领域那真是被“逼上梁山”.多年来在严苛的业务需求和数据压力下,我们几乎尝试了所有可能的大数据分析方法,最终落地于Had

Memcached, Redis, MongoDB区别

mongodb和memcached不是一个范畴内的东西.mongodb是文档型的非关系型数据库,其优势在于查询功能比较强大,能存储海量数据.mongodb和memcached不存在谁替换谁的问题. 和memcached更为接近的是redis.它们都是内存型数据库,数据保存在内存中,通过tcp直接存取,优势是速度快,并发高,缺点是数据类型有限,查询功能不强,一般用作缓存.在我们团队的项目中,一开始用的是memcached,后来用redis替代. 相比memcached: 1.redis具有持久化机

NoSQL之Windows下Redis的测试使用

NoSQL简介 介绍Redis前,我想还是先认识下NoSQL,即not only sql, 是一种非关系型的数据存储,key/value键值对存储.现有Nosql DB 产品: redis/MongoDB/Memcached/Hbase/Cassandra/ Tokyo Cabinet/Voldemort/Dynomite/Riak/ CouchDB/Hypertable/Flare/Tin/Lightcloud/ KiokuDB/Scalaris/Kai/ThruDB, 等等~~~ 为什么需要

大数据下的数据分析平台架构

时间:2011-08-15 14:59 作者:谢超 随着互联网.移动互联网和物联网的发展,谁也无法否认,我们已经切实地迎来了一个海量数据的时代,数据调查公司IDC预计2011年的数据总量将达到1.8万亿GB,对这些海量数据的分析已经成为一个非常重要且紧迫的需求. 谢超 Admaster数据挖掘总监,云计算实践者,10年数据仓库和数据挖掘咨询经验,现专注于分布式平台上的海量数据挖掘和机器学习. 作为一家互联网数据分析公司,我们在海量数据的分析领域那真是被“逼上梁山”.多年来在严苛的业务需求和数据压

(转)Memcache,Redis,MongoDB(数据缓存系统)方案对比与分析

Memcache,Redis,MongoDB(数据缓存系统)方案对比与分析 数据库表数据量极大(千万条),要求让服务器更加快速地响应用户的需求. 二.解决方案: 1.通过高速服务器Cache缓存数据库数据 2.内存数据库 (这里仅从数据缓存方面考虑,当然,后期可以采用Hadoop+HBase+Hive等分布式存储分析平台) 三.主流解Cache和数据库对比: 上述技术基本上代表了当今在数据存储方面所有的实现方案,其中主要涉及到了普通关系型数据库(MySQL/PostgreSQL),NoSQL数据

[轉]redis;mongodb;memcache三者的性能比較

先说我自己用的情况: 最先用的memcache ,用于键值对关系的服务器端缓存,用于存储一些常用的不是很大,但需要快速反应的数据 然后,在另一个地方,要用到redis,然后就去研究了下redis. 一看,显示自己安装了php扩展,因为有服务器上的redis服务端,自己本地就没有安装,其实用法和memcache基本一样,可能就是几个参数有所不 同.当然 它们缓存的效果也不一样,具体的哪里不一样,一下就是一些资料,和自己的总结 1. Redis和Memcache都是将数据存放在内存中,都是内存数据库