詳解NoSQL數據庫使用實例
一、NoSQL基礎知識
1．關於NoSQL
在“NoSQL”一詞，實際上是一個叫Racker的同事創造的，當約翰埃文斯埃裏克要組織一次活動來討論開源的分佈式數據庫。這個名稱和概念都由此而來。
有些人反對NoSQL術語，因爲它聽起來像我們定義自己是什麼．在一定程度，但長期仍然是有價值的，因爲當一個關係數據庫是唯一的工具，你知道，每一個問題，看起來像一個大拇指。 NoSQL是讓人們知道有其他選擇哪裏。但我們並不反對關係數據庫，因爲當這確實是工作的最佳工具.
一個與NoSQL名稱真正關注的是，它是一個很大的帳篷，有非常不同的設計空間。如果這不是在討論清楚的，它在各種產品混亂的結果。因此，我要建議沿着三個軸的思考很多數據庫選項：可擴展性，數據和查詢模型和持久性的設計。
前所未有的數據量正推動企業關注傳統的關係數據庫技術，已服務了30多年良好替代品。總的來說，這些替代品已被稱作“NoSQL數據庫。”
最根本的問題是關係數據庫不能處理很多現代的工作量。有三個具體的問題：擴大向像Digg新聞評論網站的（3TB綠色徽章）或Facebook的（50TB收件箱中的搜索）或EBay（整體2PB），
每服務器性能和嚴格的架構設計。
備註：（Digg概念源自美國Digg公司。它完全是依靠真實的網民的自己力量。網站上所有內容都是由網民自己發佈，並且內容的位置也是由網民自己來決定。當內容的頂數，評論等達到一定的數字，這些內容就有可能從衆多的信息中脫穎而出。）
我最近寫了郵件給卡桑德拉，關於非關係型數據庫的資源，我們承諾後，還有其他非關係型數據庫在工作，我們稱之爲“NoSQL運動。”
2.一個簡單的NoSQL實例
我選擇了一些作爲例子NoSQL數據庫。這不是一個詳盡的清單，但討論的概念是對於衡量其他人也至關重要。
可伸縮性
縮放讀取與複製容易，當我們對在這方面縮放時，我們的意思寫了縮放到多臺機器自動分區的數據。我們呼籲制度不健全，這種“分佈式數據庫。”這其中包括Cassandra，HBase，Riak，Scalaris，Voldemort，等等。如果你寫卷或數據容量超過一臺機器可處理，那麼這些是你的唯一選擇，如果你不想手動分區管理。
有兩件事情看在分佈式數據庫：1）支持多種數據中心和2）能夠添加新的機器現場集羣的應用程序的透明。
二、NoSQL數據庫使用
1． NoSQL數據和查詢模型
非分佈式NoSQL數據庫包括CouchDB，MongoDB，Neo4j，Redis，和Tokyo Cabinet。這些可以作爲分佈式系統持久層; MongoDB提供有限的共享支持，做了單獨的休息室爲CouchDB項目，和Tokyo Cabinet可作爲Voldemort存儲引擎使用。
數據和查詢模型
在NoSQL裏有很多不同的數據模型和數據庫的查詢API.
一些重點：
該columnfamily模型Cassandra共享和HBase的是由谷歌的Bigtable文件，第2節描述的啓發。 （Cassandra下降，歷史版本，並添加超級列。）在這兩個系統，你必須像你行和列習以爲常，但稀疏行：每一行可以有許多或儘可能少列的需要，以及列不必須提前定義。
鍵/值模型是最簡單和最容易實現的，但效率低，只有當你在查詢或更新的值的一部分感興趣。這也是難以執行的分佈式圈頂更復雜的結構/價值。
文檔數據庫基本上是下一階段重點/值，允許嵌套的值與每個鍵關聯。文件數據庫支持查詢的效率比每次返回了整個BLOB更簡單。
Neo4J有一個真正獨特的數據模型，對象存儲在圖和節點和邊的關係。對於查詢適合這個模型（例如，分層數據），它們可以是1000倍速度比替代品。
Scalaris是獨特的，提供跨多個鍵分佈式事務。 （討論與貿易之間的一致性和可用性權衡超出了這個職位的範圍，但另一個方面就是要牢記在評價分佈式系統。）
持久性設計
通過持續的設計我的意思是，“如何在內部存儲的數據？” 持久性模型告訴我們很多這些數據庫能夠善於什麼樣的工作量.
在內存數據庫是非常，非常快的（Redis達到每秒超過100,000操作一臺計算機上），但不能與數據集的工作，超出可用的RAM。耐久性（保留數據，即使服務器崩潰或斷電）也將是一個問題的數據量，可以預期損失之間的衝（複製數據到磁盤）可能非常大。 Scalaris，其他內存數據庫，我們的名單上，意向處理與複製耐久性問題，但由於它不支持多個數據中心的數據將仍然容易受到停電的事情一樣。
Memtables和SSTables緩存在內存中寫入（1“memtable”）後，以書面追加只承諾爲耐久性日誌。當寫夠已被接受的memtable排序並寫入到磁盤上的所有一次作爲“sstable。”這提供近內存中的表現，因爲沒有涉及要求，同時避免了純粹的耐久性問題，在內存的方法。 （這是詳細描述在第5.3和先前提及的5.4 Bigtable的文件，以及在該日誌結構合併樹。）
B-樹已被用於從數據庫中實際上是時間的起點。索引他們提供強大的支持，但表現欠佳的旋轉盤（這仍然是迄今爲止最具有成本效益，因爲多）要求讀或寫什麼工作。
一個有趣的變體是CouchDB的追加，只有B -樹，它避免了管理費用的目的在限制CouchDB一寫一時間成本.
結論
該NoSQL運動在2009年爆炸地爲越來越多的企業全力對付大量數據。在Rackspace雲高興地發揮了NoSQL運動的早期作用，並繼續投入資源，Cassandra像NoSQL支持事件。