近期 整理的 关于Redis mongoDB memcache 对比
|
|
Redis |
mongoDB |
memcache |
|
性能 |
都比较高，性能对我们来说应该都不是瓶颈。 |
||
|
操作的便利性 |
稍微丰富一点，提供list，set， hash 等数据结构的存储 |
最像关系型数据库，数据类型非常丰富 |
memcache 数据结构单一。（key-value） |
|
内存大小和数据量大小 |
Redis可以针对key-value设置过期时间， |
适合大数据量的存储，依赖操作系统 VM 做内存管理，吃内存也比较厉害，服务 不要和别的服务在一起。 |
可以修改最大可用内存,采用 LRU 算法。Memcached 代理软件 magent，比如建立 10 台 4G 的 Memcache 集群，就相当于有了 40G。 |
|
单点问题 |
Redis依赖客户端实现分布式读写分离，主从复制时，每次从节点重新连接主节点的时候，都依赖整个快照，无增量复制，性能比较差。也不支持自动sharding,需要设置一定的hash机制。不过，有解决方案：不用redis本身的复制机制，采用自己做主动复制（多分储存），或者改成增量复制等方式 |
mongoDB 牛逼很牛逼的使用master-slave,replicaset（内部采用 paxos 选举算法，自动故障恢复）,auto sharding 机制，。对客户端屏蔽了故障转移和切分机制 |
这个就不用担心了。本身就没有数据冗余机制。采用成熟的hash或者环状算法轻松搞定单点问题。 |
|
可靠性（持久化） |
Redis支持快照·Aof技术。依赖快照对数据进行持久化操作。当然了，这对性能有点影响。 |
采用binlog（二进制日志） 方式支持持久化的可靠性。 |
不支持 |
|
事务支持 |
事务支持比较弱，只能保证事务中的每个操作连续执行 |
mongoDB 不支持事务 |
在并发场景下，用 cas 保证一致性 |
|
应用场景 |
数据量较小的更性能操作和运算上 |
主要解决海量数据的访问效率问题。 |
用于在动态系统中减少数据库负载，提升性能;做缓存，提高性能（适合读多写 |
