關系型數(shù)據(jù)庫和非關系型數(shù)據(jù)庫

1、關系型數(shù)據(jù)庫和非關系型數(shù)據(jù)庫自1970年，埃德加科德提出關系模型之后，關系數(shù)據(jù)庫便開始出現(xiàn)，經(jīng)過 了 40 多年的演化，如今的關系型數(shù)據(jù)庫具備了強大的存儲、維護、查詢數(shù)據(jù)的 能力。但在關系數(shù)據(jù)庫日益強大的時候， 人們發(fā)現(xiàn)，在這個信息爆炸的“大數(shù)據(jù)” 時代，關系型數(shù)據(jù)庫遇到了性能方面的瓶頸，面對一個表中上億條的數(shù)據(jù)， SQL 語句在大數(shù)據(jù)的查詢方面效率欠佳。 我們應該知道， 往往添加了越多的約束的技 術，在一定程度上定會拖延其效率。在 1998 年， CarloStrozzi 提出 NOSQL 的概念， 指的是他開發(fā)的一個沒有 SQL 功能，輕量級的，開源的關系型數(shù)據(jù)庫。注意，這個定義跟我們現(xiàn)在

2、對 NoSQL 的定義有很大的區(qū)別，它確確實實字如其名，指的就是“沒有SQL”的數(shù)據(jù)庫。 但是 NoSQL 的發(fā)展慢慢偏離了初衷， CarloStrozzi 也發(fā)覺，其實我們要的不是 nosql ，而應該是 norelational ，也就是我們現(xiàn)在常說的非關系型數(shù)據(jù)庫了。 在關系型數(shù)據(jù)庫中， 導致性能欠佳的最主要因素是多表的關聯(lián)查詢， 以及復雜的 數(shù)據(jù)分析類型的復雜 SQL 報表查詢。為了保證數(shù)據(jù)庫的 ACID 特性，我們必須 盡量按照其要求的范式進行設計， 關系型數(shù)據(jù)庫中的表都是存儲一些格式化的數(shù) 據(jù)結構，每個元組字段的組成都一樣， 即使不是每個元組都需要所有的字段， 但 數(shù)據(jù)庫會為每個元

3、組分配所有的字段， 這樣的結構可以便于表與表之間進行連接 等操作，但從另一個角度來說它也是關系型數(shù)據(jù)庫性能瓶頸的一個因素。 非關系型數(shù)據(jù)庫提出另一種理念， 他以鍵值對存儲， 且結構不固定， 每一個元組 可以有不一樣的字段， 每個元組可以根據(jù)需要增加一些自己的鍵值對， 這樣就不 會局限于固定的結構， 可以減少一些時間和空間的開銷。 使用這種方式， 用戶可 以根據(jù)需要去添加自己需要的字段， 這樣，為了獲取用戶的不同信息， 不需要像 關系型數(shù)據(jù)庫中，要對多表進行關聯(lián)查詢。僅需要根據(jù) id 取出相應的 value 就 可以完成查詢。但非關系型數(shù)據(jù)庫由于很少的約束，他也不能夠提供想 SQL 所 提供的

4、where 這種對于字段屬性值情況的查詢。并且難以體現(xiàn)設計的完整性。 他只適合存儲一些較為簡單的數(shù)據(jù)，對于需要進行較復雜查詢的數(shù)據(jù)， SQL 數(shù) 據(jù)庫顯得更為合適。目前出現(xiàn)的 NoSQL（NotonlySQL ，非關系型數(shù)據(jù)庫 ）有不下于 25 種，除了 Dynamo 、Bigtable 以外還有很多，比如 Amazon 的 SimpleDB 、微軟公司的 AzureTable 、 Facebook 使用的 Cassandra 、類 Bigtable 的 Hypertable 、 Hadoop 的 HBase、MongoDB、CouchDB、Redis 以及 Yahoo!的 PNUTS 等 等

5、。這些 NoSQL 各有特色，是基于不同應用場景而開發(fā)的， 而其中以 MongoDB 和 Redis 最為被大家追捧。以下是 MongoDB 的一些情況：MongoDB 是基于文檔的存儲的（而非表），是一個介于關系數(shù)據(jù)庫和非關系 數(shù)據(jù)庫之間的產(chǎn)品， 是非關系數(shù)據(jù)庫當中功能最豐富， 最像關系數(shù)據(jù)庫的。 他支 持的數(shù)據(jù)結構非常松散，是類似 json 的 bjson 格式，因此可以存儲比較復雜的 數(shù)據(jù)類型。模式自由 （schema-free） ，意味著對于存儲在 MongoDB 數(shù)據(jù)庫中的 文件，我們不需要知道它的任何結構定義。 如果需要的話， 你完全可以把不同結 構的文件存儲在同一個數(shù)據(jù)庫里。 M

