Mongdb,Memcached,Redis的使用区别

简介

MongoDB更类似MySQL,支持字段索引、游标操作,其优势在于查询功能比较强大,擅长查询JSON数据,能存储海量数据,但是不支持事务。

Mysql在大数据量时效率显著下降,MongoDB更多时候作为关系数据库的一种替代。

内存管理机制

Redis数据全部存在内存,定期写入磁盘,当内存不够时,可以选择指定的LRU算法删除数据。

MongoDB数据存在内存,由Linux系统mmap实现,当内存不够时,只将热点数据放入内存,其他数据存在磁盘。

支持的数据结构

Redis支持的数据结构丰富,包括hash、set、list等。

MongoDB数据结构比较单一,但是支持丰富的数据表达,索引,最类似关系型数据库,支持的查询语言非常丰富。

性能

二者性能都比较高,应该说都不会是瓶颈。

可靠性

二者均支持持久化。

集群

         MongoDB集群技术比较成熟,Redis从3.0开始支持集群。

不适用场景

Ø  需要使用复杂sql的操作

Ø  事务性系统

=========================================

传统MySQL+ Memcached架构遇到的问题

  实际MySQL是适合进行海量数据存储的,通过Memcached将热点数据加载到cache,加速访问,很多公司都曾经使用过这样的架构,但随着业务数据量的不断增加,和访问量的持续增长,我们遇到了很多问题:

  1.MySQL需要不断进行拆库拆表,Memcached也需不断跟着扩容,扩容和维护工作占据大量开发时间。

  2.Memcached与MySQL数据库数据一致性问题。

  3.Memcached数据命中率低或down机,大量访问直接穿透到DB,MySQL无法支撑。

  4.跨机房cache同步问题。

  众多NoSQL百花齐放,如何选择

  最近几年,业界不断涌现出很多各种各样的NoSQL产品,那么如何才能正确地使用好这些产品,最大化地发挥其长处,是我们需要深入研究和思考的问题,实际归根结底最重要的是了解这些产品的定位,并且了解到每款产品的tradeoffs,在实际应用中做到扬长避短,总体上这些NoSQL主要用于解决以下几种问题

  1.少量数据存储,高速读写访问。此类产品通过数据全部in-momery 的方式来保证高速访问,同时提供数据落地的功能,实际这正是Redis最主要的适用场景。

  2.海量数据存储,分布式系统支持,数据一致性保证,方便的集群节点添加/删除。

  3.这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。前者是一个完全无中心的设计,节点之间通过gossip方式传递集群信息,数据保证最终一致性,后者是一个中心化的方案设计,通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log,然后定期compat归并到磁盘上,将随机写优化为顺序写,提高写入性能。

  4.Schema free,auto-sharding等。比如目前常见的一些文档数据库都是支持schema-free的,直接存储json格式数据,并且支持auto-sharding等功能,比如MongoDB

  面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。

  Redis适用场景,如何正确的使用

  前面已经分析过,Redis最适合所有数据in-momory的场景,虽然Redis也提供持久化功能,但实际更多的是一个disk-backed的功能,跟传统意义上的持久化有比较大的差别,那么可能大家就会有疑问,似乎Redis更像一个加强版的Memcached,那么何时使用Memcached,何时使用Redis呢?

