NoSQL數據管理系統與模型的比較

jopen 10年前發布 | 29K 次閱讀 NoSQL數據庫 NOSQL

簡介

NoSQL數據嘗試著提供那些關系數據庫所不能提供的功能,無論是為了存儲簡單的鍵值對(key-value),更短的時間長度,高速緩存,還是保持數據的非結構化集合(比如collections),這些都是在關系型數據庫和SQL(Structured Query Language)中很難實現的。

在這篇DigitalOcean的文章中,我們將介紹各種流行的NoSQL數據庫系統,介紹他們的作用以及功能,因而幫助你,根據你的易用系統的需求來決定選擇哪一個NoSQL數據庫。

術語表

1. 數據庫管理系統

2. NoSQL 數據庫管理系統

  1. 基于鍵/值

  2. 基于列

  3. 基于文檔

  4. 基于圖形

3. 基于鍵/值的 NoSQL 數據庫管理系統

  1. 流行的基于鍵/值的數據庫

  2. 何時使用

4. 基于列 NoSQL 數據庫管理系統

  1. 流行的基于列的數據庫

  2. 何時使用

5. 基于文件的 NoSQL 數據庫管理系統

  1. 流行的基于文件的數據庫

  2. 何時使用

6. 基于圖形的 NoSQL 數據庫管理系統

  1. 流行的基于圖形的數據庫

  2. 何時使用

7. NoSQL數據庫管理系統與關系型數據庫管理系統的比較

  1. 何時使用 NoSQL Databases

數據庫管理系統

數據庫是為各種不同的信息(數據)提供邏輯上模型化的存儲空間。除了無模式以外的每個數據庫,都有一個模型為所處理的數據提供結構。數據庫管理系統是管理各種形狀,大小和類型的數據庫的應用程序(或庫)。

