在我還在上學(xué)的時(shí)候，key-value這個(gè)詞更多的還是和hash表聯(lián)系在一起的。而現(xiàn)在，當(dāng)我看見key-value這個(gè)詞，馬上聯(lián)想到的就是BigTable，SimpleDB和云計(jì)算。當(dāng)下，key-value store（或者叫key-valueDatabase，云存儲等等）是個(gè)非常時(shí)髦的詞匯，越來越多的開發(fā)人員（特別是互聯(lián)網(wǎng)企業(yè)）開始關(guān)注和嘗試key-value的存儲形式。這年頭如果你還和別人聊關(guān)系型數(shù)據(jù)庫，貌似你都不好意思和人打招呼。
可是，key-value store真的有這么神奇嗎？畢竟，關(guān)系型數(shù)據(jù)庫已經(jīng)主導(dǎo)市場三十多年了。
背景
key-value形式的存儲并不是憑空想出來的。在我看來，是兩個(gè)問題導(dǎo)致了key-value這種存儲方式的崛起：
1.大規(guī)模的互聯(lián)網(wǎng)應(yīng)用。對于google，ebay這樣的互聯(lián)網(wǎng)企業(yè)，每時(shí)每刻都有無數(shù)的用戶在使用它們提供的互聯(lián)網(wǎng)服務(wù)，這些服務(wù)帶來的就是大量的數(shù)據(jù)吞吐量，在同一時(shí)間，會并發(fā)的有成千上萬的連接對數(shù)據(jù)庫進(jìn)行操作。在這種情況下，單臺服務(wù)器或者幾臺服務(wù)器遠(yuǎn)遠(yuǎn)不能滿足這些數(shù)據(jù)處理的需求，簡單的升級服務(wù)器性能這樣的scale up的方式也不行，所以唯一可以采用的辦法就是scale out了。scaleout的方法有很多種，但大致分為兩類：一類仍然采用RDBMS，然后通過對數(shù)據(jù)庫的垂直和水平切割將整個(gè)數(shù)據(jù)庫部署到一個(gè)集群上，這種方法的優(yōu)點(diǎn)在于可以采用RDBMS這種熟悉的技術(shù)，但缺點(diǎn)在于它是針對特定應(yīng)用的，就是說，由于應(yīng)用的不同，切割的方法是不一樣的。關(guān)于數(shù)據(jù)庫的垂直和水平切割的具體細(xì)節(jié)可以查看文獻(xiàn)【2】。
還有一類就是google所采用的方法，拋棄RDBMS，采用key-value形式的存儲，這樣可以極大的增強(qiáng)系統(tǒng)的可擴(kuò)展性（scalability），如果要處理的數(shù)據(jù)持續(xù)增大，多加機(jī)器就可以了。事實(shí)上，key-value的存儲就是由于BigTable等相關(guān)論文的發(fā)表慢慢進(jìn)入人們的視野的。
2.云存儲。如果說上一個(gè)問題還有可以替代的解決方案（切割數(shù)據(jù)庫）的話，那么對于云存儲來說，也許key-value的store就是唯一的解決方案了。云存儲簡單點(diǎn)說就是構(gòu)建一個(gè)大型的存儲平臺給別人用，這也就意味著在這上面運(yùn)行的應(yīng)用其實(shí)是不可控的。如果其中某個(gè)客戶的應(yīng)用隨著用戶的增長而不斷增長時(shí)，云存儲供應(yīng)商是沒有辦法通過數(shù)據(jù)庫的切割來達(dá)到scale的，因?yàn)檫@個(gè)數(shù)據(jù)是客戶的，供應(yīng)商不了解這個(gè)數(shù)據(jù)自然就沒法作出切割。在這種情況下，key-value的store就是唯一的選擇了，因?yàn)檫@種條件下的scalability必須是自動(dòng)完成的，不能有人工干預(yù)。這也是為什么幾乎所有的現(xiàn)有的云存儲都是key-value形式的，例如Amazon的smipleDB，底層實(shí)現(xiàn)就是key-value，還有g(shù)oogle的GoogleAppEngine，采用的是BigTable的存儲形式。也許唯一可能例外的是MS的解決方案，我在Qcon大會上聽說MS的Azure平臺的下一個(gè)版本中就會推出基于RDBMS的云存儲，盡管我本人仍然對此保持懷疑。
可以看出，以上兩個(gè)問題強(qiáng)調(diào)的都是scalability。其實(shí)，正如文獻(xiàn)【1】中所說，“Today, we are in a slightly differentsituation. For an increasing number of applications, one of thesebenefits is becoming more and more critical; and while still considereda niche, it is rapidly becoming mainstream, so much so that for anincreasing number of database users this requirement is beginning toeclipse others in importance. That benefit is scalability.”。正是由于現(xiàn)在出現(xiàn)的很多應(yīng)用非常強(qiáng)調(diào)scalability，才導(dǎo)致了key-value存儲的出現(xiàn)。key-valuestore作為一種RDBMS的可能的替代方案，犧牲了部分RDBMS的優(yōu)勢（這點(diǎn)在下文中會慢慢看到），從而確保了系統(tǒng)的可擴(kuò)展性（scalability）。
那么，key-value store和RDBMS實(shí)現(xiàn)機(jī)制上有什么區(qū)別呢？
data model上的區(qū)別
這里引用了一副文獻(xiàn)【1】中的圖。從圖中可以看到，key-value存儲相比RDBMS，一個(gè)很大的區(qū)別就是它沒有schema。在RDBMS中，schema所代表的其實(shí)就是對數(shù)據(jù)的約束，包括數(shù)據(jù)之間的關(guān)系（relationship），和數(shù)據(jù)的完整性（integrity），比如RDBMS中對于某個(gè)數(shù)據(jù)屬性會要求它的數(shù)據(jù)類型是確定的（整數(shù)或者字符串等等），數(shù)據(jù)的范圍也是確定的（0~255等等），而這些在key-valuestore中都沒有。在key-value存儲中，對于某個(gè)key，value可以是任意的數(shù)據(jù)類型。正如圖中所說，“Norelationships are explicitly defined”。
data processing上的區(qū)別
上面所提的兩種datamodel之間的差異是非常顯而易見的，而這里的區(qū)別卻并不常被提及。在RDBMS中，數(shù)據(jù)的處理都是一個(gè)個(gè)的事務(wù)（transaction），遵循ACID的原則。而在很多的key-value存儲系統(tǒng)中，并不支持事務(wù)的處理。在解釋這一點(diǎn)前，先介紹一下Brewer和他的CAP理論。
Brewer現(xiàn)在是UCBerkeley的一個(gè)教授，不過他的歷史可就牛了。在google出現(xiàn)之前，最牛的搜索引擎公司叫做Inktomi，而Brewer就是這家公司的Founder。Inktomi也是在一個(gè)大的計(jì)算機(jī)集群上構(gòu)建搜索引擎的，而Brewer根據(jù)Inktomi的經(jīng)驗(yàn)總結(jié)出了CAP理論，就是下面這幅圖（來自文獻(xiàn)【3】）：
這幅圖的內(nèi)容就是，對于一個(gè)系統(tǒng)，consistency(數(shù)據(jù)一致性)，Availability(可用性)，Partitions(網(wǎng)絡(luò)可分性)這三者只能同時(shí)滿足其中的兩個(gè)。用CAP理論來解釋RDBMS，它滿足了Consistency和Availability，但正是因?yàn)槿绱?，所以它在Partition上就很難做得好。而對于很多的key-value形式的存儲系統(tǒng)而言，它更強(qiáng)調(diào)的是Availability和NetworkPartition，所以在Consistency上做了弱化。例如，Amazon的Dynamo(SimpleDB的底層系統(tǒng))，它就不支持事務(wù)，為了高可用性而犧牲了數(shù)據(jù)的一致性“Dynamo targets applications that operate with weakerconsistency (the “C” in ACID) if this results in high availability”（見文獻(xiàn)【4】）。當(dāng)然，需要指出的是，CAP理論并不是一個(gè)被證明了的定理，它只是一個(gè)經(jīng)驗(yàn)型的結(jié)論，在這里是用CAP來更容易的解釋為什么很多key-value store不提供ACID。關(guān)于CAP更多的信息見Brewer的個(gè)人網(wǎng)站 和文獻(xiàn)【3】。
另外需要指出的是，并非所有的key-value store都不支持事務(wù)，還是有部分系統(tǒng)支持ACID的，只是它已經(jīng)不再是一個(gè)標(biāo)準(zhǔn)了。
接口層的區(qū)別
這也是一個(gè)相對顯而易見的區(qū)別。在所有RDBMS中，采用的都是SQL語言對數(shù)據(jù)進(jìn)行訪問。一方面，SQL對于數(shù)據(jù)的查詢功能非常的強(qiáng)大，另一方面，由于所有的RDBMS都支持SQL查詢，所以可移植性很強(qiáng)。而在key-valuestore中，對于數(shù)據(jù)的操作使用的都是自定義的一些API，而且支持的查詢也比較簡單。
優(yōu)勢和劣勢
正如前面所反復(fù)提及的，key-valuestore最大的特點(diǎn)就是它的可擴(kuò)展性（scalability），這也就是它最大的優(yōu)勢。所謂的scalability，在我看來這里包括了兩方面內(nèi)容。一方面，是指key-valuestore可以支持極大的數(shù)據(jù)的存儲，它的分布式的架構(gòu)決定了只要有更多的機(jī)器，就能夠保證存儲更多的數(shù)據(jù)。另一方面，是指它可以支持?jǐn)?shù)量很多的并發(fā)的查詢。對于RDBMS，一般幾百個(gè)并發(fā)的查詢就可以讓它很吃力了，而一個(gè)key-value store，可以很輕松的支持上千的并發(fā)查詢。
至于key-value store的缺陷，文獻(xiàn)【1】提出了幾點(diǎn)，我認(rèn)為還是很中肯的。例如，由于key-valuestore中沒有schema，所以它是不提供數(shù)據(jù)之間的關(guān)系和數(shù)據(jù)的完備性的，所有的這些東西都落到了應(yīng)用程序一端，其實(shí)也就是開發(fā)人員的頭上。這無疑加重了開發(fā)人員的負(fù)擔(dān)。在比如，在RDBMS中，需要設(shè)定每個(gè)表和表之間的關(guān)系，這其實(shí)是一個(gè)數(shù)據(jù)建模的過程（data modelingprocess）。當(dāng)數(shù)據(jù)建模完成后，其實(shí)這個(gè)數(shù)據(jù)庫就和應(yīng)用程序是獨(dú)立的了（application-independent），這就意味著別的程序可以在不改變數(shù)據(jù)模型的前提下使用相同的數(shù)據(jù)集。但在key-valuestore中，由于沒有這么一個(gè)數(shù)據(jù)模型，不同的應(yīng)用程序需要重復(fù)進(jìn)行這個(gè)過程。
此外，我認(rèn)為key-valuestore最大的一個(gè)缺點(diǎn)在于它的接口是不熟悉的。這阻礙了開發(fā)人員可以很快就順利的用上它。當(dāng)然，現(xiàn)在有種做法，就是在key-valuestore上再加上一個(gè)類SQL語句的抽象接口層，從而使得開發(fā)人員可以用他們熟悉的方式（SQL）來操作key-valuestore。但由于畢竟RDBMS和key-value store的底層實(shí)現(xiàn)有著很大的不同，這種抽象接口層或多或少的還是受到了限制。
結(jié)語
文獻(xiàn)【7】中給出了當(dāng)前比較常見的key-value的存儲系統(tǒng)，并逐一簡要介紹了它們各自的特點(diǎn)。感興趣的人可以去看看，這里就不羅列了。
總的來說，我認(rèn)為key-value store是未來的一種趨勢，但它并不足以完全取代RDBMS。只有當(dāng)你的系統(tǒng)對于存儲的可擴(kuò)展性要求很高時(shí)，才應(yīng)該去考慮使用key-value這種解決方案。對于一般的應(yīng)用，RDBMS還是最好的選擇。
參考文獻(xiàn)：
【1】Is the Relational Database Doomed?
【2】Database Sharding at Netlog, with MySQL and PHP
【3】Towards Robust Distributed Systems
【4】Dynamo: Amazon’s Highly Available Key-value Store
【5】關(guān)系數(shù)據(jù)庫的死期到了？
【6】Top 10 Reasons to Avoid the SimpleDB Hype
【7】Anti-RDBMS: A list of distributed key-value stores
