我为什么放弃MySQL？最终选择了MongoDB

最近有个项目的功能模块，为了处理方便，需要操作集合类型的数据以及其他原因。考虑再三最终决定放弃使用MySQL，而选择MongoDB。

两个数据库，大家应该都不陌生。他们最大的区别就是MySQL为关系型数据库，而MongoDB为非关系型数据库。常见的关系型数据库有：MySQL、Oracle、DB2、SQL Server、Postgre SQL等，非关系型数据库有MongoDB、Redis、Memcached、HBse等等。

1、关系型数据库？ 非关系型数据库？

关系型数据库可以理解为依赖一个模型来创建的数据库，比如我们使用的MySQL中的表是由横列和纵列组成的一个二维表格。关系型数据库可以通过关系模型使多个表的数据关联起来，比如我们平时说的 一对一、一对多、多对一。由于是建立在数据模型的基础上，所以我们可以通过SQL语句很方便的在多个表之间做复杂的查询操作。关系型数据库相对安全，因为直接存储在硬盘中所以突然的宕机、停电等意外不会导致数据丢失。MySQL的存储方式是由自身的引擎决定的,常用的引擎有Innodb和MyISAM。他们主要的区别就是MyISAM 不支持事务，强调的是性能，执行速度比Innodb要快，Innodb提供支持事务等高级数据库功能。

非关系型数据库即我们常说的NoSQL数据库，部署起来都比较简单，没有关系型数据库那么复杂。Mongo的存储方式为虚拟内存+持久化存储，Mongo将数据写入内存中，再由虚拟内存管理器将其持久化到硬盘中，因此写操作会比关系型数据库快很多。NOSQL的存储格式是key-value形式，可以像关系型数据库那样存储基础数据类型的数据，也可以存储集合、对象等等。NoSQL虽然性能比较高，但是并不支持事物，也不能进行联表查询，一般用于较大规模数据的存储。

2、他们的优点、缺点有哪些

关系型数据库发展了很长一段时间，拥有非常成熟的体系。所占份额也在逐渐增加。而且支持事物的操作，保证数据的一致性，可以通过SQL语句完成复杂的操作。但是使用过程中当数据量到达一定程度时，关系型数据库的效率会有明显的下降。一个复杂的查询操作，一系列的组合索引都会消耗非常多的内存空间，此时我们需要对数据库进行读写分离操作，或者将数据库结构进行拆分(水平拆分、垂直拆分)将请求压力分担在不同的库中。

垂直拆分是指将一张表拆分成多个表，表之间通过主键进行关联。

水平拆分是按照某种规则拆分成多个表，比如通过用户角色进行拆分

读写分离：所谓读写分离就是讲读操作(查询数据)和写操作(插入&更新)指向不同的数据库节点，他们中间通过某种机制实现数据的同步，如binlog。实际的应用中大部分压力还是来自读操作，所以主要是一主多从的架构。

非关系型数据库发展的这几年，深受人们的喜爱。免费开源、成本低、部署简单、非结构化存储等等明显的优势。而且它对海量数据处理能力非常强，内存级数据库，查询速度也非常快。存储的数据格式比较丰富，易于扩展，虽然不能使用sql进行复杂的查询，但是MongoDB支持JavaScript，所以可以通过js脚本进行复杂的数据库管理操作。关于NoSQL的缺点个人感觉目前就是不支持事物了吧，其他方面那都不是事儿。

3、什么时候用mongo

Mongo是用c++编写的，支持多种语言如：Java、Python、Ruby、PHP、C++、C# 等，有时候针对不同的业务需求，选择Mongo能够避免浪费很多不必要的资源

日志系统

系统运行过程中产生的日志信息，一般种类较多、范围较大、内容也比较杂乱。通过MongoDB可以将这些杂乱的日志进行收集管理。不仅方便了管理，查找或者导出也会变得非常容易

地理位置存储

MongoDB支持地理位置、二维空间索引，可以存储经纬度，因此可以很快的计算出两点之间的距离，等位置信息。如查询附近的人、或者订餐系统、配送系统等

数据规模增长很快

前面提到过关系型数据库数据量过大时，需要进行分库分表，这样真正操作起来可能会比较麻烦。如果选择mongo进行分库分表操作时，就会变得很简单。

保证高可用的环境

Mongo本身就拥有高可用及分区的解决方案，设置主从服务器非常方便，除此之外Mongo还可以快速并且安全的实现故障节点的转移。

文件存储需求

GridFS是MongoDB规范，用于存储和检索图片、音频、视频等大文件。GridFS虽然是文件存储的一种方式，可以存储超过16M的文件。但是它本身又是存储在MongoDB集合中的

其他场景

如游戏开发中我们可以通过MongoDB存储用户信息、装备、积分等，除此之外物流系统、社交系统、甚至物联网系统，Mongo都能提供完美的数据存储服务。