小編給大家分享一下關(guān)系數(shù)據(jù)庫(kù)和nosql的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

發(fā)展壯大離不開廣大客戶長(zhǎng)期以來的信賴與支持，我們將始終秉承“誠(chéng)信為本、服務(wù)至上”的服務(wù)理念，堅(jiān)持“二合一”的優(yōu)良服務(wù)模式，真誠(chéng)服務(wù)每家企業(yè)，認(rèn)真做好每個(gè)細(xì)節(jié)，不斷完善自我，成就企業(yè)，實(shí)現(xiàn)共贏。行業(yè)涉及自上料攪拌車等，在成都網(wǎng)站建設(shè)、全網(wǎng)營(yíng)銷推廣、WAP手機(jī)網(wǎng)站、VI設(shè)計(jì)、軟件開發(fā)等項(xiàng)目上具有豐富的設(shè)計(jì)經(jīng)驗(yàn)。

NoSQL概念

隨著web2.0的快速發(fā)展，非關(guān)系型、分布式數(shù)據(jù)存儲(chǔ)得到了快速的發(fā)展，它們不保證關(guān)系數(shù)據(jù)的ACID特性。NoSQL概念在2009年被提了出來。NoSQL最常見的解釋是“non-relational”，“Not
Only SQL”也被很多人接受。（“NoSQL”一詞最早于1998年被用于一個(gè)輕量級(jí)的關(guān)系數(shù)據(jù)庫(kù)的名字。）

NoSQL被我們用得最多的當(dāng)數(shù)key-value存儲(chǔ)，當(dāng)然還有其他的文檔型的、列存儲(chǔ)、圖型數(shù)據(jù)庫(kù)、xml數(shù)據(jù)庫(kù)等。在NoSQL概念提出之前，這些數(shù)據(jù)庫(kù)就被用于各種系統(tǒng)當(dāng)中，但是卻很少用于web互聯(lián)網(wǎng)應(yīng)用。比如cdb、qdbm、bdb數(shù)據(jù)庫(kù)。

傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的瓶頸

傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)具有不錯(cuò)的性能，高穩(wěn)定型，久經(jīng)歷史考驗(yàn)，而且使用簡(jiǎn)單，功能強(qiáng)大，同時(shí)也積累了大量的成功案例。在互聯(lián)網(wǎng)領(lǐng)域，MySQL成為了絕對(duì)靠前的王者，毫不夸張的說，MySQL為互聯(lián)網(wǎng)的發(fā)展做出了卓越的貢獻(xiàn)。

在90年代，一個(gè)網(wǎng)站的訪問量一般都不大，用單個(gè)數(shù)據(jù)庫(kù)完全可以輕松應(yīng)付。在那個(gè)時(shí)候，更多的都是靜態(tài)網(wǎng)頁(yè)，動(dòng)態(tài)交互類型的網(wǎng)站不多。

到了最近10年，網(wǎng)站開始快速發(fā)展?；鸨恼搲⒉┛?、sns、微博逐漸引領(lǐng)web領(lǐng)域的潮流。在初期，論壇的流量其實(shí)也不大，如果你接觸網(wǎng)絡(luò)比較早，你可能還記得那個(gè)時(shí)候還有文本型存儲(chǔ)的論壇程序，可以想象一般的論壇的流量有多大。

Memcached+MySQL

后來，隨著訪問量的上升，幾乎大部分使用MySQL架構(gòu)的網(wǎng)站在數(shù)據(jù)庫(kù)上都開始出現(xiàn)了性能問題，web程序不再僅僅專注在功能上，同時(shí)也在追求性能。程序員們開始大量的使用緩存技術(shù)來緩解數(shù)據(jù)庫(kù)的壓力，優(yōu)化數(shù)據(jù)庫(kù)的結(jié)構(gòu)和索引。開始比較流行的是通過文件緩存來緩解數(shù)據(jù)庫(kù)壓力，但是當(dāng)訪問量繼續(xù)增大的時(shí)候，多臺(tái)web機(jī)器通過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個(gè)時(shí)候，Memcached就自然的成為一個(gè)非常時(shí)尚的技術(shù)產(chǎn)品。