如果简单地比较Redis与Memcached的区别,大多数都会得到以下观点: 1  Redis不仅仅支持简单的k/v类型的数据,同时还提供list,set,zset,hash等数据结构的存储。 2  Redis支持数据的备份,即master-slave模式的数据备份。 3  Redis支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用。 抛开这些,可以深入到Redis内部构造去观察更加本质的区别,理解Redis的设计。 在Redis中,并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别。Redis只会缓存所有的 key的信息,如果Redis发现内存的使用量超过了某一个阀值,将触发swap的操作,Redis根据“swappability = age*log(size_in_memory)”计 算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中,同时在内存中清除。这种特性使得Redis可以 保持超过其机器本身内存大小的数据。当然,机器本身的内存必须要能够保持所有的key,毕竟这些数据是不会进行swap操作的。同时由于Redis将内存 中的数据swap到磁盘中的时候,提供服务的主线程和进行swap操作的子线程会共享这部分内存,所以如果更新需要swap的数据,Redis将阻塞这个 操作,直到子线程完成swap操作后才可以进行修改。 使用Redis特有内存模型前后的情况对比: VM off: 300k keys, 4096 bytes values: 1.3G used VM on:  300k keys, 4096 bytes values: 73M used VM off: 1 million keys, 256 bytes values: 430.12M used VM on:  1 million keys, 256 bytes values: 160.09M used VM on:  1 million keys, values as large as you want, still: 160.09M used 当 从Redis中读取数据的时候,如果读取的key对应的value不在内存中,那么Redis就需要从swap文件中加载相应数据,然后再返回给请求方。 这里就存在一个I/O线程池的问题。在默认的情况下,Redis会出现阻塞,即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小,进行 批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中,这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程 池的大小,对需要从swap文件中加载相应数据的读取请求进行并发操作,减少阻塞的时间。 如果希望在海量数据的环境中使用好Redis,我相信理解Redis的内存设计和阻塞的情况是不可缺少的。

补充的知识点:

memcached和redis的比较

1 网络IO模型

  Memcached是多线程,非阻塞IO复用的网络模型,分为监听主线程和worker子线程,监听线程监听网络连接,接受请求后,将连接描述字pipe 传递给worker线程,进行读写IO, 网络层使用libevent封装的事件库,多线程模型可以发挥多核作用,但是引入了cache coherency和锁的问题,比如,Memcached最常用的stats 命令,实际Memcached所有操作都要对这个全局变量加锁,进行计数等工作,带来了性能损耗。

(Memcached网络IO模型)

  Redis使用单线程的IO复用模型,自己封装了一个简单的AeEvent事件处理框架,主要实现了epoll、kqueue和select,对于单纯只有IO操作来说,单线程可以将速度优势发挥到最大,但是Redis也提供了一些简单的计算功能,比如排序、聚合等,对于这些操作,单线程模型实际会严重影响整体吞吐量,CPU计算过程中,整个IO调度都是被阻塞住的。

  2.内存管理方面

  Memcached使用预分配的内存池的方式,使用slab和大小不同的chunk来管理内存,Item根据大小选择合适的chunk存储,内存池的方式可以省去申请/释放内存的开销,并且能减小内存碎片产生,但这种方式也会带来一定程度上的空间浪费,并且在内存仍然有很大空间时,新的数据也可能会被剔除,原因可以参考Timyang的文章:http://timyang.NET/data/Memcached-lru-evictions/

  Redis使用现场申请内存的方式来存储数据,并且很少使用free-list等方式来优化内存分配,会在一定程度上存在内存碎片,Redis跟据存储命令参数,会把带过期时间的数据单独存放在一起,并把它们称为临时数据,非临时数据是永远不会被剔除的,即便物理内存不够,导致swap也不会剔除任何非临时数据(但会尝试剔除部分临时数据),这点上Redis更适合作为存储而不是cache。

  3.数据一致性问题

  Memcached提供了cas命令,可以保证多个并发访问操作同一份数据的一致性问题。 Redis没有提供cas 命令,并不能保证这点,不过Redis提供了事务的功能,可以保证一串 命令的原子性,中间不会被任何操作打断。

  4.存储方式及其它方面

  Memcached基本只支持简单的key-value存储,不支持枚举,不支持持久化和复制等功能

  Redis除key/value之外,还支持list,set,sorted set,hash等众多数据结构,提供了KEYS

  进行枚举操作,但不能在线上使用,如果需要枚举线上数据,Redis提供了工具可以直接扫描其dump文件,枚举出所有数据,Redis还同时提供了持久化和复制等功能。

  5.关于不同语言的客户端支持

  在不同语言的客户端方面,Memcached和Redis都有丰富的第三方客户端可供选择,不过因为Memcached发展的时间更久一些,目前看在客户端支持方面,Memcached的很多客户端更加成熟稳定,而Redis由于其协议本身就比Memcached复杂,加上作者不断增加新的功能等,对应第三方客户端跟进速度可能会赶不上,有时可能需要自己在第三方客户端基础上做些修改才能更好的使用。

  根据以上比较不难看出,当我们不希望数据被踢出,或者需要除key/value之外的更多数据类型时,或者需要落地功能时,使用Redis比使用Memcached更合适。

  关于Redis的一些周边功能

  Redis除了作为存储之外还提供了一些其它方面的功能,比如聚合计算、pubsub、scripting等,对于此类功能需要了解其实现原理,清楚地了解到它的局限性后,才能正确的使用,比如pubsub功能,这个实际是没有任何持久化支持的,消费方连接闪断或重连之间过来的消息是会全部丢失的,又比如聚合计算和scripting等功能受Redis单线程模型所限,是不可能达到很高的吞吐量的,需要谨慎使用。

  总的来说Redis作者是一位非常勤奋的开发者,可以经常看到作者在尝试着各种不同的新鲜想法和思路,针对这些方面的功能就要求我们需要深入了解后再使用。

  总结:

  1.Redis使用最佳方式是全部数据in-memory。

  2.Redis更多场景是作为Memcached的替代者来使用。

  3.当需要除key/value之外的更多数据类型支持时,使用Redis更合适。

  4.当存储的数据不能被剔除时,使用Redis更合适。

   谈谈Memcached与Redis(一)

