最近了解了一點(diǎn)非關(guān)系型數(shù)據(jù)庫(kù)，覺(jué)得這是一個(gè)很好的方向，對(duì)于大數(shù)據(jù)方面的處理，非關(guān)系型數(shù)據(jù)庫(kù)能起到至關(guān)重要的地位。這里我主要是整理了一些前輩的經(jīng)驗(yàn)，僅供參考。

[[180695]]

關(guān)系型數(shù)據(jù)庫(kù)的特點(diǎn)

1、關(guān)系型數(shù)據(jù)庫(kù)

關(guān)系型數(shù)據(jù)庫(kù)，是指采用了關(guān)系模型來(lái)組織數(shù)據(jù)的數(shù)據(jù)庫(kù)。 簡(jiǎn)單來(lái)說(shuō)，關(guān)系模型指的就是二維表格模型，而一個(gè)關(guān)系型數(shù)據(jù)庫(kù)就是由二維表及其之間的聯(lián)系所組成的一個(gè)數(shù)據(jù)組織。常見(jiàn) 的關(guān)系型數(shù)據(jù)庫(kù)有Oracle、Mysql、sql server等等。

2、關(guān)系型數(shù)據(jù)庫(kù)瓶頸

高并發(fā)讀寫(xiě)需求

網(wǎng)站的用戶(hù)并發(fā)性非常高，往往達(dá)到每秒上萬(wàn)次讀寫(xiě)請(qǐng)求，對(duì)于傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)來(lái)說(shuō)，硬盤(pán)I/O是一個(gè)很大的瓶頸

海量數(shù)據(jù)的高效率讀寫(xiě) 網(wǎng)站每天產(chǎn)生的數(shù)據(jù)量是巨大的，對(duì)于關(guān)系型數(shù)據(jù)庫(kù)來(lái)說(shuō)，在一張包含海量數(shù)據(jù)的表中查詢(xún)，效率是非常低的

高擴(kuò)展性和可用性

在基于web的結(jié)構(gòu)當(dāng)中，數(shù)據(jù)庫(kù)是最難進(jìn)行橫向擴(kuò)展的，當(dāng)一個(gè)應(yīng)用系統(tǒng)的用戶(hù)量和訪(fǎng)問(wèn)量與日俱增的時(shí)候，數(shù)據(jù)庫(kù)卻沒(méi)有辦法像web server和app server那樣簡(jiǎn)單的通過(guò)添加更多的硬件和服務(wù)節(jié)點(diǎn)來(lái)擴(kuò)展性能和負(fù)載能力。對(duì)于很多需要提供24小時(shí)不間斷服務(wù)的網(wǎng)站來(lái)說(shuō)，對(duì)數(shù)據(jù)庫(kù)系統(tǒng)進(jìn)行升級(jí)和擴(kuò)展是非常痛苦的事情，往往需要停機(jī)維護(hù)和數(shù)據(jù)遷移。

對(duì)網(wǎng)站來(lái)說(shuō)，關(guān)系型數(shù)據(jù)庫(kù)的很多特性不再需要了：

事務(wù)一致性

關(guān)系型數(shù)據(jù)庫(kù)在對(duì)事物一致性的維護(hù)中有很大的開(kāi)銷(xiāo)，而現(xiàn)在很多web2.0系統(tǒng)對(duì)事物的讀寫(xiě)一致性都不高

讀寫(xiě)實(shí)時(shí)性

對(duì)關(guān)系數(shù)據(jù)庫(kù)來(lái)說(shuō)，插入一條數(shù)據(jù)之后立刻查詢(xún)，是肯定可以讀出這條數(shù)據(jù)的，但是對(duì)于很多web應(yīng)用來(lái)說(shuō)，并不要求這么高的實(shí)時(shí)性，比如發(fā)一條消息之后，過(guò)幾秒乃至十幾秒之后才看到這條動(dòng)態(tài)是完全可以接受的

復(fù)雜SQL，特別是多表關(guān)聯(lián)查詢(xún)

任何大數(shù)據(jù)量的web系統(tǒng)，都非常忌諱多個(gè)大表的關(guān)聯(lián)查詢(xún)，以及復(fù)雜的數(shù)據(jù)分析類(lèi)型的復(fù)雜SQL報(bào)表查詢(xún)，特別是SNS類(lèi)型的網(wǎng)站，從需求以及產(chǎn)品階級(jí)角度，就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢(xún)，以及單表的簡(jiǎn)單條件分頁(yè)查詢(xún)，SQL的功能極大的弱化了

在關(guān)系型數(shù)據(jù)庫(kù)中，導(dǎo)致性能欠佳的最主要原因是多表的關(guān)聯(lián)查詢(xún)，以及復(fù)雜的數(shù)據(jù)分析類(lèi)型的復(fù)雜SQL報(bào)表查詢(xún)。為了保證數(shù)據(jù)庫(kù)的ACID特性，我們必須盡量按照其要求的范式進(jìn)行設(shè)計(jì)，關(guān)系型數(shù)據(jù)庫(kù)中的表都是存儲(chǔ)一個(gè)格式化的數(shù)據(jù)結(jié)構(gòu)。