Memcached作為一個(gè)獨(dú)立的分布式的緩存服務(wù)器，為多個(gè)web服務(wù)器提供了一個(gè)共享的高性能緩存服務(wù)，在Memcached服務(wù)器上，又發(fā)展了根據(jù)hash算法來進(jìn)行多臺(tái)Memcached緩存服務(wù)的擴(kuò)展，然后又出現(xiàn)了一致性hash來解決增加或減少緩存服務(wù)器導(dǎo)致重新hash帶來的大量緩存失效的弊端。當(dāng)時(shí)，如果你去面試，你說你有Memcached經(jīng)驗(yàn)，肯定會(huì)加分的。

Mysql主從讀寫分離

由于數(shù)據(jù)庫(kù)的寫入壓力增加，Memcached只能緩解數(shù)據(jù)庫(kù)的讀取壓力。讀寫集中在一個(gè)數(shù)據(jù)庫(kù)上讓數(shù)據(jù)庫(kù)不堪重負(fù)，大部分網(wǎng)站開始使用主從復(fù)制技術(shù)來達(dá)到讀寫分離，以提高讀寫性能和讀庫(kù)的可擴(kuò)展性。Mysql的master-slave模式成為這個(gè)時(shí)候的網(wǎng)站標(biāo)配了。

分表分庫(kù)

隨著web2.0的繼續(xù)高速發(fā)展，在Memcached的高速緩存，MySQL的主從復(fù)制，讀寫分離的基礎(chǔ)之上，這時(shí)MySQL主庫(kù)的寫壓力開始出現(xiàn)瓶頸，而數(shù)據(jù)量的持續(xù)猛增，由于MyISAM使用表鎖，在高并發(fā)下會(huì)出現(xiàn)嚴(yán)重的鎖問題，大量的高并發(fā)MySQL應(yīng)用開始使用InnoDB引擎(行鎖)代替MyISAM。同時(shí)，開始流行使用分表分庫(kù)來緩解寫壓力和數(shù)據(jù)增長(zhǎng)的擴(kuò)展問題。這個(gè)時(shí)候，分表分庫(kù)成了一個(gè)熱門技術(shù)，是面試的熱門問題也是業(yè)界討論的熱門技術(shù)問題。也就在這個(gè)時(shí)候，MySQL推出了還不太穩(wěn)定的表分區(qū)，這也給技術(shù)實(shí)力一般的公司帶來了希望。雖然MySQL推出了MySQL
Cluster集群，但是由于在互聯(lián)網(wǎng)幾乎沒有成功案例，性能也不能滿足互聯(lián)網(wǎng)的要求，只是在高可靠性上提供了非常大的保證。

MySQL的擴(kuò)展性瓶頸

在互聯(lián)網(wǎng)，大部分的MySQL都應(yīng)該是IO密集型的，事實(shí)上，如果你的MySQL是個(gè)CPU密集型的話，那么很可能你的MySQL設(shè)計(jì)得有性能問題，需要優(yōu)化了。大數(shù)據(jù)量高并發(fā)環(huán)境下的MySQL應(yīng)用開發(fā)越來越復(fù)雜，也越來越具有技術(shù)挑戰(zhàn)性。分表分庫(kù)的規(guī)則把握都是需要經(jīng)驗(yàn)的。雖然有像淘寶這樣技術(shù)實(shí)力強(qiáng)大的公司開發(fā)了透明的中間件層來屏蔽開發(fā)者的復(fù)雜性，但是避免不了整個(gè)架構(gòu)的復(fù)雜性。分庫(kù)分表的子庫(kù)到一定階段又面臨擴(kuò)展問題。還有就是需求的變更，可能又需要一種新的分庫(kù)方式。

MySQL數(shù)據(jù)庫(kù)也經(jīng)常存儲(chǔ)一些大文本字段，導(dǎo)致數(shù)據(jù)庫(kù)表非常的大，在做數(shù)據(jù)庫(kù)恢復(fù)的時(shí)候就導(dǎo)致非常的慢，不容易快速恢復(fù)數(shù)據(jù)庫(kù)。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數(shù)據(jù)從MySQL省去，MySQL將變得非常的小。