6、ongo 最大的特點是他支持的查詢語言非常 強大，其語法有點類似于面向對象的查詢語言，幾乎可以實現(xiàn)類似關系數(shù) 據(jù)庫單表查詢的絕大部分功能，而且還支持對數(shù)據(jù)建立索引。Mongo主要解決的是海量數(shù)據(jù)的訪問效率問題。因為Mongo主要是支持海量 數(shù)據(jù)存儲的，所以Mongo還自帶了一個出色的分布式文件系統(tǒng) GridFS，可以 支持海量的數(shù)據(jù)存儲。由于Mon go可以支持復雜的數(shù)據(jù)結構，而且?guī)в袕姶蟮?數(shù)據(jù)查詢功能，因此非常受到歡迎。關系型數(shù)據(jù)庫的特點1關系型數(shù)據(jù)庫關系型數(shù)據(jù)庫，是指采用了關系模型來組織數(shù)據(jù)的數(shù)據(jù)庫。簡單來說，關系模型指的就是二維表格模型，而一個關系型數(shù)據(jù)庫就是由二維表及其之間的聯(lián)系所組

7、 成的一個數(shù)據(jù)組織。常見的關系型數(shù)據(jù)庫有Oracle、Mysql、sqlserver等等。2關系型數(shù)據(jù)庫瓶頸？高并發(fā)讀寫需求？網(wǎng)站的用戶并發(fā)性非常高，往往達到每秒上萬次讀寫請求，對于傳統(tǒng)關系型數(shù)據(jù) 庫來說，硬盤I/O是一個很大的瓶頸？海量數(shù)據(jù)的高效率讀寫網(wǎng)站每天產(chǎn)生的數(shù)據(jù)量是巨大的，對于關系型數(shù)據(jù)庫來說,在一張包含海量數(shù)據(jù)的表中查詢，效率是非常低的？高擴展性和可用性？在基于web的結構當中，數(shù)據(jù)庫是最難進行橫向擴展的，當一個應用系統(tǒng)的用 戶量和訪問量與日俱增的時候，數(shù)據(jù)庫卻沒有辦法像webserver和appserver那樣簡單的通過添加更多的硬件和服務節(jié)點來擴展性能和負載能力。對于很多需 要

8、提供24小時不間斷服務的網(wǎng)站來說，對數(shù)據(jù)庫系統(tǒng)進行升級和擴展是非常痛苦的事情，往往需要停機維護和數(shù)據(jù)遷移。？對網(wǎng)站來說，關系型數(shù)據(jù)庫的很多特性不再需要了：？事務一致性？關系型數(shù)據(jù)庫在對事物一致性的維護中有很大的開銷， 而現(xiàn)在很多系統(tǒng)對事物的讀寫一致性都不高？讀寫實時性？對關系數(shù)據(jù)庫來說，插入一條數(shù)據(jù)之后立刻查詢，是肯定可以讀出這條數(shù)據(jù)的，但是對于很多web應用來說，并不要求這么高的實時性，比如發(fā)一條消息之后， 過幾秒乃至十幾秒之后才看到這條動態(tài)是完全可以接受的？復雜SQL，特別是多表關聯(lián)查詢？任何大數(shù)據(jù)量的web系統(tǒng)，都非常忌諱多個大表的關聯(lián)查詢，以及復雜的數(shù)據(jù)分析類型的復雜SQL報表查詢，特

9、別是SNS類型的網(wǎng)站，從需求以及產(chǎn)品階級 角度，就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢， 以及單表的 簡單條件分頁查詢，SQL的功能極大的弱化了？在關系型數(shù)據(jù)庫中，導致性能欠佳的最主要原因是多表的關聯(lián)查詢，以及復雜的數(shù)據(jù)分析類型的復雜SQL報表查詢。為了保證數(shù)據(jù)庫的 ACID特性，我們必須 盡量按照其要求的范式進行設計，關系型數(shù)據(jù)庫中的表都是存儲一個格式化的數(shù) 據(jù)結構。每個元組字段的組成都是一樣，即使不是每個元組都需要所有的字段，但數(shù)據(jù)庫會為每個元組分配所有的字段，這樣的結構可以便于標語表之間進行鏈接等操作，但從另一個角度來說它也是關系型數(shù)據(jù)庫性能瓶頸的一個因素。非關系型數(shù)據(jù)庫（

