mysql VS mongoDB
概览
几十年以来,关系数据库一直是企业应用程序的基础。自从1995年MySQL
发布以来,它一直是一种流行且廉价的选择,特别是作为早期Web应用程序LAMP stack的一部分。
如今,现代企业一直在思考有没有更佳的方式去存储和管理他们的数据——无论是为了获取更好的客户洞察力、适应不断变化的用户期望还是通过新应用程序和商业模式将商业竞争对手打败。然而,推动早期关系数据库开发的许多假设已经发生了变化:
- 更高的开发生产力以及更迅速地将产品上市,传统僵硬的关系型数据模型以及瀑布软件开发模型已然跟不上时代,取而代之的是敏捷开发、微服务、DevOps,它们能让发布周期从几个月、几年压缩到几天和几周。
- 由新型的web、mobile、social和物联网所产生的新的、快速变化的数据(半结构化、多态数据、结构化数据)需要去管理。
- 批发(趸售)转向分布式系统和云计算,使开发人员可以利用随需应变,高度可扩展的计算和存储基础架构并能够在全球任何地点为他们的工作和服务观众服务。
结果是,菲关系型或者NoSQL
数据库,如MongoDB
已经被开发出来以解决新应用的需求以及使现存的工作量适应现代需要。多文档的ACID事务支持也即将支持。
什么是MySQL
?
mysql
是由Oracle员工开发出的一个流行开源的关系型管理系统(RDBMS
)。和其他关系型数据库一样,mysql
将数据存于表内并使用结构化查询语言(SQL
)来进行访问数据库。在mysql
中,你要基于需求预定义数据库模式(schema )并且设置某种规则以管理表内的字段。任何数据库模式的更改都需要进行数据迁移(影响应用程序的性能)。
什么是mongoDB
?
mongoDB
是由mongoDB
研究所研发的一种开源的、非关系型的数据库。mongoDB
以文档(二进制表现)方式存储,称文档为BSON
(binary json
)。相关的数据被存在一起,以便可以通过速度快的mongoDB
查询语言来访问。
文档是自释性的,而且文档内可以包含文档、数据等等,因此无需为文档定制结构。如果想在文档内加一个新的字段,直接加即可,它不会影响到集合内的其他文档,也不需要脱机做数据迁移。mongoDb
文档模型天生就是一个对象,而开发人员恰恰是这么看待对象的,所以感觉很亲切,很自然。
为10多种语言提供本地的、惯用的驱动程序(能进行ad-hoc
查询,实时聚合查询、和丰富的索引)提供了强有力的编程方法来访问和分析任何结构的数据。
相关数据的表示可以通过两种方式来描述:
- 文档可以汇集相关数据。
- 或者在单独表中建立关系。
mongoDB
已经提供了单文档的原子性操作,即发生错误了可以进行事务回滚。
2018年夏季,Mongodb4.0
会提供多文档的事务。
不像MySQ
L等关系型数据库,MongoDB
是建立在分布式系统体系结构上的,而不是单一或单一的节点设计。结果,MongoDB
能自动分片、其副本可保持一直可用状态。
术语和概念
mysql
和mongodb
有响雷西的概念术语。
mysql | mongodb |
---|---|
ACID Transactions | ACID Transactions* (mongodb 4.0 ) |
Table | Collection |
Row | Document |
Column | Field |
Secondary Index | Secondary Index |
JOINs | Embedded documents, $lookup & $graphLookup |
GROUP_BY | Aggregation Pipeline |
特征对比
和mysql
一样,mongodb
提供了很多功能。mongodb
有很丰富的查询语言,二级索引,用于数据分析的聚合操作等。
MySQL | MongoDB | NoSQL Data Store | |
---|---|---|---|
Open source | Yes | Yes | Yes |
ACID Transactions | Yes | Yes*1 | No |
Flexible, rich data model | No | Yes | Partial: schema flexibility but support for only simple data structures |
Schema governance | Yes | Yes | No |
Expressive joins, faceted search, graphs queries, powerful aggregations | Yes | Yes | No |
Idiomatic, native language drivers | No | Yes | No |
Horizontal scale-out with data locality controls | No | Yes | Partial: no controls over data locality |
Analytics and BI ready | Yes | Yes | No |
Enterprise grade security and mature management tools | Yes | Yes | No |
Database as a service on all major clouds | Yes | Yes | No |
查询语言
MySQL | MongoDB |
---|---|
INSERT INTO users (user_id, age, status)VALUES ('bcd001', 45, 'A') | db.users.insert({ user_id: 'bcd001', age: 45, status: 'A'}) |
SELECT * FROM users | db.users.find() |
UPDATE users SET status = 'C'WHERE age > 25 | db.users.update( { age: { $gt: 25 } }, { $set: { status: 'C' } }, { multi: true }) |
为何使用mongodb
而不使用mysql
?
很多组织(大小规模都有)都使用mongodb
,因为它能更快的构建程序、处理种类多样的数据类型以及能更高效的管理规模庞大的数据。
因为mongodb
文档天生自然就是面向对象编程语言中的对象,因此开发更加简单。mongodb
移除了ORM层,而关系型数据库不能移除掉。mongodb
数据模型很弹性,也就是说数据模型可以跟随业务需求的演进而演进。
数据量很大的情况下,mongodb
很容易就能进行扩展,但是mysql
还需要一定的工作量。
基于JSON文档
的开发人员的生产力
事实证明,与弹性的JSON文档打交道而不是死板的行列会提升开发速度。为何?
文档是自然的。文档呈现数据的方式和程序的一模一样。意味着不需要ORM框架的帮助就可以轻松将文档映射成对象。
文档是弹性的。集合下的各个文档的属性不要求完全相同,意味着新增一个属性不会影响到同一个集合下的其他文档。
文档使应用程序更快运行。数据集中在一个文档,不会分散各处。
以上优点正式关系型数据库,如mysql
增加JSON数据类型。但是这样做并不能提升开发效率,为何?
- 专有扩展。需要特殊SQL函数来访问解析。
- 传统关系开销。
- 复杂数据处理。
- 没有数据治理。
- 架构刚性。
mongodb的使用场景
- single view。将孤立的数据聚合起来放到一个仓库,然后创建某样东西的单一视图。
- Internet of things。物物相连,信息共享。
- real time analytics.
- Content management.
什么场景下是适合使用mongodb?
- 更高的写负载。插入数据块。
- 不可靠环境保证高可用性。自动故障转移。
- 未来会有一个很大的规模。mongodb有数据库扩展优势。
- 基于位置的数据查询。
- 非结构化数据爆发增长。