关于选择MySQL还是MongoDB

有一天突然想到这个问题:能用关系型DB的地方,就能用Non-SQL,Non-SQL还有更灵活的表结构,那我们为什么还要选择关系型DB呢?

关于这个问题,Non-SQL的代表MongoDB自己也给出过解释(https://www.mongodb.com/compare/mongodb-mysql?jmp=docs),看下来的感觉依然是MongoDB完全超越MySQL。特别在于用户互动相关的社交领域,MongoDB更胜一筹。

当然,它也提到了“什么样的情况选择MySQL会更好”:

需要复杂的多行事务的应用程序(例如双记录记录系统)
涉及复杂交易的系统,比如旅行预订系统背后的预订引擎
那么,问题来了:为什么交易系统更适合用关系型数据库?

要回答这个问题,首先需要知道MySQL比MongoDB好的优点,在于Complex Transactions(复杂事务)。

所谓事务,就是一组连续的DB操作。说白了就是一批SQL。事务处理主要用来维护数据库的完整性,保证成批的 SQL 语句要么全部执行,要么全部不执行。

事务的应用场景,主要就是交易系统、订单系统、银行系统。

举几个例子:

例1:A账户扣除¥100,然后A账户增加¥200。如果第一步执行成功后,系统故障,A就无法获得增加的¥200,怎么办?
例2:删除好友,需要先从A的好友列表中删除B,然后再从B的好友列表中删除A。这两个步骤缺一不可。
这两个例子中,每组操作,就是一个事务。事务里的这些操作,要么全部执行,要么全部失败,不能只执行其中的一部分。所以事务提交之后,会将提交的事务持久化到磁盘。即使系统崩溃,提交的数据也不应该丢失。

这样的场景在交易系统、订单系统、银行系统中,很常见。这种情况,需要复杂事务操作,MongoDB无法做到,就应该选择关系型数据库。

【译】我为什么放弃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都能提供完美的数据存储服务。

4.MySQL、MongoDB简单的性能测试

关于两个数据的性能,最有力的的说话还是通过实践来进行测试,网上看到一组测试数据,分享给大家。

测试环境:Windows 10、内存8G、CPU i5 3.30GHZ。均无索引

测试语言:Python

链接工具:pymysql、pymongo

MySQL && Mongo 测试数据统计

  提交次数 单次提交个数 MySQL运行时间(s) Mongo运行时间(s) 数据量
1 1000 10000 3912 1622.02 0
2 100 100 30 1.61 1000万
3 100 100 5.77 1.60 0
4 10 25 2.35 1.56 0
5 10 25 7.42 1.60 1000万
6 10000 1 298.07 5.29 0
7 10000 1 496.18 5.29 1000万