脫離理論，觸摸NoSQL：分布式可擴展非關系數據庫聚焦
原創【51CTO精選譯文】在網絡世界中，大規模數據存儲發生了有趣的變化，一種全新的可擴展數據存儲正快速普及，傳統的LAMP組合開始變得越來越落伍。最近幾年以來，Memcached經常出現在MySQL身邊，現在整個“數據層”都開始動搖了。
雖然有些人認為這是擺脫MySQL和PostgreSQL等傳統的開源關系數據庫的機會，實際上事情并不是這么簡單，從這些有趣的變化中我們得出一些啟示：
1）關系數據庫并不適合所有的數據模型；
2）關系數據庫擴展難度大，特別是當你一開始就設計為單機配置，未進行分布式設計時；
3）標準化通常會傷害到性能；
4）在許多應用中，主鍵就是你的一切。
新的數據存儲完全改變了傳統的觀念，但總的來說，它們借鑒了一套類似的高級特征，但它們并非能夠滿足一切。下面給出一個列表，讓你看看它們正試圖實現什么。
1）反標準化，通常是無模式的，文檔型存儲；
2）以key/value為基礎，支持通過key進行查找；
3）水平擴展；
4）內置復制；
5）HTTP/REST或很容易編程的API；
6）支持MapReduce的風格的編程；
7）最終一致。
如果還要列的話，我可能還可以列出一打來。但前面兩個是對傳統數據庫最大的叛離（51CTO編者注：所以說NoSQL是數據庫領域的革命），當然你也可以堅持使用MySQL，并將其去關系化，這也是FriendFeed要做的事情，FriendFeed使用MySQL作為后端，實現分布式key/value存儲。
對這些分布式無模式的數據存儲，開始有一個新名稱來稱呼，那就是NoSQL。與其在NoSQL存儲系統理論上花大量的時間闡述，我更愿意花點時間來談談吸引我眼球的一些東西。
Redis
關于Redis我不想說太多，因為我在最近的一篇文章“Redis: Lightweight key/value Store That Goes the Extra Mile”中已經說得很詳細了，這里我只簡要說一下。它是一個輕量級內存中的key/value存儲，可以處理字符串，數據集和列表，擁有一個優秀的數據類型操縱核心。Redis內置了復制支持，保證數據在磁盤上的連續性，它還很年輕，但現在已經發布了1.0版本。
Redis吸引我的另一個原因是它的API很簡單，通過增加特殊的數據結構，并提供更快速的原子操作，給傳統key/value存儲開了一個口。
Tokyo Cabinet
Tokyo Cabinet來自日本，它是一個快速和成熟的基于磁盤的key/value存儲，感覺好像是BerkeleyDB為Web領域應用重寫的。它通常和Tokyo Tyrant搭配使用。Tokyo Tyrant是一個網絡服務器，它將Tokyo Cabinet轉變成網絡服務，使用HTTP和memcached協議以及它自己的二進制協議通信。
和其它現代DBM實現類似，Tokyo Cabinet提供B-Tree，Hash和固定大小的類似數組的記錄存儲選項。它打動我是因為，使用Tokyo Tyrant時，在穩定的低級數據庫架構上有一個現代網絡協議和接口，讓你選擇正確的數據結構使用。它是相對成熟的技術，在某些高容量網站上也有其身影。
Apache CouchDB
下面的內容引自Apache CouchDB主頁：
“Apache CouchDB是一個面向文檔的數據庫，可以使用JavaScript以MapReduce風格進行查詢和索引，CouchDB也提供了增量復制，具有雙向沖突檢測和解決能力。”
CouchDB提供了一個RESTful JSON API，可以從任何允許HTTP請求的環境訪問，也有無數的第三方客戶端庫使用，無論選擇哪種編程語言都會變得很容易，CouchDB內置的Web管理控制臺直接使用來自瀏覽器的HTTP請求與數據庫交流。
CouchDB是用Erlang編寫的，Erlang是一門功能強大的編程語言，它的理想是構建并發的分布式系統，Erlang允許靈活的，易于擴展且可輕松擴展的設計。
換句話說，CouchDB很時髦！
嚴格說來，CouchDB是第一個面向文檔的針對Web設計的數據庫，它現在屬于Apache軟件基金會，該項目相對比較成熟。
CouchDB吸引我是因為它看起來總是有點非關系數據存儲的未來主義風格，它也使你能夠使用服務器端JavaScript表現出Mapreduce風格，聽起來似乎有定瘋狂，但它確實能工作得很好，其API很簡單，都是經過深思熟慮的，因此進入的門檻非常低，你可以在PC或筆記本電腦上輕松部署一個CouchDB實例，然后與云中或你公司數據中心的CouchDB服務器進行同步。
CouchDB也實現了一個非常有用的版本控制方案，從而不必重新發明車輪構建一個協作系統。
Riak
Riak是我最近才感興趣的一個數據存儲，它也是一個面向文檔的Web數據庫，它結合了分散的key/value存儲，擁有一個靈活的Map/Reduce引擎和一個友好的HTTP/JSON查詢接口，為Web應用程序提供了一個理想的數據庫選擇，為了最大限度提高網絡和服務器中斷時的可用性，它使用了最終一致性模型。實際上，Riak最有趣的特性是你可以很容易地控制參數，定義在出現問題時系統的可用性。
這些參數來自Eric Brewer的CAP定理，該定理指出我們應該關心的三種要素是：不同程度的一致性，可用性和分區冗余。和其它系統不一樣，Riak并不強制你使用一組特定的CAP值，相反，它允許你在每個請求的基礎上決定如何約束你想要的內容。
這得感謝三個變量：N，R和W。在一個分布式系統中，N是系統中復制品的數量，因此，如果你要寫入一個新的key/value對，N設置為4，那么將有4個節點會收到它的復制品。
R和W是以每請求為基礎設置的，為了控制節點的數量，客戶端必須從一個完整的讀或寫操作接受一個響應，R表示讀，W表示寫。這提供了非常細粒度的控制，在集群環境中，客戶端可以對失效的節點做出反應。
其它
還有很多其它的NoSQL系統，下面是我準備嘗試的非關系數據庫系統：
MongoDB：MongoDB是一個以VC為后端的分布式無模式數據庫，有商業支持（參考閱讀：MongoDB簡介）。
Voldemort：Voldemort是一個相當成熟的系統，在LinkedIn上有大量的使用，它具有自動復制和分區功能。
MemcacheDB：MemcacheDB結合了BerkeleyDB存儲系統和使用memcached網絡協議的網絡服務器，因此你可以創建一個類memcached的節點，可以比傳統的基于RAM的memcached節點容納更多的數據，并可以保證重啟后數據不會丟失，在某些方面它和Tokyo Cabinet 和Tokyo Tyrant組合有些類似。
最后，我想問的是你已經涉足NoSQL了嗎？它將何去何從？
【編輯推薦】
原文：NoSQL: Distributed and Scalable Non-Relational Database Systems 作者：Jeremy Zawodny
【51CTO.com譯稿，非經授權請勿轉載。合作站點轉載請注明原文譯者和出處為51CTO.com，且不得修改原文內容。】
