脫離理論,觸摸NoSQL:分布式可擴(kuò)展非關(guān)系數(shù)據(jù)庫(kù)聚焦
原創(chuàng)【51CTO精選譯文】在網(wǎng)絡(luò)世界中,大規(guī)模數(shù)據(jù)存儲(chǔ)發(fā)生了有趣的變化,一種全新的可擴(kuò)展數(shù)據(jù)存儲(chǔ)正快速普及,傳統(tǒng)的LAMP組合開(kāi)始變得越來(lái)越落伍。最近幾年以來(lái),Memcached經(jīng)常出現(xiàn)在MySQL身邊,現(xiàn)在整個(gè)“數(shù)據(jù)層”都開(kāi)始動(dòng)搖了。
雖然有些人認(rèn)為這是擺脫MySQL和PostgreSQL等傳統(tǒng)的開(kāi)源關(guān)系數(shù)據(jù)庫(kù)的機(jī)會(huì),實(shí)際上事情并不是這么簡(jiǎn)單,從這些有趣的變化中我們得出一些啟示:
1)關(guān)系數(shù)據(jù)庫(kù)并不適合所有的數(shù)據(jù)模型;
2)關(guān)系數(shù)據(jù)庫(kù)擴(kuò)展難度大,特別是當(dāng)你一開(kāi)始就設(shè)計(jì)為單機(jī)配置,未進(jìn)行分布式設(shè)計(jì)時(shí);
3)標(biāo)準(zhǔn)化通常會(huì)傷害到性能;
4)在許多應(yīng)用中,主鍵就是你的一切。
新的數(shù)據(jù)存儲(chǔ)完全改變了傳統(tǒng)的觀念,但總的來(lái)說(shuō),它們借鑒了一套類似的高級(jí)特征,但它們并非能夠滿足一切。下面給出一個(gè)列表,讓你看看它們正試圖實(shí)現(xiàn)什么。
1)反標(biāo)準(zhǔn)化,通常是無(wú)模式的,文檔型存儲(chǔ);
2)以key/value為基礎(chǔ),支持通過(guò)key進(jìn)行查找;
3)水平擴(kuò)展;
4)內(nèi)置復(fù)制;
5)HTTP/REST或很容易編程的API;
6)支持MapReduce的風(fēng)格的編程;
7)最終一致。
如果還要列的話,我可能還可以列出一打來(lái)。但前面兩個(gè)是對(duì)傳統(tǒng)數(shù)據(jù)庫(kù)最大的叛離(51CTO編者注:所以說(shuō)NoSQL是數(shù)據(jù)庫(kù)領(lǐng)域的革命),當(dāng)然你也可以堅(jiān)持使用MySQL,并將其去關(guān)系化,這也是FriendFeed要做的事情,F(xiàn)riendFeed使用MySQL作為后端,實(shí)現(xiàn)分布式key/value存儲(chǔ)。
對(duì)這些分布式無(wú)模式的數(shù)據(jù)存儲(chǔ),開(kāi)始有一個(gè)新名稱來(lái)稱呼,那就是NoSQL。與其在NoSQL存儲(chǔ)系統(tǒng)理論上花大量的時(shí)間闡述,我更愿意花點(diǎn)時(shí)間來(lái)談?wù)勎已矍虻囊恍〇|西。
Redis
關(guān)于Redis我不想說(shuō)太多,因?yàn)槲以谧罱囊黄恼隆癛edis: Lightweight key/value Store That Goes the Extra Mile”中已經(jīng)說(shuō)得很詳細(xì)了,這里我只簡(jiǎn)要說(shuō)一下。它是一個(gè)輕量級(jí)內(nèi)存中的key/value存儲(chǔ),可以處理字符串,數(shù)據(jù)集和列表,擁有一個(gè)優(yōu)秀的數(shù)據(jù)類型操縱核心。Redis內(nèi)置了復(fù)制支持,保證數(shù)據(jù)在磁盤上的連續(xù)性,它還很年輕,但現(xiàn)在已經(jīng)發(fā)布了1.0版本。
Redis吸引我的另一個(gè)原因是它的API很簡(jiǎn)單,通過(guò)增加特殊的數(shù)據(jù)結(jié)構(gòu),并提供更快速的原子操作,給傳統(tǒng)key/value存儲(chǔ)開(kāi)了一個(gè)口。
Tokyo Cabinet
Tokyo Cabinet來(lái)自日本,它是一個(gè)快速和成熟的基于磁盤的key/value存儲(chǔ),感覺(jué)好像是BerkeleyDB為Web領(lǐng)域應(yīng)用重寫的。它通常和Tokyo Tyrant搭配使用。Tokyo Tyrant是一個(gè)網(wǎng)絡(luò)服務(wù)器,它將Tokyo Cabinet轉(zhuǎn)變成網(wǎng)絡(luò)服務(wù),使用HTTP和memcached協(xié)議以及它自己的二進(jìn)制協(xié)議通信。
和其它現(xiàn)代DBM實(shí)現(xiàn)類似,Tokyo Cabinet提供B-Tree,Hash和固定大小的類似數(shù)組的記錄存儲(chǔ)選項(xiàng)。它打動(dòng)我是因?yàn)椋褂肨okyo Tyrant時(shí),在穩(wěn)定的低級(jí)數(shù)據(jù)庫(kù)架構(gòu)上有一個(gè)現(xiàn)代網(wǎng)絡(luò)協(xié)議和接口,讓你選擇正確的數(shù)據(jù)結(jié)構(gòu)使用。它是相對(duì)成熟的技術(shù),在某些高容量網(wǎng)站上也有其身影。
Apache CouchDB
下面的內(nèi)容引自Apache CouchDB主頁(yè):
“Apache CouchDB是一個(gè)面向文檔的數(shù)據(jù)庫(kù),可以使用JavaScript以MapReduce風(fēng)格進(jìn)行查詢和索引,CouchDB也提供了增量復(fù)制,具有雙向沖突檢測(cè)和解決能力。”
CouchDB提供了一個(gè)RESTful JSON API,可以從任何允許HTTP請(qǐng)求的環(huán)境訪問(wèn),也有無(wú)數(shù)的第三方客戶端庫(kù)使用,無(wú)論選擇哪種編程語(yǔ)言都會(huì)變得很容易,CouchDB內(nèi)置的Web管理控制臺(tái)直接使用來(lái)自瀏覽器的HTTP請(qǐng)求與數(shù)據(jù)庫(kù)交流。
CouchDB是用Erlang編寫的,Erlang是一門功能強(qiáng)大的編程語(yǔ)言,它的理想是構(gòu)建并發(fā)的分布式系統(tǒng),Erlang允許靈活的,易于擴(kuò)展且可輕松擴(kuò)展的設(shè)計(jì)。
換句話說(shuō),CouchDB很時(shí)髦!
嚴(yán)格說(shuō)來(lái),CouchDB是第一個(gè)面向文檔的針對(duì)Web設(shè)計(jì)的數(shù)據(jù)庫(kù),它現(xiàn)在屬于Apache軟件基金會(huì),該項(xiàng)目相對(duì)比較成熟。
CouchDB吸引我是因?yàn)樗雌饋?lái)總是有點(diǎn)非關(guān)系數(shù)據(jù)存儲(chǔ)的未來(lái)主義風(fēng)格,它也使你能夠使用服務(wù)器端JavaScript表現(xiàn)出Mapreduce風(fēng)格,聽(tīng)起來(lái)似乎有定瘋狂,但它確實(shí)能工作得很好,其API很簡(jiǎn)單,都是經(jīng)過(guò)深思熟慮的,因此進(jìn)入的門檻非常低,你可以在PC或筆記本電腦上輕松部署一個(gè)CouchDB實(shí)例,然后與云中或你公司數(shù)據(jù)中心的CouchDB服務(wù)器進(jìn)行同步。
CouchDB也實(shí)現(xiàn)了一個(gè)非常有用的版本控制方案,從而不必重新發(fā)明車輪構(gòu)建一個(gè)協(xié)作系統(tǒng)。
Riak
Riak是我最近才感興趣的一個(gè)數(shù)據(jù)存儲(chǔ),它也是一個(gè)面向文檔的Web數(shù)據(jù)庫(kù),它結(jié)合了分散的key/value存儲(chǔ),擁有一個(gè)靈活的Map/Reduce引擎和一個(gè)友好的HTTP/JSON查詢接口,為Web應(yīng)用程序提供了一個(gè)理想的數(shù)據(jù)庫(kù)選擇,為了最大限度提高網(wǎng)絡(luò)和服務(wù)器中斷時(shí)的可用性,它使用了最終一致性模型。實(shí)際上,Riak最有趣的特性是你可以很容易地控制參數(shù),定義在出現(xiàn)問(wèn)題時(shí)系統(tǒng)的可用性。
這些參數(shù)來(lái)自Eric Brewer的CAP定理,該定理指出我們應(yīng)該關(guān)心的三種要素是:不同程度的一致性,可用性和分區(qū)冗余。和其它系統(tǒng)不一樣,Riak并不強(qiáng)制你使用一組特定的CAP值,相反,它允許你在每個(gè)請(qǐng)求的基礎(chǔ)上決定如何約束你想要的內(nèi)容。
這得感謝三個(gè)變量:N,R和W。在一個(gè)分布式系統(tǒng)中,N是系統(tǒng)中復(fù)制品的數(shù)量,因此,如果你要寫入一個(gè)新的key/value對(duì),N設(shè)置為4,那么將有4個(gè)節(jié)點(diǎn)會(huì)收到它的復(fù)制品。
R和W是以每請(qǐng)求為基礎(chǔ)設(shè)置的,為了控制節(jié)點(diǎn)的數(shù)量,客戶端必須從一個(gè)完整的讀或?qū)懖僮鹘邮芤粋€(gè)響應(yīng),R表示讀,W表示寫。這提供了非常細(xì)粒度的控制,在集群環(huán)境中,客戶端可以對(duì)失效的節(jié)點(diǎn)做出反應(yīng)。
其它
還有很多其它的NoSQL系統(tǒng),下面是我準(zhǔn)備嘗試的非關(guān)系數(shù)據(jù)庫(kù)系統(tǒng):
MongoDB:MongoDB是一個(gè)以VC為后端的分布式無(wú)模式數(shù)據(jù)庫(kù),有商業(yè)支持(參考閱讀:MongoDB簡(jiǎn)介)。
Voldemort:Voldemort是一個(gè)相當(dāng)成熟的系統(tǒng),在LinkedIn上有大量的使用,它具有自動(dòng)復(fù)制和分區(qū)功能。
MemcacheDB:MemcacheDB結(jié)合了BerkeleyDB存儲(chǔ)系統(tǒng)和使用memcached網(wǎng)絡(luò)協(xié)議的網(wǎng)絡(luò)服務(wù)器,因此你可以創(chuàng)建一個(gè)類memcached的節(jié)點(diǎn),可以比傳統(tǒng)的基于RAM的memcached節(jié)點(diǎn)容納更多的數(shù)據(jù),并可以保證重啟后數(shù)據(jù)不會(huì)丟失,在某些方面它和Tokyo Cabinet 和Tokyo Tyrant組合有些類似。
最后,我想問(wèn)的是你已經(jīng)涉足NoSQL了嗎?它將何去何從?
【編輯推薦】
- NoSQL運(yùn)動(dòng):緩慢而堅(jiān)定的前進(jìn)著
- NoSQL真的能終結(jié)關(guān)系數(shù)據(jù)庫(kù)?
- 對(duì)SQL說(shuō)不!NoSQL的數(shù)據(jù)庫(kù)技術(shù)革命
- 云計(jì)算使關(guān)系數(shù)據(jù)庫(kù)逐漸落伍
- 關(guān)系數(shù)據(jù)庫(kù)的末日是否已經(jīng)來(lái)臨
原文:NoSQL: Distributed and Scalable Non-Relational Database Systems 作者:Jeremy Zawodny
【51CTO.com譯稿,非經(jīng)授權(quán)請(qǐng)勿轉(zhuǎn)載。合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com,且不得修改原文內(nèi)容。】