SQL vs NoSQL 沒(méi)有硝煙的戰(zhàn)爭(zhēng)！
聲明：本文譯自SQL vs NoSQL The Differences，如需轉(zhuǎn)載請(qǐng)注明出處。
SQL(結(jié)構(gòu)化查詢(xún)語(yǔ)言)數(shù)據(jù)庫(kù)作為一個(gè)主要的數(shù)據(jù)存儲(chǔ)機(jī)制已經(jīng)超過(guò)40個(gè)年頭了。隨著web應(yīng)用和像MySQL、PostgreSQL和SQLite這些開(kāi)源項(xiàng)的興起，SQL使用量大大增加。
NoSQL數(shù)據(jù)庫(kù)在20世紀(jì)60年代就已經(jīng)出現(xiàn)了，但最近因?yàn)镸ongoDB、CouchDB，Redis和Apache Cassandra等才受到廣泛的關(guān)注。
你會(huì)發(fā)現(xiàn)很多教程都會(huì)解釋如何根據(jù)你的興趣選擇去使用SQL還是NoSQL，但是很少討論為什么應(yīng)該去選擇它。我希望能夠填補(bǔ)這一空白。在這篇文章中，我們將介紹基本的差異。在稍后的后續(xù)的文章中，我們將查看一些典型的場(chǎng)景，并確定***的選擇。
大多數(shù)的例子都適用于目前流行的MySQL SQL和MongoDB NoSQL數(shù)據(jù)庫(kù)系統(tǒng)。其他SQL/NOSQL數(shù)據(jù)庫(kù)都是類(lèi)似的，但會(huì)有細(xì)微的差別和語(yǔ)法特征。
SQL和NoSQL的圣戰(zhàn)
在我們開(kāi)始之前，先糾正一些所謂的神話(huà)…
神話(huà)1：NoSQL將取代SQL
這么說(shuō)就好比說(shuō)船將被車(chē)取代，因?yàn)樗切碌募夹g(shù)。SQL和NoSQL做的是相同的事：數(shù)據(jù)存儲(chǔ)。它們采取的方法不同，這可能回幫組或阻礙你的項(xiàng)目。盡管感覺(jué)技術(shù)更新，并經(jīng)常在最近上頭條，NoSQL不是SQL的替代品——而是一種選擇。
神話(huà)2：NoSQL比SQL更好或更壞
一些項(xiàng)目更適合使用SQL數(shù)據(jù)庫(kù)，一些更適合NoSQL，而一些可以?xún)烧呓惶媸褂?。這邊文章不會(huì)是SitePoint Smackdown，因?yàn)槟悴荒茉谒蟹矫娑紤?yīng)用相同的廣泛性假設(shè)。
神話(huà)3：SQL和NoSQL天壤之別
這不一定是個(gè)事實(shí)。一些SQL數(shù)據(jù)庫(kù)采用NoSQL的特點(diǎn)，反之亦然。選擇可能會(huì)變得越來(lái)越模糊，NewSQL混合數(shù)據(jù)庫(kù)可能會(huì)在將來(lái)提供一些有趣的選擇。
神話(huà)4：語(yǔ)言/框架決定了使用什么樣的數(shù)據(jù)庫(kù)
我們已經(jīng)習(xí)慣了技術(shù)堆，比如——
LAMP: Linux, Apache, MySQL (SQL), PHP
MEAN: MongoDB (NoSQL), Express, Angular, Node.js
.NET, IIS and SQL Server
Java, Apache and Oracle.
有實(shí)踐的、歷史的和商業(yè)的原因來(lái)解釋這些stack的發(fā)展——但不能認(rèn)為它們就是規(guī)則。你可以在你的PHP或.NET項(xiàng)目中使用MongoDB NoSQL數(shù)據(jù)庫(kù)。你可以在Node.js中連接MySQL或者SQL服務(wù)器。你可能沒(méi)有找到很多教程和資源，但是是你的需求決定數(shù)據(jù)庫(kù)的類(lèi)型——而不是所謂的語(yǔ)言。
(有句話(huà)是這么說(shuō)的，不要讓生活有目地為難自己!選擇一個(gè)不尋常的技術(shù)組合或者SQL和NoSQL組合是可行的，但困難的是找到支持和聘請(qǐng)有經(jīng)驗(yàn)的開(kāi)發(fā)者)
有了這樣的想法，我們來(lái)看看主要的差異。
SQL表VS NoSQL文檔
SQL數(shù)據(jù)庫(kù)提供相關(guān)數(shù)據(jù)表的存儲(chǔ)。例如，如果你有一個(gè)網(wǎng)上書(shū)店，圖書(shū)的信息將會(huì)被添加到一個(gè)book的表中：
每一行是一個(gè)不同的記錄。設(shè)計(jì)是剛性的;你不能使用同一個(gè)表來(lái)存儲(chǔ)不同的信息，或者在一個(gè)數(shù)字格式輸入字符。
NoSQL數(shù)據(jù)庫(kù)存儲(chǔ)JSON格式的字段值對(duì)文檔，比如：
{
- ISBN: 9780992461225,
- title: "JavaScript: Novice to Ninja",
- author: "Darren Jones",
- format: "ebook",
- price: 29.00
}
相似的文檔可以存儲(chǔ)于一個(gè)集合里，這類(lèi)似于一個(gè)SQL表。然而你可以存儲(chǔ)任何數(shù)據(jù)在任何文檔里;而NoSQL數(shù)據(jù)庫(kù)永遠(yuǎn)不會(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)建一個(gè)嚴(yán)格的數(shù)據(jù)模板，因此很難犯錯(cuò)誤。NoSQL更加的靈活和寬容，但能夠存儲(chǔ)任何數(shù)據(jù)可能會(huì)導(dǎo)致一致性的問(wèn)題。
SQL模式VS NoSQL無(wú)模式
在一個(gè)SQL數(shù)據(jù)庫(kù)中，除非你在指定模式中定義了表格和字段格式，不然不可能添加數(shù)據(jù)。該模式還可以包含其他的信息，例如——
主鍵——唯一的標(biāo)識(shí)符，如ISBN，適用于單個(gè)記錄。
索引——通常被查詢(xún)的字段，用來(lái)幫助快熟搜索。
關(guān)系——數(shù)據(jù)字段之間的邏輯連接
功能——如觸發(fā)器和存儲(chǔ)過(guò)程
你的數(shù)據(jù)模式必須在任何商業(yè)邏輯可以被開(kāi)發(fā)去處理數(shù)據(jù)前被設(shè)計(jì)出來(lái)并實(shí)現(xiàn)。完成后可以行進(jìn)一些更新，但不能完成大的改變。
在一個(gè)NoSQL數(shù)據(jù)庫(kù)，數(shù)據(jù)可以隨時(shí)隨地被添加。沒(méi)有必要去制定一個(gè)文檔設(shè)計(jì)，甚至集合前端。例如在MongoDB，下面的語(yǔ)句將在新的book集合創(chuàng)建一個(gè)新的文檔，如果這個(gè)文檔之前沒(méi)有被創(chuàng)建過(guò)：
db.book.insert(
- ISBN: 9780994182654,
- title: "Jump Start Git",
- author: "Shaumik Daityari",
- format: "ebook",
- price: 29.00
);
(MongoDB會(huì)給每個(gè)集合內(nèi)的文檔自動(dòng)添加唯一的_id值。你可能任然想要定義索引，如果需要的話(huà)可以稍后進(jìn)行。)
如果一個(gè)項(xiàng)目初始數(shù)據(jù)要求很難去確定，那么NoSQL數(shù)據(jù)庫(kù)可能更加的適合。有句話(huà)說(shuō)，不要為懶散而制造困難：忽略了在項(xiàng)目中設(shè)計(jì)適合的數(shù)據(jù)庫(kù)的重要性將會(huì)在之后導(dǎo)致很多的麻煩。
SQL規(guī)范化VS NoSQL反規(guī)范化
假設(shè)我們要向書(shū)店數(shù)據(jù)庫(kù)中添加出版商信息。一個(gè)單一的出版商可以提供多個(gè)標(biāo)題，在一個(gè)SQL數(shù)據(jù)庫(kù)里，我們創(chuàng)建一個(gè)新的publisher表：
我們接下來(lái)可以增加publisher_id到book表，這個(gè)表是publisher.id引用。
這***限度的減少數(shù)據(jù)的冗余;我們不用重復(fù)每本書(shū)的出版商信息——僅僅只用索引。這種技巧可以稱(chēng)作規(guī)范化，并有實(shí)際的好處。我們只用更新單一的出版商而不用改變整個(gè)book數(shù)據(jù)。
在NoSQL中，我們也可以使用規(guī)范化技巧。在book集中的文檔——
{
- ISBN: 9780992461225,
- title: "JavaScript: Novice to Ninja",
- author: "Darren Jones",
- format: "ebook",
- price: 29.00,
- publisher_id: "SP001"
}
——在一個(gè)出版商集合中引用一個(gè)文檔：
{
- id: "SP001"
- name: "SitePoint",
- country: "Australia",
- email: "feedback@sitepoint.com"
}
然而，這并不總是可行的，原因在下面很明顯。我們可能選擇反規(guī)范化我們的文檔，重復(fù)每本書(shū)的出版商信息：
{
- ISBN: 9780992461225,
- title: "JavaScript: Novice to Ninja",
- author: "Darren Jones",
- format: "ebook",
- price: 29.00,
- publisher: {
- name: "SitePoint",
- country: "Australia",
- email: "feedback@sitepoint.com"
- }
}
這可以加快查詢(xún)的速度，但在多個(gè)記錄中更新出版商信息將會(huì)顯著變慢。
SQL關(guān)系連接VS NoSQL
SQL查詢(xún)提供了一個(gè)強(qiáng)大的JOIN條款。我們可以使用單個(gè)SQL語(yǔ)句獲取不同表中的相關(guān)數(shù)據(jù)。例如：
SELECT book.title, book.author, publisher.name
FROM book
LEFT JOIN book.publisher_id ON publisher.id;
這將返回所有的書(shū)名、作者和相關(guān)出版商名稱(chēng)。
NoSQL沒(méi)有等效的JOIN，有SQL的經(jīng)驗(yàn)的可能會(huì)驚訝. 如果我們使用上述的規(guī)范化集合，我們將需要獲取所有的book文檔，檢索所有的相關(guān)publisher文檔，并手動(dòng)在程序邏輯中連接兩者。這就是反規(guī)范化常常是必不可少的一個(gè)原因。
SQL VS NoSQL數(shù)據(jù)完整性
大多數(shù)SQL數(shù)據(jù)庫(kù)允許你使用外鍵約束去強(qiáng)制性數(shù)據(jù)完整性(除非你仍在使用舊的，在MySQL已不存在的MyISAM存儲(chǔ)引擎)。我們的書(shū)店可以——
確保所有的書(shū)都有一個(gè)有效的publisher_id編碼，這個(gè)編碼在 publisher表中都有匹配的條目
如果一個(gè)或多個(gè)書(shū)被分配給它們，則出版商不能被刪除。
模式強(qiáng)制數(shù)據(jù)庫(kù)遵循這些規(guī)則。開(kāi)發(fā)者或用戶(hù)則不能增加、編輯或者移除可能引起無(wú)效數(shù)據(jù)或孤立的數(shù)據(jù)
相同數(shù)據(jù)完整性選項(xiàng)在NoSQL數(shù)據(jù)庫(kù)中不可用;你可以存儲(chǔ)所有你想存儲(chǔ)的東西。理想情況下，單一文檔將成為項(xiàng)目所有信息的唯一來(lái)源。
SQL VS NoSQL事務(wù)
在SQL數(shù)據(jù)庫(kù)中，兩個(gè)或多個(gè)更新可以在同一個(gè)事務(wù)中執(zhí)行——一個(gè)all-or-nothing的封裝保證成功或失敗。例如，假設(shè)我們的書(shū)店包含了order和stock表。當(dāng)一本書(shū)被訂購(gòu)時(shí)，我們?cè)趏rder表添加一條記錄并減少stock表中的庫(kù)存數(shù)。如果我們分別地執(zhí)行這兩個(gè)更新，一個(gè)可能成功另外一個(gè)會(huì)失敗——因此我們的數(shù)據(jù)會(huì)不同步。在一個(gè)事務(wù)中放置相同更新可以保證同時(shí)成功或失敗。
在NoSQL數(shù)據(jù)庫(kù)中，單個(gè)文檔的修改是微小的。換句話(huà)說(shuō)。如果你正在文檔中更新三個(gè)值，要不三個(gè)值都是成功的，要不三個(gè)值都保持不變。然而，卻沒(méi)有相等的事務(wù)去更新不同的文檔。有類(lèi)似的選項(xiàng)，但是，在寫(xiě)這些的時(shí)候，必須在你的代碼中手動(dòng)處理。
SQL VS NoSQL CRUD 語(yǔ)法
創(chuàng)建、讀取更新和刪除數(shù)據(jù)是上所有數(shù)據(jù)庫(kù)系統(tǒng)的基礎(chǔ)。本質(zhì)上——
SQL是一個(gè)輕量級(jí)的陳述性語(yǔ)言。這是非常強(qiáng)大的，并已經(jīng)成為一個(gè)國(guó)際化的標(biāo)準(zhǔn)，雖然大多數(shù)系統(tǒng)實(shí)現(xiàn)略有不同的語(yǔ)法。
NoSQL數(shù)據(jù)庫(kù)使用與JSON類(lèi)似 JavaScripty-looking查詢(xún)!基本操作很簡(jiǎn)單，但嵌套的JSON對(duì)于復(fù)雜的查詢(xún)會(huì)變得更加的繁雜。
簡(jiǎn)單的比較：
SQL VS NoSQL性能
這也許是最有爭(zhēng)議的比較，NoSQL經(jīng)常被認(rèn)為比SQL更快。這并不奇怪;NoSQL更加簡(jiǎn)單的反規(guī)范化存儲(chǔ)允許你使用單個(gè)請(qǐng)求去在所有信息中查詢(xún)一個(gè)特定的項(xiàng)目。不需要使用相關(guān)的JSON或復(fù)雜的SQL查詢(xún)。
也就是說(shuō)，你的項(xiàng)目設(shè)計(jì)和數(shù)據(jù)要求將產(chǎn)生***的影響。一個(gè)良好設(shè)計(jì)的SQL數(shù)據(jù)庫(kù)必然會(huì)比一個(gè)設(shè)計(jì)很差的NoSQL表現(xiàn)要好，反之亦然。
SQL VS NoSQL縮放
隨著你的數(shù)據(jù)的增長(zhǎng)，你可能會(huì)發(fā)現(xiàn)在多個(gè)服務(wù)器之前分配負(fù)載是很必要的。這對(duì)于SQL為基礎(chǔ)的系統(tǒng)可能很棘手。如何分配相關(guān)的數(shù)據(jù)呢?聚類(lèi)可能是最簡(jiǎn)單的選擇;多個(gè)服務(wù)器訪(fǎng)問(wèn)相同的中央存儲(chǔ)——但即使這樣也會(huì)存在挑戰(zhàn)。
NoSQL的簡(jiǎn)單數(shù)據(jù)模型可以讓這個(gè)過(guò)程容易很多，許多一開(kāi)始就建立了縮放功能。這是一個(gè)概論性的，所以如果碰到這種情況請(qǐng)去咨詢(xún)專(zhuān)家意見(jiàn)。
SQL VS NoSQL實(shí)用性
***，我們來(lái)考慮安全和系統(tǒng)的問(wèn)題。最有名的NoSQL數(shù)據(jù)庫(kù)才存在了幾年;他們比更成熟的SQL產(chǎn)品更易出現(xiàn)問(wèn)題。許多的問(wèn)題已經(jīng)被曝光，但大部分還是歸結(jié)為一個(gè)問(wèn)題：知識(shí)。
開(kāi)發(fā)人員和系統(tǒng)管理員對(duì)于新的數(shù)據(jù)庫(kù)系統(tǒng)有較少的經(jīng)驗(yàn)，所以錯(cuò)誤常常發(fā)生。選擇NoSQL是因?yàn)樗杏X(jué)會(huì)更快，或因?yàn)槟阆肴ケ苊饧軜?gòu)設(shè)計(jì)而導(dǎo)致之后的問(wèn)題。
SQL VS NoSQL的總結(jié)
SQL和NoSQL數(shù)據(jù)庫(kù)用不同的方式做同樣的事情。從一個(gè)切換到另一個(gè)是可能的，但是一點(diǎn)計(jì)劃可以節(jié)約很多的時(shí)間和金錢(qián)。
更適合SQL的項(xiàng)目：
可預(yù)先確定的邏輯關(guān)系離散數(shù)據(jù)的要求
數(shù)據(jù)完整性是必不可少的
有良好開(kāi)發(fā)經(jīng)驗(yàn)和支持的標(biāo)準(zhǔn)基礎(chǔ)技術(shù)
更適合NoSQL的項(xiàng)目：
不相關(guān)的、不確定或不斷變化的數(shù)據(jù)要求
更加簡(jiǎn)單寬松的項(xiàng)目對(duì)象，可以立即編碼
速度和擴(kuò)展性是必要的
在這個(gè)書(shū)店例子的背景下，SQL數(shù)據(jù)庫(kù)是最實(shí)用的選項(xiàng)——特別是當(dāng)我們引進(jìn)電商設(shè)施，需要強(qiáng)大的事務(wù)支持。
