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