何時(shí)該用SQL，何時(shí)該用NoSQL

有些人做架構(gòu)決策的時(shí)候純粹是基于誰的聲音大：

@xeraa @lukaseder 不，我們最重要的架構(gòu)決策是基于 #tweets. 這是一個(gè)面向Twitter的體系結(jié)構(gòu)。

— 加里斯 維斯特恩 (@gareth) 2016年9月21日

然而對(duì)其他大多數(shù)人而言，決策并不是這么簡(jiǎn)單。例如：什么時(shí)候我們應(yīng)該啟用NoSQL存儲(chǔ)系統(tǒng)來代替關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)（RDBMS）？

關(guān)系型數(shù)據(jù)庫(kù)（RDBMS）能夠適應(yīng)所有情況

這個(gè)問題很明顯，假設(shè)你開始就使用關(guān)系型數(shù)據(jù)庫(kù)（RDBMS)，這種傳統(tǒng)的數(shù)據(jù)庫(kù)系統(tǒng)能夠解決任何問題且不容易被取代。這意味著什么？簡(jiǎn)單的舉例：

關(guān)系型數(shù)據(jù)庫(kù)（RDBMS）一直被使用，所以他們和”新來者“相比在市場(chǎng)上有巨大的優(yōu)勢(shì)， “新來者”缺少優(yōu)秀的工具，如社區(qū)、支持也不夠成熟。

埃德加·弗蘭克·科德的工作對(duì)我們整個(gè)行業(yè)產(chǎn)生的最大影響可能就是，自那以后，幾乎沒有像關(guān)系模型那樣具有革命性的東西了。對(duì)一個(gè)替代型數(shù)據(jù)庫(kù)來說，它很難被普遍使用。意即它們通常被用來解決小問題。

有人會(huì)這么說，有時(shí)候你確實(shí)碰到一個(gè)小問題。 例如， 一個(gè)圖形數(shù)據(jù)庫(kù)的問題。然而事實(shí)上，圖表和你在關(guān)系模型中所標(biāo)識(shí)的東西沒有什么根本性的不同。它很容易用多到多的關(guān)系表來模擬一個(gè)圖。

這些同樣使用于數(shù)據(jù)庫(kù)中的XML/JSON(別忘記， JSON就是XML，但比XML少一些語法和屬性，所以它更棒)。有時(shí)候，您需要在數(shù)據(jù)庫(kù)中的層次結(jié)構(gòu)中存儲(chǔ)文檔的結(jié)構(gòu)（層次結(jié)構(gòu)數(shù)據(jù)）而不是規(guī)范他們。當(dāng)然你也可以先規(guī)范文檔，但可能會(huì)做很大的無用功。

大多數(shù)現(xiàn)代關(guān)系型數(shù)據(jù)庫(kù)提供XML/JSON數(shù)據(jù)結(jié)構(gòu)來存儲(chǔ)（以及更重要的查詢）數(shù)據(jù)，包括PostgreSQL、Oracle、DB2、SQL Server等。

那么，我們什么時(shí)候決定切換？

作為開發(fā)人員，我們傾向于能夠快速的切換。例如，當(dāng)我們處理圖形時(shí)，我們喜歡用Neo4j， 因?yàn)樗哂胁黄鸬臄?shù)字查詢語言。 當(dāng)我們使用JSON時(shí)，我們喜歡用Couchbase， 因?yàn)樗鼘?shí)現(xiàn)了有趣的N1QL查詢語言。這兩種語言都深受SQL查詢語言影響，在我看來我們的供應(yīng)商會(huì)給我們提供明智的選擇（不會(huì)像MongoDB基于JSON查詢語言），終究原因，SQL語言乃是由最強(qiáng)大和最流行的4GL 曾經(jīng)創(chuàng)造的。

但是作為開發(fā)人員，我們不應(yīng)該輕率的做出決定。 首先，雖然這些專業(yè)的數(shù)據(jù)庫(kù)看起來像是更好的選擇，但是運(yùn)營(yíng)團(tuán)隊(duì)需要增加額外的維護(hù)成本、監(jiān)控、補(bǔ)丁以及生產(chǎn)系統(tǒng)的額外調(diào)整。這在關(guān)系型數(shù)據(jù)庫(kù)中真實(shí)的存在，最近的一個(gè)突出的例子是Uber從PostgreSQL 切換回MySQL：

然而唯一令人遺憾的是他們切換方式和以前相反，這點(diǎn)請(qǐng)注意。事實(shí)上你的團(tuán)隊(duì)總是喜歡使用相同的數(shù)據(jù)庫(kù)有很多的原因，即使是這些數(shù)據(jù)庫(kù)團(tuán)隊(duì)開發(fā)許可很貴，在很多案例里更貴：

從事額外的許可和/或合同需要新數(shù)據(jù)庫(kù)供應(yīng)商提供技術(shù)支持.

為了新技術(shù)尋找技能熟練的數(shù)據(jù)庫(kù)管理員（DBA）(能夠勝任新數(shù)據(jù)庫(kù)).

維護(hù)兩個(gè)數(shù)據(jù)倉(cāng)庫(kù)，并能維持?jǐn)?shù)據(jù)同步的成本。

最終，有一個(gè)臨界值：

@gareth @xeraa 一般情況下，都有一個(gè)臨界值，沒到臨界點(diǎn)，可以堅(jiān)持使用關(guān)系型數(shù)據(jù)庫(kù)（RDBMS），在某種程度上就要開始考慮同時(shí)使用兩種數(shù)據(jù)庫(kù)或者完全遷移到另一個(gè)上。

— 盧卡斯埃德爾 (@lukaseder) 2016年9月21日

在數(shù)據(jù)庫(kù)中使用JSON，這很簡(jiǎn)單：

偶爾使用JSON存儲(chǔ)：堅(jiān)持使用關(guān)系型數(shù)據(jù)庫(kù)（RDBMS）。

一切以JSON為主：可以考慮不用關(guān)系型數(shù)據(jù)庫(kù)(RDBMS）。

這個(gè)同樣適用于圖形問題。SQL完全能夠處理圖形和遞歸遍歷。遞歸的計(jì)算子集之和，這是一個(gè)時(shí)髦的聲明：

如果你只有一點(diǎn)樹形/圖形遍歷需要計(jì)算（例如，一個(gè)簡(jiǎn)單的菜單結(jié)構(gòu)），就無需涉及關(guān)系型數(shù)據(jù)庫(kù)。如果圖形存儲(chǔ)是您的主要業(yè)務(wù)，那么關(guān)系型數(shù)據(jù)庫(kù)可能不是一個(gè)好的選擇。

結(jié)論

無論你要解決什么問題，請(qǐng)記?。喝绻阌幸话彦N子，而每一個(gè)問題開始的時(shí)候都可以當(dāng)作釘子。但不要把關(guān)系型數(shù)據(jù)庫(kù)當(dāng)作是把愚蠢的錘子。不要小看它，在2016年它在處理非關(guān)系型小眾的事情上做的非常的好。

關(guān)系型數(shù)據(jù)庫(kù)仍然是處理各種數(shù)據(jù)問題的最好的選擇。 只有當(dāng)你存儲(chǔ)超過一定閥值（或者你可以預(yù)見到要這么做），那是你應(yīng)該去尋找替代品來替代它。因?yàn)楫?dāng)你去尋找一個(gè)新的(JSON，圖形等）來改變的時(shí)候，要浪費(fèi)你很多的時(shí)間回到你“正常”的關(guān)系業(yè)務(wù)里去。