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

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

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

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

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

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

在關(guān)系型數(shù)據(jù)庫中，導(dǎo)致性能欠佳的最主要原因是多表的關(guān)聯(lián)查詢，以及復(fù)雜的數(shù)據(jù)分析類型的復(fù)雜SQL報(bào)表查詢。為了保證數(shù)據(jù)庫的ACID特性，我們必須盡量按照其要求的范式進(jìn)行設(shè)計(jì)，關(guān)系型數(shù)據(jù)庫中的表都是存儲(chǔ)一個(gè)格式化的數(shù)據(jù)結(jié)構(gòu)。每個(gè)元組字段的組成都是一樣，即使不是每個(gè)元組都需要所有的字段，但數(shù)據(jù)庫會(huì)為每個(gè)元組分配所有的字段，這樣的結(jié)構(gòu)可以便于標(biāo)語表之間進(jìn)行鏈接等操作，但從另一個(gè)角度來說它也是關(guān)系型數(shù)據(jù)庫性能瓶頸的一個(gè)因素。

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

2009年初，Johan
Oskarsson舉辦了一場關(guān)于開源分布式數(shù)據(jù)庫的討論，Eric
Evans在這次討論中提出了NoSQL一詞，用于指代那些非關(guān)系型的，分布式的，且一般不保證遵循ACID原則的數(shù)據(jù)存儲(chǔ)系統(tǒng)。Eric
Evans使用NoSQL這個(gè)詞，并不是因?yàn)樽置嫔系摹皼]有SQL”的意思，他只是覺得很多經(jīng)典的關(guān)系型數(shù)據(jù)庫名字都叫“**SQL”,所以為了表示跟這些關(guān)系型數(shù)據(jù)庫在定位上的截然不同，就是用了“NoSQL“一詞。
注：數(shù)據(jù)庫事務(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ù)庫提出另一種理念，例如，以鍵值對存儲(chǔ)，且結(jié)構(gòu)不固定，每一個(gè)元組可以有不一樣的字段，每個(gè)元組可以根據(jù)需要增加一些自己的鍵值對，這樣就不會(huì)局限于固定的結(jié)構(gòu)，可以減少一些時(shí)間和空間的開銷。使用這種方式，用戶可以根據(jù)需要去添加自己需要的字段，這樣，為了獲取用戶的不同信息，不需要像關(guān)系型數(shù)據(jù)庫中，要對多表進(jìn)行關(guān)聯(lián)查詢。僅需要根據(jù)id取出相應(yīng)的value就可以完成查詢。但非關(guān)系型數(shù)據(jù)庫由于很少的約束，他也不能夠提供像SQL所提供的where這種對于字段屬性值情況的查詢。并且難以體現(xiàn)設(shè)計(jì)的完整性。他只適合存儲(chǔ)一些較為簡單的數(shù)據(jù)，對于需要進(jìn)行較復(fù)雜查詢的數(shù)據(jù)，SQL數(shù)據(jù)庫顯的更為合適。
關(guān)系型數(shù)據(jù)庫與非關(guān)系型數(shù)據(jù)庫的區(qū)別
關(guān)系型數(shù)據(jù)庫的最大特點(diǎn)就是事務(wù)的一致性：傳統(tǒng)的關(guān)系型數(shù)據(jù)庫讀寫操作都是事務(wù)的，具有ACID的特點(diǎn)，這個(gè)特性使得關(guān)系型數(shù)據(jù)庫可以用于幾乎所有對一致性有要求的系統(tǒng)中，如典型的銀行系統(tǒng)。
但是，在網(wǎng)頁應(yīng)用中，尤其是SNS應(yīng)用中，一致性卻不是顯得那么重要，用戶A看到的內(nèi)容和用戶B看到同一用戶C內(nèi)容更新不一致是可以容忍的，或者說，兩個(gè)人看到同一好友的數(shù)據(jù)更新的時(shí)間差那么幾秒是可以容忍的，因此，關(guān)系型數(shù)據(jù)庫的最大特點(diǎn)在這里已經(jīng)無用武之地，起碼不是那么重要了。

