SQL作為主要的資料儲存方式已經超過40年，並且經歷了至少兩個指數擴張期：20世紀90年代Web應用程式崛起之後，以及在過去十年中由於移動裝置爆炸引起的擴張。 因此，越來越小的公司開始發現使用資料庫的好處，而像Google這樣的網際網路巨頭則已經將資料單位上升到PB或甚至EB。

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

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

SQL

SQL是關係型資料庫管理系統（RDBMS），顧名思義，它是圍繞關係代數和元組關係演算構建的。 70年代以來，它一直是主要的資料庫解決方案，只是最近才有了其他產品的空間。 不管有些人說什麼，這意味著它一直能出色地執行廣泛的任務。 其主要優點如下：

• 不同的角色（開發者，使用者，資料庫管理員）使用相同的語言。
• 不同的RDBMS使用統一標準的語言。
• SQL使用一種高階的非結構化查詢語言。.
• 它堅持 ACID 準則 (原子性，一致性，隔離性，永續性),，這些準則保證了資料庫尤其是每個事務的穩定性，安全性和可預測性。

如你所見，許多SQL的好處來源於它的統一性，舒適性和易用性。 即使你只有非常有限的SQL知識（或完全沒有，如果需要），你可以在像 

然而，它的缺點使得它非常不適合某些型別的專案。 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似乎是明智的選擇; 等等。