1. Memcached简介

Memcached是以LiveJurnal旗下Danga Interactive公司的Bard Fitzpatric为首开发的高性能分布式内存缓存服务器。其本质上就是一个内存key-value数据库,但是不支持数据的持久化,服务器关闭之后数据全部丢失。Memcached使用C语言开发,在大多数像Linux、BSD和Solaris等POSIX系统上,只要安装了libevent即可使用。在Windows下,它也有一个可用的非官方版本(http://code.jellycan.com/memcached/)。Memcached的客户端软件实现非常多,包括C/C++, PHP, Java, Python, Ruby, Perl, Erlang, Lua等。当前Memcached使用广泛,除了LiveJournal以外还有Wikipedia、Flickr、Twitter、Youtube和WordPress等。

在Window系统下,Memcached的安装非常方便,只需从以上给出的地址下载可执行软件然后运行memcached.exe –d install即可完成安装。在Linux等系统下,我们首先需要安装libevent,然后从获取源码,make && make install即可。默认情况下,Memcached的服务器启动程序会安装到/usr/local/bin目录下。在启动Memcached时,我们可以为其配置不同的启动参数。

1.1 Memcache配置

Memcached服务器在启动时需要对关键的参数进行配置,下面我们就看一看Memcached在启动时需要设定哪些关键参数以及这些参数的作用。

1)-p <num> Memcached的TCP监听端口,缺省配置为11211;

2)-U <num> Memcached的UDP监听端口,缺省配置为11211,为0时表示关闭UDP监听;

3)-s <file> Memcached监听的UNIX套接字路径;

4)-a <mask> 访问UNIX套接字的八进制掩码,缺省配置为0700;

5)-l <addr> 监听的服务器IP地址,默认为所有网卡;

6)-d 为Memcached服务器启动守护进程;

7)-r 最大core文件大小;

8)-u <username> 运行Memcached的用户,如果当前为root的话需要使用此参数指定用户;

9)-m <num> 分配给Memcached使用的内存数量,单位是MB;

10)-M 指示Memcached在内存用光的时候返回错误而不是使用LRU算法移除数据记录;

11)-c <num> 最大并发连数,缺省配置为1024;

12)-v –vv –vvv 设定服务器端打印的消息的详细程度,其中-v仅打印错误和警告信息,-vv在-v的基础上还会打印客户端的命令和相应,-vvv在-vv的基础上还会打印内存状态转换信息;

13)-f <factor> 用于设置chunk大小的递增因子;

14)-n <bytes> 最小的chunk大小,缺省配置为48个字节;

15)-t <num> Memcached服务器使用的线程数,缺省配置为4个;

16)-L 尝试使用大内存页;

