MySQLSQL vs NoSQL 没有硝烟的战争!

扬言:本文译自SQL vs NoSQL The
Differences,如需要转载请注明出处。


SQL(结构化查询语言)数据库作为一个主要的数目存储机制已过40个新春了。随着web应用与诸如MySQL、PostgreSQL和SQLite这些开源项的勃兴,SQL使用量大大加。

NoSQL数据库在20世纪60年份就早已起了,但近期以MongoDB、CouchDB,Redis和Apache
Cassandra等才吃广大的关爱。

卿见面发现许多科目都见面讲如何根据你的趣味选择去下SQL还是NoSQL,但是非常少讨论为什么当去选它。我期望能补这无异于空白。在及时首文章被,我们将介绍中心的歧异。在稍后底持续之章中,我们拿翻开有天下无双的状况,并确定最佳的选取。

大多数底事例都适用于目前兴的MySQL SQL和MongoDB
NoSQL数据库系统。其他SQL/NOSQL数据库都是近乎之,但会发生微小的距离和语法特征。

SQL和NoSQL的圣战

在我们开前,先改一些所谓的神话…

  • 神话1:NoSQL将取代SQL

如此这般说不怕好比说船将受车替代,因为其是初的艺。SQL和NoSQL做的凡同样之行:数据存储。它们运的方不同,这恐怕回帮组或堵住你的品种。尽管觉得技术创新,并时常以前不久达头修,NoSQL不是SQL的替代品——而是同样栽选择。

  • 神话2:NoSQL比SQL更好要重复特别

有些门类还契合采取SQL数据库,一些再度合乎NoSQL,而有些好彼此交替使用。这边文章未见面是SitePoint
Smackdown,因为你不克在有方都运相同的广泛性假设。

  • 神话3:SQL和NoSQL天壤之别

这不自然是个真相。一些SQL数据库采用NoSQL的特性,反之亦然。选择或许会见变换得更加混淆,NewSQL混合数据库可能会见以前提供有好玩的选择。

  • 神话4:语言/框架决定了以什么的数据库

咱曾习以为常了技能堆,比如——

  • LAMP: Linux, Apache, MySQL (SQL), PHP
  • MEAN: MongoDB (NoSQL), Express, Angular, Node.js
  • .NET, IIS and SQL Server
  • Java, Apache and Oracle.

生实施的、历史的及商贸的原委来分解这些stack的腾飞——但非克看它们就规则。你可在你的PHP或.NET项目面临使用MongoDB
NoSQL数据库。你可以Node.js中老是MySQL或者SQL服务器。你或没有找到多课以及资源,但是是公的求决定数据库的品类——而非是所谓的言语。

(有句话是这么说之,不要给生活产生目地为难自己!选择一个未平常的艺结合要SQL和NoSQL组合是立竿见影的,但艰苦的是找到支持和请有经验的开发者)

生了如此的想法,我们来看望主要的区别。

SQL表VS NoSQL文档

SQL数据库提供相关数据表的蕴藏。例如,如果你产生一个网上书店,图书的音讯将会让补充加至一个book的申中:

MySQL 1

各个一样履行是一个见仁见智之笔录。设计是刚性的;你不能够采取及一个表来存储不同之音,或者以一个数字格式输入字符。

NoSQL数据库存储JSON格式的字段值对文档,比如:

{

ISBN: 9780992461225,
title: "JavaScript: Novice to Ninja",
author: "Darren Jones",
format: "ebook",
price: 29.00
}

  

貌似之文档可以储存于一个聚众里,这仿佛于一个SQL表。然而你可储存任何数据以另文档里;而NoSQL数据库永远不会见抱怨,例如:

{

ISBN: 9780992461225,
title: "JavaScript: Novice to Ninja",
author: "Darren Jones",
format: "ebook",
price: 29.00
}

 

