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