17)-R 每个事件的最大请求数,缺省配置为20个;

18)-C 禁用CAS,CAS模式会带来8个字节的冗余;

2. Redis简介

Redis是一个开源的key-value存储系统。与Memcached类似,Redis将大部分数据存储在内存中,支持的数据类型包括:字符串、哈希表、链表、集合、有序集合以及基于这些数据类型的相关操作。Redis使用C语言开发,在大多数像Linux、BSD和Solaris等POSIX系统上无需任何外部依赖就可以使用。Redis支持的客户端语言也非常丰富,常用的计算机语言如C、C#、C++、Object-C、PHP、Python、Java、Perl、Lua、Erlang等均有可用的客户端来访问Redis服务器。当前Redis的应用已经非常广泛,国内像新浪、淘宝,国外像Flickr、Github等均在使用Redis的缓存服务。

Redis的安装非常方便,只需从http://redis.io/download获取源码,然后make && make install即可。默认情况下,Redis的服务器启动程序和客户端程序会安装到/usr/local/bin目录下。在启动Redis服务器时,我们需要为其指定一个配置文件,缺省情况下配置文件在Redis的源码目录下,文件名为redis.conf。

2.1 Redis配置文件

为了对Redis的系统实现有一个直接的认识,我们首先来看一下Redis的配置文件中定义了哪些主要参数以及这些参数的作用。

1)daemonize no 默认情况下,redis不是在后台运行的。如果需要在后台运行,把该项的值更改为yes;

2)pidfile /var/run/redis.pid当Redis在后台运行的时候,Redis默认会把pid文件放在/var/run/redis.pid,你可以配置到其他地址。当运行多个redis服务时,需要指定不同的pid文件和端口;

3)port 6379指定redis运行的端口,默认是6379;

4)bind 127.0.0.1 指定redis只接收来自于该IP地址的请求,如果不进行设置,那么将处理所有请求。在生产环境中最好设置该项;

5)loglevel debug 指定日志记录级别,其中Redis总共支持四个级别:debug、verbose、notice、warning,默认为verbose。debug表示记录很多信息,用于开发和测试。verbose表示记录有用的信息,但不像debug会记录那么多。notice表示普通的verbose,常用于生产环境。warning 表示只有非常重要或者严重的信息会记录到日志;

6)logfile /var/log/redis/redis.log 配置log文件地址,默认值为stdout。若后台模式会输出到/dev/null;

7)databases 16 可用数据库数,默认值为16,默认数据库为0,数据库范围在0-(database-1)之间;

8)save 900 1保存数据到磁盘,格式为save <seconds> <changes>,指出在多长时间内,有多少次更新操作,就将数据同步到数据文件rdb。相当于条件触发抓取快照,这个可以多个条件配合。save 900 1就表示900秒内至少有1个key被改变就保存数据到磁盘;

9)rdbcompression yes 存储至本地数据库时(持久化到rdb文件)是否压缩数据,默认为yes;

10)dbfilename dump.rdb本地持久化数据库文件名,默认值为dump.rdb;

11)dir ./ 工作目录,数据库镜像备份的文件放置的路径。这里的路径跟文件名要分开配置是因为redis在进行备份时,先会将当前数据库的状态写入到一个临时文件中,等备份完成时,再把该临时文件替换为上面所指定的文件。而这里的临时文件和上面所配置的备份文件都会放在这个指定的路径当中,AOF文件也会存放在这个目录下面。注意这里必须指定一个目录而不是文件;

12)slaveof <masterip> <masterport> 主从复制,设置该数据库为其他数据库的从数据库。设置当本机为slave服务时,设置master服务的IP地址及端口。在Redis启动时,它会自动从master进行数据同步;

13)masterauth <master-password> 当master服务设置了密码保护时(用requirepass制定的密码)slave服务连接master的密码;

14)slave-serve-stale-data yes 当从库同主机失去连接或者复制正在进行,从机库有两种运行方式:如果slave-serve-stale-data设置为yes(默认设置),从库会继续相应客户端的请求。如果slave-serve-stale-data是指为no,除去INFO和SLAVOF命令之外的任何请求都会返回一个错误"SYNC with master in progress";

