SQL、NoSQL 和 NewSQL，長江後浪推進浪！

SQL作為主要的資料存儲方式已經超過40年，并且經曆了至少兩個指數擴張期：20世紀90年代Web應用程式崛起之後，以及在過去十年中由于移動裝置爆炸引起的擴張。

是以，越來越小的公司開始發現使用資料庫的好處，而像Google這樣的網際網路巨頭則已經将資料機關上升到PB或甚至EB。

在SQL 的發展過程中，産生了許多疊代産品，其中最重要的是SQL，NoSQL和NewSQL — 它們一起負責絕大部分的資料庫市場。

是以，如果你要選擇一個資料庫工具，你應該選擇哪一個？其實，沒有明确的答案。不同的人和公司選擇不同，這更多地取決于他們對每個特定項目的偏好和相對優勢，而不是其中一個對其他所有的直接優勢。那麼，這些優點和缺點是什麼？讓我們來看一下。

SQL

SQL是關系型資料庫管理系統（RDBMS），顧名思義，它是圍繞關系代數和元組關系演算建構的。

70年代以來，它一直是主要的資料庫解決方案，隻是最近才有了其他産品的空間。不管有些人說什麼，這意味着它一直能出色地執行廣泛的任務。其主要優點如下：

不同的角色（開發者，使用者，資料庫管理者）使用相同的語言。

不同的RDBMS使用統一标準的語言。

SQL使用一種進階的非結構化查詢語言。

它堅持 ACID 準則 (原子性，一緻性，隔離性，持久性),，這些準則保證了資料庫尤其是每個事務的穩定性，安全性和可預測性。

如你所見，許多SQL的好處來源于它的統一性，舒适性和易用性。即使你隻有非常有限的SQL知識（或完全沒有，如果需要），你可以在像 online SQL Query Builder 這樣的特殊工具幫助下使用它。

然而，它的缺點使得它非常不适合某些類型的項目。SQL的主要問題是它難以擴充，因為它的性能随着資料庫的變大而快速下降。分布式也是有問題的。

NoSQL和NewSQL出現的原因之一是，以前的RDBMS的設計不能滿足現代資料庫每秒處理的事務數量。像亞馬遜或阿裡巴巴等需要處理驚人資料量的巨頭，以前的RDBMS會在幾分鐘内出現問題。

NoSQL (Not Only SQL)

NoSQL越來越受歡迎，其中最重要的實作是Apache Cassandra，MongoDB等産品。它主要用于解決SQL的可擴充性問題。是以，它是沒有架構的并且建立在分布式系統上，這使得它易于擴充和分片。

然而，這些好處是以放寬ACID原則為代價的：NoSQL采取最終一緻性原則，而不是所有四個參數在每個事務中保持一緻。這意味着如果在特定時間段内沒有特定資料項的更新，則最終對其所有的通路都将傳回最後更新的值。這就是這樣的系統通常被描述為提供基本保證的原因（基本可用，軟狀态，最終一緻性） — 而不是ACID。

雖然這個方案極大地增加了可用時間和伸縮性,它也會導緻資料丢失----這個問題的嚴重程度取決于資料庫伺服器的支援情況和應用代碼品質.在某些情況下,這個問題十分嚴重.

另一個NoSQL出現的問題是現在有很多類型的NoSQL系統,但它們之間卻幾乎沒有一緻性.諸如靈活性,性能,複雜性,伸縮性等等特性在不同系統間差别巨大,這使得甚至是專家在他們之間都很難選擇.不過,當你根據項目特點作出了合适的選擇,NoSQL可以在不顯著丢失穩定性的情況下提供一個遠比SQL系統更高效的解決方案.

NewSQL

NewSQL是一種相對較新的形式，旨在使用現有的程式設計語言和以前不可用的技術來結合SQL和NoSQL中最好的部分。NewSQL目标是将SQL的ACID保證與NoSQL的可擴充性和高性能相結合。

顯然，因為結合了過去僅單獨存在的優點，NewSQL看起來很有前途; 或許，在未來的某個時候，它将成為大多數人使用的标準。不幸的是，目前大多數NewSQL資料庫都是專有軟體或僅适用于特定場景，這顯然限制了新技術的普及和應用。

除此之外，NewSQL在每個方面比較均勻，每個解決方案都有自己的缺點和優勢。

例如，SAP HANA可以輕松處理低到中等的事務性工作負載，但不使用本機叢集，MemSQL對于叢集分析很有用，但在ACID事務上表現出較差的一緻性，等等。是以，在這些解決方案變得真正普及之前，可能還需要一段時間。

結論

圍繞SQL有許多謬見和誤解：例如，SQL已過時，應該盡可能替換為NoSQL或New SQL。當然，這不是真的。目前，在三種基本替代方案中沒有明确的上司者 - 每一種都有更适合的項目，而在其他情況下不太适合（或完全不适合）。

是以，沒有普遍的理想選擇。例如，如果你主要考慮資料庫應始終可用于接受新的内容，則應考慮最終一緻性解決方案，如Cassandra或Riak。如果你追求高速緩存SQL，新的緩存資料庫比如VoltDB似乎是明智的選擇; 等等。