相反地，關(guān)系型數(shù)據(jù)庫為了維護(hù)一致性所付出的巨大代價(jià)就是其讀寫性能比較差，而像微博、facebook這類SNS的應(yīng)用，對并發(fā)讀寫能力要求極高，關(guān)系型數(shù)據(jù)庫已經(jīng)無法應(yīng)付(在讀方面，傳統(tǒng)上為了克服關(guān)系型數(shù)據(jù)庫缺陷，提高性能，都是增加一級memcache來靜態(tài)化網(wǎng)頁，而在SNS中，變化太快，memchache已經(jīng)無能為力了)，因此，必須用新的一種數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)來代替關(guān)系數(shù)據(jù)庫。
關(guān)系數(shù)據(jù)庫的另一個(gè)特點(diǎn)就是其具有固定的表結(jié)構(gòu)，因此，其擴(kuò)展性極差，而在SNS中，系統(tǒng)的升級，功能的增加，往往意味著數(shù)據(jù)結(jié)構(gòu)巨大變動(dòng)，這一點(diǎn)關(guān)系型數(shù)據(jù)庫也難以應(yīng)付，需要新的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)。
于是，非關(guān)系型數(shù)據(jù)庫應(yīng)運(yùn)而生，由于不可能用一種數(shù)據(jù)結(jié)構(gòu)化存儲(chǔ)應(yīng)付所有的新的需求，因此，非關(guān)系型數(shù)據(jù)庫嚴(yán)格上不是一種數(shù)據(jù)庫，應(yīng)該是一種數(shù)據(jù)結(jié)構(gòu)化存儲(chǔ)方法的集合。 必須強(qiáng)調(diào)的是，數(shù)據(jù)的持久存儲(chǔ)，尤其是海量數(shù)據(jù)的持久存儲(chǔ)，還是需要一種關(guān)系數(shù)據(jù)庫。
非關(guān)系型數(shù)據(jù)庫簡介
SQLite
1. ACID事務(wù)
2. 零配置 – 無需安裝和管理配置
3. 儲(chǔ)存在單一磁盤文件中的一個(gè)完整的數(shù)據(jù)庫
4. 數(shù)據(jù)庫文件可以在不同字節(jié)順序的機(jī)器間自由的共享
5. 支持?jǐn)?shù)據(jù)庫大小至2TB
6. 足夠小, 大致3萬行C代碼, 250K
7. 比一些流行的數(shù)據(jù)庫在大部分普通數(shù)據(jù)庫操作要快8. 簡單, 輕松的API
9. 包含TCL綁定, 同時(shí)通過Wrapper支持其他語言的綁定10. 良好注釋的源代碼, 并且有著90%以上的測試覆蓋率 11. 獨(dú)立: 沒有額外依賴
12. Source完全的Open, 你可以用于任何用途, 包括出售它 13. 支持多種開發(fā)語言,C, PHP, Perl, Java, ASP .NET,Python

下面介紹下key相關(guān)的命令
exits key 測試指定key是否存在，返回1表示存在，0不存在
del key1 key2 ....keyN 刪除給定key,返回刪除key的數(shù)目，0表示給定key都不存在
type key 返回給定key的value類型。返回 none 表示不存在key,string字符類型，list 鏈表類型 set 無序集合類型...
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ù)庫中隨機(jī)選擇的一個(gè)key,如果當(dāng)前數(shù)據(jù)庫是空的，返回空串 rename oldkey newkey
原子的重命名一個(gè)key,如果newkey存在，將會(huì)被覆蓋，返回1表示成功，0失敗?？赡苁莖ldkey不存在或者和newkey相同
renamenx oldkey newkey 同上，但是如果newkey存在返回失敗 dbsize 返回當(dāng)前數(shù)據(jù)庫的key數(shù)量
expire key seconds 為key指定過期時(shí)間，單位是秒。返回1成功，0表示key已經(jīng)設(shè)置過過期時(shí)間或者不存在
ttl key 返回設(shè)置過過期時(shí)間的key的剩余過期秒數(shù) -1表示key不存在或者沒有設(shè)置過過期時(shí)間
select db-index 通過索引選擇數(shù)據(jù)庫，默認(rèn)連接的數(shù)據(jù)庫所有是0,默認(rèn)數(shù)據(jù)庫數(shù)是16個(gè)。返回1表示成功，0失敗
move key db-index 將key從當(dāng)前數(shù)據(jù)庫移動(dòng)到指定數(shù)據(jù)庫。返回1成功。0 如果key不存在，或者已經(jīng)在指定數(shù)據(jù)庫中
flushdb 刪除當(dāng)前數(shù)據(jù)庫中所有key,此方法不會(huì)失敗。慎用
flushall 刪除所有數(shù)據(jù)庫中的所有key，此方法不會(huì)失敗。更加慎用
2. string 類型
string是redis最基本的類型，而且string類型是二進(jìn)制安全的。意思是redis的string可以包含任何數(shù)據(jù)。比如jpg圖片或者序列化的對象

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

1、High performance – 對數(shù)據(jù)庫高并發(fā)讀寫的需求
web2.0網(wǎng)站要根據(jù)用戶個(gè)性化信息來實(shí)時(shí)生成動(dòng)態(tài)頁面和提供動(dòng)態(tài)信息，所以基本上無法使用動(dòng)態(tài)頁面靜態(tài)化技術(shù)，因此數(shù)據(jù)庫并發(fā)負(fù)載非常高，往往要達(dá)到 每秒上萬次讀寫請求。關(guān)系數(shù)據(jù)庫應(yīng)付上萬次SQL查詢還勉強(qiáng)頂?shù)米?，但是?yīng)付上萬次SQL寫數(shù)據(jù)請求，硬盤IO就已經(jīng)無法承受了。其實(shí)對于普通的BBS網(wǎng) 站，往往也存在對高并發(fā)寫請求的需求，例如像JavaEye網(wǎng)站的實(shí)時(shí)統(tǒng)計(jì)在線用戶狀態(tài)，記錄熱門帖子的點(diǎn)擊次數(shù)，投票計(jì)數(shù)等，因此這是一個(gè)相當(dāng)普遍的需 求。

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

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

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

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

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

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

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

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

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