15)repl-ping-slave-period 10从库会按照一个时间间隔向主库发送PING,可以通过repl-ping-slave-period设置这个时间间隔,默认是10秒;

16)repl-timeout 60 设置主库批量数据传输时间或者ping回复时间间隔,默认值是60秒,一定要确保repl-timeout大于repl-ping-slave-period;

17)requirepass foobared 设置客户端连接后进行任何其他指定前需要使用的密码。因为redis速度相当快,所以在一台比较好的服务器下,一个外部的用户可以在一秒钟进行150K次的密码尝试,这意味着你需要指定非常强大的密码来防止暴力破解;

18)rename-command CONFIG "" 命令重命名,在一个共享环境下可以重命名相对危险的命令,比如把CONFIG重名为一个不容易猜测的字符:# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52。如果想删除一个命令,直接把它重命名为一个空字符""即可:rename-command CONFIG "";

19)maxclients 128设置同一时间最大客户端连接数,默认无限制。Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数。如果设置 maxclients 0,表示不作限制。当客户端连接数到达限制时,Redis会关闭新的连接并向客户端返回max number of clients reached错误信息;

20)maxmemory <bytes> 指定Redis最大内存限制。Redis在启动时会把数据加载到内存中,达到最大内存后,Redis会先尝试清除已到期或即将到期的Key,Redis同时也会移除空的list对象。当此方法处理后,仍然到达最大内存设置,将无法再进行写入操作,但仍然可以进行读取操作。注意:Redis新的vm机制,会把Key存放内存,Value会存放在swap区;

21)maxmemory-policy volatile-lru 当内存达到最大值的时候Redis会选择删除哪些数据呢?有五种方式可供选择:volatile-lru代表利用LRU算法移除设置过过期时间的key (LRU:最近使用 Least Recently Used ),allkeys-lru代表利用LRU算法移除任何key,volatile-random代表移除设置过过期时间的随机key,allkeys_random代表移除一个随机的key,volatile-ttl代表移除即将过期的key(minor TTL),noeviction代表不移除任何key,只是返回一个写错误。

注意:对于上面的策略,如果没有合适的key可以移除,写的时候Redis会返回一个错误;

22)appendonly no 默认情况下,redis会在后台异步的把数据库镜像备份到磁盘,但是该备份是非常耗时的,而且备份也不能很频繁。如果发生诸如拉闸限电、拔插头等状况,那么将造成比较大范围的数据丢失,所以redis提供了另外一种更加高效的数据库备份及灾难恢复方式。开启append only模式之后,redis会把所接收到的每一次写操作请求都追加到appendonly.aof文件中。当redis重新启动时,会从该文件恢复出之前的状态,但是这样会造成appendonly.aof文件过大,所以redis还支持了BGREWRITEAOF指令对appendonly.aof 进行重新整理,你可以同时开启asynchronous dumps 和 AOF;

23)appendfilename appendonly.aof  AOF文件名称,默认为"appendonly.aof";

24)appendfsync everysec  Redis支持三种同步AOF文件的策略: no代表不进行同步,系统去操作,always代表每次有写操作都进行同步,everysec代表对写操作进行累积,每秒同步一次,默认是"everysec",按照速度和安全折中这是最好的。

25)slowlog-log-slower-than 10000 记录超过特定执行时间的命令。执行时间不包括I/O计算,比如连接客户端,返回结果等,只是命令执行时间。可以通过两个参数设置slow log:一个是告诉Redis执行超过多少时间被记录的参数slowlog-log-slower-than(微妙),另一个是slow log 的长度。当一个新命令被记录的时候最早的命令将被从队列中移除,下面的时间以微妙微单位,因此1000000代表一分钟。注意制定一个负数将关闭慢日志,而设置为0将强制每个命令都会记录;

