本文轉(zhuǎn)載自公眾號“讀芯術(shù)”(ID：AI_Discovery)

在大數(shù)據(jù)時代，數(shù)據(jù)是信息系統(tǒng)的核心，數(shù)據(jù)組織和運(yùn)營的效率是任何公司都關(guān)心的問題，業(yè)務(wù)專長和對現(xiàn)有技術(shù)解決方案的理解是非常必要的。因此，公司必須同時繼續(xù)評估和選擇能夠滿足其未來需求和支持其增長的數(shù)據(jù)庫。

[[323719]]

關(guān)系數(shù)據(jù)庫已經(jīng)被用于存儲數(shù)據(jù)幾十年了，它們?nèi)允窃S多用例的可行解決方案。而NoSQL數(shù)據(jù)庫則是針對關(guān)系數(shù)據(jù)庫技術(shù)的局限性而創(chuàng)建的。

與關(guān)系型數(shù)據(jù)庫相比，NoSQL數(shù)據(jù)庫具有更強(qiáng)的可擴(kuò)展性和更好的性能，它彌補(bǔ)了關(guān)系型數(shù)據(jù)庫的一些不足。

NoSQL數(shù)據(jù)庫旨在解決大數(shù)據(jù)環(huán)境中的海量，多源和多格式的數(shù)據(jù)處理問題。它們提供了一種新的方法來滿足容量需求以及新的數(shù)據(jù)類型。如今，NoSQL數(shù)據(jù)庫的數(shù)量變得越來越重要。了解了它們之間的差異是至關(guān)重要的，你才能采用正確的技術(shù)進(jìn)行正確的應(yīng)用。

本文將闡述從RDBMS遷移到NoSQL的困難、過程和好處。

1. 簡介

SQL：

SQL是結(jié)構(gòu)化查詢語言的縮寫。IT工程師在大型關(guān)系數(shù)據(jù)庫(DBMS)中快速搜索信息已經(jīng)有很長一段時間了。

SQL如今被廣泛使用，因?yàn)樗亲罱Y(jié)構(gòu)化、最快的數(shù)據(jù)庫組織和查詢設(shè)備之一;不同的名字代表不同的改進(jìn)版本，如Oracle的MySQL和微軟的SQL Server。此外，SQL具有預(yù)定義的結(jié)構(gòu)和模式，是許多公司最推薦的選擇。

NoSQL：

“NoSQL”這個縮略語有兩種不同的解釋，目前尚不明確：

• 對有些人來說是“No SQL”，也就是說，使用了另一種不同于SQL的查詢語言。
• 對于其他人，它不僅是“SQL”，也就是說，是SQL與其他信息檢索工具的結(jié)合使用。

這個術(shù)語既與技術(shù)特征有關(guān)，也與20世紀(jì)10年代出現(xiàn)的歷史性一代DBMS有關(guān)。導(dǎo)致NoSQL發(fā)明的主要原因是，它解決了這樣一個問題，即一個網(wǎng)站上的同一個數(shù)據(jù)庫可以在全世界范圍內(nèi)被數(shù)百萬用戶同時使用;像亞馬遜這樣的公司就存在這種典型問題……

筆者試圖通過NoSQL來降低查詢語言的復(fù)雜性，簡化數(shù)據(jù)庫的體系結(jié)構(gòu)。這些數(shù)據(jù)庫包括面向列、面向文檔、面向圖形和面向鍵/值的數(shù)據(jù)。NoSQL由各種產(chǎn)品組成，每個產(chǎn)品都有一組獨(dú)特的功能。

主要差別：

• SQL數(shù)據(jù)庫有一個預(yù)定義的模式，而NoSQL數(shù)據(jù)庫有一個用于非結(jié)構(gòu)化數(shù)據(jù)的動態(tài)模式。
• SQL數(shù)據(jù)庫是可垂直擴(kuò)展的，而NoSQL數(shù)據(jù)庫是可水平擴(kuò)展的。SQL數(shù)據(jù)庫是通過增加CPU、RAM或SSD等硬件的能力來擴(kuò)展的。
• NoSQL數(shù)據(jù)庫通過增加數(shù)據(jù)服務(wù)器的數(shù)量來減少負(fù)載。這就像在同一棟建筑上增加更多的樓層，而不是在鄰近地區(qū)增加更多的建筑。
• SQL數(shù)據(jù)庫使用SQL(結(jié)構(gòu)化查詢語言)來定義和操作數(shù)據(jù)，這是非常強(qiáng)大的。在NoSQL數(shù)據(jù)庫中，查詢的重點(diǎn)是文檔收集。有時也稱為UnQL(非結(jié)構(gòu)化查詢語言)。在不同的NoSQL數(shù)據(jù)庫之間，使用UnQL的語法差異很大。
• SQL數(shù)據(jù)庫是基于表的數(shù)據(jù)庫，而NoSQL數(shù)據(jù)庫是基于鍵值對的數(shù)據(jù)庫。這意味著SQL數(shù)據(jù)庫以表的形式表示數(shù)據(jù)，表由表示數(shù)據(jù)的一定數(shù)量的行組成，而NoSQL數(shù)據(jù)庫是鍵值對、文檔、圖形數(shù)據(jù)庫等的集合。

