NoSQLSQL vs NoSQL 没有硝烟的战事!

声称:本文译自SQL vs NoSQL The
Differences
,如需转载请注解出处。


SQL(结构化查询语言)数据库作为一个至关主要的多寡存储机制已经领先40个新春了。随着web应用和像MySQL、PostgreSQL和SQLite这么些开源项的兴起,SQL使用量大大扩充。

NoSQL数据库在20世纪60年间就曾经冒出了,但目前因为MongoDB、CouchDB,Redis和Apache
卡Sandra(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 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表:
NoSQL 2
俺们接下去可以扩张publisher_id到book表,这些表是publisher.id引用。
NoSQL 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对于复杂的查询会变得尤其的繁杂。

简易的比较:
NoSQL 4
NoSQL 5
NoSQL 6
NoSQL 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地图