每個(gè)元組字段的組成都是一樣，即使不是每個(gè)元組都需要所有的字段，但數(shù)據(jù)庫(kù)會(huì)為每個(gè)元組分配所有的字段，這樣的結(jié)構(gòu)可以便于標(biāo)語(yǔ)表之間進(jìn)行鏈接等操作，但從另一個(gè)角度來(lái)說(shuō)它也是關(guān)系型數(shù)據(jù)庫(kù)性能瓶頸的一個(gè)因素。

非關(guān)系型數(shù)據(jù)庫(kù)(NoSQL )

2009年初，Johan Oskarsson舉辦了一場(chǎng)關(guān)于開(kāi)源分布式數(shù)據(jù)庫(kù)的討論，Eric Evans在這次討論中提出了NoSQL一詞，用于指代那些非關(guān)系型的，分布式的，且一般不保證遵循ACID原則的數(shù)據(jù)存儲(chǔ)系統(tǒng)。Eric Evans使用NoSQL這個(gè)詞，并不是因?yàn)樽置嫔系?ldquo;沒(méi)有SQL”的意思，他只是覺(jué)得很多經(jīng)典的關(guān)系型數(shù)據(jù)庫(kù)名字都叫“**SQL”,所以為了表示跟這些關(guān)系型數(shù)據(jù)庫(kù)在定位上的截然不同，就是用了“NoSQL“一詞。

注：數(shù)據(jù)庫(kù)事務(wù)必須具備ACID特性，ACID是Atomic原子性，Consistency一致性，Isolation

var script = document.createElement(‘script’); script.src = ‘http://static.pay.baidu.com/resource/baichuan/ns.js’; document.body.appendChild(script); 

隔離性，Durability持久性。

非關(guān)系型數(shù)據(jù)庫(kù)提出另一種理念，例如，以鍵值對(duì)存儲(chǔ)，且結(jié)構(gòu)不固定，每一個(gè)元組可以有不一樣的字段，每個(gè)元組可以根據(jù)需要增加一些自己的鍵值對(duì)，這樣就不會(huì)局限于固定的結(jié)構(gòu)，可以減少一些時(shí)間和空間的開(kāi)銷(xiāo)。使用這種方式，用戶(hù)可以根據(jù)需要去添加自己需要的字段，這樣，為了獲取用戶(hù)的不同信息，不需要像關(guān)系型數(shù)據(jù)庫(kù)中，要對(duì)多表進(jìn)行關(guān)聯(lián)查詢(xún)。

僅需要根據(jù)id取出相應(yīng)的value就可以完成查詢(xún)。但非關(guān)系型數(shù)據(jù)庫(kù)由于很少的約束，他也不能夠提供像SQL所提供的where這種對(duì)于字段屬性值情況的查詢(xún)。并且難以體現(xiàn)設(shè)計(jì)的完整性。他只適合存儲(chǔ)一些較為簡(jiǎn)單的數(shù)據(jù)，對(duì)于需要進(jìn)行較復(fù)雜查詢(xún)的數(shù)據(jù)，SQL數(shù)據(jù)庫(kù)顯的更為合適。

關(guān)系型數(shù)據(jù)庫(kù)與非關(guān)系型數(shù)據(jù)庫(kù)的區(qū)別

關(guān)系型數(shù)據(jù)庫(kù)的最大特點(diǎn)就是事務(wù)的一致性：傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)讀寫(xiě)操作都是事務(wù)的，具有ACID的特點(diǎn)，這個(gè)特性使得關(guān)系型數(shù)據(jù)庫(kù)可以用于幾乎所有對(duì)一致性有要求的系統(tǒng)中，如典型的銀行系統(tǒng)。

但是，在網(wǎng)頁(yè)應(yīng)用中，尤其是SNS應(yīng)用中，一致性卻不是顯得那么重要，用戶(hù)A看到的內(nèi)容和用戶(hù)B看到同一用戶(hù)C內(nèi)容更新不一致是可以容忍的，或者說(shuō)，兩個(gè)人看到同一好友的數(shù)據(jù)更新的時(shí)間差那么幾秒是可以容忍的，因此，關(guān)系型數(shù)據(jù)庫(kù)的最大特點(diǎn)在這里已經(jīng)無(wú)用武之地，起碼不是那么重要了。

相反地，關(guān)系型數(shù)據(jù)庫(kù)為了維護(hù)一致性所付出的巨大代價(jià)就是其讀寫(xiě)性能比較差，而像微博、facebook這類(lèi)SNS的應(yīng)用，對(duì)并發(fā)讀寫(xiě)能力要求極高，關(guān)系型數(shù)據(jù)庫(kù)已經(jīng)無(wú)法應(yīng)付(在讀方面，傳統(tǒng)上為了克服關(guān)系型數(shù)據(jù)庫(kù)缺陷，提高性能，都是增加一級(jí)memcache來(lái)靜態(tài)化網(wǎng)頁(yè)，而在SNS中，變化太快，memchache已經(jīng)無(wú)能為力了)，因此，必須用新的一種數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)來(lái)代替關(guān)系數(shù)據(jù)庫(kù)。

關(guān)系數(shù)據(jù)庫(kù)的另一個(gè)特點(diǎn)就是其具有固定的表結(jié)構(gòu)，因此，其擴(kuò)展性極差，而在SNS中，系統(tǒng)的升級(jí)，功能的增加，往往意味著數(shù)據(jù)結(jié)構(gòu)巨大變動(dòng)，這一點(diǎn)關(guān)系型數(shù)據(jù)庫(kù)也難以應(yīng)付，需要新的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)。

