何時該用SQL，何時該用NoSQL

有些人做架構決策的時候純粹是基于誰的聲音大：

@xeraa @lukaseder 不，我們最重要的架構決策是基于 #tweets. 這是一個面向Twitter的體系結構。

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

然而對其他大多數人而言，決策并不是這么簡單。例如：什么時候我們應該啟用NoSQL存儲系統來代替關系型數據庫管理系統（RDBMS）？

關系型數據庫（RDBMS）能夠適應所有情況

這個問題很明顯，假設你開始就使用關系型數據庫（RDBMS)，這種傳統的數據庫系統能夠解決任何問題且不容易被取代。這意味著什么？簡單的舉例：

關系型數據庫（RDBMS）一直被使用，所以他們和”新來者“相比在市場上有巨大的優勢， “新來者”缺少優秀的工具，如社區、支持也不夠成熟。

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

有人會這么說，有時候你確實碰到一個小問題。 例如， 一個圖形數據庫的問題。然而事實上，圖表和你在關系模型中所標識的東西沒有什么根本性的不同。它很容易用多到多的關系表來模擬一個圖。

這些同樣使用于數據庫中的XML/JSON(別忘記， JSON就是XML，但比XML少一些語法和屬性，所以它更棒)。有時候，您需要在數據庫中的層次結構中存儲文檔的結構（層次結構數據）而不是規范他們。當然你也可以先規范文檔，但可能會做很大的無用功。

大多數現代關系型數據庫提供XML/JSON數據結構來存儲（以及更重要的查詢）數據，包括PostgreSQL、Oracle、DB2、SQL Server等。

那么，我們什么時候決定切換？

作為開發人員，我們傾向于能夠快速的切換。例如，當我們處理圖形時，我們喜歡用Neo4j， 因為它具有不起的數字查詢語言。 當我們使用JSON時，我們喜歡用Couchbase， 因為它實現了有趣的N1QL查詢語言。這兩種語言都深受SQL查詢語言影響，在我看來我們的供應商會給我們提供明智的選擇（不會像MongoDB基于JSON查詢語言），終究原因，SQL語言乃是由最強大和最流行的4GL 曾經創造的。

但是作為開發人員，我們不應該輕率的做出決定。 首先，雖然這些專業的數據庫看起來像是更好的選擇，但是運營團隊需要增加額外的維護成本、監控、補丁以及生產系統的額外調整。這在關系型數據庫中真實的存在，最近的一個突出的例子是Uber從PostgreSQL 切換回MySQL：

然而唯一令人遺憾的是他們切換方式和以前相反，這點請注意。事實上你的團隊總是喜歡使用相同的數據庫有很多的原因，即使是這些數據庫團隊開發許可很貴，在很多案例里更貴：

從事額外的許可和/或合同需要新數據庫供應商提供技術支持.

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

維護兩個數據倉庫，并能維持數據同步的成本。

最終，有一個臨界值：

@gareth @xeraa 一般情況下，都有一個臨界值，沒到臨界點，可以堅持使用關系型數據庫（RDBMS），在某種程度上就要開始考慮同時使用兩種數據庫或者完全遷移到另一個上。

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

在數據庫中使用JSON，這很簡單：

偶爾使用JSON存儲：堅持使用關系型數據庫（RDBMS）。

一切以JSON為主：可以考慮不用關系型數據庫(RDBMS）。

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

如果你只有一點樹形/圖形遍歷需要計算（例如，一個簡單的菜單結構），就無需涉及關系型數據庫。如果圖形存儲是您的主要業務，那么關系型數據庫可能不是一個好的選擇。

結論

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

關系型數據庫仍然是處理各種數據問題的最好的選擇。 只有當你存儲超過一定閥值（或者你可以預見到要這么做），那是你應該去尋找替代品來替代它。因為當你去尋找一個新的(JSON，圖形等）來改變的時候，要浪費你很多的時間回到你“正?！钡年P系業務里去。