SQL 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的申中:

各个一样实施是一个异之笔录。设计是刚性的;你莫克使以及一个表来存储不同的信息,或者在一个数字格式输入字符。

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表:

我们接下去好长publisher_id到book表,这个发明是publisher.id引用。

这太老限度的削减多少的冗余;我们绝不再每本书的出版商信息——仅仅只用索引。这种技术可以称规范化,并发出实在的补益。我们只用更新单一的出版商而休用改变一切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对于复杂的询问会换得进一步的乱。

概括的较:



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对我们的话是无限适用的。

相关文章