譯者按：SQL與NoSQL之爭(zhēng)近年來(lái)十分受到關(guān)注，既存在“SQL吃遍天下”這種理念，也不乏“NoSQL一定代表著先進(jìn)生產(chǎn)力”這種謬誤。爭(zhēng)者往往不求甚解，為弄潮而爭(zhēng)，忽略了本質(zhì)。這篇文章原文地址：http://www.sitepoint.com/sql-vs-nosql-differences/ 作者對(duì)SQL與NoSQL在多個(gè)層面進(jìn)行了細(xì)致的比較。值得一讀。
SQL（結(jié)構(gòu)化查詢語(yǔ)言）數(shù)據(jù)庫(kù)成為主流的數(shù)據(jù)存儲(chǔ)機(jī)制已經(jīng)存在了80余年。在1990年代末，隨著web應(yīng)用和諸如MySQL、PostgreSQL和SQLite這類開源項(xiàng)目的興起，SQL隨之得到爆發(fā)式應(yīng)用。
NoSQL數(shù)據(jù)庫(kù)產(chǎn)生于1960年代，但是最近才出現(xiàn)了一些類似于MongoDB、CouchDB、Redis和Apache Cassandra這樣的流行選擇。
你可能會(huì)看到很多探討如何使用SQL或NoSQL的某個(gè)特性的文章。對(duì)如何從中二選一的討論卻并不多見。我希望能填補(bǔ)這個(gè)空白。這篇文章中，我們會(huì)覆蓋到最基本的差異。而接下來(lái)會(huì)有一篇文章針對(duì)典型的場(chǎng)景討論數(shù)據(jù)存儲(chǔ)的最優(yōu)選擇。
大多數(shù)例子適用于流行的MySQL SQL數(shù)據(jù)庫(kù)和MongoDB NoSQL數(shù)據(jù)庫(kù)。其他的SQL/NoSQL數(shù)據(jù)庫(kù)是類似的，但是在特性和語(yǔ)法上可能略有不同。
SQL與NoSQL的神圣戰(zhàn)爭(zhēng)
在進(jìn)一步討論之前，讓我們先來(lái)修正一些普遍的謬誤：
謬誤： NoSQL比SQL更好/差
有些項(xiàng)目更適合使用SQL數(shù)據(jù)庫(kù)。有些則更適合NoSQL。 還有些則能配合使用。這篇文章不是想在兩者之間決出一個(gè)勝者，因?yàn)槟悴豢赡茉谒械膱?chǎng)景下都應(yīng)用同樣的假設(shè)。
謬誤： NoSQL和MySQL之間有著清晰的鴻溝
這不一定是對(duì)的。有些SQL數(shù)據(jù)庫(kù)正在加入NoSQL的特性，反之亦然。這兩者的界限很可能會(huì)越來(lái)越模糊。而新的混合數(shù)據(jù)庫(kù)能在未來(lái)提供有趣的選擇。
謬誤：編程語(yǔ)言/框架 決定了數(shù)據(jù)庫(kù)
我們?cè)絹?lái)越習(xí)慣各種各樣的技術(shù)棧：
- LAMP: linux, Apache, MySQL(SQL), PHP
- MEAN: MongoDB(NoSQL), Express, Angular, Node.js
- .NET, IIS和SQL Server
- Java, Apache和Oracle
這些技術(shù)棧產(chǎn)生可以歸于應(yīng)用的，歷史上的和商業(yè)上的原因，但別被限死了。 你當(dāng)然可以在你的PHP或.NET項(xiàng)目使用MongoDB的NoSQL數(shù)據(jù)庫(kù)。你也可以在Node.js里面連接MySQL或SQL SERVER。可能你沒(méi)法找到那么多教程和資源，但是你的需求本身應(yīng)該決定數(shù)據(jù)庫(kù)的類型，而不是編程語(yǔ)言。
（這意味著，別給自己故意挖坑！原則一個(gè)不常見的技術(shù)組合或SQL和NoSQL的混合式可能的，但是在尋求幫助和找到有經(jīng)驗(yàn)的開發(fā)者方面會(huì)遇到不少困難
）
記住了這些，讓我們來(lái)看看異同的比較。
SQL的表 vs NoSQL的文檔
SQL數(shù)據(jù)庫(kù)提供了一族相關(guān)的數(shù)據(jù)表。舉例來(lái)說(shuō)，如果你在運(yùn)營(yíng)一個(gè)線上的書店，書的信息可以被加入到一個(gè)叫book的表。
| ISBN | title | author | format | price |
|---|---|---|---|---|
| 9780992461225 | JavaScript: Novice to Ninja | Darren Jones | ebook | 29.00 |
| 9780994182654 | Jump Start Git | Shaumik Daityari | ebook | 29.00 |
每一行都是一條不同的書德爾記錄。這種設(shè)計(jì)是比較苛刻的，你沒(méi)法使用同樣的表去存儲(chǔ)不同的信息或者在是數(shù)字類型的字段插入字符串。
NoSQL數(shù)據(jù)庫(kù)存儲(chǔ)類JSON的鍵值對(duì)文檔：
{
ISBN: 9780992461225,
title: "JavaScript: Novice to Ninja",
author: "Darren Jones",
format: "ebook",
price: 29.00
}
相似的文檔可以被存儲(chǔ)進(jìn)一個(gè)集合，這跟SQL表十分類似。但是，在文檔里面你可以存儲(chǔ)任何形式的數(shù)據(jù)，NoSQL數(shù)據(jù)庫(kù)并不會(huì)抱怨：
{
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表創(chuàng)建的是嚴(yán)格的數(shù)據(jù)模板，所以你很難犯錯(cuò)。而NoSQL更加靈活，但是能夠在任何地方存儲(chǔ)數(shù)據(jù)可能會(huì)導(dǎo)致持續(xù)的問(wèn)題。
SQL架構(gòu) vs NoSQL去架構(gòu)
在一個(gè)SQL數(shù)據(jù)庫(kù)中，在你確定表和字段類型這些架構(gòu)之前是無(wú)法添加數(shù)據(jù)的。SQL架構(gòu)還可能包括其他的信息：
- primary keys: 主鍵，就像ISBN一樣標(biāo)示了唯一的一條記錄
- indexs: 索引，經(jīng)常被查詢的字段會(huì)被加上索引來(lái)提高檢索速度
- relationships: 關(guān)系，數(shù)據(jù)字段之間的邏輯聯(lián)系
- 諸如存儲(chǔ)過(guò)程和觸發(fā)器這樣的機(jī)制
你的數(shù)據(jù)架構(gòu)一定要在實(shí)現(xiàn)任何操作數(shù)據(jù)的應(yīng)用邏輯之前被設(shè)計(jì)和實(shí)現(xiàn)出來(lái)。盡管之后再修改是可行的，但是大量的變更會(huì)非常復(fù)雜。
在NoSQL數(shù)據(jù)庫(kù)中，數(shù)據(jù)可以被非常靈活的添加。并不需要事先進(jìn)行字段設(shè)計(jì)和表的設(shè)計(jì)。比如說(shuō)，在MongoDB中，下面的命令會(huì)在book表中創(chuàng)建一條新的記錄，如果book表不存在，那它也會(huì)被同時(shí)創(chuàng)建：
db.book.insert(
ISBN: 9780994182654,
title: "Jump Start Git",
author: "Shaumik Daityari",
format: "ebook",
price: 29.00
);
(MongoDB會(huì)自動(dòng)在表中添加一條唯一的_id字段，隨后你也可以對(duì)索引進(jìn)行定義。)
一個(gè)NoSQL數(shù)據(jù)庫(kù)可能更適合初始數(shù)據(jù)形式很難確定的項(xiàng)目中。但這并不意味著，你可以因此而偷懶：在項(xiàng)目開始的時(shí)候忽視設(shè)計(jì)正確的數(shù)據(jù)表，可能會(huì)在之后引入問(wèn)題。
SQL 中心化 vs NoSQL去中心化
假定我們需要往book數(shù)據(jù)庫(kù)中添加出版社信息。在SQL數(shù)據(jù)庫(kù)中，一個(gè)出版社會(huì)包含多個(gè)標(biāo)題，我們創(chuàng)建了一張新的publisher表：
| id | name | country | |
|---|---|---|---|
| SP001 | SitePoint | Australia | feedback@sitepoint.com |
我們可以在book表里面添加一個(gè)publisher_id字段，來(lái)作為publisher.id的外鍵。
| ISBN | title | author | format | price | publisher_id |
|---|---|---|---|---|---|
| 9780992461225 | JavaScript: Novice to Ninja | Darren Jones | ebook | 29.00 | SP001 |
| 9780994182654 | Jump Start Git | Shaumik Daityari | ebook | 29.00 | SP001 |
這使得數(shù)據(jù)冗余被最小化，我們不必為每本書重復(fù)出版社的信息--只需要?jiǎng)?chuàng)建外鍵就行了。這種技術(shù)被稱為中心化，而且也確實(shí)很有益處。我們可以在不用修改book的數(shù)據(jù)的前提下更新出版社信息。
在NoSQL中我們也可以使用中心化的技術(shù)。看一下在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.com"
}
然而這有的時(shí)候卻并不實(shí)際。更希望的是能夠把數(shù)據(jù)去中心化，對(duì)每一個(gè)book重復(fù)冗余的publisher.
{
ISBN: 9780992461225,
title: "JavaScript: Novice to Ninja",
author: "Darren Jones",
format: "ebook",
price: 29.00,
publisher:
{
name: "SitePoint",
country: "Australia",
email: "feedback@sitepoint.com"
}
}
這會(huì)使我們查詢的更快，但是再多條記錄中更新publisher信息，會(huì)非常的慢。
SQL關(guān)系型的JOIN vs NoSQL
SQL查詢提供了強(qiáng)勁的JOIN語(yǔ)法。我們可以使用一條SQL語(yǔ)句在多個(gè)數(shù)據(jù)表中獲取關(guān)系數(shù)據(jù)庫(kù)。舉例來(lái)說(shuō):
SELECT book.title, book.author, publisher.nameFROM bookLEFT JOIN book.publisher_id ON publisher.id;
這個(gè)語(yǔ)句會(huì)返回所有的書的標(biāo)題，作者以及相關(guān)的出版人姓名。（假設(shè)出版人姓名存在）
NoSQL沒(méi)有相對(duì)應(yīng)的JOIN，這可能對(duì)那些熟練使用SQL的人非常不習(xí)慣。如果我們使用中心化的NoSQL集合，那我們需要拉取所有的book文檔，再獲取所有的publisher文檔，再手動(dòng)的通過(guò)程序邏輯來(lái)把兩者聯(lián)系起來(lái)。這也是為什么對(duì)NoSQL往往使用去中心化的方式很有必要。
SQL vs NoSQL 數(shù)據(jù)完整性
大部分的SQL數(shù)據(jù)庫(kù)允許你通過(guò)外鍵限制的方式來(lái)強(qiáng)制的保證數(shù)據(jù)完整性。（除非你還在使用MySQL中得陳舊 不再被維護(hù)的MyISAM引擎）我們的book數(shù)據(jù)表能夠：
- 保證所有的book數(shù)據(jù)能夠有一個(gè)合法的對(duì)應(yīng)在pubilisher表中得publisher_id
- 如果有book數(shù)據(jù)引用了publisher信息，那么這條數(shù)據(jù)不能被刪除
這種模式強(qiáng)制了數(shù)據(jù)庫(kù)應(yīng)該遵循的規(guī)范。對(duì)于開發(fā)者或者用戶而言，無(wú)法在可能引入孤兒數(shù)據(jù)或非法數(shù)據(jù)的情況下，對(duì)數(shù)據(jù)條目進(jìn)行編輯或刪除。但是在NoSQL中卻沒(méi)有類似的數(shù)據(jù)完整性保證。你可以不管其他的文檔，只存儲(chǔ)你想要存儲(chǔ)的內(nèi)容。理想的情況下，一個(gè)數(shù)據(jù)條目應(yīng)該成為關(guān)于一個(gè)事物的唯一信息來(lái)源。
SQL vs NoSQL 事務(wù)
在SQL數(shù)據(jù)庫(kù)中，兩條或多條更新語(yǔ)句能夠在一個(gè)事務(wù)（保證成功或失敗回滾的機(jī)制）中被同時(shí)執(zhí)行。舉例來(lái)說(shuō)，假設(shè)book數(shù)據(jù)庫(kù)包含訂單和庫(kù)存兩張表。當(dāng)一本書被訂購(gòu)的時(shí)候，我們需要往訂單表添加一條數(shù)據(jù)，然后在庫(kù)存表中將庫(kù)存字段減一。如果我們把這兩條更新語(yǔ)句獨(dú)立執(zhí)行，一條可能失敗，另一條可能成功。因此會(huì)造成數(shù)據(jù)的不同步。而把他們通過(guò)事務(wù)的方式執(zhí)行，就能保證一起成功或一起失敗。
在NoSQL數(shù)據(jù)庫(kù)中，對(duì)單個(gè)文檔的修改是原子的。也就是說(shuō)，如果你在文檔中更新三個(gè)字段，那么要么三個(gè)字段同時(shí)更新，要么都不變。但是對(duì)于多條文檔的更新而言卻沒(méi)有事務(wù)。不過(guò)有一個(gè)類事務(wù)的選項(xiàng)（http://docs.mongodb.org/manual/core/write-operations-atomicity/）。不過(guò)在寫這篇文章的時(shí)候，這些還都需要你在代碼里自行處理。
SQL vs NoSQL CRUD 語(yǔ)法
創(chuàng)建、讀取、更新和刪除數(shù)據(jù)是所有數(shù)據(jù)庫(kù)系統(tǒng)的基礎(chǔ)。本質(zhì)上來(lái)說(shuō)：
- SQL是輕量級(jí)的解釋性語(yǔ)言。語(yǔ)法強(qiáng)大，并且已經(jīng)成為了國(guó)際標(biāo)準(zhǔn)。盡管大多數(shù)系統(tǒng)實(shí)現(xiàn)語(yǔ)法的時(shí)候略有不同。
- NoSQL數(shù)據(jù)庫(kù)使用帶json參數(shù)的類javascript語(yǔ)言一樣的查詢?；镜牟僮鞅容^簡(jiǎn)單，但是對(duì)于更復(fù)雜的查詢來(lái)說(shuō)，嵌套的JSON會(huì)非常的繁復(fù)。
一個(gè)快速的對(duì)比：
| SQL | NoSQL |
|---|---|
| SP001 | SitePoint |
| 插入一條book記錄 | |
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"}); |
| 更新一條book記錄 | |
UPDATE bookSET price = 19.99WHERE ISBN = '9780992461256' |
db.book.update( { ISBN: '9780992461256' }, { $set: { price: 19.99 } }); |
| 返回所有$10以上的書的標(biāo)題 | |
SELECT title FROM bookWHERE price > 10; |
db.book.find( { price: { >: 10 } }, { _id: 0, title: 1 });第二個(gè)JSON對(duì)象就是所謂的projection: 它設(shè)置了哪些字段要被返回 (_id字段是被默認(rèn)返回的，所以需要覆蓋它). |
| 計(jì)算所有SitePoint網(wǎng)站的書的數(shù)量 | |
SELECT COUNT(1) FROM bookWHERE publisher_id = 'SP001'; |
db.book.count({ "publisher.name": "SitePoint"});這條語(yǔ)句假定使用了NoSQL的去中心化設(shè)計(jì) |
| 返回book的格式類型的數(shù)量 | |
SELECT format, COUNT(1) AS `total`FROM bookGROUP BY format; |
db.book.aggregate([ { $group: { _id: "$format", total: { $sum: 1 } } }]);這就是所謂的聚合：一個(gè)新的文檔集合從原始的文檔集合計(jì)算出來(lái)。 |
| 刪除所有的SitePoint書 | |
DELETE FROM bookWHERE publisher_id = 'SP001'; |
db.book.remove({ "publisher.name": "SitePoint"}); |
SQL vs NoSQL 性能表現(xiàn)
或許這是最有爭(zhēng)議性的比較。NoSQL通常被認(rèn)為勢(shì)必SQL更快的。這并不奇怪。NoSQL更簡(jiǎn)單的去中心化存儲(chǔ)允許你在單詞請(qǐng)求中獲取一個(gè)條目的所有信息。因此并不需要相關(guān)的JOIN或復(fù)雜的SQL查詢。
也就是說(shuō)，你的項(xiàng)目設(shè)計(jì)和數(shù)據(jù)庫(kù)設(shè)計(jì)的影響很大。一個(gè)被設(shè)計(jì)的很好的SQL數(shù)據(jù)庫(kù)肯定比設(shè)計(jì)的很差的NoSQL數(shù)據(jù)庫(kù)性能好很多，當(dāng)然反之亦然。
SQL vs NoSQL 擴(kuò)容
隨著你數(shù)據(jù)的增加，你可能會(huì)覺得有必要把負(fù)載分布到多臺(tái)服務(wù)器。對(duì)于基于SQL的系統(tǒng)來(lái)說(shuō)，這有時(shí)候沒(méi)那么容易。你如何分配相關(guān)的數(shù)據(jù)呢？集群化可能是最簡(jiǎn)單的選項(xiàng)；多個(gè)服務(wù)器訪問(wèn)相同的中心化存儲(chǔ) -- 但是即使這樣也會(huì)有挑戰(zhàn)。
NoSQL簡(jiǎn)單地?cái)?shù)據(jù)模型會(huì)使得擴(kuò)容簡(jiǎn)單一些，很多NoSQL數(shù)據(jù)庫(kù)一開始就自建了擴(kuò)容的功能。不過(guò)當(dāng)你遇到實(shí)際問(wèn)題的時(shí)候，還是最好尋求專家的建議。
SQL vs NoSQL 實(shí)用性
最終，來(lái)考慮下安全和系統(tǒng)的問(wèn)題。最流行的NoSQL數(shù)據(jù)庫(kù)已經(jīng)有幾年了。不過(guò)它們相比于成熟的SQL產(chǎn)品，問(wèn)題還是較多。不過(guò)大多數(shù)被報(bào)告的問(wèn)題，還是因?yàn)橐粋€(gè)原因：知識(shí)不足.
開發(fā)者和系統(tǒng)管理者對(duì)新的數(shù)據(jù)庫(kù)系統(tǒng)經(jīng)驗(yàn)不足，因此不免會(huì)犯錯(cuò)誤。如果因?yàn)镹oSQL比較新鮮或者因?yàn)槟阆氡苊庾罱K必會(huì)發(fā)生的范式設(shè)計(jì)而使用它，那么之后你很可能會(huì)遇到問(wèn)題。
SQL vs NoSQL 總結(jié)
SQL和NoSQL數(shù)據(jù)庫(kù)用不同的方式做著同樣的事情。在剛開始選擇一種，之后在進(jìn)行切換時(shí)完全可行的，但是預(yù)先設(shè)計(jì)肯定會(huì)節(jié)省時(shí)間和金錢。
適用于SQL的項(xiàng)目：
- 可以被預(yù)先確定的邏輯相關(guān)的離散數(shù)據(jù)
- 數(shù)據(jù)完整性是必須的
- 需要具有豐富開發(fā)者經(jīng)驗(yàn)和支持的標(biāo)準(zhǔn)技術(shù)的項(xiàng)目
適用于NoSQL的項(xiàng)目:
- 非關(guān)系型的、模糊的或是不斷演進(jìn)的數(shù)據(jù)存儲(chǔ)需求
- 簡(jiǎn)單、寬松的項(xiàng)目目標(biāo)，能夠快速的開始編程
- 速度和可擴(kuò)展性很有必要
在我們的書店的例子中，一個(gè)SQL數(shù)據(jù)庫(kù)看起來(lái)是更加實(shí)際的選擇。尤其是當(dāng)我們遇到要求嚴(yán)格的事務(wù)支持的電子商務(wù)場(chǎng)景的時(shí)候。在下一篇文章中，我們會(huì)討論更多的項(xiàng)目場(chǎng)景，以及決定到底SQL或是NoSQL數(shù)據(jù)庫(kù)是個(gè)更好的選擇。