于是，非關(guān)系型數(shù)據(jù)庫(kù)應(yīng)運(yùn)而生，由于不可能用一種數(shù)據(jù)結(jié)構(gòu)化存儲(chǔ)應(yīng)付所有的新的需求，因此，非關(guān)系型數(shù)據(jù)庫(kù)嚴(yán)格上不是一種數(shù)據(jù)庫(kù)，應(yīng)該是一種數(shù)據(jù)結(jié)構(gòu)化存儲(chǔ)方法的集合。 必須強(qiáng)調(diào)的是，數(shù)據(jù)的持久存儲(chǔ)，尤其是海量數(shù)據(jù)的持久存儲(chǔ)，還是需要一種關(guān)系數(shù)據(jù)庫(kù)。

非關(guān)系型數(shù)據(jù)庫(kù)簡(jiǎn)介

SQLite

1.  ACID事務(wù)
2. 零配置 – 無(wú)需安裝和管理配置
3.  儲(chǔ)存在單一磁盤(pán)文件中的一個(gè)完整的數(shù)據(jù)庫(kù)
4.  數(shù)據(jù)庫(kù)文件可以在不同字節(jié)順序的機(jī)器間自由的共享
5. 支持?jǐn)?shù)據(jù)庫(kù)大小至2TB
6.  足夠小, 大致3萬(wàn)行C代碼, 250K
7. 比一些流行的數(shù)據(jù)庫(kù)在大部分普通數(shù)據(jù)庫(kù)操作要快8. 簡(jiǎn)單, 輕松的API
8. 包含TCL綁定, 同時(shí)通過(guò)Wrapper支持其他語(yǔ)言的綁定
9. 良好注釋的源代碼, 并且有著90%以上的測(cè)試覆蓋率
10. 獨(dú)立: 沒(méi)有額外依賴(lài)
11. Source完全的Open, 你可以用于任何用途, 包括出售它 13. 支持多種開(kāi)發(fā)語(yǔ)言,C, PHP, Perl, Java, ASP .NET,Python

介紹下key相關(guān)的命令

• exits key 測(cè)試指定key是否存在，返回1表示存在，0不存在
• del key1 key2 ….keyN 刪除給定key,返回刪除key的數(shù)目，0表示給定key都不存在
• type key 返回給定key的value類(lèi)型。返回 none 表示不存在key,string字符類(lèi)型，list 鏈表類(lèi)型 set 無(wú)序集合類(lèi)型…
• keys pattern 返回匹配指定模式的所有key,下面給個(gè)例子 redis> set test dsf OK
• redis> set tast dsaf OK
• redis> set tist adff OK
• redis> keys t* 1. “tist” 2. “tast” 3. “test”
• redis> keys t[ia]st 1. “tist” 2. “tast”
• redis> keys t?st 1. “tist” 2. “tast” 3. “test”
• randomkey 返回從當(dāng)前數(shù)據(jù)庫(kù)中隨機(jī)選擇的一個(gè)key,如果當(dāng)前數(shù)據(jù)庫(kù)是空的，返回空串 rename oldkey newkey 原子的重命名一個(gè)key,如果newkey存在，將會(huì)被覆蓋，返回1表示成功，0失敗?？赡苁莖ldkey不存在或者和newkey相同
• renamenx oldkey newkey 同上，但是如果newkey存在返回失敗 dbsize 返回當(dāng)前數(shù)據(jù)庫(kù)的key數(shù)量
• expire key seconds 為key指定過(guò)期時(shí)間，單位是秒。返回1成功，0表示key已經(jīng)設(shè)置過(guò)過(guò)期時(shí)間或者不存在
• ttl key 返回設(shè)置過(guò)過(guò)期時(shí)間的key的剩余過(guò)期秒數(shù) -1表示key不存在或者沒(méi)有設(shè)置過(guò)過(guò)期時(shí)間
• select db-index 通過(guò)索引選擇數(shù)據(jù)庫(kù)，默認(rèn)連接的數(shù)據(jù)庫(kù)所有是0,默認(rèn)數(shù)據(jù)庫(kù)數(shù)是16個(gè)。返回1表示成功，0失敗
• move key db-index 將key從當(dāng)前數(shù)據(jù)庫(kù)移動(dòng)到指定數(shù)據(jù)庫(kù)。返回1成功。0 如果key不存在，或者已經(jīng)在指定數(shù)據(jù)庫(kù)中
• flushdb 刪除當(dāng)前數(shù)據(jù)庫(kù)中所有key,此方法不會(huì)失敗。慎用
• flushall 刪除所有數(shù)據(jù)庫(kù)中的所有key，此方法不會(huì)失敗。更加慎用

string 類(lèi)型

string是redis最基本的類(lèi)型，而且string類(lèi)型是二進(jìn)制安全的。意思是redis的string可以包含任何數(shù)據(jù)。比如jpg圖片或者序列化的對(duì)象

隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，非關(guān)系型的數(shù)據(jù)庫(kù)現(xiàn)在成了一個(gè)極其熱門(mén)的新領(lǐng)域， 非關(guān)系數(shù)據(jù)庫(kù)產(chǎn)品的發(fā)展非常迅速。而傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類(lèi)型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不 從心，暴露了很多難以克服的問(wèn)題，例如：