關(guān)系數(shù)據(jù)庫(kù)很強(qiáng)大，但是它并不能很好的應(yīng)付所有的應(yīng)用場(chǎng)景。MySQL的擴(kuò)展性差（需要復(fù)雜的技術(shù)來實(shí)現(xiàn)），大數(shù)據(jù)下IO壓力大，表結(jié)構(gòu)更改困難，正是當(dāng)前使用MySQL的開發(fā)人員面臨的問題。

NOSQL的優(yōu)勢(shì)

易擴(kuò)展

NoSQL數(shù)據(jù)庫(kù)種類繁多，但是一個(gè)共同的特點(diǎn)都是去掉關(guān)系數(shù)據(jù)庫(kù)的關(guān)系型特性。數(shù)據(jù)之間無關(guān)系，這樣就非常容易擴(kuò)展。也無形之間，在架構(gòu)的層面上帶來了可擴(kuò)展的能力。

大數(shù)據(jù)量，高性能

NoSQL數(shù)據(jù)庫(kù)都具有非常高的讀寫性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)秀。這得益于它的無關(guān)系性，數(shù)據(jù)庫(kù)的結(jié)構(gòu)簡(jiǎn)單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對(duì)web2.0的交互頻繁的應(yīng)用，Cache性能不高。而NoSQL的Cache是記錄級(jí)的，是一種細(xì)粒度的Cache，所以NoSQL在這個(gè)層面上來說就要性能高很多了。

靈活的數(shù)據(jù)模型

NoSQL無需事先為要存儲(chǔ)的數(shù)據(jù)建立字段，隨時(shí)可以存儲(chǔ)自定義的數(shù)據(jù)格式。而在關(guān)系數(shù)據(jù)庫(kù)里，增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表，增加字段簡(jiǎn)直就是一個(gè)噩夢(mèng)。這點(diǎn)在大數(shù)據(jù)量的web2.0時(shí)代尤其明顯。

高可用

NoSQL在不太影響性能的情況，就可以方便的實(shí)現(xiàn)高可用的架構(gòu)。比如Cassandra，HBase模型，通過復(fù)制模型也能實(shí)現(xiàn)高可用。

總結(jié)

NoSQL數(shù)據(jù)庫(kù)的出現(xiàn)，彌補(bǔ)了關(guān)系數(shù)據(jù)（比如MySQL）在某些方面的不足，在某些方面能極大的節(jié)省開發(fā)成本和維護(hù)成本。

MySQL和NoSQL都有各自的特點(diǎn)和使用的應(yīng)用場(chǎng)景，兩者的緊密結(jié)合將會(huì)給web2.0的數(shù)據(jù)庫(kù)發(fā)展帶來新的思路。讓關(guān)系數(shù)據(jù)庫(kù)關(guān)注在關(guān)系上，NoSQL關(guān)注在存儲(chǔ)上。

NoSQL的分類

NoSQL僅僅是一個(gè)概念，NoSQL數(shù)據(jù)庫(kù)根據(jù)數(shù)據(jù)的存儲(chǔ)模型和特點(diǎn)分為很多種類。

類型	部分代表	特點(diǎn)
列存儲(chǔ)	Hbase Cassandra Hypertable	顧名思義，是按列存儲(chǔ)數(shù)據(jù)的。較大的特點(diǎn)是方便存儲(chǔ)結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)，方便做數(shù)據(jù)壓縮，對(duì)針對(duì)某一列或者某幾列的查詢有非常大的IO優(yōu)勢(shì)。
文檔存儲(chǔ)	MongoDB CouchDB	文檔存儲(chǔ)一般用類似json的格式存儲(chǔ)，存儲(chǔ)的內(nèi)容是文檔型的。這樣也就有有機(jī)會(huì)對(duì)某些字段建立索引，實(shí)現(xiàn)關(guān)系數(shù)據(jù)庫(kù)的某些功能。
key-value存儲(chǔ)	Tokyo Cabinet / Tyrant Berkeley DB MemcacheDB Redis	可以通過key快速查詢到其value。一般來說，存儲(chǔ)不管value的格式，照單全收。（Redis包含了其他功能）
圖存儲(chǔ)	Neo4J FlockDB	圖形關(guān)系的很好存儲(chǔ)。使用傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)來解決的話性能低下，而且設(shè)計(jì)使用不方便。
對(duì)象存儲(chǔ)	db4o Versant	通過類似面向?qū)ο笳Z言的語法操作數(shù)據(jù)庫(kù)，通過對(duì)象的方式存取數(shù)據(jù)。
xml數(shù)據(jù)庫(kù)	Berkeley DB XML BaseX	高效的存儲(chǔ)XML數(shù)據(jù)，并支持XML的內(nèi)部查詢語法，比如XQuery,Xpath。