2. 歷史因素

(1) 關(guān)系型DBMS的歷史支配地位

• 20世紀(jì)70年代創(chuàng)建的關(guān)系型DBMS已經(jīng)逐漸成為主流， 20世紀(jì)90年代初成為了非常普遍的主流數(shù)據(jù)庫范式。
• 在20世紀(jì)90年代，許多物流公司的銷售人員開始使用它來存儲業(yè)務(wù)數(shù)據(jù)。事實(shí)上，他們既沒有鼠標(biāo)，也沒有用戶界面來搜索存儲在服務(wù)器上的某些信息，服務(wù)器通常由專業(yè)線連接并且相距很遠(yuǎn)，它們用于通過鍵盤輸入SQL命令，并且能夠在幾秒內(nèi)檢索到特定產(chǎn)品或原材料可用性的相關(guān)信息。
• 出現(xiàn)了其他幾種數(shù)據(jù)庫模型，如面向?qū)ο蟮臄?shù)據(jù)庫管理系統(tǒng)、層次數(shù)據(jù)庫管理系統(tǒng)、對象關(guān)系數(shù)據(jù)庫管理系統(tǒng)，但它們的使用非常有限。
• 從本世紀(jì)初開始，隨著谷歌、亞馬遜等大型互聯(lián)網(wǎng)公司的發(fā)展，出現(xiàn)了大量的非結(jié)構(gòu)化數(shù)據(jù)，其增長速度遠(yuǎn)遠(yuǎn)超過不再符合RDBMS關(guān)系模式的結(jié)構(gòu)化數(shù)據(jù)。集群計(jì)算也得到了發(fā)展，關(guān)系模型的主導(dǎo)地位由于其在新實(shí)踐上的限制受到了質(zhì)疑。

(2) NoSQL模型的先驅(qū)

大型web公司必須處理非常大的數(shù)據(jù)量，這就是為什么它們首先要面對傳統(tǒng)關(guān)系型DBMS的固有限制。

這些系統(tǒng)嚴(yán)格應(yīng)用ACID屬性(原子性、一致性、隔離性、持久性)，通常設(shè)計(jì)為在單臺計(jì)算機(jī)上運(yùn)行，很快就出現(xiàn)了可伸縮性問題。為了滿足這些限制，一些公司已經(jīng)開始開發(fā)自己的數(shù)據(jù)庫管理系統(tǒng)，這些系統(tǒng)可以在分布式硬件架構(gòu)上運(yùn)行，可以處理大量數(shù)據(jù)：

• 谷歌(BigTable)，
• 亞馬遜(DynamoDB)，
• LinkedIn(Voldemort )，
• Facebook (Cassandra和HBase)，
• 百度(Hypertable)

通過簡單增加服務(wù)器數(shù)量，性能保持良好，這是降低成本的合理解決方案，特別是如果收入隨著活動的增長而增長的話。

3. 流行的數(shù)據(jù)庫

為了選擇合適的管理系統(tǒng)，了解市場上存在什么是很重要的。看看下面5個流行的SQL和NoSQL數(shù)據(jù)庫，其中有付費(fèi)的也有免費(fèi)的。

(1) SQL數(shù)據(jù)庫產(chǎn)品：

• MySql：它是免費(fèi)的，即使是免費(fèi)的數(shù)據(jù)庫引擎也提供了很多功能。
• Postgres：這個數(shù)據(jù)庫管理引擎是可擴(kuò)展的，可以處理tb級的數(shù)據(jù)，具有各種預(yù)定義的功能。
• Oracle：Oracle數(shù)據(jù)庫管理工具集最新的創(chuàng)意和功能于一身，非常強(qiáng)大。
• SQL Server：非常快速和穩(wěn)定，與微軟的其他產(chǎn)品配合得很好。
• SQLite：SQLite數(shù)據(jù)庫非常靈巧，并且可以快速地設(shè)置，它還可以用于在智能手機(jī)應(yīng)用程序(iPhone或Android)的實(shí)際數(shù)據(jù)庫中存儲數(shù)據(jù)。