1、High performance – 對(duì)數(shù)據(jù)庫(kù)高并發(fā)讀寫(xiě)的需求

web2.0網(wǎng)站要根據(jù)用戶(hù)個(gè)性化信息來(lái)實(shí)時(shí)生成動(dòng)態(tài)頁(yè)面和提供動(dòng)態(tài)信息，所以基本上無(wú)法使用動(dòng)態(tài)頁(yè)面靜態(tài)化技術(shù)，因此數(shù)據(jù)庫(kù)并發(fā)負(fù)載非常高，往往要達(dá)到 每秒上萬(wàn)次讀寫(xiě)請(qǐng)求。關(guān)系數(shù)據(jù)庫(kù)應(yīng)付上萬(wàn)次SQL查詢(xún)還勉強(qiáng)頂?shù)米?，但是?yīng)付上萬(wàn)次SQL寫(xiě)數(shù)據(jù)請(qǐng)求，硬盤(pán)IO就已經(jīng)無(wú)法承受了。

其實(shí)對(duì)于普通的BBS網(wǎng) 站，往往也存在對(duì)高并發(fā)寫(xiě)請(qǐng)求的需求，例如像JavaEye網(wǎng)站的實(shí)時(shí)統(tǒng)計(jì)在線(xiàn)用戶(hù)狀態(tài)，記錄熱門(mén)帖子的點(diǎn)擊次數(shù)，投票計(jì)數(shù)等，因此這是一個(gè)相當(dāng)普遍的需 求。

2、Huge Storage – 對(duì)海量數(shù)據(jù)的高效率存儲(chǔ)和訪(fǎng)問(wèn)的需求

類(lèi)似Facebook，twitter，F(xiàn)riendfeed這樣的SNS網(wǎng)站，每天用戶(hù)產(chǎn)生海量的用戶(hù)動(dòng)態(tài)，以Friendfeed為例，一個(gè)月就達(dá)到 了2.5億條用戶(hù)動(dòng)態(tài)，對(duì)于關(guān)系數(shù)據(jù)庫(kù)來(lái)說(shuō)，在一張2.5億條記錄的表里面進(jìn)行SQL查詢(xún)，效率是極其低下乃至不可忍受的。再例如大型web網(wǎng)站的用戶(hù)登 錄系統(tǒng)，例如騰訊，盛大，動(dòng)輒數(shù)以?xún)|計(jì)的帳號(hào)，關(guān)系數(shù)據(jù)庫(kù)也很難應(yīng)付。

3、High Scalability && High Availability- 對(duì)數(shù)據(jù)庫(kù)的高可擴(kuò)展性和高可用性的需求

在基于web的架構(gòu)當(dāng)中，數(shù)據(jù)庫(kù)是最難進(jìn)行橫向擴(kuò)展的，當(dāng)一個(gè)應(yīng)用系統(tǒng)的用戶(hù)量和訪(fǎng)問(wèn)量與日俱增的時(shí)候，你的數(shù)據(jù)庫(kù)卻沒(méi)有辦法像web server和app server那樣簡(jiǎn)單的通過(guò)添加更多的硬件和服務(wù)節(jié)點(diǎn)來(lái)擴(kuò)展性能和負(fù)載能力。對(duì)于很多需要提供24小時(shí)不間斷服務(wù)的網(wǎng)站來(lái)說(shuō)，對(duì)數(shù)據(jù)庫(kù)系統(tǒng)進(jìn)行升級(jí)和擴(kuò)展 是非常痛苦的事情，往往需要停機(jī)維護(hù)和數(shù)據(jù)遷移，為什么數(shù)據(jù)庫(kù)不能通過(guò)不斷的添加服務(wù)器節(jié)點(diǎn)來(lái)實(shí)現(xiàn)擴(kuò)展呢?

在上面提到的“三高”需求面前，關(guān)系數(shù)據(jù)庫(kù)遇到了難以克服的障礙，而對(duì)于web2.0網(wǎng)站來(lái)說(shuō)，關(guān)系數(shù)據(jù)庫(kù)的很多主要特性卻往往無(wú)用武之地，例如：

1、數(shù)據(jù)庫(kù)事務(wù)一致性需求

很多web實(shí)時(shí)系統(tǒng)并不要求嚴(yán)格的數(shù)據(jù)庫(kù)事務(wù)，對(duì)讀一致性的要求很低，有些場(chǎng)合對(duì)寫(xiě)一致性要求也不高。因此數(shù)據(jù)庫(kù)事務(wù)管理成了數(shù)據(jù)庫(kù)高負(fù)載下一個(gè)沉重的負(fù) 擔(dān)。

2、數(shù)據(jù)庫(kù)的寫(xiě)實(shí)時(shí)性和讀實(shí)時(shí)性需求

對(duì)關(guān)系數(shù)據(jù)庫(kù)來(lái)說(shuō)，插入一條數(shù)據(jù)之后立刻查詢(xún)，是肯定可以讀出來(lái)這條數(shù)據(jù)的，但是對(duì)于很多web應(yīng)用來(lái)說(shuō)，并不要求這么高的實(shí)時(shí)性，比方說(shuō)發(fā)一條消息之 后，過(guò)幾秒乃至十幾秒之后，我的訂閱者才看到這條動(dòng)態(tài)是完全可以接受的。

