Redis、Memcache和MongoDB的区别(转载)

1. Memcached

1.1. Memcached的优点

  • Memcached可以利用多核优势,单实例吞吐量极高,可以达到几十万QPS(取决于key. value的字节大小以及服务器硬件性能,日常环境中QPS高峰大约在4-6w左右)。适用于最大程度扛量。
  • 支持直接配置为session handle。

1.2. Memcached的局限性

  • 只支持简单的key/value数据结构,不像Redis可以支持丰富的数据类型。
  • 无法进行持久化,数据不能备份,只能用于缓存使用,且重启后数据全部丢失。
  • 无法进行数据同步,不能将MC中的数据迁移到其他MC实例中。
  • Memcached内存分配采用Slab Allocation机制管理内存,value大小分布差异较大时会造成内存利用率降低,并引发低利用率时依然出现踢出等问题。需要用户注重value设计。

2. Redis

2.1. Redis的优点

  • 支持多种数据结构,如 string(字符串)、list(双向链表)、dict(hash表)、set(集合)、zset(排序set)、hyperloglog(基数估算)
  • 支持持久化操作,可以进行aof及rdb数据持久化到磁盘,从而进行数据备份或数据恢复等操作,较好的防止数据丢失的手段。
  • 支持通过Replication进行数据复制,通过master-slave机制,可以实时进行数据的同步复制,支持多级复制和增量复制,master-slave机制是Redis进行HA的重要手段。
  • 单线程请求,所有命令串行执行,并发情况下不需要考虑数据一致性问题。
  • 支持pub/sub消息订阅机制,可以用来进行消息订阅与通知。
  • 支持简单的事务需求,但业界使用场景很少,并不成熟。

2.2. Redis的局限性

  • Redis只能使用单线程,性能受限于CPU性能,故单实例CPU最高才可能达到5-6wQPS每秒(取决于数据结构,数据大小以及服务器硬件性能,日常环境中QPS高峰大约在1-2w左右)。
  • 支持简单的事务需求,但业界使用场景很少,并不成熟,既是优点也是缺点。
  • Redis在string类型上会消耗较多内存,可以使用dict(hash表)压缩存储以降低内存耗用。
  • Mc和Redis都是Key-Value类型,不适合在不同数据集之间建立关系,也不适合进行查询搜索。比如redis的keys pattern这种匹配操作,对redis的性能是灾难。

3. MongoDB

  • MongoDB 是一种文档性的数据库。先解释一下文档的数据库,即可以存放xml. json. bson类型系那个的数据。
    这些数据具备自述性(self-describing),呈现分层的树状数据结构。redis可以用hash存放简单关系型数据。
  • MongoDB 存放json格式数据。
  • 适合场景:事件记录、内容管理或者博客平台,比如评论系统。
  1. MongoDB持久化原理
    mongodb与mysql不同,mysql的每一次更新操作都会直接写入硬盘,但是mongo不会,做为内存型数据库,数据操作会先写入内存,然后再会持久化到硬盘中去,那么mongo是如何持久化的呢
    mongodb在启动时,专门初始化一个线程不断循环(除非应用crash掉),用于在一定时间周期内来从defer队列中获取要持久化的数据并写入到磁盘的journal(日志)和mongofile(数据)处,当然因为它不是在用户添加记录时就写到磁盘上,所以按mongodb开发者说,它不会造成性能上的损耗,因为看过代码发现,当进行CUD操作时,记录(Record类型)都被放入到defer队列中以供延时批量(groupcommit)提交写入,但相信其中时间周期参数是个要认真考量的参数,系统为90毫秒,如果该值更低的话,可能会造成频繁磁盘操作,过高又会造成系统宕机时数据丢失过。
  2. 什么是NoSQL数据库?NoSQL和RDBMS有什么区别?在哪些情况下使用和不使用NoSQL数据库?
    NoSQL是非关系型数据库,NoSQL = Not Only SQL。
    关系型数据库采用的结构化的数据,NoSQL采用的是键值对的方式存储数据。
    在处理非结构化/半结构化的大数据时;在水平方向上进行扩展时;随时应对动态增加的数据项时可以优先考虑使用NoSQL数据库。
    在考虑数据库的成熟度;支持分析和商业智能管理及专业性等问题时,应优先考虑关系型数据库。
  3. MySQL和MongoDB之间最基本的区别是什么?
    关系型数据库与非关系型数据库的区别,即数据存储结构的不同。
  4. MongoDB的特点是什么?
    (1)面向文档(2)高性能(3)高可用(4)易扩展(5)丰富的查询语言
  5. MongoDB支持存储过程吗?如果支持的话,怎么用?
    MongoDB支持存储过程,它是javascript写的,保存在db.system.js表中。
  6. 如何理解MongoDB中的GridFS机制,MongoDB为何使用GridFS来存储文件?
    GridFS是一种将大型文件存储在MongoDB中的文件规范。使用GridFS可以将大文件分隔成多个小文档存放,这样我们能够有效的保存大文档,而且解决了BSON对象有限制的问题。
  7. 为什么MongoDB的数据文件很大?
    MongoDB采用的预分配空间的方式来防止文件碎片。
  8. 当更新一个正在被迁移的块(Chunk)上的文档时会发生什么?
    更新操作会立即发生在旧的块(Chunk)上,然后更改才会在所有权转移前复制到新的分片上。
  9. MongoDB在A:{B,C}上建立索引,查询A:{B,C}和A:{C,B}都会使用索引吗?
    不会,只会在A:{B,C}上使用索引。
  10. 如果一个分片(Shard)停止或很慢的时候,发起一个查询会怎样?
    如果一个分片停止了,除非查询设置了“Partial”选项,否则查询会返回一个错误。如果一个分片响应很慢,MongoDB会等待它的响应。

