12.app后端如何选择合适的数据库产品
app后端的开发中，经常要面临的一个问题是：数据放在哪里? mysql ？redis？mongodb？
现在有这么多优秀的开源数据库产品，怎么根据业务场景来选择合适的数据?
常用的数据库产品的优缺点又是什么呢?
通过阅读这篇文章，能帮你解决以上的疑惑，使你在碰到数据存储选择问题时思路更清晰。
数据，就涉及读和写这两个问题．出于性能的考虑，当然希望读和写的速度越快越好．
计算机中，数据一般都放在内存或硬盘，众所周知，内存的读写速度比硬盘快多了。因此，为了获得更快的读写速度，数据尽可能放在内存中。
但是，内存的容量是非常有限的，例如，在ucloud的服务器上，最多只能拥有64G的内存，而ucloud的服务器上的单个硬盘，最多可高达1000G。
redis的数据是放在服务器的内存中，当内存用满了，redis就没折了（现在只有第三方的分布式解决方案，官方的分布式方案要在3.0版本才会出。）。当然了，为了防止数据丢失，可通过配置文件，把数据在硬盘上做一个备份。
mongodb的数据主要是放在内存中，如果mongodb发现内存满了，数据再也放不下了，mongodb就把新增的数据放在硬盘中。如果是采用分布式架构，那基本不用考虑数据会放在硬盘中。
mysql的数据是放在硬盘中。虽然mysql也有缓存，但mysql缓存的是查询的结果，而不是缓存数据。
如果你想在一栋大楼里找某个房间，但是你不知道这个房间的门牌号，只记得这个房间的门是非常特别的，那找到这个房间唯一的方式只能每层楼逐个房间找一次，直到找到这个房间为止。
如果你知道了这个房间的门牌号，那很简单，直奔那个楼层就是了。
redis的数据是基于“键值对”存储，“键”相当于门牌号，“值”相当于房间。redis查找数据，每次都是直奔目标，读写速度当然高。
mongodb和mysql中，每组数据都有一个id（或者可以为每组数据建索引），这个id或索引就相当于门牌号。
mongodb和mysql中查找数据，有两种模式，知道id或索引，和不知道知道id或索引。知道id或索引，就相当于知道门牌号，那就直奔目标就行了，效率很高。如果不知道id或索引的情况下查找数据，那就相当于每层楼逐个房间找，效率很低。
redis适用场景：
数据读写速度快，但由于redis数据只存放在一台服务器的内存中（现在只有第三方的分布式解决方案，官方的分布式方案要在3.0版本才会出来），所以存储数据有限。
同时，由于redis存放的数据必须是键值对(key-value)的形式，在读写redis的数据时必须要知道键，这点需要考虑。
所以，在app后端中，最讲求读写效率，最频繁读的数据一般都会放在redis中（当然，这部分数据同时也存在于mysql 或者mongodb中， redis中的数据是一个冗余，当数据更新的时候，两部分都要更新）。
举例，在社交app中，很多操作都需要验证用户的登录信息，那一般怎么做的呢？
用户登录后，服务器会把一个token符串返回给用户，假设这个token字符串为"abcdsdf", 服务器中已经登记了这个token符串，而且把这个tokentoken符串和用户的信息关联在一起，通过这个token符串就能查询到用户的信息。
当遇到需要验证用户的登录信息，就把这个token字符串传给服务器，服务器根据这个token的信息，在服务器中查找这个用户的信息。
在社交app中，大多数的操作都需要这个验证，可以看出，是个很频繁的操作，而且这个操作需要在极短的时间内完成。
那么，这个token字符串和用户的信息，就很适合放在redis中，把token字符串当成一个key(键)，用户的信息当成是value（值），查找起来非常方便和高效。
当然了，验证用户的登录信息还需要很多安全的措施，这里只讲一个最简单的模型，在以后的《app通讯安全性》一文中会讲完善的安全措施。
mongodb适用场景：
a.网站数据：mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
b.缓存：由于性能很高，mongo也适合作为信息基础设施的缓存层。在系统重启之后，由mongo搭建的持久化缓存可以避免下层的数据源过载。
c.大尺寸、低价值的数据：使用传统的关系数据库存储一些数据时可能会比较贵，在此之前，很多程序员往往会选择传统的文件进行存储。
d.高伸缩性的场景：mongo非常适合由数十或者数百台服务器组成的数据库。
e.存储地理坐标的数据。mongo支持非常强大的地理坐标的查询，例如，可以在某个矩形范围内的用户。非常适合于LBS的应用。
mongodb不适合的场景：
a.高度事物性的系统：例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
例如，涉及金钱的操作，假设要把转账，必须从一个账号上扣钱，再在另外一个账号上把钱转账。这个操作必须保证要么两个都完成，要么两个都不做，不能只做一个。但很遗憾，由于mongodb不支持事务，所以没法保证。
b. 传统的商业智能应用：针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。
c. 需要SQL的问题。虽然mongodb支持类似于sql的查询方式，但它的查询比起mysql还是有一定的差距。
mysql适用场景:
a. 事物性的系统。例如，在mongodb中举例的转账的例子
b. 需要复杂SQL的问题。
【QQ】190678908
【qq群】254659220
【微信公众号】 appbackend
【新浪微博】 @newjueqi
【博客】http://blog.csdn.net/newjueqi
现在有这么多优秀的开源数据库产品，怎么根据业务场景来选择合适的数据?
常用的数据库产品的优缺点又是什么呢?
通过阅读这篇文章，能帮你解决以上的疑惑，使你在碰到数据存储选择问题时思路更清晰。
1. redis，mongodb，mysql存储数据的区别
数据，就涉及读和写这两个问题．出于性能的考虑，当然希望读和写的速度越快越好．
计算机中，数据一般都放在内存或硬盘，众所周知，内存的读写速度比硬盘快多了。因此，为了获得更快的读写速度，数据尽可能放在内存中。
但是，内存的容量是非常有限的，例如，在ucloud的服务器上，最多只能拥有64G的内存，而ucloud的服务器上的单个硬盘，最多可高达1000G。
redis的数据是放在服务器的内存中，当内存用满了，redis就没折了（现在只有第三方的分布式解决方案，官方的分布式方案要在3.0版本才会出。）。当然了，为了防止数据丢失，可通过配置文件，把数据在硬盘上做一个备份。
mongodb的数据主要是放在内存中，如果mongodb发现内存满了，数据再也放不下了，mongodb就把新增的数据放在硬盘中。如果是采用分布式架构，那基本不用考虑数据会放在硬盘中。
mysql的数据是放在硬盘中。虽然mysql也有缓存，但mysql缓存的是查询的结果，而不是缓存数据。
2. redis，mongodb，mysql查找数据的区别
如果你想在一栋大楼里找某个房间，但是你不知道这个房间的门牌号，只记得这个房间的门是非常特别的，那找到这个房间唯一的方式只能每层楼逐个房间找一次，直到找到这个房间为止。
如果你知道了这个房间的门牌号，那很简单，直奔那个楼层就是了。
redis的数据是基于“键值对”存储，“键”相当于门牌号，“值”相当于房间。redis查找数据，每次都是直奔目标，读写速度当然高。
mongodb和mysql中，每组数据都有一个id（或者可以为每组数据建索引），这个id或索引就相当于门牌号。
mongodb和mysql中查找数据，有两种模式，知道id或索引，和不知道知道id或索引。知道id或索引，就相当于知道门牌号，那就直奔目标就行了，效率很高。如果不知道id或索引的情况下查找数据，那就相当于每层楼逐个房间找，效率很低。
3. redis，mongodb，mysql适用场景
redis适用场景：
数据读写速度快，但由于redis数据只存放在一台服务器的内存中（现在只有第三方的分布式解决方案，官方的分布式方案要在3.0版本才会出来），所以存储数据有限。
同时，由于redis存放的数据必须是键值对(key-value)的形式，在读写redis的数据时必须要知道键，这点需要考虑。
所以，在app后端中，最讲求读写效率，最频繁读的数据一般都会放在redis中（当然，这部分数据同时也存在于mysql 或者mongodb中， redis中的数据是一个冗余，当数据更新的时候，两部分都要更新）。
举例，在社交app中，很多操作都需要验证用户的登录信息，那一般怎么做的呢？
用户登录后，服务器会把一个token符串返回给用户，假设这个token字符串为"abcdsdf", 服务器中已经登记了这个token符串，而且把这个tokentoken符串和用户的信息关联在一起，通过这个token符串就能查询到用户的信息。
当遇到需要验证用户的登录信息，就把这个token字符串传给服务器，服务器根据这个token的信息，在服务器中查找这个用户的信息。
在社交app中，大多数的操作都需要这个验证，可以看出，是个很频繁的操作，而且这个操作需要在极短的时间内完成。
那么，这个token字符串和用户的信息，就很适合放在redis中，把token字符串当成一个key(键)，用户的信息当成是value（值），查找起来非常方便和高效。
当然了，验证用户的登录信息还需要很多安全的措施，这里只讲一个最简单的模型，在以后的《app通讯安全性》一文中会讲完善的安全措施。
mongodb适用场景：
a.网站数据：mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
b.缓存：由于性能很高，mongo也适合作为信息基础设施的缓存层。在系统重启之后，由mongo搭建的持久化缓存可以避免下层的数据源过载。
c.大尺寸、低价值的数据：使用传统的关系数据库存储一些数据时可能会比较贵，在此之前，很多程序员往往会选择传统的文件进行存储。
d.高伸缩性的场景：mongo非常适合由数十或者数百台服务器组成的数据库。
e.存储地理坐标的数据。mongo支持非常强大的地理坐标的查询，例如，可以在某个矩形范围内的用户。非常适合于LBS的应用。
mongodb不适合的场景：
a.高度事物性的系统：例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
例如，涉及金钱的操作，假设要把转账，必须从一个账号上扣钱，再在另外一个账号上把钱转账。这个操作必须保证要么两个都完成，要么两个都不做，不能只做一个。但很遗憾，由于mongodb不支持事务，所以没法保证。
b. 传统的商业智能应用：针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。
c. 需要SQL的问题。虽然mongodb支持类似于sql的查询方式，但它的查询比起mysql还是有一定的差距。
mysql适用场景:
a. 事物性的系统。例如，在mongodb中举例的转账的例子
b. 需要复杂SQL的问题。
简单地来说，综合考虑后，发现数据不适合放在redis和mongodb后，那就把数据放在mysql吧^-^
---------------------------------------------------------------------------------------------------------------------------
打开链接 app后端系列文章总目录 总目录 ，能查看本人发表过的所有原创“app后端”文章。
【作者】曾健生
【QQ】190678908
【qq群】254659220
【微信公众号】 appbackend
【新浪微博】 @newjueqi
【博客】http://blog.csdn.net/newjueqi