1、鍵值(Key-Value)存儲數(shù)據(jù)庫
成都創(chuàng)新互聯(lián)長期為上1000+客戶提供的網(wǎng)站建設服務,團隊從業(yè)經(jīng)驗10年,關(guān)注不同地域、不同群體,并針對不同對象提供差異化的產(chǎn)品和服務;打造開放共贏平臺,與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為欽南企業(yè)提供專業(yè)的成都網(wǎng)站設計、成都網(wǎng)站建設,欽南網(wǎng)站改版等技術(shù)服務。擁有10年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
這一類數(shù)據(jù)庫主要會使用到一個哈希表,這個表中有一個特定的鍵和一個指針指向特定的數(shù)據(jù)。Key/value模型對于IT系統(tǒng)來說的優(yōu)勢在于簡單、易部署。
但是如果數(shù)據(jù)庫管理員(DBA)只對部分值進行查詢或更新的時候,Key/value就顯得效率低下了。舉例如:Tokyo Cabinet/Tyrant,Redis,Voldemort,Oracle BDB。
2、列存儲數(shù)據(jù)庫
這部分數(shù)據(jù)庫通常用來應對分布式存儲的海量數(shù)據(jù)。鍵仍然存在,但是它們的特點是指向了多個列。這些列是由列家族來安排的。如:Cassandra,HBase,Riak。
3、文檔型數(shù)據(jù)庫
文檔型數(shù)據(jù)庫的靈感是來自于Lotus Notes辦公軟件的,而且它同第一種鍵值存儲相類似。該類型的數(shù)據(jù)模型是版本化的文檔,半結(jié)構(gòu)化的文檔以特定的格式存儲,比如JSON。
文檔型數(shù)據(jù)庫可以看作是鍵值數(shù)據(jù)庫的升級版,允許之間嵌套鍵值,在處理網(wǎng)頁等復雜數(shù)據(jù)時,文檔型數(shù)據(jù)庫比傳統(tǒng)鍵值數(shù)據(jù)庫的查詢效率更高。如:CouchDB,MongoDb,國內(nèi)也有文檔型數(shù)據(jù)庫SequoiaDB,已經(jīng)開源。
4、圖形(Graph)數(shù)據(jù)庫
圖形結(jié)構(gòu)的數(shù)據(jù)庫同其他行列以及剛性結(jié)構(gòu)的SQL數(shù)據(jù)庫不同,它是使用靈活的圖形模型,并且能夠擴展到多個服務器上。
NoSQL數(shù)據(jù)庫沒有標準的查詢語言(SQL),因此進行數(shù)據(jù)庫查詢需要制定數(shù)據(jù)模型。許多NoSQL數(shù)據(jù)庫都有REST式的數(shù)據(jù)接口或者查詢API。如:Neo4J,InfoGrid,Infinite Graph。
擴展資料
NoSQL數(shù)據(jù)庫適合追求速度和可擴展性、業(yè)務多變的應用場景。對于非結(jié)構(gòu)化數(shù)據(jù)的處理更合適,如文章、評論,這些數(shù)據(jù)如全文搜索、機器學習通常只用于模糊處理,并不需要像結(jié)構(gòu)化數(shù)據(jù)一樣,進行精確查詢,而且這類數(shù)據(jù)的數(shù)據(jù)規(guī)模往往是海量的,數(shù)據(jù)規(guī)模的增長往往也是不可能預期的。
而NoSQL數(shù)據(jù)庫的擴展能力幾乎也是無限的,所以NoSQL數(shù)據(jù)庫可以很好地滿足這一類數(shù)據(jù)的存儲。NoSQL數(shù)據(jù)庫利用key-value可以大量的獲取大量的非結(jié)構(gòu)化數(shù)據(jù),并且數(shù)據(jù)的獲取效率很高,但用它查詢結(jié)構(gòu)化數(shù)據(jù)效果就比較差。
參考資料來源:百度百科-數(shù)據(jù)庫
參考資料來源:百度百科-NoSQL
2. 什么是NoSQL?
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,
泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起,傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應付web2.0網(wǎng)站,特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心,暴露了很多難以克服的問題,而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn),尤其是大數(shù)據(jù)應用難題,包括超大規(guī)模數(shù)據(jù)的存儲。
(例如谷歌或Facebook每天為他們的用戶收集萬億比特的數(shù)據(jù))。這些類型的數(shù)據(jù)存儲不需要固定的模式,無需多余操作就可以橫向擴展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 關(guān)系型數(shù)據(jù)庫與NoSQL的區(qū)別?
3.1 RDBMS
高度組織化結(jié)構(gòu)化數(shù)據(jù)
結(jié)構(gòu)化查詢語言(SQL)
數(shù)據(jù)和關(guān)系都存儲在單獨的表中。
數(shù)據(jù)操縱語言,數(shù)據(jù)定義語言
嚴格的一致性
基礎事務
ACID
關(guān)系型數(shù)據(jù)庫遵循ACID規(guī)則
事務在英文中是transaction,和現(xiàn)實世界中的交易很類似,它有如下四個特性:
A (Atomicity) 原子性
原子性很容易理解,也就是說事務里的所有操作要么全部做完,要么都不做,事務成功的條件是事務里的所有操作都成功,只要有一個操作失敗,整個事務就失敗,需要回滾。比如銀行轉(zhuǎn)賬,從A賬戶轉(zhuǎn)100元至B賬戶,分為兩個步驟:1)從A賬戶取100元;2)存入100元至B賬戶。這兩步要么一起完成,要么一起不完成,如果只完成第一步,第二步失敗,錢會莫名其妙少了100元。
C (Consistency) 一致性
一致性也比較容易理解,也就是說數(shù)據(jù)庫要一直處于一致的狀態(tài),事務的運行不會改變數(shù)據(jù)庫原本的一致性約束。
I (Isolation) 獨立性
所謂的獨立性是指并發(fā)的事務之間不會互相影響,如果一個事務要訪問的數(shù)據(jù)正在被另外一個事務修改,只要另外一個事務未提交,它所訪問的數(shù)據(jù)就不受未提交事務的影響。比如現(xiàn)有有個交易是從A賬戶轉(zhuǎn)100元至B賬戶,在這個交易還未完成的情況下,如果此時B查詢自己的賬戶,是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事務提交后,它所做的修改將會永久的保存在數(shù)據(jù)庫上,即使出現(xiàn)宕機也不會丟失。
3.2 NoSQL
代表著不僅僅是SQL
沒有聲明性查詢語言
沒有預定義的模式
鍵 - 值對存儲,列存儲,文檔存儲,圖形數(shù)據(jù)庫
最終一致性,而非ACID屬性
非結(jié)構(gòu)化和不可預知的數(shù)據(jù)
CAP定理
高性能,高可用性和可伸縮性
分布式數(shù)據(jù)庫中的CAP原理(了解)
CAP定理:
Consistency(一致性), 數(shù)據(jù)一致更新,所有數(shù)據(jù)變動都是同步的
Availability(可用性), 好的響應性能
Partition tolerance(分區(qū)容錯性) 可靠性
P: 系統(tǒng)中任意信息的丟失或失敗不會影響系統(tǒng)的繼續(xù)運作。
定理:任何分布式系統(tǒng)只可同時滿足二點,沒法三者兼顧。
CAP理論的核心是:一個分布式系統(tǒng)不可能同時很好的滿足一致性,可用性和分區(qū)容錯性這三個需求,
因此,根據(jù) CAP 原理將 NoSQL 數(shù)據(jù)庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類:
CA - 單點集群,滿足一致性,可用性的系統(tǒng),通常在可擴展性上不太強大。
CP - 滿足一致性,分區(qū)容忍性的系統(tǒng),通常性能不是特別高。
AP - 滿足可用性,分區(qū)容忍性的系統(tǒng),通??赡軐σ恢滦砸蟮鸵恍?。
CAP理論就是說在分布式存儲系統(tǒng)中,最多只能實現(xiàn)上面的兩點。
而由于當前的網(wǎng)絡硬件肯定會出現(xiàn)延遲丟包等問題,所以分區(qū)容忍性是我們必須需要實現(xiàn)的。
所以我們只能在一致性和可用性之間進行權(quán)衡,沒有NoSQL系統(tǒng)能同時保證這三點。
說明:C:強一致性 A:高可用性 P:分布式容忍性
舉例:
CA:傳統(tǒng)Oracle數(shù)據(jù)庫
AP:大多數(shù)網(wǎng)站架構(gòu)的選擇
CP:Redis、Mongodb
注意:分布式架構(gòu)的時候必須做出取舍。
一致性和可用性之間取一個平衡。多余大多數(shù)web應用,其實并不需要強一致性。
因此犧牲C換取P,這是目前分布式數(shù)據(jù)庫產(chǎn)品的方向。
4. 當下NoSQL的經(jīng)典應用
當下的應用是 SQL 與 NoSQL 一起使用的。
代表項目:阿里巴巴商品信息的存放。
去 IOE 化。
ps:I 是指 IBM 的小型機,很貴的,好像好幾萬一臺;O 是指 Oracle 數(shù)據(jù)庫,也很貴的,好幾萬呢;M 是指 EMC 的存儲設備,也很貴的。
難點:
數(shù)據(jù)類型多樣性。
數(shù)據(jù)源多樣性和變化重構(gòu)。
數(shù)據(jù)源改造而服務平臺不需要大面積重構(gòu)。
舉例說明如下:
銀行A賬戶向B賬戶匯款100元,數(shù)據(jù)庫執(zhí)行如下過程
從A賬戶減少100元,然后在B賬戶增加100元,這個過程稱為一個事務
但是:
如果從A賬戶減少100元后系統(tǒng)出故障了或者出現(xiàn)了其他意外造成B賬戶沒有增加100元(這種事情相信無論是誰遇到也會很無語吧?好吧言歸正傳)這種情況稱為事務不一致,因為一個事務沒有做完,所以數(shù)據(jù)庫會將整個過程回滾,你可以理解為就當什么事也沒發(fā)生過,這種回滾機制就是事務的一種特征,目的就是為了保持數(shù)據(jù)庫的數(shù)據(jù)庫的事務一致性。
文檔數(shù)據(jù)庫
源起:受Lotus Notes啟發(fā)。
數(shù)據(jù)模型:包含了key-value的文檔集合
例子:CouchDB, MongoDB
優(yōu)點:數(shù)據(jù)模型自然,編程友好,快速開發(fā),web友好,CRUD。
圖數(shù)據(jù)庫
源起: 歐拉和圖理論。
數(shù)據(jù)模型:節(jié)點和關(guān)系,也可處理鍵值對。
例子:AllegroGraph, InfoGrid, Neo4j
優(yōu)點:解決復雜的圖問題。
關(guān)系數(shù)據(jù)庫
源起: E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的
數(shù)據(jù)模型:各種關(guān)系
例子:VoltDB, Clustrix, MySQL
優(yōu)點:高性能、可擴展的OLTP,支持SQL,物化視圖,支持事務,編程友好。
對象數(shù)據(jù)庫
源起:圖數(shù)據(jù)庫研究
數(shù)據(jù)模型:對象
例子:Objectivity, Gemstone
優(yōu)點:復雜對象模型,快速鍵值訪問,鍵功能訪問,以及圖數(shù)據(jù)庫的優(yōu)點。
Key-Value數(shù)據(jù)庫
源起:Amazon的論文 Dynamo 和 Distributed HashTables。
數(shù)據(jù)模型:鍵值對
例子:Membase, Riak
優(yōu)點:處理大量數(shù)據(jù),快速處理大量讀寫請求。編程友好。
BigTable類型數(shù)據(jù)庫
源起:Google的論文 BigTable。
數(shù)據(jù)模型:列簇,每一行在理論上都是不同的
例子:HBase, Hypertable, Cassandra
優(yōu)點:處理大量數(shù)據(jù),應對極高寫負載,高可用,支持跨數(shù)據(jù)中心, MapReduce。
數(shù)據(jù)結(jié)構(gòu)服務
源起: ?
數(shù)據(jù)模型:字典操作,lists, sets和字符串值
例子:Redis
優(yōu)點:不同于以前的任何數(shù)據(jù)庫
網(wǎng)格數(shù)據(jù)庫
源起:數(shù)據(jù)網(wǎng)格和元組空間研究。
數(shù)據(jù)模型:基于空間的架構(gòu)
例子:GigaSpaces, Coherence
優(yōu)點:適于事務處理的高性能和高擴展性
基本含義NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,是一項全新的數(shù)據(jù)庫革命性運動,早期就有人提出,發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護者們提倡運用非關(guān)系型的數(shù)據(jù)存儲,相對于鋪天蓋地的關(guān)系型數(shù)據(jù)庫運用,這一概念無疑是一種全新的思維的注入。NoSQLNoSQL數(shù)據(jù)庫的四大分類鍵值(Key-Value)存儲數(shù)據(jù)庫這一類數(shù)據(jù)庫主要會使用到一個哈希表,這個表中有一個特定的鍵和一個指針指向特定的數(shù)據(jù)。Key/value模型對于IT系統(tǒng)來說的優(yōu)勢在于簡單、易部署。但是如果DBA只對部分值進行查詢或更新的時候,Key/value就顯得效率低下了。[3] 舉例如:Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.列存儲數(shù)據(jù)庫。這部分數(shù)據(jù)庫通常是用來應對分布式存儲的海量數(shù)據(jù)。鍵仍然存在,但是它們的特點是指向了多個列。這些列是由列家族來安排的。如:Cassandra, HBase, Riak.文檔型數(shù)據(jù)庫文檔型數(shù)據(jù)庫的靈感是來自于Lotus Notes辦公軟件的,而且它同第一種鍵值存儲相類似。該類型的數(shù)據(jù)模型是版本化的文檔,半結(jié)構(gòu)化的文檔以特定的格式存儲,比如JSON。文檔型數(shù)據(jù)庫可 以看作是鍵值數(shù)據(jù)庫的升級版,允許之間嵌套鍵值。而且文檔型數(shù)據(jù)庫比鍵值數(shù)據(jù)庫的查詢效率更高。如:CouchDB, MongoDb. 國內(nèi)也有文檔型數(shù)據(jù)庫SequoiaDB,已經(jīng)開源。圖形(Graph)數(shù)據(jù)庫圖形結(jié)構(gòu)的數(shù)據(jù)庫同其他行列以及剛性結(jié)構(gòu)的SQL數(shù)據(jù)庫不同,它是使用靈活的圖形模型,并且能夠擴展到多個服務器上。NoSQL數(shù)據(jù)庫沒有標準的查詢語言(SQL),因此進行數(shù)據(jù)庫查詢需要制定數(shù)據(jù)模型。許多NoSQL數(shù)據(jù)庫都有REST式的數(shù)據(jù)接口或者查詢API。[2] 如:Neo4J, InfoGrid, Infinite Graph.因此,我們總結(jié)NoSQL數(shù)據(jù)庫在以下的這幾種情況下比較適用:1、數(shù)據(jù)模型比較簡單;2、需要靈活性更強的IT系統(tǒng);3、對數(shù)據(jù)庫性能要求較高;4、不需要高度的數(shù)據(jù)一致性;5、對于給定key,比較容易映射復雜值的環(huán)境。