10、NoSQL2009年初，JohanOskarsson舉辦了一場關于開源分布式數(shù)據(jù)庫的討論，EricEvans在這次討論中提出了 NoSQL 詞，用于指代那些非關系型的，分布 式的，且一般不保證遵循 ACID原則的數(shù)據(jù)存儲系統(tǒng)。EricEvans使用NoSQL 這個詞，并不是因為字面上的“沒有 SQL”的意思，他只是覺得很多經(jīng)典的關 系型數(shù)據(jù)庫名字都叫“*SQL”，所以為了表示跟這些關系型數(shù)據(jù)庫在定位上的截 然不同，就是用了“ NoSQL “一詞。？注：數(shù)據(jù)庫事務必須具備 ACID特性，ACID是Atomic原子性，Consistency一致性，隔離性，Durability 持久性。？非關系型數(shù)

11、據(jù)庫提出另一種理念，例如，以鍵值對存儲，且結構不固定，每一個 元組可以有不一樣的字段，每個元組可以根據(jù)需要增加一些自己的鍵值對，這樣就不會局限于固定的結構，可以減少一些時間和空間的開銷。 使用這種方式，用 戶可以根據(jù)需要去添加自己需要的字段，這樣，為了獲取用戶的不同信息，不需要像關系型數(shù)據(jù)庫中，要對多表進行關聯(lián)查詢。僅需要根據(jù)id取出相應的value 就可以完成查詢。但非關系型數(shù)據(jù)庫由于很少的約束，他也不能夠提供像SQL所提供的where這種對于字段屬性值情況的查詢。并且難以體現(xiàn)設計的完整性。 他只適合存儲一些較為簡單的數(shù)據(jù)，對于需要進行較復雜查詢的數(shù)據(jù)，SQL數(shù)據(jù)庫顯的更為合適。？關系型數(shù)據(jù)

12、庫與非關系型數(shù)據(jù)庫的區(qū)別？關系型數(shù)據(jù)庫的最大特點就是事務的一致性：傳統(tǒng)的關系型數(shù)據(jù)庫讀寫操作都是 事務的，具有ACID的特點，這個特性使得關系型數(shù)據(jù)庫可以用于幾乎所有對一 致性有要求的系統(tǒng)中，如典型的銀行系統(tǒng)。？但是，在網(wǎng)頁應用中，尤其是 SNS應用中，一致性卻不是顯得那么重要，用戶 A看到的內(nèi)容和用戶B看到同一用戶C內(nèi)容更新不一致是可以容忍的，或者說， 兩個人看到同一好友的數(shù)據(jù)更新的時間差那么幾秒是可以容忍的，因此，關系型數(shù)據(jù)庫的最大特點在這里已經(jīng)無用武之地，起碼不是那么重要了。相反地，關系型數(shù)據(jù)庫為了維護一致性所付出的巨大代價就是其讀寫性能比較差，而像微博、 facebook這類SNS的應

13、用，對并發(fā)讀寫能力要求極高，關系型數(shù)據(jù)庫已經(jīng)無 法應付（在讀方面，傳統(tǒng)上為了克服關系型數(shù)據(jù)庫缺陷，提高性能，都是增加一級memcache 來靜態(tài)化網(wǎng)頁，而在 SNS中，變化太快，memchache 已經(jīng)無 能為力了），因此，必須用新的一種數(shù)據(jù)結構存儲來代替關系數(shù)據(jù)庫。？關系數(shù)據(jù)庫的另一個特點就是其具有固定的表結構，因此，其擴展性極差，而在SNS中，系統(tǒng)的升級，功能的增加，往往意味著數(shù)據(jù)結構巨大變動，這一點關 系型數(shù)據(jù)庫也難以應付，需要新的結構化數(shù)據(jù)存儲。？于是，非關系型數(shù)據(jù)庫應運而生，由于不可能用一種數(shù)據(jù)結構化存儲應付所有的 新的需求，因此，非關系型數(shù)據(jù)庫嚴格上不是一種數(shù)據(jù)庫， 應該是一種數(shù)據(jù)