以上NoSQL數(shù)據(jù)庫(kù)類型的劃分并不是絕對(duì)，只是從存儲(chǔ)模型上來進(jìn)行的大體劃分。它們之間沒有絕對(duì)的分界，也有交差的情況，比如Tokyo Cabinet / Tyrant的Table類型存儲(chǔ)，就可以理解為是文檔型存儲(chǔ)，Berkeley DB XML數(shù)據(jù)庫(kù)是基于Berkeley DB之上開發(fā)的。

NoSQL還是關(guān)系數(shù)據(jù)庫(kù)

雖然09年出現(xiàn)了比較激進(jìn)的文章《關(guān)系數(shù)據(jù)庫(kù)已死》，但是我們心里都清楚，關(guān)系數(shù)據(jù)庫(kù)其實(shí)還活得好好的，你還不能不用關(guān)系數(shù)據(jù)庫(kù)。但是也說明了一個(gè)事實(shí)，關(guān)系數(shù)據(jù)庫(kù)在處理WEB2.0數(shù)據(jù)的時(shí)候，的確已經(jīng)出現(xiàn)了瓶頸。

那么我們到底是用NoSQL還是關(guān)系數(shù)據(jù)庫(kù)呢？我想我們沒有必要來進(jìn)行一個(gè)絕對(duì)的回答。我們需要根據(jù)我們的應(yīng)用場(chǎng)景來決定我們到底用什么。

如果關(guān)系數(shù)據(jù)庫(kù)在你的應(yīng)用場(chǎng)景中，完全能夠很好的工作，而你又是非常善于使用和維護(hù)關(guān)系數(shù)據(jù)庫(kù)的，那么我覺得你完全沒有必要遷移到NoSQL上面，除非你是個(gè)喜歡折騰的人。如果你是在金融，電信等以數(shù)據(jù)為王的關(guān)鍵領(lǐng)域，目前使用的是Oracle數(shù)據(jù)庫(kù)來提供高可靠性的，除非遇到特別大的瓶頸，不然也別貿(mào)然嘗試NoSQL。

然而，在WEB2.0的網(wǎng)站中，關(guān)系數(shù)據(jù)庫(kù)大部分都出現(xiàn)了瓶頸。在磁盤IO、數(shù)據(jù)庫(kù)可擴(kuò)展上都花費(fèi)了開發(fā)人員相當(dāng)多的精力來優(yōu)化，比如做分表分庫(kù)（database sharding）、主從復(fù)制、異構(gòu)復(fù)制等等，然而，這些工作需要的技術(shù)能力越來越高，也越來越具有挑戰(zhàn)性。如果你正在經(jīng)歷這些場(chǎng)合，那么我覺得你應(yīng)該嘗試一下NoSQL了。

選擇合適的NoSQL

如此多類型的NoSQL，而每種類型的NoSQL又有很多，到底選擇什么類型的NoSQL來作為我們的存儲(chǔ)呢？這并不是一個(gè)很好回答的問題，影響我們選擇的因素有很多，而選擇也可能有多種，隨著業(yè)務(wù)場(chǎng)景，需求的變更可能選擇又會(huì)變化。我們常常需要根據(jù)如下情況考慮：

1. 數(shù)據(jù)結(jié)構(gòu)特點(diǎn)。包括結(jié)構(gòu)化、半結(jié)構(gòu)化、字段是否可能變更、是否有大文本字段、數(shù)據(jù)字段是否可能變化。

2. 寫入特點(diǎn)。包括insert比例、update比例、是否經(jīng)常更新數(shù)據(jù)的某一個(gè)小字段、原子更新需求。

3. 查詢特點(diǎn)。包括查詢的條件、查詢熱點(diǎn)的范圍。比如用戶信息的查詢，可能就是隨機(jī)的，而新聞的查詢就是按照時(shí)間，越新的越頻繁。

NoSQL和關(guān)系數(shù)據(jù)庫(kù)結(jié)合

