關(guān)系數(shù)據(jù)庫(kù)的末日是否已經(jīng)來(lái)臨
最近，大量新的非關(guān)系式數(shù)據(jù)庫(kù)如雨后春筍般出現(xiàn)在云里云外。這其中所釋放出的一個(gè)關(guān)鍵信息是：“如果想獲得豐富而隨需應(yīng)變的可伸縮性，你需要一個(gè)非關(guān)系數(shù)據(jù)庫(kù)?！?/p>
如果這是真的，那么這是不是一個(gè)跡象，表明曾經(jīng)強(qiáng)大的關(guān)系式數(shù)據(jù)庫(kù)終于在它的盔甲上出現(xiàn)了裂縫？關(guān)系數(shù)據(jù)庫(kù)的日子是不是到頭了？該隱退了？在本文中，我們將檢視當(dāng)前這種在特定情況下擺脫關(guān)系數(shù)據(jù)庫(kù)的趨勢(shì)，并分析這對(duì)于關(guān)系數(shù)據(jù)庫(kù)的未來(lái)意味著什么。
關(guān)系數(shù)據(jù)庫(kù)已過(guò)而立之年。在此期間，短暫爆發(fā)過(guò)一些所謂終結(jié)關(guān)系數(shù)據(jù)庫(kù)的革命。當(dāng)然，最終都失敗了，絲毫沒(méi)有動(dòng)搖到關(guān)系數(shù)據(jù)庫(kù)的主導(dǎo)地位。
先了解一些背景
一個(gè)關(guān)系數(shù)據(jù)庫(kù)基本上就是一個(gè)表（實(shí)體）集合。表由列和行（變量集）構(gòu)成。這些表存在約束，相互之間定義了關(guān)系。關(guān)系數(shù)據(jù)庫(kù)使用SQL進(jìn)行查詢，結(jié)果集通過(guò)訪問(wèn)一個(gè)或多個(gè)表的查詢生成。單個(gè)查詢里被訪問(wèn)到的多個(gè)表，一般是利用在表關(guān)系列里定義的范式被“連接”到一起的。 規(guī)范化 是關(guān)系數(shù)據(jù)庫(kù)使用到的一種數(shù)據(jù)結(jié)構(gòu)模型，能保證數(shù)據(jù)一致性并消除數(shù)據(jù)冗余。
關(guān)系數(shù)據(jù)庫(kù)在 關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng) (RDBMS)的幫助下得以促進(jìn)。我們今天所使用的絕大部分?jǐn)?shù)據(jù)庫(kù)系統(tǒng)都是RDBMS，包括 Oracle，SQL Server， MySQL，Sybase，DB2，TeraData等等。
關(guān)系數(shù)據(jù)庫(kù)占據(jù)統(tǒng)治地位的原因并非微不足道的。它們持續(xù)提供了簡(jiǎn)單性、健壯性、靈活性以及性能的***組合，并帶來(lái)了通用數(shù)據(jù)管理的兼容性。
不過(guò)，為了實(shí)現(xiàn)這一切，關(guān)系數(shù)據(jù)庫(kù)的內(nèi)部不得不復(fù)雜得難以置信。舉個(gè)例子說(shuō)，一個(gè)相對(duì)簡(jiǎn)單的SELECT語(yǔ)句可能有著上百條執(zhí)行路徑，優(yōu)化程序在運(yùn)行時(shí)必須進(jìn)行評(píng)估。這一切都被隱藏起來(lái)，對(duì)用戶都是不可見(jiàn)的，RDBMS通過(guò)使用類似基于代價(jià)的算法來(lái)決定***響應(yīng)請(qǐng)求的“執(zhí)行計(jì)劃”。
關(guān)系數(shù)據(jù)庫(kù)的問(wèn)題
盡管RDBMS為數(shù)據(jù)庫(kù)用戶提供了簡(jiǎn)單性、健壯性、靈活性、性能、可伸縮性以及兼容性的***組合，但它在其中每個(gè)領(lǐng)域里的性能，不一定就優(yōu)于其他追求某一項(xiàng)好處的獨(dú)立替代方案。迄今為止這不是太大的問(wèn)題，因?yàn)镽DBMS的普遍優(yōu)勢(shì)已經(jīng)壓制了開(kāi)疆拓土的需求。不過(guò)，如果你的確存在著通用關(guān)系數(shù)據(jù)庫(kù)無(wú)法滿足的要求，替代的方案則總可以填補(bǔ)這些壁龕。
今天，形勢(shì)略有不同。對(duì)于數(shù)量不斷增長(zhǎng)的應(yīng)用程序而言，上述的其中一項(xiàng)好處變得越來(lái)越重要；雖仍被視為特殊，但正迅速成為主流，以至于對(duì)于不斷增長(zhǎng)的數(shù)據(jù)庫(kù)用戶來(lái)說(shuō)，其在重要性方面已經(jīng)開(kāi)始侵蝕掉其它的好處了。這項(xiàng)好處就是可伸縮性。隨著越來(lái)越多如Web服務(wù)之類承受大規(guī)模工作負(fù)荷的應(yīng)用的發(fā)行，其對(duì)可伸縮性的需求，首先有可能會(huì)改變得非常迅速，其次會(huì)變得無(wú)比龐大。***種場(chǎng)景下，如果你只有一個(gè)龜縮在一所房子內(nèi)的服務(wù)器中的關(guān)系數(shù)據(jù)庫(kù)，情況將難以管理。舉個(gè)例子，如果你的負(fù)載一夜之間增加了2倍，你能用多快的速度去升級(jí)硬件？第二種情況下，一般的關(guān)系數(shù)據(jù)庫(kù)是也很難管理的。
關(guān)系數(shù)據(jù)庫(kù)的確能伸縮自如，但通常只能單臺(tái)服務(wù)器節(jié)點(diǎn)上進(jìn)行。一旦單節(jié)點(diǎn)的能力抵達(dá)上限，你就得通過(guò)多服務(wù)器節(jié)點(diǎn)來(lái)往外擴(kuò)展來(lái)分發(fā)負(fù)載。這時(shí)候關(guān)系數(shù)據(jù)庫(kù)的復(fù)雜性就開(kāi)始影響其潛在的擴(kuò)展規(guī)模了。試圖擴(kuò)展到成百上千個(gè)節(jié)點(diǎn)，而不是幾個(gè)，將導(dǎo)致不堪復(fù)雜性之重負(fù)，這一特點(diǎn)使得RDBMS在大型分布式系統(tǒng)平臺(tái)市場(chǎng)里的生存能力被大幅削減。
為了讓云服務(wù)變得可行，供應(yīng)商不得不突破這種限制，因?yàn)橐粋€(gè)缺乏伸縮性的數(shù)據(jù)倉(cāng)儲(chǔ)的云平臺(tái)根據(jù)就不能算一個(gè)平臺(tái)。因此，為了能向客戶提供的一個(gè)伸縮自如的空間去存放應(yīng)用數(shù)據(jù)，供應(yīng)商實(shí)際上只有一種真正的選擇。他們不得不實(shí)現(xiàn)一種新型的關(guān)注于可擴(kuò)性的數(shù)據(jù)庫(kù)系統(tǒng)，而犧牲掉關(guān)系數(shù)據(jù)庫(kù)所帶來(lái)的其他好處。
這些努力，再加上那些已有的特殊供應(yīng)商，已經(jīng)帶來(lái)了一種新型的數(shù)據(jù)庫(kù)管理系統(tǒng)。
#p#
新品種
這種新型的數(shù)據(jù)庫(kù)管理系統(tǒng)通常被稱為鍵/值存儲(chǔ)。實(shí)際上，尚無(wú)正式的名字，因此你可能會(huì)看到它被稱為面向文檔的、面向互聯(lián)網(wǎng)的、面向?qū)傩缘摹?分布式數(shù)據(jù)庫(kù) (盡管這也可以是關(guān)系式的)、共享排序數(shù)組、 分布式哈希表以及鍵/值數(shù)據(jù)庫(kù)。雖然每個(gè)名字都指出了這種新方案的某種特征，但都是基于一個(gè)主題的派生，這個(gè)主題就是我們將要命名的鍵/值數(shù)據(jù)庫(kù)。
不關(guān)你怎么稱呼它，這個(gè)“新型”的數(shù)據(jù)庫(kù)其實(shí)已經(jīng)在某些普通關(guān)系數(shù)據(jù)庫(kù)不合適的特殊應(yīng)用里使用了很長(zhǎng)時(shí)間了。不過(guò)如果沒(méi)有Web和云應(yīng)用所帶來(lái)的伸縮性的話，它很可能還得繼續(xù)呆在深閨大院里?，F(xiàn)在的挑戰(zhàn)是我們得弄清楚，究竟是它還是關(guān)系數(shù)據(jù)庫(kù)更適合于特定應(yīng)用。
關(guān)系數(shù)據(jù)庫(kù)和鍵/值數(shù)據(jù)庫(kù)從根本上來(lái)說(shuō)是完全不同的，分別被設(shè)計(jì)用于滿足不同的需求。迄今為止，一項(xiàng)一對(duì)一的比較能有助于你理解這種差異性，不過(guò)在開(kāi)始之前，先讓我們來(lái)看看下面：
沒(méi)有實(shí)體連接
鍵/值數(shù)據(jù)庫(kù)是面向項(xiàng)目的，這意味著所有與項(xiàng)目有關(guān)的數(shù)據(jù)都被存儲(chǔ)進(jìn)該項(xiàng)目中。一個(gè)域（你可以把它視為表）可以包含大量不同的項(xiàng)目。比如說(shuō)，一個(gè)域里可以同時(shí)包含客戶項(xiàng)目和定單項(xiàng)目。這意味著在一個(gè)域內(nèi)，不同項(xiàng)目間的數(shù)據(jù)通常是重復(fù)的。這在實(shí)踐上是可行的，因?yàn)榇疟P空間相對(duì)廉價(jià)。但這個(gè)模型允許一個(gè)單一的項(xiàng)目包含完所有相關(guān)數(shù)據(jù)，就可以通過(guò)消除對(duì)多表的數(shù)據(jù)連接的需求來(lái)改善可擴(kuò)性。而在關(guān)系數(shù)據(jù)庫(kù)中，那樣的數(shù)據(jù)需要被連接到一起，以便能重組為相關(guān)屬性。
不過(guò)雖然在關(guān)系數(shù)據(jù)庫(kù)中的需求在鍵/值數(shù)據(jù)庫(kù)已大為減少，有些東西還是不可避免的。那些關(guān)系一般存在于核心實(shí)體之間。比如說(shuō)，定單系統(tǒng)會(huì)有這樣一些項(xiàng)目，其中包含有客戶、產(chǎn)品及定單的數(shù)據(jù)。 這些是否在相同或不同的域都是無(wú)關(guān)緊要的；但是當(dāng)客戶下單時(shí)，你大概不會(huì)想把客戶和產(chǎn)品的屬性都放進(jìn)同一張定單里吧。
相反，定單需要包含相關(guān)鍵值指向客戶和產(chǎn)品。盡管這在鍵/值數(shù)據(jù)庫(kù)是完全可行的，這些關(guān)系卻不會(huì)在數(shù)據(jù)模型本身內(nèi)進(jìn)行定義，因此數(shù)據(jù)庫(kù)管理系統(tǒng)是無(wú)法強(qiáng)制要求這些關(guān)系的數(shù)據(jù)一致性的。這意味著你可以刪除客戶及其已訂購(gòu)產(chǎn)品。確保數(shù)據(jù)完整性的責(zé)任完全落在了應(yīng)用的身上。
鍵/值存儲(chǔ):優(yōu)點(diǎn)
有兩點(diǎn)鍵/值數(shù)據(jù)庫(kù)是明顯優(yōu)于關(guān)系數(shù)據(jù)庫(kù)的。
云的***搭檔
***個(gè)好處是它們簡(jiǎn)單，并因此比關(guān)系數(shù)據(jù)庫(kù)伸縮起來(lái)要自如得多。如果你正在打算把一個(gè)內(nèi)部系統(tǒng)聚攏起來(lái)，試圖把預(yù)期中規(guī)模龐大的伸縮需求交給數(shù)據(jù)倉(cāng)儲(chǔ)背后那數(shù)十上百臺(tái)服務(wù)器去處理，那么就請(qǐng)考慮一下鍵/值存儲(chǔ)。
由于鍵/值數(shù)據(jù)庫(kù)簡(jiǎn)單，且動(dòng)態(tài)可擴(kuò)，它們也是提供多用戶、web服務(wù)的平臺(tái)數(shù)據(jù)存儲(chǔ)的供應(yīng)商的選擇。這種數(shù)據(jù)庫(kù)提供了相對(duì)廉價(jià)的設(shè)計(jì)存儲(chǔ)平臺(tái)，并擁有龐大的擴(kuò)充潛力。用戶通常只需用多少就給多少，而其需求增長(zhǎng)時(shí)配額能隨之而增。與此同時(shí)，供應(yīng)商能基于總用量動(dòng)態(tài)擴(kuò)充平臺(tái)，整個(gè)平臺(tái)的大小幾乎不受限制。（譯者：最典型的就是各種所謂支持多少G的郵箱應(yīng)用了）
編碼得心應(yīng)手
關(guān)系數(shù)據(jù)庫(kù)模型和應(yīng)用代碼對(duì)象模型通常是以不同方式建立起來(lái)的，這導(dǎo)致了不兼容性。開(kāi)發(fā)人員通過(guò)將代碼映射到關(guān)系模型去克服這種不兼容性。這個(gè)過(guò)程一般被稱為 對(duì)象-關(guān)系映射，基本上等于是“管道”代碼，沒(méi)有直接明確的價(jià)值，卻耗費(fèi)掉了應(yīng)用開(kāi)發(fā)的大量時(shí)間和精力。另一方面，許多鍵/值數(shù)據(jù)庫(kù)在結(jié)構(gòu)中保留的數(shù)據(jù)，與底層代碼中的對(duì)象類的映射關(guān)系卻要直接得多，從而顯著減少了開(kāi)發(fā)時(shí)間。
其它一些支持這種數(shù)據(jù)存儲(chǔ)的理由，比如“關(guān)系數(shù)據(jù)庫(kù)相比之下更為笨拙（不管這意味這什么）”等，則不太令人信服。不過(guò)在跳上這趟鍵/值數(shù)據(jù)庫(kù)的列車之前，請(qǐng)先考慮一下它的缺點(diǎn)。
鍵/值存儲(chǔ): 缺點(diǎn)
關(guān)系數(shù)據(jù)庫(kù)固有的約束保證數(shù)據(jù)在***層次擁有完整性。違反完整性約束的數(shù)據(jù)在物理上進(jìn)不了數(shù)據(jù)庫(kù)中。這些約束在鍵/值數(shù)據(jù)庫(kù)中是不存在的，因此確保設(shè)計(jì)完整性的責(zé)任全部落到了應(yīng)用程序的肩上。但是程序會(huì)經(jīng)常出現(xiàn)Bug。在一個(gè)設(shè)計(jì)得當(dāng)?shù)年P(guān)系數(shù)據(jù)庫(kù)里，Bug通常不會(huì)導(dǎo)致數(shù)據(jù)完整性問(wèn)題；但是在鍵/值數(shù)據(jù)庫(kù)里的bug就很容易引起數(shù)據(jù)完整性問(wèn)題。
關(guān)系數(shù)據(jù)庫(kù)另一項(xiàng)關(guān)鍵的好處就是它強(qiáng)迫你經(jīng)過(guò)一個(gè)數(shù)據(jù)建模的過(guò)程。如果做得好，這個(gè)建模過(guò)程所創(chuàng)建出的數(shù)據(jù)庫(kù)的邏輯結(jié)構(gòu)，就應(yīng)該是映射它所要包含的數(shù)據(jù)，而非映射應(yīng)用程序的結(jié)構(gòu)。然后數(shù)據(jù)從某種程度上就變得是獨(dú)立于應(yīng)用的，意味著其他應(yīng)用同樣也能使用統(tǒng)一數(shù)據(jù)集，從而應(yīng)用邏輯的改變不會(huì)影響到底層的數(shù)據(jù)模型。而鍵/值數(shù)據(jù)庫(kù)要實(shí)現(xiàn)這一過(guò)程的話，就要以類的建模實(shí)踐替代關(guān)系數(shù)據(jù)建模，以便在數(shù)據(jù)的自然結(jié)構(gòu)基礎(chǔ)上創(chuàng)建出通用的類。
還有別忘了兼容性。面向云的數(shù)據(jù)庫(kù)不像關(guān)系數(shù)據(jù)庫(kù)，并沒(méi)有多少辦法去共享標(biāo)準(zhǔn)。盡管它們都有著類似的概念，卻各有著自己的API、特定的查詢接口及特性。因此，你真的要信任你的供應(yīng)商，因?yàn)榫退隳銓?duì)服務(wù)不滿意也覆水難收了。還有，由于目前所有的鍵/值數(shù)據(jù)庫(kù)均處于測(cè)試階段，這種信任的風(fēng)險(xiǎn)可比對(duì)老派的關(guān)系數(shù)據(jù)庫(kù)要高的多。
分析上的限制
在云內(nèi)，鍵/值數(shù)據(jù)庫(kù)一般是多租戶的，這意味這許多用戶和應(yīng)用將使用同一系統(tǒng)。為了防止任一進(jìn)程導(dǎo)致共享環(huán)境過(guò)載，大部分云數(shù)據(jù)存儲(chǔ)嚴(yán)格限制了單一查詢可能導(dǎo)致的總影響效應(yīng)。舉個(gè)例子，在 SimpleDB里，你不能執(zhí)行過(guò)程超過(guò)5秒鐘的查詢。而在Google的AppEngine Datastore里，任何查詢結(jié)果都不允許超過(guò)1000條。
這些限制對(duì)于你的面包-奶油式的應(yīng)用邏輯（添加、更新、刪除、獲取少量?jī)?nèi)容）而言不成問(wèn)題。但是當(dāng)你的應(yīng)用取得成功的時(shí)候會(huì)發(fā)生什么呢？你已經(jīng)攫取了許多用戶，獲得了大量數(shù)據(jù)，現(xiàn)在你想為客戶創(chuàng)造新價(jià)值，或者也許還想利用這些數(shù)據(jù)產(chǎn)生新的收入。你就會(huì)發(fā)現(xiàn)自己被嚴(yán)重限制了，甚至連直接的分析型查詢都很困難。在此類平臺(tái)上，類似追蹤（用戶的）使用模式、基于用戶歷史提供建議等事情，即便不是不可能也是非常困難的。
這種情況下，你將不得不實(shí)現(xiàn)一個(gè)從鍵/值數(shù)據(jù)庫(kù)分離出來(lái)的，獨(dú)立的分析型數(shù)據(jù)庫(kù)，以便執(zhí)行那樣的分析。再想想你該在哪里才能做這樣的事情？又該如何去做？是不是應(yīng)在云上維護(hù)它？還是投資于一個(gè)現(xiàn)場(chǎng)（譯者：on-site對(duì)應(yīng)于off-site，一般在IT外包中應(yīng)用）的設(shè)施？你和云服務(wù)供應(yīng)商之間的延遲會(huì)不會(huì)成為問(wèn)題？你現(xiàn)在的基于云的鍵/值數(shù)據(jù)庫(kù)支持它嗎？如果你的鍵/值數(shù)據(jù)庫(kù)有10億個(gè)條目，可是每秒鐘卻只能提供1000條結(jié)果，這樣的查詢?cè)搱?zhí)行多久才能完事呢？
歸根結(jié)底，雖然規(guī)模是一項(xiàng)考慮因素，不要把它排在你將數(shù)據(jù)轉(zhuǎn)換成為資產(chǎn)的能力的前頭。如果你的用戶，因?yàn)楦?jìng)爭(zhēng)對(duì)手擁有更酷更人性化的特性而跑掉，這世上的一切伸縮性都將一無(wú)是處。
#p#
云服務(wù)競(jìng)爭(zhēng)者
一些網(wǎng)絡(luò)服務(wù)供應(yīng)商現(xiàn)在提供了基于即用即付的多租戶鍵/值數(shù)據(jù)庫(kù)。大部分都符合我們這里討論到的標(biāo)準(zhǔn)，但是每一個(gè)都有其獨(dú)特之處，與迄今描述的一般標(biāo)準(zhǔn)有所不同。現(xiàn)在讓我們看看這些特定的數(shù)據(jù)庫(kù)，分別是SimpleDB， Google AppEngine Datastore和SQL Data Services。
亞馬遜: SimpleDB
SimpleDB 是一個(gè)亞馬遜網(wǎng)絡(luò)服務(wù)平臺(tái)的一個(gè)面向?qū)傩缘逆I/值數(shù)據(jù)庫(kù)。SimpleDB仍處于公眾測(cè)試階段；當(dāng)前，用戶能在線注冊(cè)其“免費(fèi)”版 --免費(fèi)的意思是說(shuō)直到超出使用限制為止。
SimpleDB有幾方面的限制。首先，一次查詢最多只能執(zhí)行5秒鐘。其次，除了字符串類型，別無(wú)其它數(shù)據(jù)類型。一切都以字符串形式被存儲(chǔ)、獲取和比較，因此除非你把所有日期都轉(zhuǎn)為ISO8601，否則日期比較將不起作用。第三，任何字符串長(zhǎng)度都不能超過(guò)1024字節(jié)，這限制了你在一個(gè)屬性中能存儲(chǔ)的文本的大?。ū热缯f(shuō)產(chǎn)品描述等）。不過(guò)，由于該模式動(dòng)態(tài)靈活，你可以通過(guò)追加“產(chǎn)品描述1”、“產(chǎn)品描述2”等來(lái)繞過(guò)這類限制。一個(gè)項(xiàng)目最多可以有 256個(gè)屬性。由于處在測(cè)試階段，SimpleDB的域不能大于10GB，整個(gè)庫(kù)容量則不能超過(guò)1TB。
SimpleDB的一項(xiàng)關(guān)鍵特性是它使用一種最終一致性模型。這個(gè)一致性模型對(duì)并發(fā)性很有好處，但意味著在你改變了項(xiàng)目屬性之后，那些改變有可能不能立即反映到隨后的讀操作上。盡管這種情況實(shí)際發(fā)生的幾率很低，你也得有所考慮。比如說(shuō)，在你的演出訂票系統(tǒng)里，你不會(huì)想把***一張音樂(lè)會(huì)門票賣給5個(gè)人，因?yàn)樵谑鄢鰰r(shí)你的數(shù)據(jù)是不一致的。
Google AppEngine Data Store
Google AppEngine Datastore 是在BigTable之上建造出來(lái)的，是Google的內(nèi)部存儲(chǔ)系統(tǒng)，用于處理結(jié)構(gòu)化數(shù)據(jù)。AppEngine Datastore其自身及其內(nèi)部都不是直接訪問(wèn)BigTable的實(shí)現(xiàn)機(jī)制，可被視為BigTable之上的一個(gè)簡(jiǎn)單接口。
AppEngine Datastore所支持的項(xiàng)目的數(shù)據(jù)類型要比SimpleDB豐富得多，也包括了包含在一個(gè)項(xiàng)目?jī)?nèi)的數(shù)據(jù)集合的列表型。
如果你打算在Google AppEngine之內(nèi)建造應(yīng)用的話，幾乎可以肯定要用到這個(gè)數(shù)據(jù)存儲(chǔ)。然而，不像SimpleDB，使用谷歌網(wǎng)絡(luò)服務(wù)平臺(tái)之外的應(yīng)用，你并不能并發(fā)地與AppEngine Datastore進(jìn)行接口 (或通過(guò)BigTable)。
微軟: SQL數(shù)據(jù)服務(wù)
SQL數(shù)據(jù)服務(wù) 是微軟 Azure 網(wǎng)絡(luò)服務(wù)平臺(tái)的一部分。該SDS服務(wù)也是處于測(cè)試階段，因此也是免費(fèi)的，但對(duì)數(shù)據(jù)庫(kù)大小有限制。 SQL數(shù)據(jù)服務(wù)其自身實(shí)際上是一項(xiàng)處在許多SQL服務(wù)器之上的應(yīng)用，這些SQL服務(wù)器組成了SDS平臺(tái)底層的數(shù)據(jù)存儲(chǔ)。你不需要訪問(wèn)到它們，雖然底層的數(shù)據(jù)庫(kù)可能是關(guān)系式的；SDS是一個(gè)鍵/值型倉(cāng)儲(chǔ)，正如我們迄今所討論過(guò)的其它平臺(tái)一樣。
微軟看起來(lái)不同于前三個(gè)供應(yīng)商，因?yàn)殡m然鍵/值存儲(chǔ)對(duì)于可擴(kuò)性而言非常棒，相對(duì)于RDBMS，在數(shù)據(jù)管理上卻很困難。微軟的方案似乎是入木三分，在實(shí)現(xiàn)可擴(kuò)性和分布機(jī)制的同時(shí)，隨著時(shí)間的推移，不斷增加特性，在鍵/值存儲(chǔ)和關(guān)系數(shù)據(jù)庫(kù)平臺(tái)的鴻溝之間搭起一座橋梁。
非云服務(wù)競(jìng)爭(zhēng)者
在云之外，也有一些可以獨(dú)立安裝的鍵/值數(shù)據(jù)庫(kù)軟件產(chǎn)品。大部分都還很年輕，不是alpha版就是beta版，但大都是開(kāi)源的；通過(guò)看看它的代碼，比起在非開(kāi)源供應(yīng)商那里，你也許更能意識(shí)到潛在的問(wèn)題和限制。
CouchDB
CouchDB 是一個(gè)免費(fèi)、開(kāi)源、面向文檔的數(shù)據(jù)庫(kù)。它來(lái)自于鍵/值存儲(chǔ)，使用JSON（譯者：JavaScript Object Notation，一種輕量級(jí)的數(shù)據(jù)交換格式）來(lái)定義項(xiàng)目的模式。CouchDB允許通過(guò)JavaScript動(dòng)態(tài)創(chuàng)建“視圖”，意在跨越面向文檔型數(shù)據(jù)庫(kù)與關(guān)系數(shù)據(jù)庫(kù)之間的鴻溝。這些視圖將文檔數(shù)據(jù)映射在類似表的結(jié)構(gòu)上，可被索引和查詢。
現(xiàn)在，CouchDB 還不是真正的分布式數(shù)據(jù)庫(kù)。它的復(fù)制功能允許數(shù)據(jù)在服務(wù)器間同步，但這并非建設(shè)高可擴(kuò)性的環(huán)境所需的那種分布類型。毫無(wú)疑問(wèn)，CouchDB團(tuán)隊(duì)將朝此目標(biāo)繼續(xù)努力。
Project Voldemort
Project Voldemort 是分布式的鍵/值數(shù)據(jù)庫(kù)，旨在橫向擴(kuò)展于大量的服務(wù)器中。它產(chǎn)生自LinkedIn所完成的工作，據(jù)報(bào)告在那兒為幾個(gè)有著極高可擴(kuò)性要求的系統(tǒng)所使用。Project Voldemort也使用了Amazon的最終一致性模型。
Project Voldemort還很新；它的網(wǎng)站前幾周才剛開(kāi)張。
Mongo
Mongo是由Geir Magnusson和Dwight Merriman (提到DoubleClick你可能就想到他)在10gen開(kāi)發(fā)出來(lái)的數(shù)據(jù)庫(kù)系統(tǒng)。跟CouchDB一樣，Mongo是一個(gè)面向文檔的JSON數(shù)據(jù)庫(kù)，除了它是被設(shè)計(jì)為一個(gè)真正的對(duì)象數(shù)據(jù)庫(kù)，而不是一個(gè)純粹的鍵/值存儲(chǔ)這一點(diǎn)之外。起初，10gen關(guān)注于整合出一個(gè)完整的網(wǎng)絡(luò)服務(wù)棧;然而最近，它已經(jīng)把重點(diǎn)轉(zhuǎn)移到Mongo數(shù)據(jù)庫(kù)上了。其beta測(cè)試版計(jì)劃在二月中發(fā)布。
Drizzle
Drizzle可被認(rèn)為是鍵/值存儲(chǔ)要解決的問(wèn)題的反向方案。Drizzle誕生于MySQL（6.0）關(guān)系數(shù)據(jù)庫(kù)的拆分。在過(guò)去幾個(gè)月里，它的開(kāi)發(fā)者已經(jīng)移走了大量非核心的功能（包括視圖、觸發(fā)器、已編譯語(yǔ)句、存儲(chǔ)過(guò)程、查詢緩沖、ACL以及一些數(shù)據(jù)類型），其目標(biāo)是要建立一個(gè)更精簡(jiǎn)、更快的數(shù)據(jù)庫(kù)系統(tǒng)。Drizzle 仍能存放關(guān)系數(shù)據(jù)；正如MySQL/Sun的Brian Aker所說(shuō)那樣：“沒(méi)理由潑洗澡水時(shí)連孩子也倒掉”。它的目標(biāo)就是，針對(duì)運(yùn)行于16核（或以上）系統(tǒng)上的以網(wǎng)絡(luò)和云為基礎(chǔ)的應(yīng)用，建立一個(gè)半關(guān)系型數(shù)據(jù)庫(kù)平臺(tái)。
決策
最終，有四條理由支持你為應(yīng)用選擇非關(guān)系式的鍵/值數(shù)據(jù)庫(kù)平臺(tái)：
1. 你的數(shù)據(jù)很大程度上是面向文檔的，使得它比關(guān)系數(shù)據(jù)庫(kù)更自然地適合于鍵/值數(shù)據(jù)模型。
2. 你的開(kāi)發(fā)環(huán)境嚴(yán)重地面向?qū)ο髸r(shí)，鍵/值數(shù)據(jù)庫(kù)能盡量減少對(duì)“管道”代碼的需求。
3. 數(shù)據(jù)存儲(chǔ)很廉價(jià)，易于集成進(jìn)供應(yīng)商的網(wǎng)絡(luò)服務(wù)平臺(tái)。
4. 你優(yōu)先考慮的是隨需應(yīng)變的高端可擴(kuò)性 -- 也就是說(shuō)，那種通過(guò)簡(jiǎn)單的擴(kuò)充所無(wú)法獲得的大規(guī)模、分布式的可擴(kuò)性。
但是在作決定的時(shí)候，要記得這種數(shù)據(jù)庫(kù)的限制，以及從關(guān)系式大路出走時(shí)所面臨的風(fēng)險(xiǎn)。
對(duì)于其他需求而言，你也許在RDBMS那里能得到***的滿足。因此，關(guān)系數(shù)據(jù)庫(kù)的死期是不是到了？顯然不是。嗯，至少還沒(méi)有。
原文：Is the Relational Database Doomed?
【編輯推薦】
