【51CTO精選譯文】在網(wǎng)絡世界中，大規(guī)模數(shù)據(jù)存儲發(fā)生了有趣的變化，一種全新的可擴展數(shù)據(jù)存儲正快速普及，傳統(tǒng)的LAMP組合開始變得越來越落伍。最近幾年以來，Memcached經(jīng)常出現(xiàn)在MySQL身邊，現(xiàn)在整個“數(shù)據(jù)層”都開始動搖了。

雖然有些人認為這是擺脫MySQL和PostgreSQL等傳統(tǒng)的開源關系數(shù)據(jù)庫的機會，實際上事情并不是這么簡單，從這些有趣的變化中我們得出一些啟示：

1）關系數(shù)據(jù)庫并不適合所有的數(shù)據(jù)模型；

2）關系數(shù)據(jù)庫擴展難度大，特別是當你一開始就設計為單機配置，未進行分布式設計時；

3）標準化通常會傷害到性能；

4）在許多應用中，主鍵就是你的一切。

新的數(shù)據(jù)存儲完全改變了傳統(tǒng)的觀念，但總的來說，它們借鑒了一套類似的高級特征，但它們并非能夠滿足一切。下面給出一個列表，讓你看看它們正試圖實現(xiàn)什么。

1）反標準化，通常是無模式的，文檔型存儲；

2）以key/value為基礎，支持通過key進行查找；

3）水平擴展；

4）內(nèi)置復制；

5）HTTP/REST或很容易編程的API；

6）支持MapReduce的風格的編程；

7）最終一致。

如果還要列的話，我可能還可以列出一打來。但前面兩個是對傳統(tǒng)數(shù)據(jù)庫最大的叛離（51CTO編者注：所以說NoSQL是數(shù)據(jù)庫領域的革命），當然你也可以堅持使用MySQL，并將其去關系化，這也是FriendFeed要做的事情，F(xiàn)riendFeed使用MySQL作為后端，實現(xiàn)分布式key/value存儲。

對這些分布式無模式的數(shù)據(jù)存儲，開始有一個新名稱來稱呼，那就是NoSQL。與其在NoSQL存儲系統(tǒng)理論上花大量的時間闡述，我更愿意花點時間來談談吸引我眼球的一些東西。

Redis

關于Redis我不想說太多，因為我在最近的一篇文章“Redis: Lightweight key/value Store That Goes the Extra Mile”中已經(jīng)說得很詳細了，這里我只簡要說一下。它是一個輕量級內(nèi)存中的key/value存儲，可以處理字符串，數(shù)據(jù)集和列表，擁有一個優(yōu)秀的數(shù)據(jù)類型操縱核心。Redis內(nèi)置了復制支持，保證數(shù)據(jù)在磁盤上的連續(xù)性，它還很年輕，但現(xiàn)在已經(jīng)發(fā)布了1.0版本。

Redis吸引我的另一個原因是它的API很簡單，通過增加特殊的數(shù)據(jù)結(jié)構(gòu)，并提供更快速的原子操作，給傳統(tǒng)key/value存儲開了一個口。

Tokyo Cabinet

Tokyo Cabinet來自日本，它是一個快速和成熟的基于磁盤的key/value存儲，感覺好像是BerkeleyDB為Web領域應用重寫的。它通常和Tokyo Tyrant搭配使用。Tokyo Tyrant是一個網(wǎng)絡服務器，它將Tokyo Cabinet轉(zhuǎn)變成網(wǎng)絡服務，使用HTTP和memcached協(xié)議以及它自己的二進制協(xié)議通信。

和其它現(xiàn)代DBM實現(xiàn)類似，Tokyo Cabinet提供B-Tree，Hash和固定大小的類似數(shù)組的記錄存儲選項。它打動我是因為，使用Tokyo Tyrant時，在穩(wěn)定的低級數(shù)據(jù)庫架構(gòu)上有一個現(xiàn)代網(wǎng)絡協(xié)議和接口，讓你選擇正確的數(shù)據(jù)結(jié)構(gòu)使用。它是相對成熟的技術，在某些高容量網(wǎng)站上也有其身影。

Apache CouchDB

下面的內(nèi)容引自Apache CouchDB主頁：

“Apache CouchDB是一個面向文檔的數(shù)據(jù)庫，可以使用JavaScript以MapReduce風格進行查詢和索引，CouchDB也提供了增量復制，具有雙向沖突檢測和解決能力?！?/P>

CouchDB提供了一個RESTful JSON API，可以從任何允許HTTP請求的環(huán)境訪問，也有無數(shù)的第三方客戶端庫使用，無論選擇哪種編程語言都會變得很容易，CouchDB內(nèi)置的Web管理控制臺直接使用來自瀏覽器的HTTP請求與數(shù)據(jù)庫交流。