(2) NoSQL數(shù)據(jù)庫產(chǎn)品：

• MongoDB：MongoDB是一個靈活/可靠的數(shù)據(jù)庫，它會把讀者吸引到NoSQL的世界中來。管理和維護(hù)非常簡單快捷。
• Hbase：它是一個面向列的數(shù)據(jù)庫，有助于提高查詢性能和集合。
• Cassandra：Cassandra提供的線性可伸縮性，允許通過簡單地添加/刪除服務(wù)器來輕松地?cái)U(kuò)展/縮小集群。
• Redis：使用非常簡單和直接。下載Redis，并在接下來的五分鐘內(nèi)開始使用它。
• CouchDb：由于CouchDB能夠存儲序列化(JSON格式)的非結(jié)構(gòu)化數(shù)據(jù)和Restful HTTP API，因此它非常適合用于Web和移動應(yīng)用程序。

4. NoSQL數(shù)據(jù)庫設(shè)計(jì)

NoSQLDBMS的主要特點(diǎn)，在于支持對大量數(shù)據(jù)的操作和水平可伸縮性。然而，目前大多數(shù)公司面臨的困難是，如何用最適當(dāng)?shù)募夹g(shù)解決問題，使應(yīng)用作出反應(yīng)。

[[323721]]

圖源：unsplash

要解決這個問題，首先要很好地理解不同類型的NoSQL數(shù)據(jù)庫。

有一個普遍的誤解，所有的NoSQL數(shù)據(jù)庫都是平等創(chuàng)建的。實(shí)際上，這些數(shù)據(jù)庫可以分為四類：面向文檔的數(shù)據(jù)庫、鍵/值數(shù)據(jù)庫、列數(shù)據(jù)庫和面向圖形的數(shù)據(jù)庫。它們都有一個共同點(diǎn)：支持比傳統(tǒng)關(guān)系數(shù)據(jù)庫更靈活和更動態(tài)的模型。

事實(shí)上，每個類別都有自己的屬性和限制。沒有數(shù)據(jù)庫可以解決所有問題。必須根據(jù)項(xiàng)目的需要選擇數(shù)據(jù)庫。

必須考慮將操作什么類型的數(shù)據(jù)，以及應(yīng)用程序最終將如何使用這些數(shù)據(jù)。

(1) 面向文檔的數(shù)據(jù)庫：混合結(jié)構(gòu)

面向文檔的NoSQL數(shù)據(jù)庫將數(shù)據(jù)存儲和提取為鍵/值對，但是值部分存儲為文檔。文檔以JSON或XML格式存儲。

MongoDB, Apache CouchDB, MarkLogic是面向文檔的數(shù)據(jù)庫

(2) 鍵/值數(shù)據(jù)庫：

面向鍵值的數(shù)據(jù)庫有大量的鍵和值散列。它代表了NoSQL數(shù)據(jù)庫的最簡單形式。將唯一的鍵與數(shù)據(jù)中的值相關(guān)聯(lián)，目的是基于相對簡單的數(shù)據(jù)集極大地提高應(yīng)用程序的性能。

Redis, Riak, Memcached 和 Aerospike 就是鍵值數(shù)據(jù)庫的例子。

(3) 列數(shù)據(jù)庫：

列數(shù)據(jù)庫將數(shù)據(jù)保存在具有大量列的表中。每個存儲塊包含來自單個列的數(shù)據(jù)，并且每個列被單獨(dú)處理。它們在諸如COUNT、SUM、AVG、MAX等聚合查詢上有很高的性能，因?yàn)閿?shù)據(jù)很容易從列中取出。

HBase, Cassandra 和 Accumulo 就是列數(shù)據(jù)庫的例子。

(4) 面向圖形的數(shù)據(jù)庫：

基于圖的數(shù)據(jù)庫是一種網(wǎng)絡(luò)數(shù)據(jù)庫，它將數(shù)據(jù)元素存儲在“圖”結(jié)構(gòu)中，使得在節(jié)點(diǎn)之間創(chuàng)建關(guān)聯(lián)成為可能，最終成為推薦引擎或社交網(wǎng)絡(luò)的基礎(chǔ)。

從圖形數(shù)據(jù)庫中可以獲得很多信息。例如，可以使用圖形技術(shù)根據(jù)不同人的興趣來確定他們之間的關(guān)系。

圖源：neo4j.

Neo4J, InfiniteGraph 和 FlockDB 就是面向圖形數(shù)據(jù)庫的例子。

