redis和mongodb哪个简单

redis、memcahce 比较相似，但与 mongodb 完全不同，几乎没有可比性。

总的来说 redis/memcache 是基于内存的，讲究的是性能，多用作缓存层，比如说存放session。而 mongodb 是面向文档的，存储的是类似JSON的非结构化数据，查询起来非常方便，开发效率高，比较类似传统SQL关系型数据库。

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

体积

Redis是一个基于内存的键值数据库，它由C语言实现的，以单线程异步的方式工作，与Nginx/ NodeJS工作原理近似。所以文件非常小。编绎出来的主文件还不到 2Mb，在 Linux 服务器上初始只需要占用1Mb左右的内存。

Mongodb安装包则要大的多，跟mySQL差不多，都是百兆级的。

性能

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

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

*** 作的便利性

memcache数据结构单一

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

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

推荐学习《python教程》

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

redis在20版本后增加了自己的VM特性，突破物理内存的限制；可以对key value设置过期时间（类似memcache）

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

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

可用性（单点问题）

对于单点问题，

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

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

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

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

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

可靠性（持久化）

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

redis支持（快照、AOF）：依赖快照进行持久化，aof增强了可靠性的同时，对性能有所影响

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

MongoDB从18版本开始采用binlog方式支持持久化的可靠性，备份还原方法

7数据一致性（事务支持）

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

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

mongoDB不支持事务

8数据分析

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

9应用场景

redis：数据量较小的更性能 *** 作和运算上

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

MongoDB:主要解决海量数据的访问效率问题。

游戏服务器开发中，玩家的账号，背包，装备，物品，排名等数据都需要落地存储在数据库中。行业中主流的数据库当属mysql，优点是免费开源，从端游时代过渡过来的程序员，求稳保守的话大多数会选用mysql数据库做存储。但是游戏中要存储的数据表会经常改动，导致数据库的表会频繁更新改动表结构，如果游戏数据量达到千万级别，对所有的表刷新改动会是一项很恐怖的事情，期间如果再出错，运维跟开发人员估计全都GG。

为了应对方便扩展，提升读写速度，NoSQL数据库（非关系型数据库）诞生。在NoSQL中应用比较广泛的当属mongodb和redis，由于对开发者友好，方便快速开发迭代高可用复制集满足数据高可靠、服务高可用的需求，运维简单，故障自动切换可扩展分片集群海量数据存储被游戏服务器广泛应用。现在的项目《鹿鼎记》用redis做高速缓存角色列表信息数据。

就Redis和MongoDB来说，大家一般称之为Redis缓存、MongoDB数据库。这也是有道有理有根据的，

Redis主要把数据存储在内存中，其“缓存”的性质远大于其“数据存储“的性质，其中数据的增删改查也只是像变量 *** 作一样简单；

MongoDB却是一个“存储数据”的系统，增删改查可以添加很多条件，就像SQL数据库一样灵活，这一点在面试的时候很受用。《linux 就该这么学》

Mongodb与Redis应用指标对比

MongoDB和Redis都是NoSQL，采用结构型数据存储。二者在使用场景中，存在一定的区别，这也主要由于

二者在内存映射的处理过程，持久化的处理方法不同。MongoDB建议集群部署，更多的考虑到集群方案，Redis

更偏重于进程顺序写入，虽然支持集群，也仅限于主-从模式。

（1）MySQL数据库：

属于关系型数据库。

在不同的引擎上有不同的存储方式。

查询语句是使用传统的sql语句，拥有较为成熟的体系，成熟度很高。

开源数据库的份额在不断增加，mysql的份额页在持续增长。

缺点就是在海量数据处理的时候效率会显著变慢。

（2）Mongodb数据库：

非关系型数据库(nosql ),属于文档型数据库。先解释一下文档的数据库，即可以存放xml、json、bson类型系那个的数据。这些数据具备自述性（self-describing），呈现分层的树状数据结构。数据结构由键值(key=>value)对组成。

存储方式：虚拟内存+持久化。

查询语句：是独特的Mongodb的查询方式。

适合场景：事件的记录，内容管理或者博客平台等等。

架构特点：可以通过副本集，以及分片来实现高可用。

数据处理：数据是存储在硬盘上的，只不过需要经常读取的数据会被加载到内存中，将数据存储在物理内存中，从而达到高速读写。

成熟度与广泛度：新兴数据库，成熟度较低，Nosql数据库中最为接近关系型数据库，比较完善的DB之一，适用人群不断在增长。

分析一下Mysql和Mongodb应用场景

1如果需要将mongodb作为后端db来代替mysql使用，即这里mysql与mongodb 属于平行级别，那么，这样的使用可能有以下几种情况的考量： (1)mongodb所负责部分以文档形式存储，能够有较好的代码亲和性，json格式的直接写入方便。(如日志之类) (2)从data models设计阶段就将原子性考虑于其中，无需事务之类的辅助。开发用如nodejs之类的语言来进行开发，对开发比较方便。 (3)mongodb本身的failover机制，无需使用如MHA之类的方式实现。