CouchDB是用Erlang編寫的，Erlang是一門功能強大的編程語言，它的理想是構(gòu)建并發(fā)的分布式系統(tǒng)，Erlang允許靈活的，易于擴展且可輕松擴展的設計。

換句話說，CouchDB很時髦！

嚴格說來，CouchDB是第一個面向文檔的針對Web設計的數(shù)據(jù)庫，它現(xiàn)在屬于Apache軟件基金會，該項目相對比較成熟。

CouchDB吸引我是因為它看起來總是有點非關系數(shù)據(jù)存儲的未來主義風格，它也使你能夠使用服務器端JavaScript表現(xiàn)出Mapreduce風格，聽起來似乎有定瘋狂，但它確實能工作得很好，其API很簡單，都是經(jīng)過深思熟慮的，因此進入的門檻非常低，你可以在PC或筆記本電腦上輕松部署一個CouchDB實例，然后與云中或你公司數(shù)據(jù)中心的CouchDB服務器進行同步。

CouchDB也實現(xiàn)了一個非常有用的版本控制方案，從而不必重新發(fā)明車輪構(gòu)建一個協(xié)作系統(tǒng)。

Riak

Riak是我最近才感興趣的一個數(shù)據(jù)存儲，它也是一個面向文檔的Web數(shù)據(jù)庫，它結(jié)合了分散的key/value存儲，擁有一個靈活的Map/Reduce引擎和一個友好的HTTP/JSON查詢接口，為Web應用程序提供了一個理想的數(shù)據(jù)庫選擇，為了最大限度提高網(wǎng)絡和服務器中斷時的可用性，它使用了最終一致性模型。實際上，Riak最有趣的特性是你可以很容易地控制參數(shù)，定義在出現(xiàn)問題時系統(tǒng)的可用性。

這些參數(shù)來自Eric Brewer的CAP定理，該定理指出我們應該關心的三種要素是：不同程度的一致性，可用性和分區(qū)冗余。和其它系統(tǒng)不一樣，Riak并不強制你使用一組特定的CAP值，相反，它允許你在每個請求的基礎上決定如何約束你想要的內(nèi)容。

這得感謝三個變量：N，R和W。在一個分布式系統(tǒng)中，N是系統(tǒng)中復制品的數(shù)量，因此，如果你要寫入一個新的key/value對，N設置為4，那么將有4個節(jié)點會收到它的復制品。

R和W是以每請求為基礎設置的，為了控制節(jié)點的數(shù)量，客戶端必須從一個完整的讀或?qū)懖僮鹘邮芤粋€響應，R表示讀，W表示寫。這提供了非常細粒度的控制，在集群環(huán)境中，客戶端可以對失效的節(jié)點做出反應。

其它

還有很多其它的NoSQL系統(tǒng)，下面是我準備嘗試的非關系數(shù)據(jù)庫系統(tǒng)：

MongoDB：MongoDB是一個以VC為后端的分布式無模式數(shù)據(jù)庫，有商業(yè)支持（參考閱讀：MongoDB簡介）。

Voldemort：Voldemort是一個相當成熟的系統(tǒng)，在LinkedIn上有大量的使用，它具有自動復制和分區(qū)功能。

MemcacheDB：MemcacheDB結(jié)合了BerkeleyDB存儲系統(tǒng)和使用memcached網(wǎng)絡協(xié)議的網(wǎng)絡服務器，因此你可以創(chuàng)建一個類memcached的節(jié)點，可以比傳統(tǒng)的基于RAM的memcached節(jié)點容納更多的數(shù)據(jù)，并可以保證重啟后數(shù)據(jù)不會丟失，在某些方面它和Tokyo Cabinet 和Tokyo Tyrant組合有些類似。

最后，我想問的是你已經(jīng)涉足NoSQL了嗎？它將何去何從？

【編輯推薦】

1. NoSQL運動：緩慢而堅定的前進著
2. NoSQL真的能終結(jié)關系數(shù)據(jù)庫？
3. 對SQL說不！NoSQL的數(shù)據(jù)庫技術革命
4. 云計算使關系數(shù)據(jù)庫逐漸落伍
5. 關系數(shù)據(jù)庫的末日是否已經(jīng)來臨

原文：NoSQL: Distributed and Scalable Non-Relational Database Systems  作者：Jeremy Zawodny

【51CTO.com譯稿，非經(jīng)授權(quán)請勿轉(zhuǎn)載。合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com，且不得修改原文內(nèi)容?！?