其實(shí)NoSQL數(shù)據(jù)庫(kù)僅僅是關(guān)系數(shù)據(jù)庫(kù)在某些方面（性能，擴(kuò)展）的一個(gè)彌補(bǔ)，單從功能上講，NoSQL的幾乎所有的功能，在關(guān)系數(shù)據(jù)庫(kù)上都能夠滿足，所以選擇NoSQL的原因并不在功能上。

所以，我們一般會(huì)把NoSQL和關(guān)系數(shù)據(jù)庫(kù)進(jìn)行結(jié)合使用，各取所長(zhǎng)，需要使用關(guān)系特性的時(shí)候我們使用關(guān)系數(shù)據(jù)庫(kù)，需要使用NoSQL特性的時(shí)候我們使用NoSQL數(shù)據(jù)庫(kù)，各得其所。

舉個(gè)簡(jiǎn)單的例子吧，比如用戶評(píng)論的存儲(chǔ)，評(píng)論大概有主鍵id、評(píng)論的對(duì)象aid、評(píng)論內(nèi)容content、用戶uid等字段。我們能確定的是評(píng)論內(nèi)容content肯定不會(huì)在數(shù)據(jù)庫(kù)中用where content=’’查詢，評(píng)論內(nèi)容也是一個(gè)大文本字段。那么我們可以把 主鍵id、評(píng)論對(duì)象aid、用戶id存儲(chǔ)在數(shù)據(jù)庫(kù)，評(píng)論內(nèi)容存儲(chǔ)在NoSQL，這樣數(shù)據(jù)庫(kù)就節(jié)省了存儲(chǔ)content占用的磁盤空間，從而節(jié)省大量IO，對(duì)content也更容易做Cache。

//從MySQL中查詢出評(píng)論主鍵id列表 
commentIds=DB.query("SELECT id FROM comments where aid='評(píng)論對(duì)象id' LIMIT 0,20"); 
//根據(jù)主鍵id列表，從NoSQL取回評(píng)論實(shí)體數(shù)據(jù) 
CommentsList=NoSQL.get(commentIds);

NoSQL代替MySQL

在某些應(yīng)用場(chǎng)合，比如一些配置的關(guān)系鍵值映射存儲(chǔ)、用戶名和密碼的存儲(chǔ)、Session會(huì)話存儲(chǔ)等等，用NoSQL完全可以替代MySQL存儲(chǔ)。不但具有更高的性能，而且開發(fā)也更加方便。

NoSQL作為緩存服務(wù)器

MySQL+Memcached的架構(gòu)中，我們處處都要精心設(shè)計(jì)我們的緩存，包括過期時(shí)間的設(shè)計(jì)、緩存的實(shí)時(shí)性設(shè)計(jì)、緩存內(nèi)存大小評(píng)估、緩存命中率等等。

NoSQL數(shù)據(jù)庫(kù)一般都具有非常高的性能，在大多數(shù)場(chǎng)景下面，你不必再考慮在代碼層為NoSQL構(gòu)建一層Memcached緩存。NoSQL數(shù)據(jù)本身在Cache上已經(jīng)做了相當(dāng)多的優(yōu)化工作。

Memcached這類內(nèi)存緩存服務(wù)器緩存的數(shù)據(jù)大小受限于內(nèi)存大小，如果用NoSQL來代替Memcached來緩存數(shù)據(jù)庫(kù)的話，就可以不再受限于內(nèi)存大小。雖然可能有少量的磁盤IO讀寫，可能比Memcached慢一點(diǎn)，但是完全可以用來緩存數(shù)據(jù)庫(kù)的查詢操作。

規(guī)避風(fēng)險(xiǎn)

由于NoSQL是一個(gè)比較新的東西，特別是我們選擇的NoSQL數(shù)據(jù)庫(kù)還不是非常成熟的產(chǎn)品，所以我們可能會(huì)遇到未知的風(fēng)險(xiǎn)。為了得到NoSQL的好處，又要考慮規(guī)避風(fēng)險(xiǎn)，魚與熊掌如何兼得？

