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