SQL表创建一个严酷的数目模板,因此非常不便犯错误。NoSQL更加的利落和姑息,但能存储任何数或者会见招一致性的题目。

SQL模式VS NoSQL无模式

每当一个SQL数据库被,除非你以指定模式遭遇定义了表和字段格式,不然不容许抬高数据。该模式还可以蕴涵其他的信,例如——
主键——唯一的标识符,如ISBN,适用于单个记录。
目录——通常被询问的字段,用来帮衬快熟搜索。
波及——数据字段之间的逻辑连接
力量——如触发器和仓储过程

君的多少模式要以旁商业逻辑可以被开去处理数据前被规划下并贯彻。完成后方可履一些翻新,但不可知不负众望好的改。

每当一个NoSQL数据库,数据可以随时随地为增长。没有必要去制定一个文档设计,甚至集合前端。例如当MongoDB,下面的讲话以在初的book集合创建一个新的文档,如果此文档之前从没受创造了:

db.book.insert(

ISBN: 9780994182654,
title: "Jump Start Git",
author: "Shaumik Daityari",
format: "ebook",
price: 29.00
);

 

(MongoDB会叫每个集合内的文档自动抬高唯一的_id值。你或任然想要定义索引,如果需要的话可以稍后进行。)

如若一个档初步数据要求大麻烦去确定,那么NoSQL数据库可能一发的抱。有句话说,不要啊懒散而做困难:忽略了以列面临设计符合的数据库的基本点将会见当后来导致群之麻烦。

SQL规范化VS NoSQL反规范化

若我们只要朝向书店数据库中补充加出版商信息。一个单一的出版商可以提供多独标题,在一个SQL数据库里,我们创建一个新的publisher表:
MySQL 2
咱们对接下去好加publisher_id到book表,这个发明是publisher.id引用。
MySQL 3
马上绝可怜限度的减数量的冗余;我们不用还每本书的出版商信息——仅仅只用索引。这种技能可以叫规范化,并发出实际的便宜。我们只用更新单一的出版商而非用改变总体book数据。
以NoSQL中,我们也堪采取规范化技巧。在book集中的文档——

{

ISBN: 9780992461225,
title: "JavaScript: Novice to Ninja",
author: "Darren Jones",
format: "ebook",
price: 29.00,
publisher_id: "SP001"
}

 

——在一个出版商集合中援一个文档:

{

id: "SP001"
name: "SitePoint",
country: "Australia",
email: "feedback@sitepoint.com"
}

 

然而,这并无总是实惠的,原因在下面很扎眼。我们或许选择反规范化我们的文档,重复每本书的出版商信息:

{

ISBN: 9780992461225,
title: "JavaScript: Novice to Ninja",
author: "Darren Jones",
format: "ebook",
price: 29.00,
publisher: {
    name: "SitePoint",
    country: "Australia",
    email: "feedback@sitepoint.com"
}
}

 

当时好加速查询的进度,但在多独记录被创新出版商信息用见面明确变慢。

SQL关系连接VS NoSQL

SQL查询提供了一个强有力的JOIN条款。我们好下单个SQL语句获取不同表中的相关数据。例如:
SELECT book.title, book.author, publisher.name
FROM book
LEFT JOIN book.publisher_id ON publisher.id;
当下将回所有的书名、作者和系出版商名称。

NoSQL没有一样的JOIN,有SQL的更的或是会见惊讶.
如果我们使用上述的规范化集合,我们将急需取有的book文档,检索所有的相干publisher文档,并手动在程序逻辑中连接两者。这就是倒规范化常常是不可或缺的一个缘故。

SQL VS NoSQL数据完整性

大部SQL数据库允许你用外键约束去强制性数据完整性(除非您照当用旧的,在MySQL已无存的MyISAM存储引擎)。我们的书摊可以——

  •  确保有的题都发生一个得力的publisher_id编码,这个编码在
    publisher表中还生相当的条目
  •  如果一个要么多只写为分配给其,则出版商不能够给剔除。

