来自《App 后台开发运维和架构实践》

1.Redis、MongoDB、MySQL读写数据区别

数据涉及读和写这两个问题，出于性能考虑，当然希望读和写的速度越快越好。
计算机中常见的存储设备是内存和硬盘，其特性如下：
1.内存的读取速度大概是硬盘的80倍，因此为了更快的读写速度，数据尽可能放在内存。
2.内存的容量有限。例如UCloud 最多只能拥有64G的内存，而UCloud服务器上的单个硬盘可高达1000G

Redis 的数据是存放在服务器的内存，当内存用满了后需要扩容，就只能使用Redis的分布式方案，为了防止断电或者Redis程序重启后造成内存数据的丢失，可调整Redis配置文件，按照一定策略把数据持久化传到硬盘。

Mongodb同时使用了硬盘和内存，其使用了操作系统的MMAP（内存文件映射）机制进行数据文件的读写，MMAP可以把文件直接映射到进程的内存空间中，这样文件就会在内存中有对应的地址，这是对文件的读写是通过操作内存进行额，而不需要使用传统的如fread.fwrite文件操作方式。

Mysql的数据是放在硬盘中，虽然Mysql也有缓存，但是Mysql缓存是查询的结果，而不是缓存数据。

2.Redis、MongoDB、MySQL查找数据的区别

如果读者需要在一栋大楼里面查找某个房间，但是读者不知道这个房间的门牌号，只记得这个房间的门是非常特别的。那么找到这个房间唯一的方式只能每层楼逐个房间找一次，比较一下房间的们和记忆中房间的门是否相同。
如果读者知道这个房间的门牌号，就很简单，直奔那个楼层就可以了。

Redis的数据是基于“键值对”存储，“键”相当于门牌号，“值”相当于房间。Redis查找数据，每次都是直奔目标，读写速度相当快。

MongoDB和MySQL中，每组数据都有一个id（或者可以为每组数据建立索引），这个id或索引就相当于门牌号。
MongoDB和MySQL中查找数据，有两种模式：知道id或者索引，不知道id或索引。知道id或索引的情况就相当于知道门牌号，直奔目标就可以了，效率高。如果不知道id和索引的情况下，查找数据，那么就相当于每个楼层逐一找房间，效率很低。

3.应用场景

1.Redis

数据读写速度非常快，但是由于Redis数据只存在于服务器的内存（可以采用Redis的分布式方案扩容），内存的价格高，所以用内存存储数据的成本高。
同时由于Redis存放的数据必须是键值对的形式，在读写Redis数据的时候必须要知道所读写数据的key。
所以在App后台中，读写频率高的数据一般都会存放在Redis中（当然这部分数据也可以同时存放在MysQL或者MongoDB中，Redis中的数据是以缓存的形式存在的，当数据更新的时候，两部分都要更新以保持数据的一致性）。
利用API中附带了用户的身份信息，由于每次API操作都要验证用的身份信息，这些身份信息的数据存放在Redis中就非常合适了，因为验证用户信息是个频率非常高的操作。

2.MongoDB

适合于：
（1）网站数据:MongoDB非常适合实时的插入、更新和查询，并且具备网站实时数据存储所需要的复制以及高度伸缩性。
（2）大尺寸、低价值的数据：使用传统的关系数据库存储一些数据时可能会比较贵、在此之前，很多程序员往往会选择传统的文件进行存储。
（3）高伸缩性的场景：MongoDB非常适合由数十台或者数百台服务器组成的数据库。
（4）存储地理坐标的数据:MongoDB的地理坐标查询功能非常强大，例如，MongoDB可以查找在某个矩形范围内的所有坐标，因此MongoDB非常适合于LBS应用。
不适合：
（1）高度事务性的系统：例如银行、会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。例如：涉及金钱的操作，假设要转账，必须从一个找好上扣钱，再在另外一个账号上把钱转账。这个操作必须保证要么要个都要完成、要么两个都不做，不能只做一个。但是MongoDB不支持事务，所以没有办法保证
（2）传统的商业只能应用：针对特定问题的BI数据库会产生高度优化的查询方式，但它的查询比起Mysql是有一定差距的。
（3）需要SQL的问题：虽然MongoDB支持类似SQL的查询方式，但他的查询比起Mysql还是有一定的差距的

3.MySQL

（1）事务性的系统。
（2）需要复杂SQL的问题