純粹的鍵/值
純粹的鍵值數(shù)據(jù)庫實(shí)際上已經(jīng)存在很長時(shí)間了。甚至在SQL數(shù)據(jù)庫流行之前，dbm(一個(gè)純粹的鍵/值數(shù)據(jù)庫)就在世界上的很多UNX系統(tǒng)中使用了。之后是 Berkeley DB，目前仍然是一個(gè)維護(hù)中的富有生命活力的數(shù)據(jù)庫解決方案。今天，這些純粹的鍵值存儲(chǔ)庫正在重新流行起來，部分原因是所有的 NOSQL數(shù)據(jù)庫都在變得流行起來，但也是因?yàn)殚_發(fā)了一些速度更快、更為現(xiàn)代的數(shù)據(jù)庫實(shí)現(xiàn)，如 Tokyo Cabinet、 Kyoto Cabinet、 Memcachedb。
正是它們的簡(jiǎn)單性定義了這組數(shù)據(jù)庫。向數(shù)據(jù)庫存入一個(gè)鍵和一個(gè)值，然后用同一個(gè)鍵查詢數(shù)據(jù)庫，則會(huì)得到相同的值。沒有結(jié)構(gòu)或類型系統(tǒng)一一通常所處理的只是字節(jié)或字符串。因?yàn)檫@種簡(jiǎn)單性，這些數(shù)據(jù)庫的開銷極小，所以非?？?。事實(shí)上，這些數(shù)據(jù)庫通常都是實(shí)現(xiàn)為磁盤上的B樹或哈希表。
對(duì)一個(gè)純粹的鍵值數(shù)據(jù)庫進(jìn)行分片是直截了當(dāng)?shù)囊灰缓?jiǎn)單地選一個(gè)哈希算法，以鍵作為參數(shù)運(yùn)行該算法，輸出就是要查詢或?qū)懭氲臄?shù)據(jù)庫節(jié)點(diǎn)。另一方面，對(duì)于復(fù)雜查詢就完全不是這么簡(jiǎn)單了。醫(yī)如對(duì)于這樣的查詢:年齡大于50的用戶，就無法直接查詢，不得不維持另外一個(gè)鍵/值對(duì)，其中值是一個(gè)序列化的用戶鍵列表，這些用戶的年齡大于50，每次要?jiǎng)?chuàng)建新用戶或更新用戶信息，都要更新這個(gè)列表。
對(duì)于純料的鍵/值存儲(chǔ)庫，可能的應(yīng)用包括HTTP會(huì)話、用戶喜好以及URL縮寫(shorteners)。我在前面已經(jīng)描述過HTTP會(huì)話，HTTP會(huì)話應(yīng)該以一種非常直接的方式存儲(chǔ)在能/值摩中。其中鍵就是用戶的會(huì)話關(guān)鍵字( session key)，而值是包含用戶會(huì)話信息的一個(gè)序列化了的對(duì)象。對(duì)于用戶喜好，可以這樣來實(shí)現(xiàn):鍵是用戶1D連接上用戶喜好的名稱，值就是用戶實(shí)際的喜好。對(duì)于URL縮寫，URL路徑就是鍵，而值就是路徑重定向的位置。
數(shù)據(jù)結(jié)構(gòu)
數(shù)據(jù)結(jié)構(gòu)數(shù)據(jù)庫對(duì)鍵/值數(shù)據(jù)庫做了些修改。在純粹鍵值數(shù)據(jù)庫中，通常只是將鍵和值作為字符串或字節(jié)來存儲(chǔ)，而數(shù)據(jù)結(jié)構(gòu)數(shù)據(jù)庫則將其存儲(chǔ)為特定的數(shù)據(jù)結(jié)構(gòu)，如列表、集合或哈希表。由于有了這些附加的結(jié)構(gòu)，就可以對(duì)值執(zhí)行一些原子操作。對(duì)于列表，可以對(duì)值進(jìn)行壓入或彈出操作。對(duì)于集合，可以執(zhí)行并集和交集操作?？梢詫?duì)數(shù)據(jù)庫執(zhí)行在應(yīng)用程序中對(duì)數(shù)據(jù)結(jié)構(gòu)進(jìn)行的各種操作。本質(zhì)上，這些都是應(yīng)用程序已經(jīng)在使用的數(shù)據(jù)結(jié)構(gòu)只不過由外部進(jìn)程維護(hù)而已。
實(shí)際上這個(gè)領(lǐng)域唯一的競(jìng)爭(zhēng)者就是Redis。某些實(shí)現(xiàn)細(xì)節(jié)使得Redis很有。Redis默認(rèn)是在內(nèi)存中存儲(chǔ)其全部內(nèi)容的，只是周期性地將內(nèi)容的快照存儲(chǔ)到磁盤。這使得Redist出奇得快，但假如數(shù)據(jù)庫崩潰了，就會(huì)對(duì)數(shù)據(jù)造成一些損失。同時(shí)也意味著必須有足夠的內(nèi)存(RAM)存儲(chǔ)整個(gè)數(shù)據(jù)庫。值得指出的是，這些默認(rèn)設(shè)置是可以改變的一可以以速度為代價(jià)來增加數(shù)據(jù)的可持續(xù)性，還可以使用虛擬內(nèi)存模式，這樣就可以存儲(chǔ)比實(shí)際內(nèi)存更多的數(shù)據(jù)(雖然仍然是有限制的)。
數(shù)器、任務(wù)隊(duì)列或趨勢(shì)分析，是很理想的。想象一下，給每個(gè)登錄進(jìn)來的用戶一個(gè)唯一的鍵，映射到一張空表上，該用戶訪問的每個(gè)頁面的每個(gè)URL都從尾部壓人這張表。然后就可以獲取任何用戶的這些信息，觀察該用戶的訪問路徑，并對(duì)該路徑進(jìn)行分析。通過這張表的長度就可以得出該用戶的活躍程度。這是一個(gè)人為的例子，但仍然展示了極快的內(nèi)存操作和豐富的數(shù)據(jù)結(jié)構(gòu)能做什么事情。
圖
圖數(shù)據(jù)庫幾乎就是數(shù)據(jù)結(jié)構(gòu)數(shù)據(jù)庫的一個(gè)特定實(shí)現(xiàn)，因?yàn)閳D本就是一種數(shù)據(jù)結(jié)構(gòu)。區(qū)別是圖數(shù)據(jù)庫不再是基于鍵/值，數(shù)據(jù)是作為圖的節(jié)點(diǎn)和邊存儲(chǔ)的。圖數(shù)據(jù)庫不是用鍵來查詢值，而是給出根節(jié)點(diǎn)的句柄，然后就可以遍歷整個(gè)圖以找到需要的節(jié)點(diǎn)或者邊。這會(huì)非常有價(jià)值，因?yàn)楹芏鄳?yīng)用程序都大量使用了圖這種數(shù)據(jù)結(jié)構(gòu)，將這些數(shù)據(jù)結(jié)構(gòu)映射為圖數(shù)據(jù)庫上的操作是相當(dāng)容易的。就像數(shù)據(jù)結(jié)構(gòu)數(shù)據(jù)庫一樣，數(shù)據(jù)庫的圖也跟應(yīng)用程序使用的圖是一樣的，只不過是由外部進(jìn)程維護(hù)的而已。
這個(gè)領(lǐng)域的主要競(jìng)爭(zhēng)者是Neo4j，這是是一個(gè)嵌入式的ava圖數(shù)據(jù)庫，但可以用好幾種語言進(jìn)行訪同。除了Neo4之外，其他開源的圖數(shù)據(jù)庫包括Hypergraphdb、Infogrid、Vertexdb Hypergraphdb定位在對(duì)圖的一種更為通用的表示上，其中之一就是邊可以指向多個(gè)節(jié)點(diǎn)。Vertex的有趣之處是呈現(xiàn)了一個(gè)RESTFULL的HTTPAPI，通過這個(gè)API可以直接訪問數(shù)據(jù)庫，而其他幾種數(shù)據(jù)庫主要都是通過Java方法來訪問的。
圖數(shù)據(jù)庫的優(yōu)勢(shì)應(yīng)該正是你所期望的:存儲(chǔ)圖或樹形的數(shù)據(jù)。例如，假如網(wǎng)站想要維護(hù)一個(gè)社交圖(social graph)，則使用圖數(shù)據(jù)庫會(huì)產(chǎn)生一些有趣的應(yīng)用。警如，發(fā)現(xiàn)或向用戶推薦新朋友，傳統(tǒng)上實(shí)現(xiàn)起來既復(fù)雜，速度又慢，而使用圖數(shù)據(jù)庫則既簡(jiǎn)單，效率又高一一僅僅運(yùn)行一下寬度優(yōu)先搜索或最短路徑遍歷，事情就搞定了。
面向文檔
面向文檔的數(shù)據(jù)庫又類似于鍵值數(shù)據(jù)庫，但值不再是字節(jié)、字符串、列表、集合，而是文檔”。什么是文檔?在我們要談到的兩個(gè)面向文檔數(shù)據(jù)庫 COUCHDB和MONGODB中，文檔是作為JSON(或類似于JSON)對(duì)象存儲(chǔ)的，本質(zhì)上是一種哈希表或字典。這些值都有相同的結(jié)構(gòu)，意味著可以用查詢來探測(cè)這種結(jié)構(gòu)，并只返回所需要的文檔。要記住的是，這種查詢能力是建立在通過鍵來查找文檔的能力之上的。
COUCHDB是一個(gè)面向文檔的數(shù)據(jù)庫，是用 Erlang開發(fā)的，有一些有趣的實(shí)現(xiàn)細(xì)節(jié)，警如說是一種只附加(append-only)的數(shù)據(jù)結(jié)構(gòu)，并且能夠在數(shù)據(jù)庫中直接向應(yīng)用程序提供服務(wù)。Mongodb是另一個(gè)面向文檔的數(shù)據(jù)庫，是用C++開發(fā)的，在速度上做了很多優(yōu)化，提供了一個(gè)更加傳統(tǒng)的查詢層。雖然這兩個(gè)系統(tǒng)在紙上看起來很像，但目標(biāo)卻是不同的。在我寫這些東西的時(shí)候，COUCHDB的趨勢(shì)是作為桌面數(shù)據(jù)庫或?yàn)g覽器中的數(shù)據(jù)庫，由用戶下載安裝，而Mongodb則趨向于更多地用在數(shù)據(jù)中心。
在不能確切地知道能獲得什么數(shù)據(jù)時(shí)，如在生活串流應(yīng)用中那樣，面向文檔的數(shù)據(jù)庫就非常合適了。在這樣的應(yīng)用中，從一個(gè)流行的照片網(wǎng)站上檢索的文檔應(yīng)該包含照片屬性，而來自微博網(wǎng)站的文檔可能有一些地理屬性，而來自博客網(wǎng)站的文檔將不會(huì)有這些信息。面向文檔數(shù)據(jù)庫的另一個(gè)不錯(cuò)的應(yīng)用是內(nèi)容管理系統(tǒng)，在這樣的系統(tǒng)中，每個(gè)文檔都表示一個(gè)頁面，或頁面的一部分。
高度分布
高度分布的數(shù)據(jù)庫多少有些不同一一有些本質(zhì)上更接近于鍵/值存儲(chǔ)，其他則更像大型的多維哈希圖。它們的共同點(diǎn)是都為多節(jié)點(diǎn)部署優(yōu)化過。在這些系統(tǒng)中，簡(jiǎn)單地在集群中增加一個(gè)新節(jié)點(diǎn)就會(huì)增加更多的容量。其中一個(gè)節(jié)點(diǎn)失效并不會(huì)導(dǎo)致數(shù)據(jù)損失，但會(huì)失掉一些容量。多數(shù)這種系統(tǒng)都會(huì)允許用戶犧牲掉一些一致性而保證高可用性和分區(qū)容錯(cuò)性。
Hbase是一個(gè)高度分布式的數(shù)據(jù)庫，源自于Hadoop-項(xiàng)目，并且受到Big Table(Google專有的高度分布式數(shù)據(jù)庫)的直接影響。 Cassandra是另一個(gè)高度分布式數(shù)據(jù)庫，最初是在Facebook開發(fā)的，雖然數(shù)據(jù)模型非常類似于Hbase，但集中在不產(chǎn)生單點(diǎn)故障以及寫操作性能上。Hbase和Cassandra都將數(shù)據(jù)存儲(chǔ)為大型的多維哈希圖。 Basho公司的Riak是另個(gè)高度分布式數(shù)據(jù)庫，使用Erlang開發(fā)，可以通過RESTFULL的HTTPAPE來訪問，和Hibase與Cassandra比起來，是一個(gè)更加簡(jiǎn)單的鍵值模型。Voldemort和Hypertable項(xiàng)目是另外兩個(gè)值得提及的高度分布式數(shù)據(jù)庫。
為什么要使用高度分布的網(wǎng)站建設(shè)數(shù)據(jù)庫呢?噢，通常都是沒有其他選擇的結(jié)果。這些數(shù)據(jù)庫都是用在這樣的場(chǎng)合，就是其他的數(shù)據(jù)庫(基于SQL的數(shù)據(jù)庫或其他數(shù)據(jù)庫)或者對(duì)數(shù)據(jù)無法處理，或者無法處理那些查詢。幾乎每個(gè)問題領(lǐng)域(problem domain)都可以用這些數(shù)據(jù)庫系統(tǒng)來建模，但有時(shí)候會(huì)比許多傳統(tǒng)數(shù)據(jù)庫更為詭異。
本文地址：http://m.blackside-inc.com//article/3357.html