26)hash-max-zipmap-entries 512 && hash-max-zipmap-value 64 当hash中包含超过指定元素个数并且最大的元素没有超过临界时,hash将以一种特殊的编码方式(大大减少内存使用)来存储,这里可以设置这两个临界值。Redis Hash对应Value内部实际就是一个HashMap,实际这里会有2种不同实现。这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储,而不会采用真正的HashMap结构,对应的value redisObject的encoding为zipmap。当成员数量增大时会自动转成真正的HashMap,此时encoding为ht;

27)list-max-ziplist-entries 512 list数据类型多少节点以下会采用去指针的紧凑存储格式;

28)list-max-ziplist-value 64数据类型节点值大小小于多少字节会采用紧凑存储格式;

29)set-max-intset-entries 512 set数据类型内部数据如果全部是数值型,且包含多少节点以下会采用紧凑格式存储;

30)zset-max-ziplist-entries 128 zsort数据类型多少节点以下会采用去指针的紧凑存储格式;

31)zset-max-ziplist-value 64 zsort数据类型节点值大小小于多少字节会采用紧凑存储格式。

32)activerehashing yes Redis将在每100毫秒时使用1毫秒的CPU时间来对redis的hash表进行重新hash,可以降低内存的使用。当你的使用场景中,有非常严格的实时性需要,不能够接受Redis时不时的对请求有2毫秒的延迟的话,把这项配置为no。如果没有这么严格的实时性要求,可以设置为yes,以便能够尽可能快的释放内存;

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏黑泽君的专栏

day69_淘淘商城项目_02

  由于淘淘商城是基于soa的架构,表现层和服务层是不同的工程。所以要实现商品列表查询需要两个系统之间进行通信。   如何实现远程通信?

35620
来自专栏Janti

记一次内存溢出的分析经历——thrift带给我的痛orz

说在前面的话 朋友,你经历过部署好的服务突然内存溢出吗? 你经历过没有看过Java虚拟机,来解决内存溢出的痛苦吗? 你经历过一个BUG,百思不得其解,头发一根一...

53480
来自专栏决胜机器学习

Java初涉感悟

Java初涉感悟 (原创内容,转载请注明来源,谢谢) 一、概述 近期要接触到一些PHP转Java项目,用到的java框架是SpringBoot,故学习一些ja...

37840
来自专栏Java职业技术分享

如果你想搞懂“分布式锁”,必须要看这篇文章 ,看了很意外!

对于锁大家肯定不会陌生,在 Java 中 synchronized 关键字和 ReentrantLock 可重入锁在我们的代码中是经常见的,一般我们用其在多线程...

5.5K30
来自专栏安恒信息

安全漏洞公告

Apache Roller OGNL表达式注入远程代码执行漏洞发布时间:2013-11-27漏洞编号:BUGTRAQ ID: 63928 CVE(CAN...

33660
来自专栏大宽宽的碎碎念

聊聊BIO,NIO和AIO (1)到底什么是“IO Block”BIONIOIO多路复用用epoll实现的IO多路复用epoll的优势水平触发和边沿触发再来思考一下什么是“Block”总结

64580
来自专栏大闲人柴毛毛

Java基础笔记——学习Java前的准备

        接下来的一个月我会和大家分享我学JavaSE时候的笔记,分享是最好的老师,希望我的笔记能给大家一些帮助。 我会每天发一篇文章,这些都是我学Jav...

36890
来自专栏北京马哥教育

windows环境下使用virtualenv对python进行多版本隔离

最近在用python做一个文本的情感分析的项目,用到tensorflow,需要用python3的版本,之前因为《机器学习实战》那本书的缘故,用的是python...

29750
来自专栏小狼的世界

[每天五分钟,备战架构师-2]操作系统基本原理

操作系统是管理和控制计算机硬件和软件资源的计算机程序,是直接运行在“裸机”上的最基本的系统软件。注意,这里说的裸机可以是物理机,也可以是虚拟机。随着技术的发展,...

10010
来自专栏Kirito的技术分享

深入理解RPC之服务注册与发现篇

在我们之前 RPC 原理的分析中,主要将笔墨集中在 Client 和 Server 端。而成熟的服务治理框架中不止存在这两个角色,一般还会有一个 Registr...

656100

扫码关注云+社区

领取腾讯云代金券