I had tested the following key-value store for set() and get()
- MemcacheDB, use memcached client protocol.
- Tokyo Tyrant (Tokyo Cabinet), use memcached client protocol
- Redis, use JRedis Java client
1. Test environment
1.1 Hardware/OS
2 Linux boxes in a LAN, 1 server and 1 test client
Linux Centos 5.2 64bit
Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (L2 cache: 6M), Quad-Core * 2
8G memory
SCSI disk (standalone disk, no other access)
1.2 Software version
db-4.7.25.tar.gz
libevent-1.4.11-stable.tar.gz
memcached-1.2.8.tar.gz
memcachedb-1.2.1-beta.tar.gz
redis-0.900_2.tar.gz
tokyocabinet-1.4.9.tar.gz
tokyotyrant-1.1.9.tar.gz
1.3 Configuration
Memcachedb startup parameter
Test 100 bytes
./memcachedb -H /data5/kvtest/bdb/data -d -p 11212 -m 2048 -N -L 8192
(Update: As mentioned by Steve, the 100-byte-test missed the -N paramter, so I added it and updated the data)
Test 20k bytes
./memcachedb -H /data5/kvtest/mcdb/data -d -p 11212 -b 21000 -N -m 2048
Tokyo Tyrant (Tokyo Cabinet) configuration
Use default Tokyo Tyrant sbin/ttservctl
use .tch database, hashtable database
ulimsiz=”256m”
sid=1
dbname=”$basedir/casket.tch#bnum=50000000″ # default 1M is not enough!
maxcon=”65536″
retval=0
Redis configuration
timeout 300
save 900 1
save 300 10
save 60 10000
# no maxmemory settings
1.4 Test client
Client in Java, JDK1.6.0, 16 threads
Use Memcached client java_memcached-release_2.0.1.jar
JRedis client for Redis test, another JDBC-Redis has poor performance.
2. Small data size test result
Test 1, 1-5,000,000 as key, 100 bytes string value, do set, then get test, all get test has result.
Request per second(mean)
| Store | Write | Read |
| Memcached | 55,989 | 50,974 |
| Memcachedb | 25,583 | 35,260 |
| Tokyo Tyrant | 42,988 | 46,238 |
| Redis | 85,765 | 71,708 |
Server Load Average
| Store | Write | Read |
| Memcached | 1.80, 1.53, 0.87 | 1.17, 1.16, 0.83 |
| MemcacheDB | 1.44, 0.93, 0.64 | 4.35, 1.94, 1.05 |
| Tokyo Tyrant | 3.70, 1.71, 1.14 | 2.98, 1.81, 1.26 |
| Redis | 1.06, 0.32, 0.18 | 1.56, 1.00, 0.54 |
3. Larger data size test result
Test 2, 1-500,000 as key, 20k bytes string value, do set, then get test, all get test has result.
Request per second(mean)
(Aug 13 Update: fixed a bug on get() that read non-exist key)
| Store | Write | Read |
| Memcachedb | 357 | 327 |
| Tokyo Tyrant | 3,501 | 257 |
| Redis | 1,542 | 957 |
4. Some notes about the test
When test Redis server, the memory goes up steadily, consumed all 8G and then use swap(and write speed slow down), after all memory and swap space is used, the client will get exceptions. So use Redis in a productive environment should limit to a small data size. It is another cache solution rather than a persistent storage. So compare Redis together with MemcacheDB/TC may not fair because Redis actually does not save data to disk during the test.
Tokyo cabinet and memcachedb are very stable during heavy load, use very little memory in set test and less than physical memory in get test.
MemcacheDB peformance is poor for write large data size(20k).
The call response time was not monitored in this test.
[…] 这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考 […]
[…] MemcacheDB，Redis数据库。状态全部保存在数据库中，并且通过数据库进行同步。 我们的业务特点是，并发不会太大，但是逻辑复杂。这可能是我们和互联网业务不同的地方。我们基本不会用无状态特性来水平扩展。 3、组合服务，流程，交互 组合服务就是一个服务会调用多个基本服务，通过封装来提供更粗粒度的服务，以达到重用，方便开发的目的。问题是组合服务中可能会记录服务调用的进度，特别是如果这个组合服务还涉及到和调用者的交互，如何保持无状态的特性？这个问题问过小米的嘉宾，不过没有具体回答，参会者有人提出米聊逻辑不会这么复杂。 确实如此，互联网业务的一个特点是逻辑简单，但是并发量大；而企业领域的一个特点是逻辑复杂，但是并发量一般不大。后来又参加天猫的一个分享，发现电子商务的逻辑也够复杂，应该算是互联网中的另类。而我们的业务特点是逻辑中很多地方都涉及到和用户的交互，即可能在流程的任意阶段，收到用户的某些事件。 一个组合服务如果不涉及到和用户的再次交互，那么保持无状态会简单一点，按照和用户的交互点对组合服务进一步分割是一个思路。还有一个思路是后端只提供基本服务，组合的调用，把它放到前端，类似于RESTful，将状态信息转移到客户端。 分享中涉及到目前一些开源的软件如thrift，消息队列产品，zookeeper等。 4、去c化 能够用脚本语言去完成的，尽量用脚本语言完成，可以提高开发的效率及质量。这是从新浪开发者演讲得出的一个结论，也是最近我们正在进行的一件事情。之前我们公司的程序员主要以C为主，即便是做业务开发也是基本用c（也会用java）。结果就是c程序开发成本和维护成本相对较高，如果业务逻辑复杂的话，更难处理，目前我们在linux服务器开发上尝试使用python，嵌入式开发尝试使用lua。已经尝试了几个项目，目前来看效果不错。 和这个相关的一个分享是ngx_lua。Nginx 的lua扩展，总体思路应该是很“通过将lua解释器集成进Nginx，可以采用lua脚本实现业务逻辑，由于lua的紧凑、快速以及内建协程，所以在保证高并发服务能力的同时极大地降低了业务逻辑实现成本。”。lua的运行效率相对其他脚本语言可能更好。缺点正如分享所说：基础设施不是很完善，开源库不够丰富。有人提问为什么不考虑python，ruby等其他脚本语言，分享者的回答是这些语言不支持协程，所以直接就不在考虑范围之内。python应该是支持协程，自带的yield虽然实现协程受限较多，但是第三方的实现，比如greenlet还是比较成熟的，这一块我使用的还是比较多的。我分析没有考虑python的原因可能是python的协程实现和nginx集成有难度，同时运行性能也没有lua好（个人猜测，对nginx不是很熟悉）。可惜后面没有机会确认。 如果python可以的话，可读性，语言表达力，基础设施完备性相对lua优势更大。 nodejs:适合IO密集，逻辑不复杂的系统。如果逻辑复杂，用回调描述逻辑是反人类认知的。这里使用协程更好。javascript中也有很多这方面的库。印象中老赵也开源了一个。 5、小小的遗憾 和我们领域接近的杭州的大公司，比如华为，海康，华三等基本上都是在这种技术交流中缺席的，比较遗憾。 总结： 两天时间学了不少东西，这里只记录了一些和我最近比较有共鸣的一些想法。同时，SOA和去c也是我最近的一个方向。 […]
[…] TC除了支持Key-Value存储之外，还支持保存Hashtable数据类型，因此很像一个简单的数据库表，并且还支持基于column的条 件查询，分页查询和排序功能，基本上相当于支持单表的基础查询功能了，所以可以简单的替代关系数据库的很多操作，这也是TC受到大家欢迎的主要原因之一， 有一个Ruby的项目miyazakiresistance将TT的hashtable的操作封装成和ActiveRecord一样的操作，用起来非常爽。TC/TT在mixi的实际应用当中，存储了2000万条以上的数据，同时支撑了上万个并发连接，是一个久经考验的项目。TC在保证了极高的并发 读写性能的同时，具有可靠的数据持久化机制，同时还支持类似关系数据库表结构的hashtable以及简单的条件，分页和排序操作，是一个很棒的 NoSQL数据库。TC的主要缺点是在数据量达到上亿级别以后，并发写数据性能会大幅度下降，NoSQL: If Only It Was That Easy提到，他们发现在TC里面插入1.6亿条2-20KB数据的时候，写入性能开始急剧下降。看来是当数据量上亿条的时候，TC性能开始大幅度下降，从TC作者自己提供的mixi数据来看，至少上千万条数据量的时候还没有遇到这么明显的写入性能瓶颈。这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考 […]
[…] 该文的url：http://my.oschina.net/victorli/blog/10939最近在研究Redis。去年曾做过一个MemcacheDB, Tokyo Tyrant, Redis performance test， 到目前为止，这个benchmark结果依然有效。这1年我们经历了很多眼花缭乱的key value存储产品的诱惑，从Cassandra的淡出(Twitter暂停在主业务使用)到HBase的兴起(Facebook新的邮箱业务选用 HBase(2))，当再回头再去看Redis，发现这个只有1万多行源代码的程序充满了神奇及大量未经挖掘的特性。Redis性能惊人，国内前十大网站 的子产品估计用1台Redis就可以满足存储及Cache的需求。除了性能印象之外，业界其实普遍对Redis的认识存在一定误区。本文提出一些观点供大 家探讨。 […]
我们测试data > 100k时，性能会急剧下降(100次/s)，不知道是不是我们的测试配置有问题，你能否帮忙测试一下？
[…] 题外话说完，最近又研究了Redis。去年曾做过一个MemcacheDB, Tokyo Tyrant, Redis performance test， […]
[…] 是否支持持久存储 是否支持认证 是否支持数据过期 其它 memcache 否 否 是 Tokyo Tyrant 是 否 否 支持双机互为主辅模式，主辅库均可读写；兼容Memcached协议 Redis 是 是 是 支持主从复制；支持k/v类型数据之外还支持set、list、hash等数据结构；支持事务 根据测试，总体上，Redis的读写性能优于memcache和ttserver。可参考http://timyang.net/data/mcdb-tt-redis/ […]
[…] 这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考 […]
[…] 题外话说完，最近又研究了Redis。去年曾做过一个MemcacheDB, Tokyo Tyrant, Redis performance test，到目前为止，这个benchmark结果依然有效。这1年我们经历了很多眼花缭乱的key value存储产品的诱惑，从Cassandra的淡出(Twitter暂停在主业务使用)到HBase的兴起(Facebook新的邮箱业务选用HBase(2))，当再回头再去看Redis，发现这个只有1万多行源代码的程序充满了神奇及大量未经挖掘的特性。Redis性能惊人，国内前十大网站的子产品估计用1台Redis就可以满足存储及Cache的需求。除了性能印象之外，业界其实普遍对Redis的认识存在一定误区。本文提出一些观点供大家探讨。 […]
[…] Redis是个高性能的key-value数据库，它的key具有丰富的数据结构：string，hash，list set和sorted set。作为NOSQL，比起memcache之类，不仅仅key数据结构丰富，而且具有持久化的功能，并且能够支持主从复制，很方便构建集群。redis高性能很大程度上源于它是个内存型数据库，它的高性能表现在：set操作11w/s，get操作8.1w/s，与其他类型数据库性能差异，可以而参考：http://timyang.net/data/mcdb-tt-redis/ 。为了进一步加深对redis的理解总结，我打算写个redis系列的博客。这里主要谈谈redis安装部署及运维维护。 […]
[…] 这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考 […]
[…] 这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考 […]
[…] 这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考 […]
[…] 这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考 […]
[…] 题外话说完，最近又研究了Redis。去年曾做过一个MemcacheDB, Tokyo Tyrant, Redis performance test，到目前为止，这个benchmark结果依然有效。这1年我们经历了很多眼花缭乱的key value存储产品的诱惑，从Cassandra的淡出(Twitter暂停在主业务使用)到HBase的兴起(Facebook新的邮箱业务选用HBase(2))，当再回头再去看Redis，发现这个只有1万多行源代码的程序充满了神奇及大量未经挖掘的特性。Redis性能惊人，国内前十大网站的子产品估计用1台Redis就可以满足存储及Cache的需求。除了性能印象之外，业界其实普遍对Redis的认识存在一定误区。本文提出一些观点供大家探讨。 […]
[…] 这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考 […]
[…] 这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考 […]
[…] 题外话说完，最近又研究了Redis。去年曾做过一个MemcacheDB, Tokyo Tyrant, Redis performance test，到目前为止，这个benchmark结果依然有效。这1年我们经历了很多眼花缭乱的key value存储产品的诱惑，从Cassandra的淡出(Twitter暂停在主业务使用)到HBase的兴起(Facebook新的邮箱业务选用HBase(2))，当再回头再去看Redis，发现这个只有1万多行源代码的程序充满了神奇及大量未经挖掘的特性。Redis性能惊人，国内前十大网站的子产品估计用1台Redis就可以满足存储及Cache的需求。除了性能印象之外，业界其实普遍对Redis的认识存在一定误区。本文提出一些观点供大家探讨。 […]
[…] FYI, a speed comparison of MemcacheDB, Redis and Tokyo Cabinet Tyrant […]
[…] MemcacheDB, Tokyo Tyrant, Redis performance test […]
[…] 这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考 3、Flare […]
You can try kyoto cabinat with on memory DB
oztweets.com…
MemcacheDB, Tokyo Tyrant, Redis performance test – Tim[后端技术]…
[…] MemcacheDB, Tokyo Tyrant, Redis performance test […]
Accept this comment and we’ll help save an made up animal!
[…] 这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考 […]
学习了， 我一直以为mc性能比Redis 好
[…] 新浪的 Tim Yang 做了 memcacheDB、Redis、tt server 的性能测试。这是比较早期的测试，相信随着版本的升级，两者的性能都会有所提升。不过按照这个测试的结果来看，redis 在数据量不多(500W)并且value 较小的时候，性能表现是很优越的；而对于稍大一些的 value ，tt 则在写方面表现很出色，但写的性能，相对较差。相比之下，redis的读写性能，倒是比较平衡。 […]
这篇文章 写的不错
[…] redis作为NoSQL数据库的一种应用，响应速度和命中率上还是比较高效的。项目中需要用集中式可横向扩展的缓存框架，做了一点调研，即便redis、memcached存在效率上的差异（具体比较参考http://timyang.net/data/mcdb-tt-redis/），但其实都能满足目前项目的需求；但是redis还是比较风骚的，支持链表和集合操作，支持正则表达式查找key，目前项目缓存的结果大多是链表，如果链表新增或者修改数据的话，redis就体现出了极大的优势（memcached只能重新加载链表，redis可以对链表新增或者修改） […]