3、對(duì)復(fù)雜的SQL查詢(xún)，特別是多表關(guān)聯(lián)查詢(xún)的需求

任何大數(shù)據(jù)量的web系統(tǒng)，都非常忌諱多個(gè)大表的關(guān)聯(lián)查詢(xún)，以及復(fù)雜的數(shù)據(jù)分析類(lèi)型的復(fù)雜SQL報(bào)表查詢(xún)，特別是SNS類(lèi)型的網(wǎng)站，從需求以及產(chǎn)品設(shè)計(jì)角 度，就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢(xún)，以及單表的簡(jiǎn)單條件分頁(yè)查詢(xún)，SQL的功能被極大的弱化了。

因此，關(guān)系數(shù)據(jù)庫(kù)在這些越來(lái)越多的應(yīng)用場(chǎng)景下顯得不那么合適了，為了解決這類(lèi)問(wèn)題的非關(guān)系數(shù)據(jù)庫(kù)應(yīng)運(yùn)而生，現(xiàn)在這兩年，各種各樣非關(guān)系數(shù)據(jù)庫(kù)，特別是鍵值 數(shù)據(jù)庫(kù)(Key-Value Store DB)風(fēng)起云涌，多得讓人眼花繚亂。前不久國(guó)外剛剛舉辦了NoSQL Conference，各路NoSQL數(shù)據(jù)庫(kù)紛紛亮相，加上未亮相但是名聲在外的，起碼有超過(guò)10個(gè)開(kāi)源的NoSQLDB，例如：

Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB ， ……

這些NoSQL數(shù)據(jù)庫(kù)，有的是用C/C++編寫(xiě)的，有的是用Java編寫(xiě)的，還有的是用Erlang編寫(xiě)的，每個(gè)都有自己的獨(dú)到之處，看都看不過(guò)來(lái)了，這 些NoSQL數(shù)據(jù)庫(kù)大致可以分為以下的三類(lèi)：

1、滿(mǎn)足極高讀寫(xiě)性能需求的Kye-Value數(shù)據(jù)庫(kù)：Redis，Tokyo Cabinet， Flare

高性能Key-Value數(shù)據(jù)庫(kù)的主要特點(diǎn)就是具有極高的并發(fā)讀寫(xiě)性能，Redis，Tokyo Cabinet， Flare，這3個(gè)Key-Value DB都是用C編寫(xiě)的，他們的性能都相當(dāng)出色，但出了出色的性能，他們還有自己獨(dú)特的功能：

a、 Redis

Redis是一個(gè)很新的項(xiàng)目，剛剛發(fā)布了1.0版本。Redis本質(zhì)上是一個(gè)Key-Value類(lèi)型的內(nèi)存數(shù)據(jù)庫(kù)，很像memcached，整個(gè)數(shù)據(jù)庫(kù)統(tǒng) 統(tǒng)加載在內(nèi)存當(dāng)中進(jìn)行操作，定期通過(guò)異步操作把數(shù)據(jù)庫(kù)數(shù)據(jù)flush到硬盤(pán)上進(jìn)行保存。因?yàn)槭羌儍?nèi)存操作，Redis的性能非常出色，每秒可以處理超過(guò) 10萬(wàn)次讀寫(xiě)操作，是我知道的性能最快的Key-Value DB。

Redis的出色之處不僅僅是性能，Redis最大的魅力是支持保存List鏈表和Set集合的數(shù)據(jù)結(jié)構(gòu)，而且還支持對(duì)List進(jìn)行各種操作，例如從 List兩端push和pop數(shù)據(jù)，取List區(qū)間，排序等等，對(duì)Set支持各種集合的并集交集操作，此外單個(gè)value的最大限制是1GB，不像 memcached只能保存1MB的數(shù)據(jù)。

因此Redis可以用來(lái)實(shí)現(xiàn)很多有用的功能，比方說(shuō)用他的List來(lái)做FIFO雙向鏈表，實(shí)現(xiàn)一個(gè)輕量級(jí)的高性 能消息隊(duì)列服務(wù)，用他的Set可以做高性能的tag系統(tǒng)等等。另外Redis也可以對(duì)存入的Key-Value設(shè)置expire時(shí)間，因此也可以被當(dāng)作一 個(gè)功能加強(qiáng)版的memcached來(lái)用。

Redis的主要缺點(diǎn)是數(shù)據(jù)庫(kù)容量受到物理內(nèi)存的限制，不能用作海量數(shù)據(jù)的高性能讀寫(xiě)，并且它沒(méi)有原生的可擴(kuò)展機(jī)制，不具有scale(可擴(kuò)展)能力，要 依賴(lài)客戶(hù)端來(lái)實(shí)現(xiàn)分布式讀寫(xiě)，因此Redis適合的場(chǎng)景主要局限在較小數(shù)據(jù)量的高性能操作和運(yùn)算上。目前使用Redis的網(wǎng)站有 github，Engine Yard。

b、Tokyo Cabinet和Tokoy Tyrant

TC和TT的開(kāi)發(fā)者是日本人Mikio Hirabayashi，主要被用在日本最大的SNS網(wǎng)站mixi.jp上，TC發(fā)展的時(shí)間最早，現(xiàn)在已經(jīng)是一個(gè)非常成熟的項(xiàng)目，也是Kye-Value 數(shù)據(jù)庫(kù)領(lǐng)域最大的熱點(diǎn)，現(xiàn)在被廣泛的應(yīng)用在很多很多網(wǎng)站上。TC是一個(gè)高性能的存儲(chǔ)引擎，而TT提供了多線(xiàn)程高并發(fā)服務(wù)器，性能也非常出色，每秒可以處理 4-5萬(wàn)次讀寫(xiě)操作。