現(xiàn)在業(yè)內(nèi)很多公司的做法就是數(shù)據(jù)的備份。在往NoSQL里面存儲(chǔ)數(shù)據(jù)的時(shí)候還會(huì)往MySQL里面存儲(chǔ)一份。NoSQL數(shù)據(jù)庫(kù)本身也需要進(jìn)行備份（冷備和熱備）?；蛘呖梢钥紤]使用兩種NoSQL數(shù)據(jù)庫(kù)，出現(xiàn)問題后可以進(jìn)行切換（避免出現(xiàn)digg使用Cassandra的悲?。?。

總結(jié)

本文只是簡(jiǎn)單的從MySQL和NoSQL的角度分析如何選擇，以及進(jìn)行融合使用。其實(shí)在選擇NoSQL的時(shí)候，你可能還會(huì)碰到關(guān)于CAP原則，最終一致性，BASE思想的考慮。因?yàn)槭褂肕ySQL架構(gòu)的時(shí)候，你也會(huì)碰到上面的問題，所以這里沒有闡述。

http://www.infoq.com/cn/news/2013/11/introducing-nosql

列簇存儲(chǔ)

面向列的DBMS是這樣一種數(shù)據(jù)庫(kù)管理系統(tǒng)，它將數(shù)據(jù)表存儲(chǔ)為數(shù)據(jù)列而非行的形式。從物理上來說，表是列的集合，每一列從本質(zhì)上來說都是只有一個(gè)字段的表。這些數(shù)據(jù)庫(kù)通常用于分析系統(tǒng)、商業(yè)智能與分析型數(shù)據(jù)存儲(chǔ)。

優(yōu)點(diǎn)：

• 可以比較數(shù)據(jù)，因?yàn)樵诒淼囊涣兄?，?shù)據(jù)通常都是同種類型的。

• 可以通過便宜、性能一般的硬件實(shí)現(xiàn)高速的查詢性能；由于壓縮的原因，相對(duì)于關(guān)系型數(shù)據(jù)庫(kù)來說，這種方式磁盤上的數(shù)據(jù)所占據(jù)的空間要少5到10倍。

缺點(diǎn)：

• 通常沒有事務(wù)。

• 對(duì)于熟悉傳統(tǒng)RDBMS的開發(fā)者來說存在不少限制。

典型代表：

• HBase

• Cassandra

• Accumulo

• Amazon SimpleDB

鍵值存儲(chǔ)

你可以通過這種數(shù)據(jù)庫(kù)將鍵值對(duì)存儲(chǔ)到持久化存儲(chǔ)中，隨后使用鍵來讀取值。那么對(duì)于這種初看起來用途非常有限的解決方案來說有哪些好處呢？在根據(jù)鍵來保存/讀取值時(shí)，系統(tǒng)是非常高效的，因?yàn)樗鼪]有SQL處理器、索引系統(tǒng)以及分析系統(tǒng)等諸多限制。這種解決方案提供了高效的性能，代價(jià)最低的實(shí)現(xiàn)以及可伸縮性。

優(yōu)點(diǎn)：

• RDBMS太慢了，SQL游標(biāo)的負(fù)擔(dān)過于沉重。

• 采用RDBMS的解決方案來存儲(chǔ)少量數(shù)據(jù)的代價(jià)有些大。

• 沒必要使用SQL查詢、索引、觸發(fā)器、存儲(chǔ)過程、臨時(shí)表、表單以及視圖等等。

• 由于其輕量級(jí)的設(shè)計(jì)，鍵值數(shù)據(jù)庫(kù)可以很容易實(shí)現(xiàn)可伸縮性以及高性能。

缺點(diǎn)：

• 關(guān)系型數(shù)據(jù)庫(kù)的限制可以從底層就確保數(shù)據(jù)的完整性，而鍵值存儲(chǔ)就沒有這些限制，數(shù)據(jù)的完整性是由應(yīng)用來控制的。在這種情況下，數(shù)據(jù)的完整性可能會(huì)由于應(yīng)用代碼的錯(cuò)誤而做一些妥協(xié)。

• 在RDBMS中，如果模型設(shè)計(jì)良好，那么數(shù)據(jù)庫(kù)的邏輯結(jié)構(gòu)就能完全反映出存儲(chǔ)數(shù)據(jù)的結(jié)構(gòu)，并且與應(yīng)用的結(jié)構(gòu)有所不同（數(shù)據(jù)是獨(dú)立于應(yīng)用的）。對(duì)于鍵值存儲(chǔ)來說，要想取得這種效果是非常困難的事情。