4. Redis. Memcache和MongoDB的区别

从以下几个维度,对redis、memcache、mongoDB 做了对比

4.1. 性能

都比较高,性能对我们来说应该都不是瓶颈

总体来讲,QPS方面redis和memcache差不多,要大于mongodb

4.2. 操作的便利性

memcache数据结构单一

redis丰富一些,数据操作方面,redis更好一些,较少的网络IO次数

mongodb支持丰富的数据表达,索引,最类似关系型数据库,支持的查询语言非常丰富

4.3. 内存空间的大小和数据量的大小

redis在2.0版本后增加了自己的VM特性,突破物理内存的限制;可以对key value设置过期时间(类似memcache)

memcache可以修改最大可用内存,采用LRU算法

mongoDB适合大数据量的存储,依赖操作系统VM做内存管理,吃内存也比较厉害,服务不要和别的服务在一起

4.4. . 可用性(单点问题)

对于单点问题,

redis,依赖客户端来实现分布式读写;主从复制时,每次从节点重新连接主节点都要依赖整个快照,无增量复制,因性能和效率问题,

所以单点问题比较复杂;不支持自动sharding,需要依赖程序设定一致hash 机制。

一种替代方案是,不用redis本身的复制机制,采用自己做主动复制(多份存储),或者改成增量复制的方式(需要自己实现),一致性问题和性能的权衡

Memcache本身没有数据冗余机制,也没必要;对于故障预防,采用依赖成熟的hash或者环状的算法,解决单点故障引起的抖动问题。

mongoDB支持master-slave,replicaset(内部采用paxos选举算法,自动故障恢复),auto sharding机制,对客户端屏蔽了故障转移和切分机制。

4.5. 可靠性(持久化)

对于数据持久化和数据恢复,

redis支持(快照. AOF):依赖快照进行持久化,aof增强了可靠性的同时,对性能有所影响

memcache不支持,通常用在做缓存,提升性能;

MongoDB从1.8版本开始采用binlog方式支持持久化的可靠性

4.6. 数据一致性(事务支持)

Memcache 在并发场景下,用cas保证一致性

redis事务支持比较弱,只能保证事务中的每个操作连续执行

mongoDB不支持事务

4.7. 数据分析

mongoDB内置了数据分析的功能(mapreduce),其他不支持

4.8. 应用场景

4.8.1. Redis应用场景

redis:数据量较小的更性能操作和运算上

  1. 热点数据的缓存
    由于redis访问速度块. 支持的数据类型比较丰富,所以redis很适合用来存储热点数据,另外结合expire,我们可以设置过期时间然后再进行缓存更新操作,这个功能最为常见,我们几乎所有的项目都有所运用。

  2. 限时业务的运用
    redis中可以使用expire命令设置一个键的生存时间,到时间后redis会删除它。利用这一特性可以运用在限时的优惠活动信息. 手机验证码等业务场景。

  3. 计数器相关问题
    redis由于incrby命令可以实现原子性的递增,所以可以运用于高并发的秒杀活动. 分布式序列号的生成. 具体业务还体现在比如限制一个手机号发多少条短信. 一个接口一分钟限制多少请求. 一个接口一天限制调用多少次等等。

  4. 排行榜相关问题
    关系型数据库在排行榜方面查询速度普遍偏慢,所以可以借助redis的SortedSet进行热点数据的排序。