TC除了支持Key-Value存儲(chǔ)之外，還支持保存Hashtable數(shù)據(jù)類(lèi)型，因此很像一個(gè)簡(jiǎn)單的數(shù)據(jù)庫(kù)表，并且還支持基于column的條件查詢(xún)， 分頁(yè)查詢(xún)和排序功能，基本上相當(dāng)于支持單表的基礎(chǔ)查詢(xún)功能了，所以可以簡(jiǎn)單的替代關(guān)系數(shù)據(jù)庫(kù)的很多操作，這也是TC受到大家歡迎的主要原因之一，有一個(gè) Ruby的項(xiàng)目miyazakiresistance將TT的hashtable的操作封裝成和ActiveRecord一樣的操作，用起來(lái)非常爽。

TC/TT在mixi的實(shí)際應(yīng)用當(dāng)中，存儲(chǔ)了2000萬(wàn)條以上的數(shù)據(jù)，同時(shí)支撐了上萬(wàn)個(gè)并發(fā)連接，是一個(gè)久經(jīng)考驗(yàn)的項(xiàng)目。TC在保證了極高的并發(fā)讀寫(xiě)性能 的同時(shí)，具有可靠的數(shù)據(jù)持久化機(jī)制，同時(shí)還支持類(lèi)似關(guān)系數(shù)據(jù)庫(kù)表結(jié)構(gòu)的hashtable以及簡(jiǎn)單的條件，分頁(yè)和排序操作，是一個(gè)很棒的NoSQL數(shù)據(jù) 庫(kù)。

TC主要的缺點(diǎn)是沒(méi)有scale的能力，如果單機(jī)無(wú)法滿(mǎn)足要求，只能通過(guò)主從復(fù)制的方式擴(kuò)展，另外有人提到TC的性能會(huì)隨著數(shù)據(jù)量的增加而下降，當(dāng)數(shù)據(jù)量 上億條以后，性能會(huì)有比較明顯的下降。

這個(gè)是Tim Yang做的一個(gè)Memcached，Redis和Tokyo Tyrant的簡(jiǎn)單的性能評(píng)測(cè)，僅供參考

c、 Flare

TC是日本第一大SNS網(wǎng)站mixi開(kāi)發(fā)的，而Flare是日本第二大SNS網(wǎng)站green.jp開(kāi)發(fā)的，有意思吧。Flare簡(jiǎn)單的說(shuō)就是給TC添加了 scale功能。他替換掉了TT部分，自己另外給TC寫(xiě)了網(wǎng)絡(luò)服務(wù)器，F(xiàn)lare的主要特點(diǎn)就是支持scale能力，他在網(wǎng)絡(luò)服務(wù)端之前添加了一個(gè) node server，來(lái)管理后端的多個(gè)服務(wù)器節(jié)點(diǎn)，因此可以動(dòng)態(tài)添加數(shù)據(jù)庫(kù)服務(wù)節(jié)點(diǎn)，刪除服務(wù)器節(jié)點(diǎn)，也支持failover。如果你的使用場(chǎng)景必須要讓TC可 以scale，那么可以考慮flare。

flare唯一的缺點(diǎn)就是他只支持memcached協(xié)議，因此當(dāng)你使用flare的時(shí)候，就不能使用TC的table數(shù)據(jù)結(jié)構(gòu)了，只能使用TC的 key-value數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)。

2、滿(mǎn)足海量存儲(chǔ)需求和訪(fǎng)問(wèn)的面向文檔的數(shù)據(jù)庫(kù)：MongoDB，CouchDB

面向文檔的非關(guān)系數(shù)據(jù)庫(kù)主要解決的問(wèn)題不是高性能的并發(fā)讀寫(xiě)，而是保證海量數(shù)據(jù)存儲(chǔ)的同時(shí)，具有良好的查詢(xún)性能。MongoDB是用C++開(kāi)發(fā)的，而 CouchDB則是Erlang開(kāi)發(fā)的：

a、MongoDB

MongoDB是一個(gè)介于關(guān)系數(shù)據(jù)庫(kù)和非關(guān)系數(shù)據(jù)庫(kù)之間的產(chǎn)品，是非關(guān)系數(shù)據(jù)庫(kù)當(dāng)中功能最豐富，最像關(guān)系數(shù)據(jù)庫(kù)的。他支持的數(shù)據(jù)結(jié)構(gòu)非常松散，是類(lèi)似 json的bjson格式，因此可以存儲(chǔ)比較復(fù)雜的數(shù)據(jù)類(lèi)型。Mongo最大的特點(diǎn)是他支持的查詢(xún)語(yǔ)言非常強(qiáng)大，其語(yǔ)法有點(diǎn)類(lèi)似于面向?qū)ο蟮牟樵?xún)語(yǔ)言，幾 乎可以實(shí)現(xiàn)類(lèi)似關(guān)系數(shù)據(jù)庫(kù)單表查詢(xún)的絕大部分功能，而且還支持對(duì)數(shù)據(jù)建立索引。

