这里有一篇关于Tornado框架中会话性能的优秀文章，大约有1年的历史。它有几个不同的实现之间的比较，其中包括Redis和MongoDB。文章中的图表表明，在这个特定的用例中，Redis落后于MongoDB大约10%。

Redis内置了一个基准测试，可以分析你所在机器的性能。在Redis的Benchmark维基上有大量的原始数据。但是你可能需要四处看看Mongo。比如这里、这里和一些随机的优化数字(但它为您自己运行一些MongoDB基准测试提供了一个起点)。

我相信这个问题的最佳解决方案是在您所期望的情况类型中自己执行测试。

这里有一篇关于Tornado框架中会话性能的优秀文章，大约有1年的历史。它有几个不同的实现之间的比较，其中包括Redis和MongoDB。文章中的图表表明，在这个特定的用例中，Redis落后于MongoDB大约10%。

Redis内置了一个基准测试，可以分析你所在机器的性能。在Redis的Benchmark维基上有大量的原始数据。但是你可能需要四处看看Mongo。比如这里、这里和一些随机的优化数字(但它为您自己运行一些MongoDB基准测试提供了一个起点)。

我相信这个问题的最佳解决方案是在您所期望的情况类型中自己执行测试。

在我的例子中，性能比较的决定因素是所使用的MongoDb WriteConcern。现在大多数mongo驱动都会将默认的WriteConcern设置为“已确认”，这意味着“写入到RAM”(Mongo2.6.3-WriteConcern)，在这方面，对于大多数写操作来说，它与redis非常相似。

但实际情况取决于您的应用程序需求和生产环境设置，您可能希望将此关注点更改为WriteConcern。JOURNALED(写入到oplog)或WriteConcern。FSYNCED(写入磁盘)，如果需要，甚至可以写入副本集(备份)。

然后您可能会看到性能有所下降。其他重要的因素还包括数据访问模式的优化程度、索引遗漏率(参见mongostat)和一般索引。

请查看这篇关于Redis和MongoDB插入性能分析的文章:

高达5000个条目的mongodb $push甚至比Redis RPUSH更快，然后它变得非常慢，可能mongodb数组类型有线性插入时间，所以它变得越来越慢。Mongodb可能通过公开常量时间插入列表类型获得一些性能，但即使使用线性时间数组类型(可以保证常量时间查找)，它也有用于小数据集的应用程序。

良好而简单的基准

我尝试使用当前版本的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

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

我认为所示基准上的2-3X是误导性的，因为如果你也取决于你运行它的硬件-从我的经验来看，机器越“强大”，差距就越大(有利于Redis)， 可能是因为基准测试很快就达到了内存限制。

至于内存容量——这部分是正确的，因为也有办法解决这个问题，有(商业)产品将Redis数据写回磁盘，也有集群(多分片)解决方案克服内存大小限制。