14、結構 化存儲方法的集合。必須強調(diào)的是，數(shù)據(jù)的持久存儲，尤其是海量數(shù)據(jù)的持久存 儲，還是需要一種關系數(shù)據(jù)庫。1.關系型數(shù)據(jù)庫關系型數(shù)據(jù)庫，是指采用了關系模型來組織數(shù)據(jù)的數(shù)據(jù)庫。關系模型是在1970年由IBM的研究員博士首先提出的，在之后的幾十年中， 關系模型的概念得到了充分的發(fā)展并逐漸成為主流數(shù)據(jù)庫結構的主流模型。簡單來說，關系模型指的就是二維表格模型，而一個關系型數(shù)據(jù)庫就是由二維表 及其之間的聯(lián)系所組成的一個數(shù)據(jù)組織。關系模型中常用的概念：?關系：可以理解為一張二維表，每個關系都具有一個關系名，就是通常說 的表名?元組：可以理解為二維表中的一行，在數(shù)據(jù)庫中經(jīng)常被稱為記錄?屬性：可以理解為二維表

15、中的一列，在數(shù)據(jù)庫中經(jīng)常被稱為字段?域：屬性的取值范圍，也就是數(shù)據(jù)庫中某一列的取值限制?關鍵字：一組可以唯一標識元組的屬性，數(shù)據(jù)庫中常稱為主鍵，由一個或 多個列組成?關系模式：指對關系的描述。其格式為：關系名（屬性1，屬性2，屬 性N），在數(shù)據(jù)庫中成為表結構關系型數(shù)據(jù)庫的優(yōu)點：?容易理解：二維表結構是非常貼近邏輯世界的一個概念，關系模型相對網(wǎng)狀、層次等其他模型來說更容易理解?使用方便：通用的SQL語言使得操作關系型數(shù)據(jù)庫非常方便?易于維護：豐富的完整性（實體完整性、參照完整性和用戶定義的完整性 ） 大大減低了數(shù)據(jù)冗余和數(shù)據(jù)不一致的概率2.關系型數(shù)據(jù)庫瓶頸?高并發(fā)讀寫需求網(wǎng)站的用戶并發(fā)性非常高，

16、往往達到每秒上萬次讀寫請求，對于傳統(tǒng)關系型數(shù)據(jù) 庫來說，硬盤I/O是一個很大的瓶頸?海量數(shù)據(jù)的高效率讀寫網(wǎng)站每天產(chǎn)生的數(shù)據(jù)量是巨大的，對于關系型數(shù)據(jù)庫來說，在一張包含海量數(shù)據(jù) 的表中查詢，效率是非常低的?高擴展性和可用性在基于web的結構當中，數(shù)據(jù)庫是最難進行橫向擴展的，當一個應用系統(tǒng)的用 戶量和訪問量與日俱增的時候，數(shù)據(jù)庫卻沒有辦法像webserver和appserver那樣簡單的通過添加更多的硬件和服務節(jié)點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務的網(wǎng)站來說，對數(shù)據(jù)庫系統(tǒng)進行升級和擴展是非常痛 苦的事情，往往需要停機維護和數(shù)據(jù)遷移。對網(wǎng)站來說，關系型數(shù)據(jù)庫的很多特性不再需要了

17、：? 事務一致性關系型數(shù)據(jù)庫在對事物一致性的維護中有很大的開銷，而現(xiàn)在很多系統(tǒng)對事物的讀寫一致性都不高?讀寫實時性對關系數(shù)據(jù)庫來說，插入一條數(shù)據(jù)之后立刻查詢，是肯定可以讀出這條數(shù)據(jù)的， 但是對于很多web應用來說，并不要求這么高的實時性，比如發(fā)一條消息之后， 過幾秒乃至十幾秒之后才看到這條動態(tài)是完全可以接受的?復雜SQL,特別是多表關聯(lián)查詢 任何大數(shù)據(jù)量的web系統(tǒng)，都非常忌諱多個大表的關聯(lián)查詢，以及復雜的數(shù)據(jù) 分析類型的復雜SQL報表查詢，特別是SNS類型的網(wǎng)站，從需求以及產(chǎn)品階級 角度，就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢， 以及單表的 簡單條件分頁查詢，SQL的功能極大的

