SQL vs NoSQL：正確數據庫的艱難選擇（以及正確的方法）

Photo by Kaleidico on Unsplash

數據是信息系統的核心。 組織的效率和運營是任何公司的主要關注點。 在大數據時代，業務專業知識和對現有技術解決方案的理解至關重要。 技術領域正在迅速發展，公司必須同時繼續評估和選擇能夠滿足其未來需求並支持其增長的數據庫。

關係數據庫已經用於存儲數據數十年了，它們仍然是許多用例的可行解決方案。 為了響應關係數據庫技術的侷限性，創建了NoSQL數據庫。 與關係數據庫相比，NoSQL數據庫具有更高的可伸縮性和更高的性能，並且它們的數據模型糾正了關係模型的一些弱點。 在本文中，我將嘗試闡明從RDBMS遷移到NoSQL的挑戰，好處和過程。

通常，NoSQL數據庫旨在解決大數據環境中批量，多源和多格式的數據處理問題。 他們提供了一種新方法來滿足容量要求和新型數據。

如今，NoSQL數據庫的數量變得越來越重要。 必須瞭解它們之間的差異，以便為正確的應用採用正確的技術。

一.引言

-SQL：

SQL是結構化查詢語言的縮寫。 所有必須在大型關係數據庫（DBMS）中快速搜索信息的IT工程師早就知道了。 由於SQL是結構化程度最高，最快的數據庫組織和查詢設備之一，因此如今已被廣泛使用。 它有不同的名稱，表明存在各種改編，例如Oracle的MySQL和Microsoft的SQL Server。 另外，由於SQL的預定義結構和架構，SQL是許多公司最推薦的選擇。

-NoSQL：

首字母縮寫詞" NoSQL"具有兩種目前尚不明確的解釋：

· 對某些人來說是" No SQL"，也就是說，使用了另一種不同於SQL的查詢語言。

· 在其他情況下，它不僅是" SQL"，也就是將SQL與其他信息檢索工具結合使用。

因此，該術語與技術特性以及在2010年代左右出現的具有歷史意義的DBMS一樣重要。 導致發明NoSQL的主要問題是解決以下事實：網站上的同一數據庫可以在全球範圍內同時被數百萬的用戶使用。 像亞馬遜這樣的公司的典型問題...

因此，我們試圖用NoSQL來實現的是降低查詢語言的複雜性並簡化數據庫的體系結構。 這些數據庫由面向列，面向文檔，面向圖和鍵/值的數據組成。 NoSQL系列由各種產品組成，每個產品都有一套獨特的功能。

-主要區別：

· SQL數據庫具有預定義的架構，而NoSQL數據庫具有用於非結構化數據的動態架構。

· SQL數據庫可垂直擴展，而NoSQL數據庫可水平擴展。 通過增加CPU，RAM或SSD等硬件的功能來擴展SQL數據庫。 通過增加數據服務器的數量以減少負載來擴展NoSQL數據庫。 這就像在同一棟建築物中添加更多樓層，而不是在附近添加更多建築物。

· SQL數據庫是基於表的數據庫，而NoSQL數據庫是基於鍵值對的數據庫。 這意味著SQL數據庫以表的形式表示數據，該表由表示數據的一定數量的行組成，而NoSQL數據庫是鍵值對，文檔，圖形數據庫等的集合。

· SQL數據庫使用SQL（結構化查詢語言）來定義和操作數據，這非常強大。 在NoSQL數據庫中，查詢集中於文檔收集。 有時也稱為UnQL（非結構化查詢語言）。 在不同的現有NoSQL數據庫之間，使用UnQL的語法差異很大。

二.歷史要素

Source : Photo by National Cancer Institute on Unsplash

關係DBMS的歷史統治

· 1970年代創建的關係DBMS逐漸強加於人，直到它在1990年代初成為廣泛使用的數據庫範例。

· 在1990年代，物流公司的許多銷售人員開始使用它來存儲他們的業務數據。 實際上，它們既沒有鼠標也沒有用戶界面來搜索存儲在服務器上的某些信息，這些服務器通常通過專用線路相距很遠且相互連接：它們用於通過鍵盤輸入SQL命令，並且能夠檢索有關特定服務器可用性的相關信息。 產品或原材料在幾秒鐘內。

