滿足極高讀寫性能需求的Key-Value數(shù)據(jù)庫

高性能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)，而且還支持對(duì)List進(jìn)行各種操作，例如 從List兩端push和pop數(shù)據(jù)，取List區(qū)間，排序等等，對(duì)Set支持各種集合的并集交集操作，此外單個(gè)value的最大限制是1GB，不像 memcached只能保存1MB的數(shù)據(jù)，因此Redis可以用來實(shí)現(xiàn)很多有用的功能，比方說用他的List來做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來用。

Redis的主要缺點(diǎn)是數(shù)據(jù)庫容量受到物理內(nèi)存的限制，不能用作海量數(shù)據(jù)的高性能讀寫，并且它沒有原生的可擴(kuò)展機(jī)制，不具有scale（可擴(kuò)展）能 力，要依賴客戶端來實(shí)現(xiàn)分布式讀寫，因此Redis適合的場(chǎng)景主要局限在較小數(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è)簡(jiǎn)單的數(shù)據(jù)庫表，并且還支持基于column的條件 查詢，分頁查詢和排序功能，基本上相當(dāng)于支持單表的基礎(chǔ)查詢功能了，所以可以簡(jiǎn)單的替代關(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以及簡(jiǎn)單的條件，分頁和排序操作，是一個(gè)很棒的NoSQL 數(shù)據(jù)庫。

TC的主要缺點(diǎn)是在數(shù)據(jù)量達(dá)到上億級(jí)別以后，并發(fā)寫數(shù)據(jù)性能會(huì)大幅度下降，NoSQL: If Only It Was That Easy提到，他們發(fā)現(xiàn)在TC里面插入1.6億條2-20KB數(shù)據(jù)的時(shí)候，寫入性能開始急劇下降。看來是當(dāng)數(shù)據(jù)量上億條的時(shí)候，TC性能開始大幅度下降， 從TC作者自己提供的mixi數(shù)據(jù)來看，至少上千萬條數(shù)據(jù)量的時(shí)候還沒有遇到這么明顯的寫入性能瓶頸。

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

3、Flare
TC是日本第一大SNS網(wǎng)站mixi開發(fā)的，而Flare是日本第二大SNS網(wǎng)站green.jp開發(fā)的，有意思吧。Flare簡(jiǎn)單的說就是給TC添加了 scale功能。他替換掉了TT部分，自己另外給TC寫了網(wǎng)絡(luò)服務(wù)器，Flare的主要特點(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。如果你的使用場(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ǔ)。

二、滿足海量存儲(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ù)庫單表查詢的絕大部分功能，而且還支持對(duì)數(shù)據(jù)建立索引。

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

因?yàn)镸ongo主要是支持海量數(shù)據(jù)存儲(chǔ)的，所以Mongo還自帶了一個(gè)出色的分布式文件系統(tǒng)GridFS，可以支持海量的數(shù)據(jù)存儲(chǔ)，但我也看到有些 評(píng)論認(rèn)為GridFS性能不佳，這一點(diǎn)還是有待親自做點(diǎn)測(cè)試來驗(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的接口，使用起來非常簡(jiǎn) 單，幾乎和DataMapper一模一樣，功能非常強(qiáng)大易用。

2、CouchDB
CouchDB現(xiàn)在是一個(gè)非常有名氣的項(xiàng)目，似乎不用多介紹了。但是卻對(duì)CouchDB沒有什么興趣，主要是因?yàn)镃ouchDB僅僅提供了基于HTTP REST的接口，因此CouchDB單純從并發(fā)讀寫性能來說，是非常糟糕的，這讓我立刻拋棄了對(duì)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ù)，對(duì)Cassandra的一個(gè)寫操作，會(huì)被 復(fù)制到其他節(jié)點(diǎn)上去，對(duì)Cassandra的讀操作，也會(huì)被路由到某個(gè)節(jié)點(diǎn)上面去讀取。對(duì)于一個(gè)Cassandra群集來說，擴(kuò)展性能是比較簡(jiǎn)單的事情， 只管在群集里面添加節(jié)點(diǎn)就可以了。看到有文章說Facebook的Cassandra群集有超過100臺(tái)服務(wù)器構(gòu)成的數(shù)據(jù)庫群集。

Cassandra也支持比較豐富的數(shù)據(jù)結(jié)構(gòu)和功能強(qiáng)大的查詢語言，和MongoDB比較類似，查詢功能比MongoDB稍弱一些，twitter 的平臺(tái)架構(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ā)讀寫性能不是特別好，有文章說評(píng)測(cè)下來Cassandra每秒大約不到1萬次讀寫請(qǐng)求，也看到一 些對(duì)這個(gè)問題進(jìn)行質(zhì)疑的評(píng)論，但是評(píng)價(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，Flare等等。Voldemort的資料不是很多，因此沒有特別仔細(xì)去鉆研，Voldemort官方給出Voldemort的并發(fā)讀寫 性能也很不錯(cuò)，每秒超過了1.5萬次讀寫。

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

總結(jié)

以上是生活随笔為你收集整理的满足极高读写性能需求的Key-Value数据库的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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