典型代表：

• Amazon DynamoDB

• Riak

• Redis

• LevelDB

• Scalaris

• MemcacheDB

• Kyoto Cabinet

文檔存儲(chǔ)

文檔存儲(chǔ)指的是用于存儲(chǔ)、搜索與管理面向文檔的信息（半結(jié)構(gòu)化數(shù)據(jù)）的程序，其中心概念就是文檔。具體的面向文檔數(shù)據(jù)庫(kù)的實(shí)現(xiàn)是不同的，不過總的來說，他們都會(huì)以各種標(biāo)準(zhǔn)化格式對(duì)數(shù)據(jù)（文檔）進(jìn)行封裝與加密，主要格式有XML、YAML、JSON、BSON、PDF等等。

優(yōu)點(diǎn)：

• 足夠靈活的查詢語言。

• 易于水平擴(kuò)展。

缺點(diǎn)：

在很多時(shí)候原子性是得不到保障的。

典型代表：

• MongoDB

• Couchbase

• CouchDB

• RethinkDB

圖型數(shù)據(jù)庫(kù)

圖型數(shù)據(jù)庫(kù)指的是使用圖結(jié)構(gòu)的數(shù)據(jù)庫(kù)，通過結(jié)點(diǎn)、邊與屬性來表示和存儲(chǔ)數(shù)據(jù)。根據(jù)定義，圖型數(shù)據(jù)庫(kù)是一種提供了無需索引而彼此鄰接的存儲(chǔ)系統(tǒng)。這意味著每個(gè)元素都包含了直接指向鄰接元素的指針，因此沒必要再通過索引進(jìn)行查找了。

優(yōu)點(diǎn)：

• 對(duì)于關(guān)聯(lián)數(shù)據(jù)集的查找速度更快。

• 可以很自然地?cái)U(kuò)展為更大的數(shù)據(jù)集，因?yàn)樗麄儫o需使用代價(jià)高昂的連接運(yùn)算符。

缺點(diǎn)：

• RDBMS可以用在更為通用的場(chǎng)景下，圖型數(shù)據(jù)庫(kù)只適合類似于圖的數(shù)據(jù)。

典型代表：

• Neo4j

• FlockDB

• InfoGrid

• OrientDB

多模數(shù)據(jù)庫(kù)

這些數(shù)據(jù)庫(kù)包含了多種數(shù)據(jù)庫(kù)的特性。

有兩種不同的產(chǎn)品分組可以認(rèn)為是多模的：

• 支持多種數(shù)據(jù)模型和用例的多模數(shù)據(jù)庫(kù)。 比如說，ArangoDB宣稱它擁有鍵值存儲(chǔ)的好處，同時(shí)還提供了面向文檔以及圖型數(shù)據(jù)庫(kù)的支持。

• 支持多種模式的通用目的的數(shù)據(jù)庫(kù)。 比如說，Oracle的MySQL 5.6支持SQL方式的訪問，也可以通過Memcached API實(shí)現(xiàn)鍵值訪問。

典型代表：

• ArangoDB

• Aerospike

• Datomic

http://coolshell.cn/articles/7270.html

要開始討論數(shù)據(jù)建模技術(shù)，我們不得不或多或少地先系統(tǒng)地看一下NoSQL數(shù)據(jù)模型的成長(zhǎng)的趨勢(shì)，以此我們可以了解一些他們內(nèi)在的聯(lián)系。下圖是NoSQL家族的進(jìn)化圖，我們可以看到這樣的進(jìn)化：Key-Value時(shí)代，BigTable時(shí)代，Document時(shí)代，全文搜索時(shí)代，和Graph數(shù)據(jù)庫(kù)時(shí)代：（陳皓注：注意圖中SQL說的那句話，NoSQL再這樣發(fā)展下去就是SQL了，哈哈。）

NoSQL Data Models

首先，我們需要注意的是SQL和關(guān)系型數(shù)據(jù)模型已存在了很長(zhǎng)的時(shí)間，這種面向用戶的自然性意味著：

• 最終用戶一般更感興趣于數(shù)據(jù)的聚合顯示，而不是分離的數(shù)據(jù)，這主要通過SQL來完成。