5. 為應(yīng)用程序選擇適當(dāng)?shù)臄?shù)據(jù)庫類型的5個標(biāo)準(zhǔn)

如何選擇哪種類型的數(shù)據(jù)庫最適合一個項(xiàng)目?可以根據(jù)以下清單做決定：

• 要存儲的數(shù)據(jù)類型：SQL數(shù)據(jù)庫不適合分層數(shù)據(jù)存儲。但是，NoSQL數(shù)據(jù)庫更適合分層數(shù)據(jù)存儲，因?yàn)樗裱I值對方法或圖方法。NoSQL數(shù)據(jù)庫是大型數(shù)據(jù)集的首選。
• 可伸縮性：在大多數(shù)情況下，SQL數(shù)據(jù)庫是可垂直伸縮的。可以通過增加單個服務(wù)器上的處理器、RAM、SSD等來管理增加的負(fù)載。另一方面，NoSQL數(shù)據(jù)庫是可水平伸縮的。可以簡單地將一些額外的服務(wù)器添加到NoSQL數(shù)據(jù)庫基礎(chǔ)設(shè)施中來處理繁重的數(shù)據(jù)流。因此，可以根據(jù)設(shè)備選擇適合的數(shù)據(jù)庫類型。
• 高度事務(wù)性應(yīng)用程序：SQL數(shù)據(jù)庫更穩(wěn)定并且可以保證原子性和數(shù)據(jù)完整性，因此更適合密集使用的事務(wù)類型的應(yīng)用程序。雖然可以將NoSQL用于事務(wù)性目的，但它仍然不能與SQL相提并論，但可以用于復(fù)雜的事務(wù)性應(yīng)用程序。
• 復(fù)雜查詢：SQL數(shù)據(jù)庫非常適合需要很多查詢的環(huán)境，而NoSQL數(shù)據(jù)庫不適合復(fù)雜查詢。所以NoSQL中的查詢不如SQL查詢語言強(qiáng)大。
• 屬性：SQL數(shù)據(jù)庫強(qiáng)調(diào)ACID屬性(原子性、一致性、隔離性、持久性)，而NoSQL數(shù)據(jù)庫遵循Brewers CAP定理(一致性、可用性和分區(qū)容限)。

6. 從RDBMS轉(zhuǎn)向NoSQL

無論選擇哪種NoSQL數(shù)據(jù)庫設(shè)計(jì)，將數(shù)據(jù)遷移到其中都會遇到一些嚴(yán)峻的挑戰(zhàn)。NoSQL中數(shù)據(jù)模型的設(shè)計(jì)具有額外的復(fù)雜性，你需要知道數(shù)據(jù)的最終用途。僅僅知道應(yīng)用程序?qū)⑻幚碣~單和客戶信息是不夠的，還必須知道這些數(shù)據(jù)將如何展示給最終用戶。

因此，NoSQL數(shù)據(jù)庫中的數(shù)據(jù)建模除了需要對最終用戶的使用有深入的了解外，還需要真正的技術(shù)專長。

[[323722]]

圖源：unsplash

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

在筆者看來，這是一個很難回答的問題。因?yàn)樵诖蠖鄶?shù)情況下，不是用NoSQL解決方案替換SQL，而是在應(yīng)用程序和用例顯示需要更改時，從一種解決方案轉(zhuǎn)換到另一種解決方案。

通常，在構(gòu)建現(xiàn)代Web和移動應(yīng)用程序時，對靈活性和可伸縮性的需求將推動這種轉(zhuǎn)變。

許多公司試圖在其web應(yīng)用程序中支持負(fù)載，因此選擇簡單地將web服務(wù)器添加到負(fù)載平衡器之后以支持更多用戶。

毫無疑問，在日益重要的云計(jì)算世界中，擴(kuò)展能力是一個基本的競爭優(yōu)勢，可以輕松地添加或刪除虛擬機(jī)實(shí)例，以滿足變化不定的需求。

關(guān)系型數(shù)據(jù)庫(RDBMS)不允許簡單的擴(kuò)展，也不提供靈活的數(shù)據(jù)模型。管理更多的用戶意味著添加更大的服務(wù)器，而大型服務(wù)器非常復(fù)雜和昂貴，不像低成本的硬件、“商品硬件”和云架構(gòu)。

組織開始看到現(xiàn)有或新應(yīng)用程序的關(guān)系數(shù)據(jù)庫的性能問題。特別是隨著用戶數(shù)量的日益增加，他們意識到對更快速、更靈活的數(shù)據(jù)庫的需求變得非常重要。是時候轉(zhuǎn)移到NoSQL了!

從SQL到NoSQL的轉(zhuǎn)換需要哪些主要步驟?