· 出現了其他幾種數據庫模型，例如面向對象的DBMS，分層的DBMS，對象關係的DBMS，但是它們的使用受到很大限制。

· 從2000年代開始，隨著大型互聯網公司（Amazon，eBay，Google…）的發展，出現了大量的非結構化數據，並且其增長速度遠遠超過結構化數據，因為它不再適合RDBMS的關係模式。 集群計算也得到了發展，因此關係模型的統治地位受到質疑，因為它對這些新實踐有一些禁止性的限制。

NoSQL模型的先驅

大型Web公司必須處理大量數據，這就是為什麼它們首先面對傳統關係DBMS的固有侷限性。 這些系統基於對ACID屬性（原子性，一致性，隔離性，耐用性）的嚴格應用，並且通常設計為在單臺計算機上運行，因此很快就帶來了可伸縮性問題。

為了滿足這些限制，這些公司已經開始開發自己的數據庫管理系統，該系統可以在分佈式硬件體系結構上運行並且可以處理大量數據：

· Google（BigTable），

· 亞馬遜（DynamoDB），

· 領英（Voldemort），

· Facebook（先是Cassandra，然後是HBase），

通過簡單地增加服務器數量就可以保持良好的性能，這是一個合理的解決方案，可以降低成本，尤其是當收入隨著活動的發展而增長時。

三.流行的數據庫

有幾種流行的數據庫系統可用。 既免費又免費。 為了為您或您的組織選擇正確的管理系統，重要的是要了解市場上存在的內容。 查看下面5個流行的SQL和NoSQL數據庫列表。

-SQL數據庫產品：

1- MySql：

它是免費提供的，甚至為免費的數據庫引擎提供了很多功能。

2-Oracle：

Oracle數據庫管理工具具有最新的創新和功能，非常強大。

3- Postgres：

該數據庫管理引擎具有可擴展性，並可以通過各種預定義功能處理TB級數據。

4- SQL Server：

它非常快速且穩定。 它與其他Microsoft產品非常兼容。

5- SQLite：

SQLite數據庫非常輕便，並且設置迅速，還可以用於將數據存儲在智能手機應用程序（iPhone或Android）上的真實數據庫中。

-NoSQL數據庫產品：

1- MongoDB：

MongoDB是一個靈活/可靠的數據庫，它將帶您進入NoSQL世界。 它的管理和維護非常簡單快捷。

2- Redis：

它非常簡單易用。 您可以下載Redis並在接下來的五分鐘內開始使用它。

3-Cassandra：

Cassandra提供的線性可擴展性，允許通過簡單地添加/刪除服務器來輕鬆擴展/縮小集群。

4- Hbase：

它是面向列的數據庫，可幫助提高查詢性能和聚合。

5-CouchDb：

憑藉其存儲序列化（JSON格式）非結構化數據的能力及其Restful HTTP API，CouchDB非常適合Web和移動應用程序。

四. NoSQL數據庫設計

NoSQL DBMS的主要特徵是允許處理大量數據並允許水平擴展。 但是，大多數公司今天面臨的困難是針對最合適的技術，以應對他們的問題和應用。

解決這一難題始於對NoSQL數據庫的不同類型的深入瞭解。 有一個普遍的神話，就是所有NoSQL數據庫的創建都是一樣的-這是不正確的！ 實際上，這些數據庫可以分為四類：面向文檔的數據庫，鍵/值數據庫，列數據庫和麵向圖形的數據庫。 它們都有一個共同點：比傳統關係數據庫生成的模型更靈活，動態的支持。

實際上，每個類別都有其自身的屬性和侷限性。 沒有解決所有問題的首選數據庫。 您必須根據項目的需要選擇一個數據庫。

您必須想知道將要處理哪種數據，以及應用程序最終將如何使用它們。

-面向文檔的數據庫：混合結構

面向文檔的NoSQL數據庫以鍵/值對的形式存儲和提取數據，但值部分存儲為文檔。 該文檔以JSON或XML格式存儲。

MongoDB，Apache CouchDB，MarkLogic是面向文檔的數據庫。

-鍵/值數據庫：