一、滿足極高讀寫性能需求的Kye-Value數(shù)據(jù)庫：Redis，Tokyo Cabinet， Flare

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

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

Redis的出色之處不僅僅是性能，Redis最大的魅力是支持保存List鏈表和Set集合的數(shù)據(jù)結(jié)構(gòu)，而且還支持對List進(jìn)行各種操作，例如從 List兩端push和pop數(shù)據(jù)，取List區(qū)間，排序等等，對Set支持各種集合的并集交集操作，此外單個(gè)value的最大限制是1GB，不像 memcached只能保存1MB的數(shù)據(jù)，因此Redis可以用來實(shí)現(xiàn)很多有用的功能，比方說用他的List來做FIFO雙向鏈表，實(shí)現(xiàn)一個(gè)輕量級的高性 能消息隊(duì)列服務(wù)，用他的Set可以做高性能的tag系統(tǒng)等等。另外Redis也可以對存入的Key-Value設(shè)置expire時(shí)間，因此也可以被當(dāng)作一 個(gè)功能加強(qiáng)版的memcached來用。

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

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

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

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

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

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

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

二、滿足海量存儲(chǔ)需求和訪問的面向文檔的數(shù)據(jù)庫：MongoDB，CouchDB

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

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

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

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

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

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

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

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

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

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

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

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

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

2、Voldemort
Voldemort是個(gè)和Cassandra類似的面向解決scale問題的分布式數(shù)據(jù)庫系統(tǒng)，Cassandra來自于Facebook這個(gè)SNS網(wǎng) 站，而Voldemort則來自于Linkedin這個(gè)SNS網(wǎng)站。說起來SNS網(wǎng)站為我們貢獻(xiàn)了n多的NoSQL數(shù)據(jù)庫，例如 Cassandar，Voldemort，Tokyo Cabinet，F(xiàn)lare等等。Voldemort的資料不是很多，因此我沒有特別仔細(xì)去鉆研，Voldemort官方給出Voldemort的并發(fā)讀 寫性能也很不錯(cuò)，每秒超過了1.5萬次讀寫。

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

補(bǔ)充說明：

1.實(shí)質(zhì)。 非關(guān)系型數(shù)據(jù)庫的實(shí)質(zhì)：非關(guān)系型數(shù)據(jù)庫產(chǎn)品是傳統(tǒng)關(guān)系型數(shù)據(jù)庫的功能閹割版本，通過減少用不到或很少用的功能，來大幅度提高產(chǎn)品性能。
2.價(jià)格。 目前基本上大部分主流的非關(guān)系型數(shù)據(jù)庫都是免費(fèi)的。而比較有名氣的關(guān)系型數(shù)據(jù)庫，比如Oracle、DB2、MSSQL是收費(fèi)的。雖然Mysql免費(fèi)，但它需要做很多工作才能正式用于生產(chǎn)。
3.功能。 實(shí)際開發(fā)中，有很多業(yè)務(wù)需求，其實(shí)并不需要完整的關(guān)系型數(shù)據(jù)庫功能，非關(guān)系型數(shù)據(jù)庫的功能就足夠使用了。這種情況下，使用性能更高、成本更低的非關(guān)系型數(shù)據(jù)庫當(dāng)然是更明智的選擇。
非關(guān)系型數(shù)據(jù)庫在某些特定的領(lǐng)域很好用，比如redis作為數(shù)據(jù)的緩存，數(shù)據(jù)是存儲(chǔ)在內(nèi)存中，所以性能非常好，底層只有三萬條代碼，貌似知乎就用到了redis作為數(shù)據(jù)庫。
非關(guān)系數(shù)據(jù)庫只實(shí)現(xiàn)了關(guān)系數(shù)據(jù)庫一部分的功能，但因此很大程度上擴(kuò)充了某些功能的性能。一般用關(guān)系數(shù)據(jù)庫就夠了。嚴(yán)格說mysql在關(guān)系數(shù)據(jù)庫兄是實(shí)現(xiàn)得也不是很完整的一類，從而在某些查詢上，mysql有超出嚴(yán)格關(guān)系數(shù)據(jù)庫很多的性能。具體應(yīng)用需要權(quán)衡，特別是關(guān)聯(lián)條件很多的數(shù)據(jù)，非關(guān)系數(shù)據(jù)庫一般不合適，有時(shí)候甚至mysql也不合適。

總結(jié)

以上是生活随笔為你收集整理的非关系型数据库（NoSql）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。