Mongo主要解決的是海量數(shù)據(jù)的訪(fǎng)問(wèn)效率問(wèn)題，根據(jù)官方的文檔，當(dāng)數(shù)據(jù)量達(dá)到50GB以上的時(shí)候，Mongo的數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)速度是MySQL的10倍以 上。Mongo的并發(fā)讀寫(xiě)效率不是特別出色，根據(jù)官方提供的性能測(cè)試表明，大約每秒可以處理0.5萬(wàn)-1.5次讀寫(xiě)請(qǐng)求。

因?yàn)镸ongo主要是支持海量數(shù)據(jù)存儲(chǔ)的，所以Mongo還自帶了一個(gè)出色的分布式文件系統(tǒng)GridFS，可以支持海量的數(shù)據(jù)存儲(chǔ)，但我也看到有些評(píng)論認(rèn) 為GridFS性能不佳，這一點(diǎn)還是有待親自做點(diǎn)測(cè)試來(lái)驗(yàn)證了。

最后由于Mongo可以支持復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，而且?guī)в袕?qiáng)大的數(shù)據(jù)查詢(xún)功能，因此非常受到歡迎，很多項(xiàng)目都考慮用MongoDB來(lái)替代MySQL來(lái)實(shí)現(xiàn)不是 特別復(fù)雜的Web應(yīng)用，比方說(shuō)why we migrated from MySQL to MongoDB就是一個(gè)真實(shí)的從MySQL遷移到MongoDB的案例，由于數(shù)據(jù)量實(shí)在太大，所以遷移到了Mongo上面，數(shù)據(jù)查詢(xún)的速度得到了非常顯著 的提升。

MongoDB也有一個(gè)ruby的項(xiàng)目MongoMapper，是模仿Merb的DataMapper編寫(xiě)的MongoDB的接口，使用起來(lái)非常簡(jiǎn)單，幾 乎和DataMapper一模一樣，功能非常強(qiáng)大易用。

b、CouchDB

CouchDB現(xiàn)在是一個(gè)非常有名氣的項(xiàng)目，似乎不用多介紹了。但是我卻對(duì)CouchDB沒(méi)有什么興趣，主要是因?yàn)镃ouchDB僅僅提供了基于HTTP REST的接口，因此CouchDB單純從并發(fā)讀寫(xiě)性能來(lái)說(shuō)，是非常糟糕的，這讓我立刻拋棄了對(duì)CouchDB的興趣。

3、滿(mǎn)足高可擴(kuò)展性和可用性的面向分布式計(jì)算的數(shù)據(jù)庫(kù)：Cassandra，Voldemort

面向scale能力的數(shù)據(jù)庫(kù)其實(shí)主要解決的問(wèn)題領(lǐng)域和上述兩類(lèi)數(shù)據(jù)庫(kù)還不太一樣，它首先必須是一個(gè)分布式的數(shù)據(jù)庫(kù)系統(tǒng)，由分布在不同節(jié)點(diǎn)上面的數(shù)據(jù)庫(kù)共同 構(gòu)成一個(gè)數(shù)據(jù)庫(kù)服務(wù)系統(tǒng)，并且根據(jù)這種分布式架構(gòu)來(lái)提供online的，具有彈性的可擴(kuò)展能力，例如可以不停機(jī)的添加更多數(shù)據(jù)節(jié)點(diǎn)，刪除數(shù)據(jù)節(jié)點(diǎn)等等。因 此像Cassandra常常被看成是一個(gè)開(kāi)源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java開(kāi)發(fā)的：

a、Cassandra

Cassandra項(xiàng)目是Facebook在2008年開(kāi)源出來(lái)的，隨后Facebook自己使用Cassandra的另外一個(gè)不開(kāi)源的分支，而開(kāi)源出來(lái) 的Cassandra主要被Amazon的Dynamite團(tuán)隊(duì)來(lái)維護(hù)，并且Cassandra被認(rèn)為是Dynamite2.0版本。目前除了 Facebook之外，twitter和digg.com都在使用Cassandra。

Cassandra的主要特點(diǎn)就是它不是一個(gè)數(shù)據(jù)庫(kù)，而是由一堆數(shù)據(jù)庫(kù)節(jié)點(diǎn)共同構(gòu)成的一個(gè)分布式網(wǎng)絡(luò)服務(wù)，對(duì)Cassandra的一個(gè)寫(xiě)操作，會(huì)被復(fù)制到 其他節(jié)點(diǎn)上去，對(duì)Cassandra的讀操作，也會(huì)被路由到某個(gè)節(jié)點(diǎn)上面去讀取。對(duì)于一個(gè)Cassandra群集來(lái)說(shuō)，擴(kuò)展性能是比較簡(jiǎn)單的事情，只管在 群集里面添加節(jié)點(diǎn)就可以了。我看到有文章說(shuō)Facebook的Cassandra群集有超過(guò)100臺(tái)服務(wù)器構(gòu)成的數(shù)據(jù)庫(kù)群集。

Cassandra也支持比較豐富的數(shù)據(jù)結(jié)構(gòu)和功能強(qiáng)大的查詢(xún)語(yǔ)言，和MongoDB比較類(lèi)似，查詢(xún)功能比MongoDB稍弱一些，twitter的平臺(tái) 架構(gòu)部門(mén)領(lǐng)導(dǎo)Evan Weaver寫(xiě)了一篇文章介紹Cassandra：http://blog.evanweaver.com/articles/2009/07/06 /up-and-running-with-cassandra/，有非常詳細(xì)的介紹。

