在我還在上學(xué)的時候，key-value這個詞更多的還是和hash表聯(lián)系在一起的。而現(xiàn)在，當(dāng)我看見key-value這個詞，馬上聯(lián)想到的就是 BigTable，SimpleDB和云計算。當(dāng)下，key-value store（或者叫key-value Database，云存儲等等）是個非常時髦的詞匯，越來越多的開發(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形式的存儲并不是憑空想出來的。在我看來，是兩個問題導(dǎo)致了key-value這種存儲方式的崛起：

1. 大規(guī)模的互聯(lián)網(wǎng)應(yīng)用。對于google，ebay這樣的互聯(lián)網(wǎng)企業(yè)，每時每刻都有無數(shù)的用戶在使用它們提供的互聯(lián)網(wǎng)服務(wù)，這些服務(wù)帶來的就是大量的數(shù)據(jù)吞 吐量，在同一時間，會并發(fā)的有成千上萬的連接對數(shù)據(jù)庫進行操作。在這種情況下，單臺服務(wù)器或者幾臺服務(wù)器遠遠不能滿足這些數(shù)據(jù)處理的需求，簡單的升級服務(wù) 器性能這樣的scale up的方式也不行，所以唯一可以采用的辦法就是scale out了。scale out的方法有很多種，但大致分為兩類：一類仍然采用RDBMS，然后通過對數(shù)據(jù)庫的垂直和水平切割將整個數(shù)據(jù)庫部署到一個集群上，這種方法的優(yōu)點在于可 以采用RDBMS這種熟悉的技術(shù)，但缺點在于它是針對特定應(yīng)用的，就是說，由于應(yīng)用的不同，切割的方法是不一樣的。關(guān)于數(shù)據(jù)庫的垂直和水平切割的具體細節(jié) 可以查看文獻【2】。
還 有一類就是google所采用的方法，拋棄RDBMS，采用key-value形式的存儲，這樣可以極大的增強系統(tǒng)的可擴展性 （scalability），如果要處理的數(shù)據(jù)持續(xù)增大，多加機器就可以了。事實上，key-value的存儲就是由于BigTable等相關(guān)論文的發(fā)表 慢慢進入人們的視野的。

2. 云存儲。如果說上一個問題還有可以替代的解決方案（切割數(shù)據(jù)庫）的話，那么對于云存儲來說，也許key-value的store就是唯一的解決方案了。云 存儲簡單點說就是構(gòu)建一個大型的存儲平臺給別人用，這也就意味著在這上面運行的應(yīng)用其實是不可控的。如果其中某個客戶的應(yīng)用隨著用戶的增長而不斷增長時， 云存儲供應(yīng)商是沒有辦法通過數(shù)據(jù)庫的切割來達到scale的，因為這個數(shù)據(jù)是客戶的，供應(yīng)商不了解這個數(shù)據(jù)自然就沒法作出切割。在這種情況 下，key-value的store就是唯一的選擇了，因為這種條件下的scalability必須是自動完成的，不能有人工干預(yù)。這也是為什么幾乎所有 的現(xiàn)有的云存儲都是key-value形式的，例如Amazon的smipleDB，底層實現(xiàn)就是key-value，還有g(shù)oogle的 GoogleAppEngine，采用的是BigTable的存儲形式。也許唯一可能例外的是MS的解決方案，我在Qcon大會上聽說MS的Azure平 臺的下一個版本中就會推出基于RDBMS的云存儲，盡管我本人仍然對此保持懷疑。

可以看出，以上兩個問題強調(diào)的都是 scalability。其實，正如文獻【1】中所說，“Today, we are in a slightly different situation. For an increasing number of applications, one of these benefits is becoming more and more critical; and while still considered a niche, it is rapidly becoming mainstream, so much so that for an increasing number of database users this requirement is beginning to eclipse others in importance. That benefit is scalability.” 。正是由于現(xiàn)在出現(xiàn)的很多應(yīng)用非常強調(diào)scalability，才導(dǎo)致了key-value存儲的出現(xiàn)。key-value store作為一種RDBMS的可能的替代方案，犧牲了部分RDBMS的優(yōu)勢（這點在下文中會慢慢看到），從而確保了系統(tǒng)的可擴展性 （scalability）。

那么，key-value store和RDBMS實現(xiàn)機制上有什么區(qū)別呢？

data model上的區(qū)別

這 里引用了一副文獻【1】中的圖。從圖中可以看到，key-value存儲相比RDBMS，一個很大的區(qū)別就是它沒有schema。在RDBMS 中，schema所代表的其實就是對數(shù)據(jù)的約束，包括數(shù)據(jù)之間的關(guān)系（relationship），和數(shù)據(jù)的完整性（integrity），比如 RDBMS中對于某個數(shù)據(jù)屬性會要求它的數(shù)據(jù)類型是確定的（整數(shù)或者字符串等等），數(shù)據(jù)的范圍也是確定的（0~255等等），而這些在key-value store中都沒有。在key-value存儲中，對于某個key，value可以是任意的數(shù)據(jù)類型。正如圖中所說，“No relationships are explicitly defined”。

data processing上的區(qū)別

上面所 提的兩種data model之間的差異是非常顯而易見的，而這里的區(qū)別卻并不常被提及。在RDBMS中，數(shù)據(jù)的處理都是一個個的事務(wù)（transaction），遵循 ACID的原則。而在很多的key-value存儲系統(tǒng)中，并不支持事務(wù)的處理。在解釋這一點前，先介紹一下Brewer和他的CAP理論。
Brewer 現(xiàn)在是UC Berkeley的一個教授，不過他的歷史可就牛了。在google出現(xiàn)之前，最牛的搜索引擎公司叫做Inktomi，而Brewer就是這家公司的 Founder。Inktomi也是在一個大的計算機集群上構(gòu)建搜索引擎的，而Brewer根據(jù)Inktomi的經(jīng)驗總結(jié)出了CAP理論，就是下面這幅圖 （來自文獻【3】）：

這 幅圖的內(nèi)容就是，對于一個系統(tǒng)，consistency(數(shù)據(jù)一致性)，Availability(可用性)，Partitions(網(wǎng)絡(luò)可分性)這三者 只能同時滿足其中的兩個。用CAP理論來解釋RDBMS，它滿足了Consistency和Availability，但正是因為如此，所以它在 Partition上就很難做得好。而對于很多的key-value形式的存儲系統(tǒng)而言，它更強調(diào)的是Availability和Network Partition，所以在Consistency上做了弱化。例如，Amazon的Dynamo(SimpleDB的底層系統(tǒng))，它就不支持事務(wù)，為了 高可用性而犧牲了數(shù)據(jù)的一致性“Dynamo targets applications that operate with weaker consistency (the  “C”  in  ACID)  if  this  results  in  high  availability”（見文獻【4】）。當(dāng)然，需要指出的是，CAP理論并不是一個被證明了的定理，它只是一個經(jīng)驗型的結(jié)論，在這里是用CAP來更 容易的解釋為什么很多key-value store不提供ACID。關(guān)于CAP更多的信息見Brewer的個人網(wǎng)站 和文獻【3】。
另外需要指出的是，并非所有的key-value store都不支持事務(wù)，還是有部分系統(tǒng)支持ACID的，只是它已經(jīng)不再是一個標(biāo)準了。

接口層的區(qū)別

這也是一個相對顯而易見的區(qū)別。在所有RDBMS中，采用的都是SQL語言對數(shù)據(jù)進行訪問。一方面，SQL對于數(shù)據(jù)的查詢功能非常的強大，另一方面，由于所 有的RDBMS都支持SQL查詢，所以可移植性很強。而在key-value store中，對于數(shù)據(jù)的操作使用的都是自定義的一些API，而且支持的查詢也比較簡單。


優(yōu)勢和劣勢

正如前面所 反復(fù)提及的，key-value store最大的特點就是它的可擴展性（scalability），這也就是它最大的優(yōu)勢。所謂的scalability，在我看來這里包括了兩方面內(nèi) 容。一方面，是指key-value store可以支持極大的數(shù)據(jù)的存儲，它的分布式的架構(gòu)決定了只要有更多的機器，就能夠保證存儲更多的數(shù)據(jù)。另一方面，是指它可以支持數(shù)量很多的并發(fā)的查 詢。對于RDBMS，一般幾百個并發(fā)的查詢就可以讓它很吃力了，而一個key-value store，可以很輕松的支持上千的并發(fā)查詢。
至于 key-value store的缺陷，文獻【1】提出了幾點，我認為還是很中肯的。例如，由于key-value store中沒有schema，所以它是不提供數(shù)據(jù)之間的關(guān)系和數(shù)據(jù)的完備性的，所有的這些東西都落到了應(yīng)用程序一端，其實也就是開發(fā)人員的頭上。這無疑 加重了開發(fā)人員的負擔(dān)。在比如，在RDBMS中，需要設(shè)定每個表和表之間的關(guān)系，這其實是一個數(shù)據(jù)建模的過程（data modeling process）。當(dāng)數(shù)據(jù)建模完成后，其實這個數(shù)據(jù)庫就和應(yīng)用程序是獨立的了（application-independent），這就意味著別的程序可 以在不改變數(shù)據(jù)模型的前提下使用相同的數(shù)據(jù)集。但在key-value store中，由于沒有這么一個數(shù)據(jù)模型，不同的應(yīng)用程序需要重復(fù)進行這個過程。 
此外，我認為key-value store最大的一個缺點在于它的接口是不熟悉的。這阻礙了開發(fā)人員可以很快就順利的用上它。當(dāng)然，現(xiàn)在有種做法，就是在key-value store上再加上一個類SQL語句的抽象接口層，從而使得開發(fā)人員可以用他們熟悉的方式（SQL）來操作key-value store。但由于畢竟RDBMS和key-value store的底層實現(xiàn)有著很大的不同，這種抽象接口層或多或少的還是受到了限制。

結(jié)語

文獻【7】中給出了當(dāng)前比較常見的key-value的存儲系統(tǒng)，并逐一簡要介紹了它們各自的特點。感興趣的人可以去看看，這里就不羅列了。
總的來說，我認為key-value store是未來的一種趨勢，但它并不足以完全取代RDBMS。只有當(dāng)你的系統(tǒng)對于存儲的可擴展性要求很高時，才應(yīng)該去考慮使用key-value這種解決方案。對于一般的應(yīng)用，RDBMS還是最好的選擇。


參考文獻：
【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