模式强制数据库遵循这些规则。开发者或用户则无能够长、编辑或者移除可能引起无效数据或者孤立的多寡

平等数据完整性选项在NoSQL数据库中无可用;你可储存所有你想囤积的物。理想状态下,单一文档将成门类所有消息的绝无仅有来源。

SQL VS NoSQL事务

在SQL数据库被,两只或多独更新得当跟一个事务中实行——一个all-or-nothing的包保证成功还是黄。例如,假要我们的书摊包含了order和stock表。当一本书被订时,我们于order表添加相同长长的记下并压缩stock表中的库存数。如果我们独家地履行这半个创新,一个可能成另外一个会晤败——因此我们的数据会不联合。在一个事情中放置相同更新得包同时打响或者失败。

以NoSQL数据库被,单个文档的改是轻微的。换句话说。如果您方文档中更新三单价值,要无三只价都是水到渠成的,要无三个价值都保持不变换。然而,却未曾当的事体去创新不同之文档。有近似的抉择项,但是,在描绘这些的时刻,必须在您的代码中手动处理。

SQL VS NoSQL CRUD 语法

开创、读取更新和去数据是高达保有数据库系统的根基。本质上——

  •  SQL是一个轻量级的陈述性语言。这是雅强大的,并一度改为一个国际化的专业,虽然多数网贯彻略有不同的语法。
  •  NoSQL数据库使用与JSON类似
    JavaScripty-looking查询!基本操作很粗略,但嵌套的JSON对于复杂的查询会变换得更其的紊乱。

粗略的于:
MySQL 4
MySQL 5
MySQL 6
MySQL 7

SQL VS NoSQL性能

立恐怕是极度有争议之较,NoSQL经常为当比SQL更快。这并无奇怪;NoSQL更加简明的倒规范化存储允许你使用单个请求去当具有信息遭到查询一个特定的花色。不待使用相关的JSON或复杂的SQL查询。

也就是说,你的型设计与数目要求以发出最特别的震慑。一个精设计之SQL数据库必然会比一个计划非常不同之NoSQL表现自己,反之亦然。

SQL VS NoSQL缩放

乘势你的数据的提高,你或会见意识以差不多只服务器之前分配负载是很必要之。这对SQL为根基的系统或许好棘手。如何分配相关的多寡也?聚类可能是无限简单易行的挑三拣四;多单服务器访问同一之中央存储——但即使如此呢会是挑战。

NoSQL的简数据模型可以为这历程易多,许多同一初始就是成立了缩放功能。这是一个概论性的,所以要碰到这种状态要去问专家看法。

SQL VS NoSQL实用性

末段,我们来设想安全与系的题材。最有名的NoSQL数据库才是了几年;他们比又成熟之SQL产品又易并发问题。许多底题材已于曝光,但大部分要归结为一个问题:知识。

开发人员和系统管理员对于新的数据库系统有比较少的经历,所以错误时出。选择NoSQL是以它感到会重复快,或坐若想去避免架构设计而导致随后的题目。

SQL VS NoSQL的总结

SQL和NoSQL数据库用不同之主意开一样的业务。从一个切换至其它一个凡是可能的,但是一些计划可省去很多的年月以及钱财。

更适合SQL的项目:

  • 可预先确定的逻辑关系离散数据的要求
  • 数据完整性是必不可少的
  • 有良好开发经验和支持的标准基础技术

更适合NoSQL的项目:

  • 不相关的、不确定或不断变化的数据要求
  • ``更加简单宽松的项目对象,可以立即编码
  • ``速度和扩展性是必要的

在这个书店例子的背景下,SQL数据库是最最实用的选择项——特别是当我们引进电商设施,需要强大的工作支持。

出于我们云巴凡是做过设备平台的音信服务之,对数据存取的快慢及扩展要求非常强,NoSQl对咱吧是无与伦比适用的。

网站地图xml地图