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