2将mongodb作为类似redis ，memcache来做缓存db，为mysql提供服务，或是后端日志收集分析。 考虑到mongodb属于nosql型数据库，sql语句与数据结构不如mysql那么亲和 ，也会有很多时候将mongodb做为辅助mysql而使用的类redis memcache 之类的缓存db来使用。 亦或是仅作日志收集分析。

参考原文：>

使用场景：

（1）网站数据：MongoDB适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。

（2）缓存：由于性能很高，MongoDB也适合作为信息基础设施的缓存层。在系统重启之后，由MongoDB搭建的持久化缓存层可以避免下层的数据源过载。

（3）大尺寸，低价值的数据。

（4）高伸缩性的场景：MongoDB适合由数十或数百台服务器组成的数据库。

（5）用于对象及JSON数据的存储：MongoDB的BSON数据格式适合文档化格式的存储及查询。

mongodb设计特点：

（1）面向集合存储，容易存储对象类型的数据。在MongoDB 中数据被分组存储在集合中，集合类似RDBMS 中的表，一个集合中可以存储无限多的文档。

（2）模式自由，采用无模式结构存储。在MongoDB 中集合中存储的数据是无模式的文档，采用无模式存储数据是集合区别于RDBMS 中的表的一个重要特征。

（3）支持完全索引，可以在任意属性上建立索引，包含内部对象。MongoDB的索引和RDBMS 的索引基本一样，可以在指定属性、内部对象上创建索引以提高查询的速度。除此之外，MongoDB 还提供创建基于地理空间的索引的能力。

（4）支持查询。MongoDB 支持丰富的查询 *** 作，MongoDB 几乎支持SQL中的大部分查询。

（5）强大的聚合工具。MongoDB 除了提供丰富的查询功能外，还提供强大的聚合工具，如count、group 等，支持使用MapReduce 完成复杂的聚合任务。

mongodb众所周知不支持事务，所以需要强事务的业务根本不能考虑mongodb。

mongodb的优势就是文档存储:

1 业务经常变动，需要不时的添加字段，那么mongodb比较适合，关系型数据库添加字段的复杂度也还好

2 嵌套文档，业务数据比较复杂，适合嵌套文档式存储，那么mongodb非常合适，这个关系型数据库比较难搞，虽然MySQL和pg也有文档存储，但MySQL的不成熟，pg毕竟现在生产中使用还是偏少，个人也不了解，这里不谈。但这不仅仅这一点优势，具体下面会细说。

3 upsert支持，查询速度也不慢

4 高可用的副本集支持

5 查询语法非常丰富，嵌套文档查询功能非常强大，不是重度用户可能不能理解

下面说说一个具体的使用事例:

项目的一条数据在10kb左右，如果使用关系型数据库那么需要将这条数据拆分成大概几百条左右，建造多个表，设计较复杂，这种数据大概在一百万条左右，想想拆分后在十几亿的数据量就可怕。打平后的数据什么DB也都可以拿下，只是一百万变十几亿比较恐怖而已。

如果采用MySQL存储，每次查询需要使用外键查询多个表，从这些表中拉取数据，性能肯定要下降很多，比不上只在一个表查询，而且只拉取少两个数量级的数据。查询也还好，业务允许可以对结果做缓存，放到redis里去。

但是重点来了，需求要增量更新部分数据，这时候需要更新多个表，根本没法做到原子性（注意事务不是原子 *** 作），当然也可以使用cas等技术补偿，达到最终一致性。但使用mongodb存储只需要update一条数据，对相应的嵌套文档中内容更新，可以做到原子性，是不是很方便？

推荐学习《python教程》

具体说说该项目的难点，查询无法使用缓存，可能会很吃惊，但是业务决定了确实做不了，而且增量更新的量达到上万的QPS，如果不能保证原子性想想多么可怕！

所以mongodb在这里帮了大忙，关系型数据库解决不了这个难题。

有人可能要问，mongodb没有事务，上游数据写入也会有问题，你不可能所有数据都存一个表吧？

当然不是的，我们mongodb里的数据是从MySQL中清洗出来存到mongodb中的，mongodb只做单点的业务需求，综合的数据还是在MySQL中。

此项目我们用了上百个副本集，保证系统的高可用，这些副本集配置只要一条shell就搞定，如果用MySQL的主从不知道怎么配（我自己不懂），估计DBA得忙死，而该项目完全不需要也没用到DBA。

说了这么多mongo的优点，也说说他的缺点:

1 查询优化器和MySQL没法比

2 不支持reload，只能冷重启，初始化配置的时候比较麻烦

3 没有事务，不敢存储第一手数据，多用来做备份数据的存储

mongodb可以做很多事情，取决于你脑洞，性能不差，存一些相对不重要的数据，mongodb嵌套文档功能强大，多看看官方文档挖掘挖掘有用信息，每次都能发现惊喜。

以上就是关于redis和mongodb哪个简单全部的内容，包括:redis和mongodb哪个简单、MongoDB 数据库、mongodb和redis区别是什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！