关系型数据库与NoSQL的对⽐
SQL(结构化的查询语⾔)数据库是过去四⼗年间存储数据的主要⽅式。20世纪90年代末随着Web应⽤和MySQL、PostgreSQL和SQLite等开源数据库的兴起，⽤户爆炸式的增长。
NoSQL数据库⾃从20世纪60年代就已经存在了，直到MongoDB, CouchDB, Redis 和 Apache Cassandra等数据库的流⾏才获取了更多的关注。
你可以很容易地到许多关于如何使⽤⼀款特定的SQL或NoSQL的教程，但是很少有讨论你为什么优先的使⽤⼀款⽽不适⽤另⼀款。我希望我能够填补这个空⽩。在这篇⽂章中将会介绍它们之间的不同。在中，我们将会根据典型的场景来确定最佳的选择。
⼤多数的例⼦都适⽤于流⾏的关系型数据库和 NoSQL数据库.其它的SQL/NoSQL也是类似的，但是在语法和特点上会有⼀些细微的差别。
SQL与NoSQL之间的战争
在我们进⼀步讨论之前，我们先不去考虑各种观点......
观点⼀：NoSQL将会取代SQL
这个观点就像是说船将会取代汽车，因为船是⼀种新的技术⼀样，这是不可能发⽣的事情。SQL和NoSQL有着相同的⽬标：存储数据。它们存储数据的⽅式不同，这可能会影响到你开发的项⽬，⼀种会简化你的开发，⼀种会阻碍你的开发。尽管⽬前NoSQL数据库⾮常的⽕爆，但是NoSQL是不能取代SQL的--它仅仅是SQL的⼀种替代品。
观点⼆：NoSQL要⽐SQL好/坏
⼀些项⽬可能会更适合使⽤SQL数据库，然⽽⼀些项⽬可能会⽐较适合使⽤NoSQL，有些项⽬使⽤哪⼀种都可以很好地达到预期的效果。本⽂不⽀持任何⼀⽅，因为没有⼀种⽅式可以使⽤到所有的项⽬中去。
观点三：SQL与NoSQL之间有明显的差别
这个观点并不是很正确。⼀些SQL数据库也采⽤了NoSQL数据库的特性，反之亦然。在选择数据库⽅⾯的界限变得越来越模糊了，并且⼀些新的混合型数据库将会在不久的将来提供更多的选择。
观点四：语⾔或框架决定使⽤何种数据库
我们已经习惯于使⽤⼀些现有的框架进⾏开发，例如：
LAMP：Linux，Apache，MySQL（SQL），PHP
MEAN：MongoDB（NoSQL），Express，Angular，Node.js
.NET，IIS和SQL Server
Java，Apache和Oracle
由于很多实际的，历史的和商业化的原因导致了这些框架的发展，但是它们并不是⼀种规则约束。你可以在你的和的项⽬中使⽤。也可以在Node.js中使⽤或者。或许在你使⽤上诉开发模式下不能到很好的教程和资源，但是我们开发应该是需求决定使⽤数据库的类型，⽽不是数据库语⾔来决定的。
(换句话说，不要⾃讨苦吃！选择⼀种⼩众的技术组合或者是将SQL和NoSQL进⾏组合开发是有可能的，但是那样你会发现寻有经验的开发者和相关的技术⽀持是⾮常困难的)
下⾯我们来看⼀下它们之间的主要的差别......
SQL中的表与NoSQL中的⽂档
SQL数据库提供关系型的表来存储数据。例如，如果你在维护⼀个在线的书店，书籍信息应该存放到book的表中：
ISBN title author format price
9780992461225JavaScript: Novice to Ninja Darren Jones ebook29.00
9780994182654Jump Start Git Shaumik Daityari ebook29.00
每⼀⾏是⼀本不同书籍的⼀个记录。这样的设计有些死板，你不能使⽤同⼀张表来存储不同结构的信息或者在规定插⼊数字的位置插⼊字符串。
NoSQL数据库采⽤类JOSN的键值对来存储⽂档，例如：
{
ISBN: 9780992461225,
title: "JavaScript: Novice to Ninja",
author: "Darren Jones",
format: "ebook",
price: 29.00
}
同⼀类型的⽂档存储为⼀个集合（collection），类似于关系型数据库中的表结构。然⽽，你可以在任意的⽂档中存储任意的数据，NoSQL 数据库不会去进⾏⽐较。例如：
{
ISBN: 9780992461225,
title: "JavaScript: Novice to Ninja",
author: "Darren Jones",
year: 2014,
format: "ebook",
price: 29.00,
description: "Learn JavaScript from scratch!",
rating: "5/5",
review: [
{ name: "A Reader", text: "The best JavaScript book I've ever read." },
{ name: "JS Expert", text: "Recommended to novice and expert developers alike." }
]
}
SQL中的表结构具有严格的数据模式约束，因此存储数据很难出错。NoSQL存储数据更加灵活⾃由，但是也会导致数据不⼀致性问题的发⽣。
SQL模式 VS NoSQL的⽆模式
在关系型数据库中，除⾮你事先定义了表和字段的模式否则你⽆法向其中添加数据。模式中包含了许多的信息：
主键 — 独⼀⽆⼆的标志就像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语⾔的⾮规范化
假设我们想要在书店的数据库中添加⼀项出版社信息。⼀个出版社会出版很多书，因此在数据库中我们创建了⼀个表publisher：
id name country email
SP001SitePoint Australia
我们要在book表中添加⼀个publisher_id的字段，⽤于引⽤出版社信息中的id：
ISBN title author format price publisher_id
9780992461225JavaScript: Novice to Ninja Darren Jones ebook29.00SP001
9780994182654Jump Start Git Shaumik Daityari ebook29.00SP001
这样的设计能够最⼩化数据的冗余，我们不需要为每⼀本书重复的添加出版社的所有信息—只需要去引⽤就可以了。这项技术叫做数据库的规范化，具有实际的意义。我们可以更改出版社信息⽽不⽤修改book中的数据。
在NoSQL中我们也可以使⽤规范化技术。在book集合中的⽂档：
{
ISBN: 9780992461225,
title: "JavaScript: Novice to Ninja",
author: "Darren Jones",
format: "ebook",
price: 29.00,
publisher_id: "SP001"
}
引⽤publisher集合中的⼀个⽂档
{
id: "SP001"
name: "SitePoint",
country: "Australia",
email: "feedback@sitepoint"
}
然⽽，在实际中我们并不会这样做。我们会更倾向于选择⾮规范化我们的⽂档为每⼀本书中都重复出版社的信息
{
ISBN: 9780992461225,
title: "JavaScript: Novice to Ninja",
author: "Darren Jones",
format: "ebook",
price: 29.00,
publisher: {
name: "SitePoint",
country: "Australia",
email: "feedback@sitepoint"
}
}
这样会使查询更快，但是在更新出版社信息的记录变多时效率将会显著地下降。
SQL关系的JOIN操作 VS NoSQL
SQL语⾔为查询提供了强⼤的JOIN操作。我们可以使⽤单个SQL语句在多个表中获取相关数据。例如：
SELECT book.title, book.author, publisher.name
FROM book
LEFT JOIN book.publisher_id ON publisher.id;
这条SQL语句会返回所有书的书名，作者和相关的出版社的名称。
在NoSQL中没有与JOIN相同的操作，对于具有SQL语⾔经验的⼈来说是⾮常令⼈震惊的。如果我们使⽤是上⾯的规范化的集合，我们需要取出book集合中所有的⽂档，检索所有的publisher的⽂档，并在程序中进⾏⼿动连接。这也是⾮规范化存在的原因之⼀。
SQL VS NoSQL 数据完整性redis是nosql数据库吗
⼤多数的数据库允许通过定义外键来进⾏数据库的完整性约束。我们的数据库能够保证：
确保所有的书的publisher_id都会对应于publisher中的⼀个实体，
如果有⼀本或多本书中的publisher_id与publisher中的id对应，那么该出版社就不能被删除。
数据模式确保了这些规则被数据库遵守。开发者或者⽤户不能添加、修改和移除⼀条记录，如果这些操作导致数据产⽣⽆效的数据或者单条⽆⽤记录。
在NoSQL数据库中没有数据完整性的约束选项。你可以存储任何你想要存储的数据。理想情况下，单个⽂档将是项⽬的所有信息的唯⼀来源。
SQL VS NoSQL 事务
在SQL数据库中，两条或者多条更新操作可以结合成⼀个事务（或者全部执⾏成功否则失败）执⾏。例如，假设我们的book数据库中包含了order和stock表。当⼀本书被订购之后，我们要在order中添加⼀条记录并减少stock中的库存数⽬。如果我们将两条更新操作分别执⾏，⼀条成功另⼀个失败---这将会导致数据库的不⼀致性。将两条更新操作绑定为⼀个事务确保了它们要么全部成功要么全部失败。
在NoSQL数据库中，对于⼀个⽂档的更新操作是原⼦性的。换句话说，如果你要更新⼀个⽂档中的三个值，要么三个值都更新成功要么它
们保持不变。然⽽，对于操作多个⽂档时没有⾬事务相对应的操作。在MongoDB中有⼀个操作是，但是，需要我们⼿动的加⼊到代码中。SQL VS NoSQL CRUD（增删改查）语法
增删改查是数据库的基本操作。本质上：
SQL是⼀种声明性语⾔。SQL语⾔的功能强⼤，并且已经成为了⼀种国际的通⽤标准，尽管⼤多数系统在语法上有⼀些细微的差别。
NoSQL数据库使⽤类似JOSN为参数的JavaScript来进⾏查询！基本操作是相同的，但是嵌套的JOSN将会产⽣复杂的查询。
⽐较：
SQL NoSQL
insert a new book record
INSERT INTO book (ISBN,title,author)VALUES ( '9780992461256', 'Full Stack JavaScript', 'Colin Ihrig & Adam Bretz');db.book.insert({ ISBN: "9780992461256", title: "Full Stack JavaScript", author: "Colin Ihrig & Adam Bretz"});
update a book record
UPDATE bookSET price = 19.99WHERE ISBN = '9780992461256'db.book.update( { ISBN: '9780992461256' }, { $set: { price: 19.99 } }); return all book titles over $10
SELECT title FROM bookWHERE price > 10;db.book.find( { price: { >: 10 } }, { _id: 0, title: 1 });The second JSON object is known as a projection: it sets which fields are returned (_id is returned by default so it needs to be unset).
count the number of SitePoint books
SELECT COUNT(1) FROM bookWHERE publisher_id = 'SP001';unt({ "publisher.name": "SitePoint"});This presumes denormalized documents are used.
return the number of book format types
SELECT format, COUNT(1) AS total FROM bookGROUP BY format;db.book.aggregate([ { $group: { _id: "$format", total: { $sum: 1 } } }]);This is known as aggregation: a new set of documents is computed from an original set.
delete all SitePoint books
DELETE FROM bookWHERE publisher_id = 'SP001';Alternatively, it’s possible to
delete the publisher record and have this cascade to
associated book records if foreign keys are specified appropriately.
ve({ "publisher.name": "SitePoint"});
SQL VS NoSQL 表现
或许最具有争议性的⽐较是：通常情况下，NoSQL⽐SQL语⾔更快。这并没有什么好震惊的，NoSQL中更加简单的⾮规范化存储允许我们在⼀次查询中得到特定项的所有信息。不需要使⽤SQL中复杂的JOIN操作。
也就是说，你的项⽬的设计和数据的需求会有很⼤的影响。⼀个好的SQL数据库的设计的表现⼀定会⽐⼀个设计不好的NoSQL数据库性能好很多，反之亦然。
SQL VS NoSQL 规模
随着数据量的增长，我们或许会发现有必要将负载分配到到不同的服务器上。对于基于SQL语⾔的开
发的系统是⾮常困难的。如何分配相关的数据？集是⼀种最简单可能的解决⽅案，多个服务器访问同⼀个中央存储器—及时是这样也会有许多的问题。
NoSQL的简单的数据模型能够简化其过程，许多NoSQL数据库在⼀开始就构建了解决⼤规模数据的功能。这仅仅是⼀个概括，如果你遇到了这样的问题应该去寻求专家的帮助。
SQL VS NoSQL 可⾏性
最后，我们考虑⼀下安全性和系统性的问题。流⾏的NoSQL数据库已经存在好⼏年了，它们展现的问题可能会⽐成熟的关系型数据库多。许多问题都已经被发现了，但是所有的问题都指向了同⼀个问题：了解程度。
开发⼈员和系统管理员对于管理新型数据库有很少的经验，因此会产⽣许多问题。选择NoSQL是因为感觉它⽐较新颖，或者你想要避免数据模式的设计，都会在将来带来⼀些问题。
SQL VS NoSQL 总结
SQL和NoSQL数据库只是⽤不同的⽅式来完成相同的事情。我们可能会先选择其中之⼀然后更换到另⼀个上，但是在选择之前制定⼀个计划将会节约许多的时间和⾦钱。
适合使⽤SQL开发的项⽬：
可以预先定义逻辑相关的离散数据的需求
数据⼀致性是必要的
具有良好的开发者经验和技术⽀持的标准的成熟技术
适合使⽤NoSQL开发的项⽬：
不相关，不确定和逐步发展的数据需求
更简单或者更宽松的能够快速开始编程的项⽬
速度和可扩展性⾄关重要的
在我们的例⼦中，⼀个关系型数据库是⼀种更好的选择— 尤其是当我们需要引⼊强⼤的事务⽀持的电⼦商务设备。在接下来的⼀篇⽂章中，我们将讨论更多的项⽬场景，并确定使⽤⼀个SQL或NoSQL数据库是否是最好的解决⽅案。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。