• 我們無法通過人手工控制數(shù)據(jù)的并發(fā)性，完整性，一致性，或是數(shù)據(jù)類型校驗(yàn)這些東西的。這就是為什么SQL需要在事務(wù)，二維表結(jié)構(gòu)（schema）和外表聯(lián)合上做很多事。

另一方面，SQL可以讓軟件應(yīng)用程序在很多情況下不需要關(guān)心數(shù)據(jù)庫(kù)的數(shù)據(jù)聚合，和數(shù)據(jù)完整性和有效性進(jìn)行控制。而如果我們?nèi)コ藬?shù)據(jù)一致性，完整性這些東西，會(huì)對(duì)性能和分布存儲(chǔ)有著重的幫助。正因?yàn)槿绱?，我們才有?shù)據(jù)模型的進(jìn)化：

• Key-Value 鍵值對(duì)存儲(chǔ)是非常簡(jiǎn)單而強(qiáng)大的。下面的很多技術(shù)基本上都是基于這個(gè)技術(shù)開始發(fā)展的。但是，Key-Value有一個(gè)非常致命的問題，那就是如果我們需要查找一段范圍內(nèi)的key。（陳皓注：學(xué)過hash-table數(shù)據(jù)結(jié)構(gòu)的人都應(yīng)該知道，hash-table是非序列容器，其并不像數(shù)組，鏈接，隊(duì)列這些有序容器，我們可以控制數(shù)據(jù)存儲(chǔ)的順序）。于是，有序鍵值
  （Ordered Key-Value） 數(shù)據(jù)模型被設(shè)計(jì)出來解決這一限制，來從根本上提高數(shù)據(jù)集的問題。

• Ordered Key-Value 有序鍵值模型也非常強(qiáng)大，但是，其也沒有對(duì)Value提供某種數(shù)據(jù)模型。通常來說，Value的模型可以由應(yīng)用負(fù)責(zé)解析和存取。這種很不方便，于是出現(xiàn)了 BigTable類型的數(shù)據(jù)庫(kù)，這個(gè)數(shù)據(jù)模型其實(shí)就是map里有map，map里再套map，一層一層套下去，也就是層層嵌套的key-value（value里又是一個(gè)key-value），這種數(shù)據(jù)庫(kù)的Value主要通過“列族”（column
  families），列，和時(shí)間戳來控制版本。（陳皓注：關(guān)于時(shí)間戳來對(duì)數(shù)據(jù)的版本控制主要是解決數(shù)據(jù)存儲(chǔ)并發(fā)問題，也就是所謂的樂觀鎖，

• Document databases 文檔數(shù)據(jù)庫(kù) 改進(jìn)了 BigTable 模型，并提供了兩個(gè)有意義的改善。第一個(gè)是允許Value中有主觀的模式（scheme），而不是map套map。第二個(gè)是索引。 Full Text Search Engines 全文搜索引擎可以被看作是文檔數(shù)據(jù)庫(kù)的一個(gè)變種，他們可以提供靈活的可變的數(shù)據(jù)模式（scheme）以及自動(dòng)索引。他們之間的不同點(diǎn)主要是，文檔數(shù)據(jù)庫(kù)用字段名做索引，而全文搜索引擎用字段值做索引。

• Graph data models 圖式數(shù)據(jù)庫(kù) 可以被認(rèn)為是這個(gè)進(jìn)化過程中從 Ordered Key-Value 數(shù)據(jù)庫(kù)發(fā)展過來的一個(gè)分支。圖式數(shù)據(jù)庫(kù)允許構(gòu)建議圖結(jié)構(gòu)的數(shù)據(jù)模型。它和文檔數(shù)據(jù)庫(kù)有關(guān)系的原因是，它的很多實(shí)現(xiàn)允許value可以是一個(gè)map或是一個(gè)document。

以上是“關(guān)系數(shù)據(jù)庫(kù)和nosql的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

網(wǎng)站名稱：關(guān)系數(shù)據(jù)庫(kù)和nosql的示例分析-創(chuàng)新互聯(lián)
分享網(wǎng)址：http://www.ekvhdxd.cn/article18/ejdgp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機(jī)、ChatGPT、App設(shè)計(jì)、搜索引擎優(yōu)化、外貿(mào)網(wǎng)站建設(shè)、關(guān)鍵詞優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)