面向鍵值的數據庫具有大量的鍵和值哈希。 它代表NoSQL數據庫的最簡單形式。 他們將唯一鍵與數據中的值相關聯，目的是基於相對簡單的數據集大大提高應用程序的性能。

Redis，Riak，Memcached和Aerospike是鍵值數據庫的示例。

-列數據庫：

列數據庫將數據保存在具有大量列的表中。 每個存儲塊都包含來自單個列的數據，並且將每個列分別處理。 它們在諸如COUNT，SUM，AVG，MAX等彙總查詢上提供了高性能，因為數據很容易在列中使用。

HBase，Cassandra和Accumulo是基於列的數據庫的示例。

-面向圖的數據庫：

基於圖的數據庫是一種網絡數據庫，它以"圖"結構存儲數據元素，並有可能在節點之間創建關聯，最終用作推薦引擎或社交網絡的基礎。

我們可以從圖形數據庫中獲得很多信息。 例如，圖形技術可用於通過他們的興趣來識別不同人之間的關係。

Twitter Graph | Source :

Neo4J，無限圖和FlockDB是面向圖的數據庫的示例。

為您的應用程序選擇適當的數據庫類型的條件

我們如何確定最適合項目的數據庫類型？ 這是您可以使用的清單：

· 要存儲的數據類型：SQL數據庫不適用於分層數據存儲。 但是，NoSQL數據庫更適合分層數據存儲，因為它遵循鍵值對方法或圖方法。 NoSQL數據庫是大型數據集的高度首選。

· 複雜查詢：SQL數據庫非常適合需要許多查詢的環境，而NoSQL數據庫不適合複雜查詢。 因此，NoSQL中的查詢不如SQL查詢語言強大。

· 可伸縮性：在大多數情況下，SQL數據庫是垂直可伸縮的。 您可以通過增加單個服務器上的處理器，RAM，SSD等來管理增加的負載。 另一方面，NoSQL數據庫可水平擴展。 您可以輕鬆地向NoSQL數據庫基礎架構中添加一些其他服務器來處理大量流量。 因此，您可以根據設備選擇適合您的數據庫類型。

· 高度事務性的應用程序：SQL數據庫更穩定，並具有原子性和數據完整性，因此更適合密集使用的事務性類型的應用程序。 儘管您可以將NoSQL用於事務目的，但是它仍然不可比，但是可以用於複雜的事務應用程序。

· 屬性：SQL數據庫強調ACID屬性（原子性，一致性，隔離性，耐久性），而NoSQL數據庫遵循Brewers CAP定理（一致性，可用性和分區容限）。

五 從RDBMS切換到NoSQL

Photo by Science in HD on Unsplash

無論您選擇哪種NoSQL數據庫設計，將數據遷移到其中都會帶來一些嚴峻的挑戰。 在NoSQL中設計數據模型具有額外的複雜性，因為它需要了解數據的最終用途。 僅僅知道您的應用程序可以處理賬單和客戶就足夠了。 現在，您必須知道如何將這些數據顯示給最終用戶。 因此，NoSQL數據庫中的數據建模除了需要對最終客戶的使用有深入瞭解之外，還需要真正的技術專長。

是時候用NoSQL解決方案替換SQL嗎？

我認為，這是一個很難的問題！ 因為在大多數情況下，這不是用NoSQL解決方案代替SQL，而是在應用程序和用例表明需要更改的情況下，從一種過渡到另一種。 通常，在構建現代Web和移動應用程序時，對靈活性和可伸縮性的需求將推動這種轉變。

通常，許多公司嘗試在其Web應用程序中支持負載，因此他們選擇僅在負載均衡器後面添加Web服務器以支持更多用戶。 毫無疑問，在日益重要的雲計算世界中，擴展能力是一項根本的競爭優勢，在雲計算世界中，可以輕鬆添加或刪除虛擬機實例以滿足不斷變化的需求。

關係數據庫（RDBMS）不允許簡單縮放，也不能提供靈活的數據模型。 管理更多的用戶意味著添加更大的服務器和大型服務器非常複雜且昂貴，這與低成本硬件，"商品硬件"和雲架構不同。 組織已經開始看到其關係數據庫對現有或新應用程序的性能問題。 尤其是隨著用戶數量的每天增加，他們意識到對更快，更靈活的數據庫的需求變得非常重要。 現在該遷移到NoSQL了！