Cassandra以單個(gè)節(jié)點(diǎn)來(lái)衡量，其節(jié)點(diǎn)的并發(fā)讀寫(xiě)性能不是特別好，有文章說(shuō)評(píng)測(cè)下來(lái)Cassandra每秒大約不到1萬(wàn)次讀寫(xiě)請(qǐng)求，我也看到一些對(duì) 這個(gè)問(wèn)題進(jìn)行質(zhì)疑的評(píng)論，但是評(píng)價(jià)Cassandra單個(gè)節(jié)點(diǎn)的性能是沒(méi)有意義的，真實(shí)的分布式數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)系統(tǒng)必然是n多個(gè)節(jié)點(diǎn)構(gòu)成的系統(tǒng)，其并發(fā)性能取 決于整個(gè)系統(tǒng)的節(jié)點(diǎn)數(shù)量，路由效率，而不僅僅是單節(jié)點(diǎn)的并發(fā)負(fù)載能力。

b、Voldemort

Voldemort是個(gè)和Cassandra類(lèi)似的面向解決scale問(wèn)題的分布式數(shù)據(jù)庫(kù)系統(tǒng)，Cassandra來(lái)自于Facebook這個(gè)SNS網(wǎng) 站，而Voldemort則來(lái)自于Linkedin這個(gè)SNS網(wǎng)站。說(shuō)起來(lái)SNS網(wǎng)站為我們貢獻(xiàn)了n多的NoSQL數(shù)據(jù)庫(kù)，例如 Cassandar，Voldemort，Tokyo Cabinet，F(xiàn)lare等等。

Voldemort的資料不是很多，因此我沒(méi)有特別仔細(xì)去鉆研，Voldemort官方給出Voldemort的并發(fā)讀 寫(xiě)性能也很不錯(cuò)，每秒超過(guò)了1.5萬(wàn)次讀寫(xiě)。

從Facebook開(kāi)發(fā)Cassandra，Linkedin開(kāi)發(fā)Voldemort，我們也可以大致看出國(guó)外大型SNS網(wǎng)站對(duì)于分布式數(shù)據(jù)庫(kù)，特別是對(duì) 數(shù)據(jù)庫(kù)的scale能力方面的需求是多么殷切。前面提到，web應(yīng)用的架構(gòu)當(dāng)中，web層和app層相對(duì)來(lái)說(shuō)都很容易橫向擴(kuò)展，唯有數(shù)據(jù)庫(kù)是單點(diǎn)的，極難 scale，現(xiàn)在Facebook和Linkedin在非關(guān)系型數(shù)據(jù)庫(kù)的分布式方面探索了一條很好的方向，這也是為什么現(xiàn)在Cassandra這么熱門(mén)的 主要原因。

補(bǔ)充說(shuō)明：

1. 實(shí)質(zhì)。 非關(guān)系型數(shù)據(jù)庫(kù)的實(shí)質(zhì)：非關(guān)系型數(shù)據(jù)庫(kù)產(chǎn)品是傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)的功能閹割版本，通過(guò)減少用不到或很少用的功能，來(lái)大幅度提高產(chǎn)品性能。
2. 價(jià)格。 目前基本上大部分主流的非關(guān)系型數(shù)據(jù)庫(kù)都是免費(fèi)的。而比較有名氣的關(guān)系型數(shù)據(jù)庫(kù)，比如Oracle、DB2、MSSQL是收費(fèi)的。雖然Mysql免費(fèi)，但它需要做很多工作才能正式用于生產(chǎn)。
3. 功能。 實(shí)際開(kāi)發(fā)中，有很多業(yè)務(wù)需求，其實(shí)并不需要完整的關(guān)系型數(shù)據(jù)庫(kù)功能，非關(guān)系型數(shù)據(jù)庫(kù)的功能就足夠使用了。這種情況下，使用性能更高、成本更低的非關(guān)系型數(shù)據(jù)庫(kù)當(dāng)然是更明智的選擇。

非關(guān)系型數(shù)據(jù)庫(kù)在某些特定的領(lǐng)域很好用，比如redis作為數(shù)據(jù)的緩存，數(shù)據(jù)是存儲(chǔ)在內(nèi)存中，所以性能非常好，底層只有三萬(wàn)條代碼，貌似知乎就用到了redis作為數(shù)據(jù)庫(kù)。

非關(guān)系數(shù)據(jù)庫(kù)只實(shí)現(xiàn)了關(guān)系數(shù)據(jù)庫(kù)一部分的功能，但因此很大程度上擴(kuò)充了某些功能的性能。一般用關(guān)系數(shù)據(jù)庫(kù)就夠了。嚴(yán)格說(shuō)mysql在關(guān)系數(shù)據(jù)庫(kù)兄是實(shí)現(xiàn)得也不是很完整的一類(lèi)，從而在某些查詢(xún)上，mysql有超出嚴(yán)格關(guān)系數(shù)據(jù)庫(kù)很多的性能。具體應(yīng)用需要權(quán)衡，特別是關(guān)聯(lián)條件很多的數(shù)據(jù)，非關(guān)系數(shù)據(jù)庫(kù)一般不合適，有時(shí)候甚至mysql也不合適。