【小資說庫】第5期 OldSQL、NoSQL和NewSQL

      網友投稿 1639 2025-03-31

      在第2期數據庫發展歷史介紹中,我們介紹到數據庫經歷了人工管理階段、文件系統階段和數據庫系統階段,最終于上世紀70年代末發展進入了關系型數據庫。時至今日,關系型數據庫在風起云涌的數據庫江湖依然占有重要地位。

      在第3期的介紹中我們說到,SQL(Structured Query Language)及SQL標準圍繞的是關系數據庫。

      隨著計算機技術的發展,數據量的爆炸性增長,關系型數據庫在海量數據的存儲及并發讀寫上遇到了瓶頸,因此近些年涌現了NoSQL和NewSQL數據庫。那么,什么是NoSQL數據庫,什么是NewSQL數據庫呢?這一期我們來嘗試聊一聊。

      SQL,NoSQL及NewSQL淺析

      ——關于什么是NoSQL及NewSQL,小編嘗試查閱了一些材料。其中這篇CSDN博客中對OldSQL、NoSQL和NewSQL的對比做了較清晰的說明。以下內容主要轉載自此博客,小編只是基于自己的理解,稍做了些文字整理。信息量有些大,大家耐心閱讀。

      一、關系數據庫SQL,也叫OldSQL

      關系數據庫,是建立在關系模型基礎上的數據庫,借助于集合代數等數學概念和方法來處理數據庫中的數據。簡單來說,關系模型指的就是二維表格模型,而一個關系型數據庫就是由二維表及其之間的聯系所組成的一個數據組織。(編者注:有關什么是數據庫關系模型,及如何構建這種關系模型即數據庫建模,在很多數據庫教材和書籍中都能了解到~~)

      關系模型的常用概念

      關系:可以理解為一張二維表,每個關系都具有一個關系名,就是通常說的表名。

      ——編者注:這也是為什么數據庫使用過程中,會在一些返回信息中經常看到Relation身影的原因~~

      元組:可以理解為二維表中的一行,在數據庫中經常被稱為記錄。

      ——編者注:Tuple、元組、記錄,他們原來是同一身份(數據庫表中的一行)的不同馬甲。

      屬性:可以理解為二維表中的一列,在數據庫中經常被稱為字段。

      ——編者注:是的,列、字段、屬性是數據庫表中一列的不同馬甲。

      域:屬性的取值范圍,也就是數據庫中某一列的取值限制。

      關鍵字:一組可以唯一標識元組的屬性,數據庫中常稱為主鍵,由一個或多個列組成。

      關系模式:指對關系的描述。其格式為:關系名(屬性1,屬性2, … … ,屬性N),在數據庫中稱為表結構。

      關系型數據庫的優點:

      容易理解:二維表結構是非常貼近邏輯世界的一個概念,關系模型相對網狀、層次等其他模型來說更容易理解。

      使用方便:通用的SQL語言使得操作關系型數據庫非常方便。

      易于維護:豐富的完整性(實體完整性、參照完整性和用戶定義的完整性)大大減低了數據冗余和數據不一致的概率。

      關系型數據庫瓶頸

      高并發讀寫需求:用戶并發性非常高,往往達到每秒上萬次讀寫請求,對于傳統關系型數據庫來說,硬盤I/O是一個很大的瓶頸。

      海量數據的高效率讀寫: ?網站每天產生的數據量是巨大的,對于關系型數據庫來說,在一張包含海量數據的表中查詢,效率是非常低。

      高擴展性和可用性:在基于web的結構當中,數據庫是最難進行橫向擴展的,當一個應用系統的用戶量和訪問量與日俱增的時候,數據庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務的網站來說,對數據庫系統進行升級和擴展是非常痛苦的事情,往往需要停機維護和數據遷移。

      在關系型數據庫中,導致性能欠佳的最主要原因是多表的關聯查詢,以及復雜的數據分析類型的復雜SQL報表查詢。為了保證數據庫的ACID特性,我們必須盡量按照其要求的范式進行設計,關系型數據庫中的表都是存儲一個格式化的數據結構。每個元組字段的組成都是一樣,即使不是每個元組都需要所有的字段, 但數據庫會為每個元組分配所有的字段,這樣的結構可以便于表與表之間進行鏈接等操作,但從另一個角度來說它也是關系型數據庫性能瓶頸的一個因素。

      ——編者注:看來接下來的一期,我們有必要介紹ACID及數據庫范式了~~

      二、NoSQL

      近些年蓬勃發展的NoSQL系統最初是宣稱不再需要SQL的,但后來也不得不修正為Not Only SQL,意即”不僅僅是SQL”,來擁抱SQL。

      NoSQL指的是非關系型的數據庫。是對不同于傳統的關系型數據庫的數據庫管理系統的統稱。NoSQL用于超大規模數據的存儲。

      鍵值(Key-Value)存儲數據庫

      這一類數據庫主要會使用到一個哈希表,這個表中有一個特定的鍵和一個指針指向特定的數據。Key/value模型對于IT系統來說的優勢在于簡單、易部署。但是如果DBA只對部分值進行查詢或更新的時候,Key/value就顯得效率低下了。舉例如:Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB。

      列存儲數據庫。

      這部分數據庫通常是用來應對分布式存儲的海量數據。鍵仍然存在,但是它們的特點是指向了多個列。這些列是由列家族來安排的。如:Cassandra, HBase, Riak。

      文檔型數據庫

      文檔型數據庫的靈感是來自于Lotus Notes辦公軟件的,而且它同第一種鍵值存儲相類似。該類型的數據模型是版本化的文檔,半結構化的文檔以特定的格式存儲,比如JSON。文檔型數據庫可以看作是鍵值數據庫的升級版,允許之間嵌套鍵值。而且文檔型數據庫比鍵值數據庫的查詢效率更高。如:CouchDB, MongoDb. 國內也有文檔型數據庫SequoiaDB,已經開源。

      圖形(Graph)數據庫:

      圖形結構的數據庫同其他行列以及剛性結構的SQL數據庫不同,它是使用靈活的圖形模型,并且能夠擴展到多個服務器上。NoSQL數據庫沒有標準的查詢語言(SQL),因此進行數據庫查詢需要制定數據模型。許多NoSQL數據庫都有REST式的數據接口或者查詢API。如:Neo4J, InfoGrid, Infinite Graph。

      因此,我們總結NoSQL數據庫在以下的這幾種情況下比較適用:

      數據模型比較簡單;

      需要靈活性更強的IT系統;

      對數據庫性能要求較高;

      不需要高度的數據一致性;

      對于給定key,比較容易映射復雜值的環境。

      NoSQL的優勢

      易擴展

      NoSQL數據庫種類繁多,但是一個共同的特點都是去掉關系數據庫的關系型特性。數據之間無關系,這樣就非常容易擴展。也無形之間,在架構的層面上帶來了可擴展的能力。

      大數據量,高性能

      NoSQL數據庫都具有非常高的讀寫性能,尤其在大數據量下,同樣表現優秀。這得益于它的無關系性,數據庫的結構簡單。一般MySQL使用Query Cache,每次表的更新Cache就失效,是一種大粒度的Cache,在針對web2.0的交互頻繁的應用,Cache性能不高。而NoSQL的Cache是記錄級的,是一種細粒度的Cache,所以NoSQL在這個層面上來說就要性能高很多了。同時NoSQL 數據庫針對特定的數據模型(如文檔、鍵值和圖形)和訪問模式進行了優化,這與嘗試使用關系數據庫完成類似功能相比可實現更高的性能。

      靈活的數據模型

      NoSQL無需事先為要存儲的數據建立字段,隨時可以存儲自定義的數據格式。而在關系數據庫里,增刪字段是一件非常麻煩的事情。如果是非常大數據量的表,增加字段簡直就是一個噩夢。這點在大數據量的web2.0時代尤其明顯。

      高可用

      NoSQL在不太影響性能的情況,就可以方便的實現高可用的架構。比如Cassandra,HBase模型,通過復制模型也能實現高可用。

      NOSQL的缺點以及一些挑戰

      已有key-value數據庫產品大多是面向特定應用自治構建的,缺乏通用性;

      已有產品支持的功能有限(不支持事務特性),導致其應用具有一定的局限性;

      已有一些研究成果和改進的NoSQL數據存儲系統,但它們都是針對不同應用需求而提出的相應解決方案,如支持組內事務特性、彈性事務等,很少從全局考慮系統的通用性,也沒有形成系列化的研究成果;

      缺乏類似關系數據庫所具有的強有力的理論(如armstrong公理系統)、技術(如成熟的基于啟發式的優化策略、兩段封鎖協議等)、標準規范(如SQL語言)的支持。

      目前,HBase數據庫是安全特性最完善的NoSQL數據庫產品之一,而其他的NoSQL數據庫多數沒有提供內建的安全機制,但隨著NoSQL的發展,越來越多的人開始意識到安全的重要,部分NoSQL產品逐漸開始提供一些安全方面的支持。

      BASE原則以及CAP定理

      BASE原則:

      Basically Availble –基本可用

      Soft-state –軟狀態/柔性事務。 “Soft state” 可以理解為”無連接”的, 而 “Hard state” 是”面向連接”的

      【小資說庫】第5期 OldSQL、NoSQL和NewSQL

      Eventual Consistency – 最終一致性, 也是是 ACID 的最終目的。

      CAP定理:

      在計算機科學中, CAP定理(CAP theorem), 又被稱作 布魯爾定理(Brewer’s theorem), 它指出對于一個分布式計算系統來說,不可能同時滿足以下三點:

      一致性(Consistency) (所有節點在同一時間具有相同的數據)

      可用性(Availability) (保證每個請求不管成功或者失敗都有響應)

      分區容忍性(Partition tolerance) (系統中任意信息的丟失或失敗不會影響系統的繼續運作)

      CAP理論的核心是:一個分布式系統不可能同時很好的滿足一致性,可用性和分區容錯性這三個需求,最多只能同時較好的滿足兩個。

      因此,根據 CAP 原理將 NoSQL 數據庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類:

      CA - 單點集群,滿足一致性,可用性的系統,通常在可擴展性上不太強大。

      CP - 滿足一致性,分區容忍性的系統,通常性能不是特別高。

      AP - 滿足可用性,分區容忍性的系統,通常可能對一致性要求低一些。

      詳細請參見

      總結

      NoSQL數據庫的出現,彌補了關系數據(比如MySQL)在某些方面的不足,在某些方面能極大的節省開發成本和維護成本。 OldSQL和NoSQL都有各自的特點和使用的應用場景,兩者的緊密結合將會給web2.0的數據庫發展帶來新的思路。讓關系數據庫關注在關系上,NoSQL關注在存儲上。

      三、NewSQL

      NewSQL 是一種新型關系數據庫管理系統,是對各種新的可擴展/高性能數據庫的簡稱,這類數據庫不僅具有NoSQL對海量數據的存儲管理能力,試圖為聯機事務處理(OLTP)讀寫工作負載提供與NoSQL系統相同的可伸縮性能,還保持了傳統數據庫支持ACID和SQL等特性。

      因此,可以將典型NewSQL技術理解成分布式關系型數據庫,能夠支持分布式事務是一個基本前提。NoSQL與NewSQL在技術棧上有很多重疊,但在是否支持關系型模型及對復雜事務的支持力度上是存在明顯區別的。

      NewSQL分類

      NewSQL系統雖然在的內部結構變化很大,但是它們有兩個顯著的共同特點:(1)它們都支持關系數據模型,(2) 它們都使用SQL作為其主要的接口。目前NewSQL系統大致分三類:

      新架構:這一類型的NewSQL系統是全新的數據庫平臺,它們均采取了不同的設計方法。

      數據庫工作在一個分布式集群的節點上,其中每個節點擁有一個數據子集。 SQL查詢被分成查詢片段發送給自己所在的數據的節點上執行。這些數據庫可以通過添加額外的節點來線性擴展。現有的這類數據庫有: Google Spanner, VoltDB, Clustrix, NuoDB.

      數據庫系統通常有一個單一的主節點的數據源。它們有一組節點用來做事務處理,這些節點接到特定的SQL查詢后,會把它所需的所有數據從主節點上取回來后執行SQL查詢,再返回結果。

      SQL引擎:這一類是高度優化的SQL存儲引擎。這些系統提供了MySQL相同的編程接口,但擴展性比內置的引擎InnoDB更好。這類數據庫系統有:TokuDB, MemSQL。

      透明分片:這一類系統提供了分片的中間件層,數據庫自動分割在多個節點運行。這類數據庫包括:ScaleBase,dbShards, Scalearc。

      ---------------------------------------------------------------------我是華麗麗的分割線---------------------------------------------------------------------

      那在數據庫選型時,如何在 SQL、NewSQL、NoSQL 之間進行取舍呢?下面兩張圖能很形象地幫助到你。

      圖片摘自:https://blog.csdn.net/defonds/article/details/48471087

      圖1 SQL vs. NewSQL vs. NoSQL

      圖2Do I Need SQL or Hadoop?

      NoSQL 存儲 數據庫

      版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。

      版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。

      上一篇:一列數據中有很多重復的內容,怎么刪除重復(刪除同一列中的重復數據)
      下一篇:怎樣設置wps的自動存儲位置,我想弄成D盤,可他默認是C盤(c盤wps可以轉到D盤嗎)
      相關文章
      亚洲精品福利网泷泽萝拉| 亚洲综合一区二区精品导航| 亚洲成a人片在线观看播放| 久久亚洲国产欧洲精品一| 国产成人综合亚洲AV第一页| 国产午夜亚洲精品不卡电影| 国产AV无码专区亚洲AV蜜芽| 国产精品无码亚洲一区二区三区| 亚洲精品国产精品| 无码亚洲成a人在线观看| 亚洲AV无码AV日韩AV网站| 国产精品亚洲AV三区| 亚洲av手机在线观看| 激情无码亚洲一区二区三区| 亚洲AV无码一区二区三区网址| 亚洲码和欧洲码一码二码三码| 亚洲国产精品无码久久98| 免费在线观看亚洲| 亚洲人妻av伦理| 亚洲熟妇中文字幕五十中出| 亚洲AV无码一区二区三区DV| 亚洲AV福利天堂一区二区三| 亚洲精品视频免费在线观看| 亚洲一区二区三区国产精品无码| 狠狠色伊人亚洲综合网站色| 午夜亚洲国产理论片二级港台二级 | 精品久久亚洲一级α| 丰满亚洲大尺度无码无码专线 | 无码天堂亚洲国产AV| 亚洲Av无码乱码在线znlu| 国产偷国产偷亚洲高清日韩| 一本久久a久久精品亚洲| 亚洲成A人片777777| 亚洲视频在线一区二区三区| 亚洲一区二区三区免费视频| 亚洲人成网站免费播放| 亚洲av麻豆aⅴ无码电影| 久久亚洲高清综合| 亚洲AV天天做在线观看| 亚洲精品一区二区三区四区乱码| 456亚洲人成在线播放网站|