注: 要學習更多數據庫管理系統知識, 請查閱我們的文章: 了解數據庫(http://link_to_10_1_understanding_databases).

NoSQL 數據庫管理系統

在過去的十年左右中,關系數據庫管理系統因為各種各樣的理由已被開發人員和系統管理員選擇用于各種各樣的應用程序中。盡管并不完全靈活,許多關系數據庫管理系統的強大的性質允許復雜的數據庫體制被創建,查詢和使用。這甚至超過許多需求的要求,直到不久以前,不同的需求開始上升才發生逆轉。

術語“NoSQL”一詞是在十年前被創造的,有趣的是,它是作為另一個關系數據庫的名稱。然而,該數據庫在背后有一個不同的想法:消除標準化的SQL的使用。在接下來的幾年,別人拾起并通過借鑒其他各種非關系型數據庫繼續發展了這一思想成為 NoSQL 數據庫

從設計上,NoSQL 數據庫和管理系統都是非關系型(也稱非范式型)的。它們并非基于同一種模型(如關系型數據庫的關系模型),而是每種數據庫依據其不同的功能目標,選擇了不同的模型。

NoSQL 數據庫不同的操作模型和功能系統幾乎有一大把:

  • 鍵 / 值:

如 Redis,MemcacheDB等。

  • 列:

如 Cassandra,HBase等。

  • 文檔:

如 MongoDB,Couchbase等。

  • 圖形:

如 OrientDB,Neo4J等。

為了更好地理解每種數據庫管理系統的不同角色和底層技術,我們快速地過一遍這4種操作模型吧。

基于鍵值

我們將要開始我們的NoSQL模型之旅,它是基于鍵值的數據庫管理系統,因為可以把它視為是實現NoSQL的基礎和骨架。

該類型的數據庫通過關鍵字與值的映射來工作,有點類似字典。沒有結構也沒有關系。連接到數據庫服務器(例如Redis)以后,應用程序陳述一個關鍵字如the_answer_to_life并提供也這對應的值如42,這個值隨后可以通過提供的關鍵字以相同的方式搜索。

鍵值數據庫通常用于快速的存儲基本信息,有時是一些處理過的非基本的,例如CPU和內存密集的計算。它們的表現非常好,性能高,且通常易于擴展。

注意:在計算機領域,字典通常指特定類型的數據對象。它們由鍵值對數組構成。

基于列

基于列的NoSQL數據庫管理系統通過提升基于鍵值的簡單本質來工作。

雖然在互聯網中它們難于理解,但是這些數據庫的工作機制相當的簡單,通過創建一個或者多個鍵值對的集合來與記錄相匹配。

不像傳統的關系數據庫定義了模式,基于列的NoSQL解決方案不需要預定義表結構就可以處理數據。每條記錄有一列或者多列,這些列包含了信息,每個記錄的每列都可能是不相同的。

基本上,基于列的NoSQL數據庫就是個二維數組,每個鍵(即 行/記錄)都連接有一個或多個 鍵/值對,這些管理系統允許非常巨大和非結構化的數據被保存和使用(例如有非常多信息的記錄)。

這些數據庫通常用在當必須存儲大量信息記錄,簡單的 鍵/值對 不足以應對時。基于列實現的數據庫管理系統,模式自由的模型,擴容性非常好。

基于文檔

基于文檔的 NoSQL 數據庫系統,就像一波瞬間席卷了許多人的最新潮流。這類數據庫系統工作原理與基于列的數據庫類似;然而,它們支持更深層的嵌套,能得到復雜的結構(例如,文檔包含在一個文檔里,而這個文檔又包含在另一個文檔里)。

文檔克服了基于列的數據庫中鍵/值嵌套只能有一級或兩級的限制。基本上,無論多么復雜、無論什么形態的結構都能形成一個文檔,而文檔就可以用這類數據庫系統來儲存。

盡管它們有這樣強大的特性,并且支持以獨立的鍵來查詢記錄,基于文檔的數據庫系統相比其他系統仍然有自己的問題和不足之處。例如,檢索記錄中的一個值就需要牽扯出整個記錄,update 也是如此,而這都會嚴重地影響性能。

基于圖形

最后來看看 NoSQL 數據庫系統中的奇葩——基于圖形的系統。

基于圖形的數據庫系統模型表示數據的方式與上文提到的三種模型截然不同。他們使用樹形的結構(也就是所說的“圖形”),包括結點和通過關系(relation)相互連接的邊。

與數學類似,某些特定操作在這類模型上會格外簡單。這要感謝樹形結構能鏈接信息、將相關信息(例如相關聯的人)分組的本質。

這類數據庫通常應用于關系(connection)需要建立明確邊界的場景。例如,當你注冊隨便一個社交網絡時,你朋友與你的關系,和他們朋友的朋友與你的關系,使用基于圖形的數據庫系統來處理會簡單很多。

基于鍵 / 值的 NoSQL 數據庫系統

鍵/值型的數據存儲往往表現很好,容易使用,并且通常有很好的擴展性。

流行的基于鍵 / 值的數據庫

一些流行的基于鍵/值的數據存儲如下:

  • Redis:

內存中的鍵/值存儲,附有可選的持久化功能。

  • Riak:

高度分布式的,自我復制(replicated)的鍵/值存儲。

  • Memcached / MemcacheDB:

基于內存的分布式鍵/值存儲。

何時使用?

基于鍵/值的數據存儲一些常見的使用場景有:

  • 緩存:

快速緩存數據,以供將來——可能是頻繁地——使用。

  • 用作隊列:

部分鍵/值存儲(例如 Redis)支持list,set,queue等類型。

  • 分布式信息 / 任務處理:

可以用來實現觀察者/發布訂閱(Pub/Sub)模式。

  • 保存活躍狀態信息:

需要維護一個狀態的應用很適合使用鍵/值存儲。

基于列的 NoSQL 數據庫系統

基于列的數據存儲非常強大,它們能夠可靠地存儲非常大規模的重要數據。盡管在數據的組成方面并不“靈活”,這類數據庫仍然功能強大,性能良好。

流行的基于列的數據庫

一些流行的基于列的數據存儲有:

  • Cassandra:

建立在 BigTable 和 DynamoDB 基礎上的基于列的數據存儲。

  • HBase:

為 Apache Hadoop 設計的數據存儲,創意來自 BigTable。

何時使用?

基于列的數據存儲的一些流行用例:

  • 保存非結構化和非易失性的信息:

如果需要長時間保存一個巨大的屬性和值的集合,基于列的數據存儲是非常方便的。

  • 擴容:

基于列的數據存儲天生是高度可擴容的。他們可以處理那些有可怕數量的信息。

基于文件的 NoSQL 數據庫管理系統

基于文件的數據存儲非常適于保存許多不相關的復雜信息,不同結構之間可以有高度的可變性。

流行的基于文件的數據庫

流行的一些基于文件的數據存儲:

  • Couchbase:

基于JSON, 兼容“內存緩沖”的基于文件的數據存儲。

  • CouchDB:

一個沖破性的基于文件的數據存儲。

  • MongoDB:

一個非常流行和功能很好的數據庫。

使時使用:

使用基于文件的數據存儲的一些普遍情況:

  • 嵌套的信息:

基于文件的數據存儲允許很深的嵌套,和復雜的數據結構。

  • JavaScript友好性:

基于文件的數據存儲的最具決定性的功能之一是他們與應用程序交互的方式:利用對JS友好的JSON。

基于圖形的NoSQL數據庫管理系統

基于圖形的數據存儲提供了一個非常獨特的功能,是任何其他數據庫管理系統無法相比的。

流行的基于圖形的數據庫

一些流行的基于圖形的數據庫如下:

  • OrientDB:

一個非常快速的基于圖形和文檔的混合 NoSQL 數據存儲,使用 Java 編寫,包含幾種不同的操作模式。

  • Neo4J:

一個非范式的,基于圖形的 Java 編寫的數據存儲,非常熱門而強大。

何時使用?

基于圖形的數據庫一些常見的使用情景如下:

  • 處理復雜的關聯信息:

如同在簡介中說過的一樣,圖形數據庫在處理復雜但相關聯的信息方面極其高效而易用。例如兩個實體和與它們不同層次間接連接的實體之間的關聯。

  • 建模和處理分類:

圖形數據庫尤擅牽涉到關系的各種情形。以關系的方式來建模數據、為各種數據分類,用這類數據庫可以處理得很好。

NoSQL數據庫與關系數據庫管理系統的比較

為了對NoSQL解決方案不同于關系數據庫管理系統之處有一個清晰畫面,讓我們創建一個快速的比較表:

何時使用NoSQL數據庫

  • 尺寸問題:

如果將具有非常大的數據集,來自NoSQL家族的數據庫管理系統更容易實現持續擴容。

  • 速度:

NoSQL數據庫通常更快,對于寫入來說有時非常快。讀取也可以很快,這取決于NoSQL數據庫的類型和查詢的數據。

  • Schema-free 的設計:

關系數據庫管理系統從一開始就需要結構化。NoSQL解決方案提供了大量的靈活性。

  • 自動(或簡單的復制/擴容):

NoSQL數據庫正在迅速增長,今天他們正在積極建立-廠商試圖解決共同的問題,其中一個顯然是復制和縮放。不像關系數據庫管理系統那樣,NoSQL解決方案可以很容易的在簇上擴容和工作。

  • 多重選擇:

當來選擇一個NoSQL數據存儲時,正如我們已經討論的,有多種模式,你可以從中選擇獲得最滿意的數據庫管理系統——這取決于你的數據類型。

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!