mongodb，redis，mysql 对比

本篇内容大部分不是原创，转载的会贴有链接。

准备学习下数据库，想对目前的主流数据库做一个简单的了解分析，就搜集了资料整理到了一块。

当下主流的要数NoSql数据库了，拥有强大的高并发能力。

mongodb：

它是一个内存数据库，数据都是放在内存里面的。

对数据的操作大部分都在内存中，但mongodb并不是单纯的内存数据库。

持久化方式：

mongodb的所有数据实际上是存放在硬盘的，所有要操作的数据通过mmap的方式映射到内存某个区域内。

然后，mongodb就在这块区域里面进行数据修改，避免了零碎的硬盘操作。

至于mmap上的内容flush到硬盘就是操作系统的事情了，所以，如果，mongodb在内存中修改了数据后，mmap数据flush到硬盘之前，系统宕机了，数据就会丢失。

mmap详解链接：http://www.cnblogs.com/techdoc/archive/2010/12/22/1913521.html

redis：

它就是一个不折不扣的内存数据库了。

持久化方式：

redis所有数据都是放在内存中的，持久化是使用RDB方式或者aof方式。

解密redis持久化：http://blog.nosqlfan.com/html/3813.html

mysql：

无论数据还是索引都存放在硬盘中。到要使用的时候才交换到内存中。能够处理远超过内存总量的数据。

数据量和性能：

当物理内存够用的时候，redis>mongodb>mysql

当物理内存不够用的时候，redis和mongodb都会使用虚拟内存。

实际上如果redis要开始虚拟内存，那很明显要么加内存条，要么你换个数据库了。

但是，mongodb不一样，只要，业务上能保证，冷热数据的读写比，使得热数据在物理内存中，mmap的交换较少。

mongodb还是能够保证性能。有人使用mongodb存储了上T的数据。

mysql，mysql根本就不需要担心数据量跟内存下的关系。不过，内存的量跟热数据的关系会极大地影响性能表现。

当物理内存和虚拟内存都不够用的时候，估计除了mysql你没什么好选择了。

其实，从数据存储原理来看，我更倾向于将mongodb归类为硬盘数据库，但是使用了mmap作为加速的手段而已。

简说mmap：

mmap系统调用并不是完全为了用于共享内存而设计的。它本身提供了不同于一般对普通文件的访问方式，进程可以像读写内存一样对普通文件进行操作。

mmap 系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后，进程可以像访问普通内存一样对文件进行访问，不必再调用。 read()，write（）等操作。mmap并不分配空间, 只是将文件映射到调用进程的地址空间里, 然后你就可以用memcpy等操作写文件, 而不用write()了.写完后用msync()同步一下, 你所写的内容就保存到文件里了. 不过这种方式没办法增加文件的长度, 因为要映射的长度在调用mmap()的时候就决定了。

下面是redis和mongodb的对比图：

在使用Redis过程中，我们发现了不少Redis不同于Memcached，也不同于MySQL的特征。
(本文主要讨论Redis未启用VM支持情况)

1. Schema

MySQL: 需事先设计
Memcached: 无需设计
Redis: 小型系统可以不用，但是如果要合理的规划及使用Redis，需要事先进行类似如下一些规划

• 数据项: value保存的内容是什么，如用户资料
• Redis数据类型: 如String, List
• 数据大小: 如100字节
• 记录数: 如100万条(决定是否需要拆分)
• ⋯⋯

上面的规划就是一种schema，为什么Redis在大型项目需要事先设计schema？因为Redis服务器有容量限制，数据容量不能超出物理内存大小，同时考虑到业务数据的可扩充性，记录数会持续增多、单条记录的内容也都会增长，因此需要提前规划好容量，数据架构师就是通过schema来判断当前业务的Redis是否需要“分库分表”以满足可扩展需求。

2. 容量及带宽规划

容量规划
MySQL: < 硬盘大小
Memcached: < RAM
Redis: < RAM

带宽规划
由于Redis比MySQL快10倍以上，因此带宽也是需要事先规划，避免带宽跑满而出现瓶颈。

3. 性能规划(QPS)

当系统读写出现瓶颈，通常如何解决？
MySQL
写: 拆分到多服务器
读: (1) 拆分 (2) 写少也可以通过增加Slave来解决

Memcached
读写: 都通过hash拆分到更多节点。

Redis:
写：拆分
读: (1) 拆分 (2) 写少也可以通过增加Slave来解决

4. 可扩展性

MySQL: 分库分表
Memcached: hash分布
Redis：也可以分库，也可以hash分布

小结

通过以上分析，Redis在很多方面同时具备MySQL及Memcached使用特征，在某些方面则更像MySQL。
由于Redis数据不能超过内存大小，一方面需要进行事先容量规划，保证容量足够；另外一方面设计上需要防止数据规模无限制增加，进而导致Redis不可扩展。
Redis需要象MySQL一样预先设计好拆分方案。

小问题

在MySQL中，通过预先建立多表或者库可以在业务增长时候将这些表或库一分为二部署到更多服务器上。
在Redis中，“分库分表”应当如何实现？有什么好的设计模式？

 

我们知道，mysql是持久化存储，存放在磁盘里面，检索的话，会涉及到一定的IO，为了解决这个瓶颈，于是出现了缓存，比如现在用的最多的 memcached(简称mc)。首先，用户访问mc，如果未命中，就去访问mysql，之后像内存和硬盘一样，把数据复制到mc一部分。

　　redis和mc都是缓存，并且都是驻留在内存中运行的，这大大提升了高数据量web访问的访问速度。然而mc只是提供了简单的数据结构，比如 string存储；redis却提供了大量的数据结构，比如string、list、set、hashset、sorted set这些，这使得用户方便了好多，毕竟封装了一层实用的功能，同时实现了同样的效果，当然用redis而慢慢舍弃mc。

　　内存和硬盘的关系，硬盘放置主体数据用于持久化存储，而内存则是当前运行的那部分数据，CPU访问内存而不是磁盘，这大大提升了运行的速度，当然这是基于程序的局部化访问原理。

　　推理到redis+mysql，它是内存+磁盘关系的一个映射，mysql放在磁盘，redis放在内存，这样的话，web应用每次只访问redis，如果没有找到的数据，才去访问Mysql。

　　然而redis+mysql和内存+磁盘的用法最好是不同的。

　　转载，仅供参考

前者是内存数据库，数据保存在内存中，当然速度快。
后者是关系型数据库，功能强大，数据访问也就慢。
像memcache，MongoDB，Redis，都属于No sql系列。
不是一个类型的东西，应用场景也不太一样，还是要看你的需求来决定。

 

 

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/mao834099514/article/details/53897021