18、弱化了在關系型數(shù)據(jù)庫中，導致性能欠佳的最主要原因是多表的關聯(lián)查詢，以及復雜的數(shù)據(jù)分析類型的復雜SQL報表查詢。為了保證數(shù)據(jù)庫的 ACID特性，我們必須 盡量按照其要求的范式進行設計，關系型數(shù)據(jù)庫中的表都是存儲一個格式化的數(shù) 據(jù)結構。每個元組字段的組成都是一樣，即使不是每個元組都需要所有的字段， 但數(shù)據(jù)庫會為每個元組分配所有的字段，這樣的結構可以便于標語表之間進行鏈 接等操作，但從另一個角度來說它也是關系型數(shù)據(jù)庫性能瓶頸的一個因素。NoSQL 一詞首先是CarloStrozzi在1998年提出來的，指的是他開發(fā)的一個沒 有SQL功能，輕量級的，開源的關系型數(shù)據(jù)庫。這個定義跟我們現(xiàn)在對NoSQL

19、的定義有很大的區(qū)別，它確確實實字如其名，指的就是“沒有SQL”的數(shù)據(jù)庫。 但是NoSQL的發(fā)展慢慢偏離了初衷，我們要的不是“ nosql ”，而是“n orelatio nal ”，也就是我們現(xiàn)在常說的非關系型數(shù)據(jù)庫了。2009年初，JohanOskarsson舉辦了一場關于開源分布式數(shù)據(jù)庫的討論，EricEvans在這次討論中再次提出了 NoSQL 詞，用于指代那些非關系型的， 分布式的，且一般不保證遵循 ACID原則的數(shù)據(jù)存儲系統(tǒng)。EricEvans使用 NoSQL這個詞，并不是因為字面上的“沒有 SQL”的意思，他只是覺得很多經(jīng) 典的關系型數(shù)據(jù)庫名字都叫“*SQL ”，所以為了表示跟這些

20、關系型數(shù)據(jù)庫在定位 上的截然不同，就是用了“ NoSQL “一詞 注：數(shù)據(jù)庫事務必須具備 ACID特性，ACID是Atomic原子性，Consistency 一致性，Isolation 隔離性，Durability 持久性。非關系型數(shù)據(jù)庫提出另一種理念，例如，以鍵值對存儲，且結構不固定，每一個 元組可以有不一樣的字段，每個元組可以根據(jù)需要增加一些自己的鍵值對，這樣就不會局限于固定的結構，可以減少一些時間和空間的開銷。 使用這種方式，用 戶可以根據(jù)需要去添加自己需要的字段，這樣，為了獲取用戶的不同信息，不需要像關系型數(shù)據(jù)庫中，要對多表進行關聯(lián)查詢。僅需要根據(jù)id取出相應的value 就可以完成查

21、詢。但非關系型數(shù)據(jù)庫由于很少的約束，他也不能夠提供像SQL所提供的where這種對于字段屬性值情況的查詢。并且難以體現(xiàn)設計的完整性。 他只適合存儲一些較為簡單的數(shù)據(jù)，對于需要進行較復雜查詢的數(shù)據(jù)，SQL數(shù)據(jù)庫顯的更為合適。4.關系型數(shù)據(jù)庫.非關系型數(shù)據(jù)庫關系型數(shù)據(jù)庫的最大特點就是事務的一致性：傳統(tǒng)的關系型數(shù)據(jù)庫讀寫操作都是 事務的，具有ACID的特點，這個特性使得關系型數(shù)據(jù)庫可以用于幾乎所有對一 致性有要求的系統(tǒng)中，如典型的銀行系統(tǒng)。但是，在網(wǎng)頁應用中，尤其是 SNS應用中，一致性卻不是顯得那么重要，用戶 A看到的內(nèi)容和用戶B看到同一用戶C內(nèi)容更新不一致是可以容忍的，或者說， 兩個人看到同一好友的數(shù)據(jù)更新的時間差那么幾秒是可以容忍的，因此，關系型數(shù)據(jù)庫的最大特點在這里已經(jīng)無用武之地，起碼不是那么重要了。相反地，關系型數(shù)據(jù)庫為了維護一致性所付出的巨大代價就是其讀寫性能比較差， 而像微博、facebook這類SNS的應用，對并發(fā)讀寫能力要求極高，關系型數(shù) 據(jù)庫已經(jīng)無法應付（在讀方面，傳統(tǒng)上為了克服關系型數(shù)