從SQL過渡到NoSQL所需的主要步驟是什麼？

應用程序/項目可能會因每個組織而有很大差異，因此過渡將取決於您的用例。 以下是有關過渡的一些一般準則：

1-瞭解您的應用程序的關鍵要求：

以下是與NoSQL數據庫需求相對應的一些要求：

· 快速的應用開發：不斷變化的市場需求和持續的數據修改

· 可擴展性

· 性能穩定：響應時間短，可帶來更好的用戶體驗

· 操作可靠性：高可用性來管理錯誤，對應用程序的影響最小，並且集成了監視API，以實現更好的維護

2-瞭解NoSQL提供的不同類型：

如上所述，NoSQL數據庫管理系統有多種類型。

例如，面向文檔的NoSQL數據庫-帶有Couchbase和MongoDB，這是兩個最著名且使用最廣泛的示例。

同樣，例如，鑑於Cassandra的柱狀模型，它可能是可用於數據分析的解決方案。 圖形數據庫Neo4j可能是需要存儲實體之間關係的應用程序的理想數據庫。

3-建立原型：

縮小數據庫類型的可能選擇範圍後，嘗試開發一個集成了應用程序主要特徵的原型。 該原型將幫助您評估響應時間，吞吐量方面的性能以及輕鬆擴展的能力。

4-文檔建模和開發：

對於面向文檔的數據庫，請花幾天時間從固定的表格圖開始對數據建模，以獲取靈活的文檔模型。

5-部署然後生產：

對於交互式Web應用程序，操作穩定性是非常重要的方面。 與通常使用傳統RDBMS系統的應用程序一樣，對您的部署進行測試和重新測試。

6-跟上最新趨勢：

今天，有大量的質量培訓，提供有關NoSQL培訓的動手課程。 確保NoSQL成功實施的最佳方法是使用最新版本。

不用擔心，您會發現採用某些NoSQL技術很容易，尤其是如果您熟悉JSON的文檔格式。 廣泛使用SQL的開發人員可能需要適應和學習文檔建模方法。 重新思考如何使用文檔在邏輯上構造數據，而不是將數據規範化為固定的數據庫模式成為重要的方面。

以下是一些有趣課程的鏈接：

· NoSQL課程和教程（Udemy）

· NoSQL系統（Coursera）

六，結論

因此，本文的目的是介紹存在的主要差異，以幫助您做出正確的決定並塑造信息系統（或簡單應用程序）的未來。

我們已經看到，SQL和NoSQL數據庫最終執行幾乎相同的操作（存儲數據），但是方式不同。 因此，對於任何數據項目而言，數據庫管理系統（DBMS）的選擇都是重要且結構化的時刻。 當然，總是可以選擇一個選項，然後稍後再切換到另一個。 但是在項目開始時進行一些概念分析和思考將使您節省時間和金錢。

當今市場上到處都是NoSQL數據庫-我認為我們每天都面臨著其中的兩個或三個數據庫，因為開發人員改用NoSQL具有很多優勢。 更加靈活的數據模型和不受剛性模式的限制是一個很大的優勢。 您還可以看到性能顯著提高，並且可以水平縮放。

但是，大多數NoSQL產品仍處於產品週期的早期階段。 對於複雜連接等功能，開發人員可能更喜歡使用傳統的RDBMS。 對於某些項目，混合方法可能是最佳選擇。

總而言之，每個公司都會根據項目的要求有自己的偏好。 因此，確定您的需求和明智地為項目開發提供集成支持的數據庫。

恭喜您成功到達這裡。 感謝您的閱讀，希望您喜歡它。 如需個人聯繫或討論，請隨時通過LinkedIn與我聯繫。

(本文翻譯自Kamal Chouhbi的文章《It's Time to Familiarize Yourself With NoSQL Databases More Than Ever》，參考：https://towardsdatascience.com/its-time-to-familiarize-yourself-with-nosql-databases-more-than-ever-5fb1f65c22b1)

閱讀更多 聞數起舞 的文章

關鍵字: MySQL 設計 Microsoft