* MongoDB vs Redis vs Tokyo Tyrant(原文链接:http://www.cnblogs.com/riceball/archive/2010/03/05/MongoDB_Vs_Redis_Vs_TokyoTyrant.html)
准备对MongoDB, Redis以及Tokyo Tyrant的读写做一个简单的测试,为了进行相对公平的测试,需要了解他们背后的实现机制,下面是一些比较:
 
存储实现的比较:
   * 内存文件映像(Memory-File Mapping) Redis, MongoDB
   * 文件 + Cache  Tokyo Tyrant
   * 内存: Redis, Tokyo Tyrant
Key/Value索引形式:
  * B+ Tree  : MongoDB, Tokyo Tyrant
  * Hash Table: Redis, Tokyo Tyrant
  * Fixed Length: Tokyo Tyrant
 
从上面的比较可以看出,Redis和MongoDB是基于系统内存映像文件,数据能命中在内存的时候读写操作性能应该是非常强的,当然,反过来,如果数据十分分散不能在内存命中,那么内存页的切换开销将是非常可怕的,MongoDB和Redis数据文件不同的是将数据存放在多个文件中,每当上一个存满的时候就会创建新的数据空间文件。鉴于MongoDB 是主要比较对象,而其采用B+Tree进行存储,故TT也使用B+Tree引擎进行比较。
 
那么该测试什么自然就可以得知:尽管使用内存映像文件读写操作会很快(快到什么程度),但是当写满内存以后呢?
 
文件大小限制:
32bit: MongoDB <= 2G
       TT no limits if u ./configure --enable-off
64bit: MongoDB和TT均无限制。
 
注:Redis 总是受限于内存的大小。
 
为了进行相对公平的测试:
首先通过虚拟机对内存的使用进行同等限制,因为MongoDB和Redi实际上读写都是在内存操作的(利用MemoryMap文件),故当数据库的大小超过内存大小时候的性能尤为重要。故用虚拟机来设置一个较小的内存大小,来快速观察数据库大小超过内存的时候的性能。
这里设置虚拟机内存256M,实际可使用内存200M左右,CPU 2核,Unbuntu Server 9.10
 
测试记录:
Key: 512的随机字符串
Value: 大约5k的随机字符串
每项记录数据大小:大约5.5k
计划插入数据100000条:5.5k*1000=5.5M*100=550M 数据量大约 550M。
 
注:key开始是用1k的随机字符串来测试,但是在测试mongoDB 报告key too large to index, 因此减小key的大小到512字节。
 
当没有任何数据的时候:
MongoDB的大小: 
  64M: (db.0, db.1, ..)data FIle
  16M: (database.ns) name space index file.
 
TC的大小:
133K btree.tcb
256  fixed.tcf
517K hash.tch
 
Redis的大小:
VirtualMemFile: 41M redis-3546.vm
DB: 0M
注:redis的文件初始大小基本等于你设置的内存以及内存页的大小,可以自己调整。redis通过定时存盘的策略进行保存,定时策略可以自行设置。
通常情况下,redis的数据库必须<=内存,如果要让redis的数据库大于内存,那么必须在配置中打开vm_enabled选项(貌似没用,当插入数据超过内存后,会被Unbuntu的后台保护进程给杀掉,如果设置了最大使用的内存,则数据已有记录数达到内存限值后不能继续插入新值)。
 
key/value 功能:
Redis: 读写key/value,value可以有各种结构,但Value无索引。
MongoDB: 以collection组织,key如果不特别指定将由系统作为ObjectId产生(指定使用“_id”字段),value是结构化的,value里的字段可以被索引。
TokyoTyrant: 读写key/value,table 数据引擎支持结构化的value和字段索引,其它数据引擎不支持,b+tree可以用key索引。
 
基准测试机器:
虚拟机是跑在 2 CPU 2.26G Intel Core 2 Duo,内存为2G
虚拟机:
  CPU  2核
  内存 256M
  操作系统:Unbuntu Server 9.10 32bit
 
使用软件版本:
  * MongoDB: mongodb-linux-i686-2010-02-26
  * TokyoTyrant:  TT1.1.40; TC1.4.42
  * Redis: 2010-03-01(GIT SRC)
 
启动:
redis-server ./redis.conf(设置了最大内存210兆:maxmemory 210000000, vm-enable=yes,vm-max-memory 20000000,vm-pages 1342177)
./ttserver -port 1974 /data/db/tt.tcb
 bin/mongod -port 1974 --dbpath /data/db/mongo
 
MongoDB
如上所述测试添加10万条数据:
内存,刚开始的时候虚拟内存占用48564,物理内存占用 3432,在插入2000条数据后,虚拟内存到达143M,物理内存33M,内存增长很迅速。最后虚拟内存稳定在1048M,物理内存则在160M-211M徘徊。
CPU占用率最低的时候为6%,最高的时候达到30%,平时在8%-10%之间。
从测试看,每次分配DB空间的时候所有插入操作被冻结,最坏的一次插入2000条耗时1分多(这个时候正好有分配空间文件发生),平时,插入2000条数据大约耗时17-18秒。
最后MongoDB的数据文件总大小达到:977M
 
接着测试MongoDB读取10万条记录(非命中形式:该key是随机产生的,因此大都不会存在数据库中)
 
内存:虚拟内存稳定在1048M,物理内存占用在90M-94M。
CPU:最低占用8%,最高到45%;平时在10%-12%左右。
读取2000条记录大约耗时3-4秒,第一次用了6秒。
 
Redis
同样测试添加10万条数据:
内存,开始的时候忘记看了,大致较开始的虚拟内存占用112M,物理内存82M,在4万条记录的时候VM占用196M,物理内存占用163M,最后的时候VM占用237M,物理内存204M。
CPU:最低占用3%,最高的时候15%,平时在7%-11%之间。
当Redis向磁盘写入数据的时候,有变慢(2000条记录耗时21秒),平时存2000条记录大约耗时18-19秒左右。
不过没有设定maxmemory的时候,在大约写入 6万多个数据后服务器被挂掉。当设置最大使用内存(200M)后,达到内存限制,写入不了(已写入48136个数据),但是不会挂了。
Redis文件在写入48136个数据时候的大小(包括VM文件):277M,其中VM 41M,数据库236M。
 
接着测试Redis读取10万条记录(非命中形式:该key大都不会存在数据库中)
内存:虚拟内存237M,物理内存占用204M
CPU:在26%-43%
 
读取2000条记录大约耗时在3-4秒。
 
Tokyo Tyrant
如上所述测试添加10万条数据:采用默认配置参数运行TT B+Tree
内存:初始的时候VM: 76928 物理内存: 1232,在插入的过程内存的增加很少,在插入到4万条记录的时候虚拟内存仅为99540,物理内存23M,到最后虚拟内存117M,物理内存37M。
CPU占用率始终稳定在2%
 
在插入到5万条记录前,平均插入2000条耗时约19-20秒,到8万条记录前时候,插入2000条耗时20-22秒,再接下来的2万条,平均插入2000条耗时在慢慢增加并有震荡,28秒,最后到42秒(B+Tree的索引节点在内存中满了?可能需要调整参数?)。
TT的数据库只有一个文件大小为:589M 
 
接着测试TT读取10万条记录(非命中形式:该key大都不会存在数据库中)
内存稳定在:VM110M;物理内存36M。
CPU:最低2%,最高6%,平时在4%
 
读取2000条记录大约耗时在7-8秒,偶尔6秒或9秒。
 
小结:
MongoDB和Redis写入数据不是直接写入磁盘,所以当重启系统时候没有存盘的数据将全部丢失。TT实际上也有内存缓冲,不过和前者相比要小的多。
以上测试并不完善,只是一个开始,比如没有测试小数据(以数字作为key,100字节Value),没有测试较大的数据(20K左右);没有测试在命中情况下的性能;没有测试并发读写的性能,据闻MongoDB的并发读写效率不是特别出色,MongoDB的特色在于支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,并实现了存储节点的自动sharding管理等配套功能;以及由于MongoDB是分布在多个文件中,当数据量远大内存,分布在足够多的文件的时候的性能;对开启同步日志后的Replication测试....对于TT来说,需要对TT的其它数据引擎进行测试,以及TT的各种数据引擎如何优化?TC/TT在mixi的实际应用当中,存储了2000万条以上的数据,同时支撑了上万个并发连接,是一个久经考验的项目。TC在保证了极高的并发读写性能的同时,具有可靠的数据持久化机制,同时还支持类似关系数据库表结构的hashtable以及简单的条件,分页和排序操作,是一个很棒的NoSQL数据库。TC的主要缺点是在数据量达到上亿级别以后,并发写数据性能会大幅度下降(读不受影响),NoSQL: If Only It Was That Easy提到,他们发现在TC里面插入1.6亿条2-20KB数据的时候,写入性能开始急剧下降。Redis本质上是一个Key-Value类型的内存数据库,很像memcached,整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作,Redis的性能非常出色,Redis最大的魅力是支持保存List链表和Set集合的数据结构,而且还支持对List进行各种操作,例如从List两端push和pop数据,取 List区间,排序等等,对Set支持各种集合的并集交集操作,此外单个value的最大限制是1GB,不像memcached只能保存1MB的数据,Redis可以用来实现很多有用的功能,比方说用他的List来做FIFO双向链表,实现一个轻量级的高性能消息队列服务,用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间,因此也可以被当作一个功能加强版的memcached来用。
 
测试程序和详细记录见附件: testbench.tgz.zip

mongodb vs redis(Tokyo Tyrant转)的更多相关文章

  1. [原]分享一下我和MongoDB与Redis那些事

    缘起:来自于我在近期一个项目上遇到的问题,在Segmentfault上发表了提问 知识背景: 对不是很熟悉MongoDB和Redis的同学做一下介绍. 1.MongoDB数组查询:MongoDB自带L ...

  2. MySQL、MongoDB、Redis数据库Docker镜像制作

    MySQL.MongoDB.Redis数据库Docker镜像制作 在多台主机上进行数据库部署时,如果使用传统的MySQL的交互式的安装方式将会重复很多遍.如果做成镜像,那么我们只需要make once ...

  3. Linux系统安装NoSQL(MongoDB和Redis)步骤及问题解决办法

    ➠更多技术干货请戳:听云博客 如下是我工作中的记录,介绍的是linux系统下NoSQL:MongoDB和Redis的安装过程和遇到的问题以及解决办法: 需要的朋友可以按照如下步骤进行安装,可以快速安装 ...

  4. Mongodb 和Redis 的相同点和不同点

    MongoDB和Redis都是NoSQL,采用结构型数据存储.二者在使用场景中,存在一定的区别,这也主要由于二者在内存映射的处理过程,持久化的处理方法不同.MongoDB建议集群部署,更多的考虑到集群 ...

  5. Tokyo Tyrant(TTServer)系列(四)-tcrmgr远程管理与调试

    Tokyo Tyrant(TTServer)系列-tcrmgr(远程管理与调试) tcrmgr是TokyoTyrant的管理工具,对ttserver进行管理与执行命令: 通过输入tcrmgr回车,能够 ...

  6. MongoDB与Redis的比较

    MongoDB和Redis都是NoSQL,采用结构型数据存储.二者在使用场景中,存在一定的区别,这也主要由于二者在内存映射的处理过程,持久化的处理方法不同. MongoDB建议集群部署,更多的考虑到集 ...

  7. MySQL、MongoDB、Redis 数据库之间的区别

    NoSQL 的全称是 Not Only SQL,也可以理解非关系型的数据库,是一种新型的革命式的数据库设计方式,不过它不是为了取代传统的关系型数据库而被设计的,它们分别代表了不同的数据库设计思路. M ...

  8. Tokyo Tyrant(TTServer)系列(一)-介绍和安装

    Tokyo Cabinet 是日本人Mikio Hirabayashi 开发的一款DBM 数据库,该数据库读写很快.哈希模式写入100 万条数据仅仅需0.643 秒.读取100 万条数据仅仅需0.77 ...

  9. 百万级运维心得一:Mongodb和Redis数据不能放在同一个服务器

    百万级运维经验一:Mongodb和Redis数据不能放在同一个服务器 一开始时,为了省服务器,把Mongodb和Redis放在一个服务器上.网站每到高峰期都特别卡,还经常出现502.找了很久的原因,发 ...

随机推荐

  1. [haoi2008]玩具命名

    某人有一套玩具,并想法给玩具命名.首先他选择WING四个字母中的任意一个字母作为玩具的基本名字.然后他会根据自己的喜好,将名字中任意一个字母用“WING”中任意两个字母代替,使得自己的名字能够扩充得很 ...

  2. telnet命令发送邮件

    下面的例子是用qq的smtp服务器. set localecho 本地回显启用 smtp.qq.com Esmtp QQ Mail Server helo sis smtp.qq.com//服务器返回 ...

  3. poj1236学校网络——连通块

    题目:http://poj.org/problem?id=1236 通过传输文件的特点可以看出要先求强联通分量,缩点: 问题1:即缩点后入度为0的点,从它们开始传文件可以传给所有学校: 问题2:对于所 ...

  4. SPOJ(后缀数组求不同子串个数)

    DISUBSTR - Distinct Substrings Given a string, we need to find the total number of its distinct subs ...

  5. Nuget:Newtonsoft.Json

    ylbtech-Nuget:Newtonsoft.Json 1.返回顶部   2.返回顶部 1,Serialize JSON Product product = new Product(); prod ...

  6. zabbix snmp、jmx配置使用

    SNMP: snmp是很古老的监控,我萌几乎可以在所有设备上看到它的身影 [root@linux-node1 ~]# yum install net-snmp net-snmp-libs net-sn ...

  7. UItextFied 的属性

    网络学习笔记 在iPhone应用中通过UITextField填写信息时,经常出现出现自动更正输入信息.首字母大写等情况 尤其是在填写用户名时,这种本想提供便捷的功能反而让人感到特别麻烦 今天查了相关书 ...

  8. [转]git merge 跟 git merge -no-ff

    根据这张图片可以看出 git merge –no-ff 可以保存你之前的分支历史.能够更好的查看 merge历史,以及branch 状态. git merge 则不会显示 feature,只保留单条分 ...

  9. Httpclient入门代码

    /** * Project Name:httpClient * File Name:Test.java * Package Name:httpClient * Date:2017年11月9日上午8:3 ...

  10. shell脚本自动部署nignx反向代理及web服务器,共享存储

    #!/bin/bash systemctl status nginx var=$? ] then yum install epel-release -y ] then echo "epel库 ...