Redis比mongoDB快多少?

Hom*_*er6 197 benchmarking mongodb redis

人们普遍提到Redis是"Blazing Fast",mongoDB也很快.但是,我很难找到比较两者结果的实际数字.鉴于类似的配置,功能和操作(并且可能显示因子如何随着不同的配置和操作而变化)等,Redis速度提高了10倍,速度提高了2倍,速度提高了5倍?

我只谈到性能.据我所知,mongoDB是一个不同的工具,具有更丰富的功能集.这不是"mongoDB 比Redis 更好 "的辩论.我问,Redis比mongoDB好多少?

在这一点上,即使是便宜的基准也比没有基准更好.

zee*_*kay 231

来自以下基准的粗略结果:2x写入,3x读取.

这是python中的一个简单基准,你可以适应你的目的,我看看每个只是设置/检索值的表现如何:

#!/usr/bin/env python2.7
import sys, time
from pymongo import Connection
import redis

# connect to redis & mongodb
redis = redis.Redis()
mongo = Connection().test
collection = mongo['test']
collection.ensure_index('key', unique=True)

def mongo_set(data):
    for k, v in data.iteritems():
        collection.insert({'key': k, 'value': v})

def mongo_get(data):
    for k in data.iterkeys():
        val = collection.find_one({'key': k}, fields=('value',)).get('value')

def redis_set(data):
    for k, v in data.iteritems():
        redis.set(k, v)

def redis_get(data):
    for k in data.iterkeys():
        val = redis.get(k)

def do_tests(num, tests):
    # setup dict with key/values to retrieve
    data = {'key' + str(i): 'val' + str(i)*100 for i in range(num)}
    # run tests
    for test in tests:
        start = time.time()
        test(data)
        elapsed = time.time() - start
        print "Completed %s: %d ops in %.2f seconds : %.1f ops/sec" % (test.__name__, num, elapsed, num / elapsed)

if __name__ == '__main__':
    num = 1000 if len(sys.argv) == 1 else int(sys.argv[1])
    tests = [mongo_set, mongo_get, redis_set, redis_get] # order of tests is significant here!
    do_tests(num, tests)
Run Code Online (Sandbox Code Playgroud)

使用mongodb 1.8.1和redis 2.2.5以及最新的pymongo/redis-py的结果:

$ ./cache_benchmark.py 10000
Completed mongo_set: 10000 ops in 1.40 seconds : 7167.6 ops/sec
Completed mongo_get: 10000 ops in 2.38 seconds : 4206.2 ops/sec
Completed redis_set: 10000 ops in 0.78 seconds : 12752.6 ops/sec
Completed redis_get: 10000 ops in 0.89 seconds : 11277.0 ops/sec
Run Code Online (Sandbox Code Playgroud)

当然,用一粒盐取结果!如果您使用其他语言进行编程,使用其他客户端/不同的实现等,您的结果将会变化很大.更不用说你的用法将完全不同!您最好的选择是以您打算使用它们的方式自己进行基准测试.作为推论,你可能会找出利用每种方法的最佳方法.永远都是自己的基准!

  • @sivann这篇文章从没有基准到明确的"粗略"基准.不要成为"基准是误导"废话的巨魔.当然,不同的条件可以改变结果.贡献回来并提交您自己的基准测试来测试您的案例并从该帖子链接,然后我们都将受益于您的"测试"意见. (49认同)
  • 我同意@sivann,你发布的基准*致命*有缺陷.MongoDB是多线程的,而Redis则不是.如果您的基准测试是多线程的,您会发现MongoDb在多核计算机上实际上具有更高的吞吐量. (4认同)
  • 值得评论的是,MongoDB和Redis具有不同的持久性结构,并且Redis仅支持能够适合内存的数据模式.虽然ram很便宜,如果你需要使用/存储超过12-16GB的数据,我会看到你的服务器选项是什么样的. (3认同)
  • @sivann默认(发货)配置是此基准测试的内容.恕我直言,默认配置确定包所在的fsync栏的哪一侧.对于Redis,它被宣传为内存服务器,当数据库大于系统总内存时,它会促使人们使用其他替代方案.对于MongoDB,它被公布为数据库.Postgres永远不会关闭fsync,因为他们显然是在持久阵营中.大多数人不会修改配置,因此这个基准测试对于这些情况来说有些准确. (2认同)
  • @ Homer6即使对于面向内存的DB,也应该在启用[WriteConcern](http://docs.mongodb.org/manual/core/write-operations/#write-concern)的情况下进行测试(默认情况下禁用).对于任何类型的基准测试,无测试都是无稽之谈.类似于reddis.不在磁盘上同步所有事务的DB,通过将数据复制到至少2台服务器来维护安全性.这意味着您的写入不会等待磁盘同步,而是在返回之前进行网络复制.不等待错误是从未做过的事情.比如在写入网络时没有检测到网线是否已连接. (2认同)

And*_*ich 18

请查看有关Redis和MongoDB插入性能分析的帖子:

即使与Redis RPUSH相比,mongodb $ push也可以更快地达到5000个条目,然后它变得非常慢,可能mongodb阵列类型具有线性插入时间,因此它变得越来越慢.mongodb可能通过暴露恒定时间插入列表类型获得一些性能,但即使使用线性时间数组类型(可以保证恒定时间查找),它也可以应用于小型数据集.


Tar*_*lah 15

简单的基准

我尝试使用当前版本的redis(2.6.16)和mongo(2.4.8)再次重新计算结果,这是结果

Completed mongo_set: 100000 ops in 5.23 seconds : 19134.6 ops/sec
Completed mongo_get: 100000 ops in 36.98 seconds : 2703.9 ops/sec
Completed redis_set: 100000 ops in 6.50 seconds : 15389.4 ops/sec
Completed redis_get: 100000 ops in 5.59 seconds : 17896.3 ops/sec
Run Code Online (Sandbox Code Playgroud)

博客文章也比较了它们,但使用了node.js. 它显示了数据库中条目数量随时间增加的影响.


Joh*_*ler 8

数字很​​难找到,因为两者并不在同一个空间.一般的答案是,当数据集适合单台机器的工作内存时,Redis的速度提高10 - 30%.一旦超过该数量的数据,Redis就会失败.Mongo将减速,其数量取决于负载的类型.对于仅插入类型的负载,一个用户最近报告了6到7个数量级(10,000到100,000次)的减速,但该报告还承认存在配置问题,并且这是非常非典型的工作负载.当必须从磁盘读取一些数据时,正常读取重负载的速度大约为10倍.

结论: Redis会更快,但不是很多.


mis*_*ves 7

这是一篇关于Tornado框架中大约1岁的会话性能的优秀文章.它对几个不同的实现进行了比较,其中包括Redis和MongoDB.文章中的图表表明,在这个特定的用例中,Redis在MongoDB中的支持率约为10%.

Redis附带内置基准测试,可分析您所使用机器的性能.Redis 的Benchmark wiki上有大量的原始数据.但你可能不得不为Mongo看一下.就像这里,这里,以及一些随机抛光数字(但它为您提供了自己运行一些MongoDB基准测试的起点).

我相信这个问题的最佳解决方案是在你期望的各种情况下自己进行测试.