在奶茶活动中,我们需要展示各个部门的点赞排行榜, 所以我针对每个部门做了一个SortedSet,然后以用户的openid作为上面的username,以用户的点赞数作为上面的score, 然后针对每个用户做一个hash,通过zrangebyscore就可以按照点赞数获取排行榜,然后再根据username获取用户的hash信息,这个当时在实际运用中性能体验也蛮不错的。

  1. 分布式锁
    这个主要利用redis的setnx命令进行,setnx:"set if not exists"就是如果不存在则成功设置缓存同时返回1,否则返回0 ,这个特性在俞你奔远方的后台中有所运用,因为我们服务器是集群的,定时任务可能在两台机器上都会运行,所以在定时任务中首先 通过setnx设置一个lock,如果成功设置则执行,如果没有成功设置,则表明该定时任务已执行。 当然结合具体业务,我们可以给这个lock加一个过期时间,比如说30分钟执行一次的定时任务,那么这个过期时间设置为小于30分钟的一个时间 就可以,这个与定时任务的周期以及定时任务执行消耗时间相关。

当然我们可以将这个特性运用于其他需要分布式锁的场景中,结合过期时间主要是防止死锁的出现。

  1. 延时操作
    这个目前我做过相关测试,但是还没有运用到我们的实际项目中,下面我举个该特性的应用场景。 比如在订单生产后我们占用了库存,10分钟后去检验用户是够真正购买,如果没有购买将该单据设置无效,同时还原库存。 由于redis自2.8.0之后版本提供Keyspace Notifications功能,允许客户订阅Pub/Sub频道,以便以某种方式接收影响Redis数据集的事件。 所以我们对于上面的需求就可以用以下解决方案,我们在订单生产时,设置一个key,同时设置10分钟后过期, 我们在后台实现一个监听器,监听key的实效,监听到key失效时将后续逻辑加上。 当然我们也可以利用rabbitmq. activemq等消息中间件的延迟队列服务实现该需求。

  2. 分页、模糊搜索
    redis的set集合中提供了一个zrangebylex方法,语法如下:

ZRANGEBYLEX key min max [LIMIT offset count]

通过ZRANGEBYLEX zset - + LIMIT 0 10 可以进行分页数据查询,其中- +表示获取全部数据

zrangebylex key min max 这个就可以返回字典区间的数据,利用这个特性可以进行模糊查询功能,这个也是目前我在redis中发现的唯一一个支持对存储内容进行模糊查询的特性。

前几天我通过这个特性,对学校数据进行了模拟测试,学校数据60万左右,响应时间在700ms左右,比mysql的like查询稍微快一点,但是由于它可以避免大量的数据库io操作,所以总体还是比直接mysql查询更利于系统的性能保障。

  1. 点赞、好友等相互关系的存储
    Redis set对外提供的功能与list类似是一个列表的功能,特殊之处在于set是可以自动排重的,当你需要存储一个列表数据,又不希望出现重复数据时,set是一个很好的选择,并且set提供了判断某个成员是否在一个set集合内的重要接口,这个也是list所不能提供的。 又或者在微博应用中,每个用户关注的人存在一个集合中,就很容易实现求两个人的共同好友功能。

这个在奶茶活动中有运用,就是利用set存储用户之间的点赞关联的,另外在点赞前判断是否点赞过就利用了sismember方法,当时这个接口的响应时间控制在10毫秒内,十分高效。

  1. 队列
    由于redis有list push和list pop这样的命令,所以能够很方便的执行队列操作。
    redis已经逐渐取代了memcached,成为分布式场景广泛使用的缓存方案。

4.8.2. Memcache应用场景

memcache:用于在动态系统中减少数据库负载,提升性能;做缓存,提高性能(适合读多写少,对于数据量比较大,可以采用sharding)

MongoDB:主要目标是在键/值存储方式(提供了高性能和高度伸缩性)和传统的RDBMS 系统(具有丰富的功能)之间架起一座桥梁,它集两者的优势于一身。根据官方网站的描述,Mongo 适用于以下场景。

4.8.3. MongoDB应用场景

  1. 网站数据:Mongo 非常适合实时的插入,更新与查询,并具备网站实时数据存储所需的复制及高度伸缩性。
  2. 缓存:由于性能很高,Mongo 也适合作为信息基础设施的缓存层。在系统重启之后,由Mongo 搭建的持久化缓存层可以避免下层的数据源过载。
  3. 大尺寸. 低价值的数据:使用传统的关系型数据库存储一些数据时可能会比较昂贵,在此之前,很多时候程序员往往会选择传统的文件进行存储。
  4. 高伸缩性的场景:Mongo 非常适合由数十或数百台服务器组成的数据库,Mongo 的路线图中已经包含对MapReduce 引擎的内置支持。
  5. 用于对象及JSON 数据的存储:Mongo 的BSON 数据格式非常适合文档化格式的存储及查询。

转载自Redis、Memcache和MongoDB的区别

赞赏

微信赞赏支付宝赞赏

发表评论

电子邮件地址不会被公开。 必填项已用*标注