應(yīng)用程序/項(xiàng)目可能因每個組織而有很大的差異，因此轉(zhuǎn)換將取決于使用用例。以下是一些關(guān)于過渡的通用準(zhǔn)則：

(1) 理解應(yīng)用的核心需求

以下是與NoSQL數(shù)據(jù)庫的需求相對應(yīng)的一些要求：

• 可擴(kuò)展性
• 快速的應(yīng)用程序開發(fā)：不斷變化的市場需求和持續(xù)的數(shù)據(jù)修改
• 性能穩(wěn)定：響應(yīng)時間短，可帶來更好的用戶體驗(yàn)
• 運(yùn)行可靠性：管理錯誤的高可用性，對應(yīng)用程序的影響最小，并且集成了監(jiān)視API以便更好維護(hù)

(2) 了解NoSQL提供的不同類型

如前所述，有不同類型的NoSQL數(shù)據(jù)庫管理系統(tǒng)。例如面向文檔的NoSQL數(shù)據(jù)庫—Couchbase和MongoDB是兩個最著名和最廣泛采用的例子。

此外，Cassandra可能也是一個解決方案，可以使用它的柱狀模型進(jìn)行數(shù)據(jù)分析。Neo4j是一個圖形數(shù)據(jù)庫，對于需要存儲實(shí)體間關(guān)系的應(yīng)用程序來說，它可能是一個完美的數(shù)據(jù)庫。

(3) 建立一個原型

一旦縮小了數(shù)據(jù)庫類型的可能選擇范圍，就可以嘗試開發(fā)一個集成了應(yīng)用程序主要特征的原型。這個原型將幫助評估響應(yīng)時間、吞吐量方面的性能和易于擴(kuò)展的能力。

(4) 文檔建模與開發(fā)

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

(5) 部署然后生產(chǎn)

操作穩(wěn)定性是交互式web應(yīng)用程序的一個非常重要的方面。對部署進(jìn)行一次又一次的測試，就像對通常使用傳統(tǒng)RDBMS系統(tǒng)的應(yīng)用程序進(jìn)行測試一樣。

(6) 緊跟最新趨勢

今天，有大量的高質(zhì)量培訓(xùn)提供了NoSQL的實(shí)踐課程，確保NoSQL成功實(shí)現(xiàn)的最佳方法是更新最新版本。

不要擔(dān)心，你會很容易接受某些NoSQL技術(shù)，特別是如果熟悉JSON文檔格式。廣泛使用SQL的開發(fā)人員可能需要適應(yīng)和學(xué)習(xí)文檔建模方法。重新思考如何使用文檔在邏輯上構(gòu)造數(shù)據(jù)，而不是將數(shù)據(jù)規(guī)范化為固定的數(shù)據(jù)庫模式，這是一個重要的方面。

7. 結(jié)論

本文旨在介紹存在的主要差異，以幫助讀者做出正確的決策并塑造信息系統(tǒng)(或簡單應(yīng)用程序)的未來。

可以看到，SQL和NoSQL數(shù)據(jù)庫最終做的是幾乎相同的事情(存儲數(shù)據(jù))，但方式不同。數(shù)據(jù)庫管理系統(tǒng)(DBMS)的選擇對于任何數(shù)據(jù)項(xiàng)目來說都是一個重要的和結(jié)構(gòu)化的時刻。當(dāng)然，總是可以選擇一個選項(xiàng)，然后切換到另一個選項(xiàng)。但是在項(xiàng)目開始時進(jìn)行一點(diǎn)概念分析和思考將節(jié)省時間和金錢。

今天的市場上到處都是NoSQL數(shù)據(jù)庫——每天都要面對兩三個這樣的數(shù)據(jù)庫，因?yàn)閷τ陂_發(fā)人員來說，轉(zhuǎn)到NoSQL有很多優(yōu)勢。更靈活的數(shù)據(jù)模型和擺脫僵化模式是一個很大的優(yōu)勢。還可以看到性能的顯著提高和水平伸縮。

[[323723]]

圖源：unsplash

但大多數(shù)NoSQL產(chǎn)品仍處于產(chǎn)品周期的早期階段。在復(fù)雜連接之類的特性上，開發(fā)人員可能更喜歡使用傳統(tǒng)的RDBMS。對于某些項(xiàng)目，混合方法可能是最佳選擇。最后，根據(jù)項(xiàng)目的需求，每個公司都有自己的偏好。

因此，確定需求和數(shù)據(jù)庫，甚至使用混合方法，為項(xiàng)目的開發(fā)提供集成支持才是最合適的做法。