NoSQL數(shù)據(jù)庫技術(shù)特性解析之文檔數(shù)據(jù)庫
本文關(guān)鍵詞:數(shù)據(jù)庫技術(shù)
更多相關(guān)文章: NoSQL 數(shù)據(jù)庫 技術(shù) 特性 解析 文檔
現(xiàn)今云計算的從業(yè)人員對NoSQL一詞并不感到陌生,雖然很多技術(shù)人員都長期從事關(guān)系數(shù)據(jù)庫的工作,但現(xiàn)在他們對NoSQL技術(shù)充滿期待。對于企業(yè)來說,從關(guān)系型數(shù)據(jù)庫到NoSQL數(shù)據(jù)庫轉(zhuǎn)變絕對是個需要深思熟慮的大改變。這涉及的不僅是軟件的變化,更多的是對于數(shù)據(jù)存儲上觀念性的變化。
CouchDB專家兼作者Bradley Holt認(rèn)為NoSQL并不是反SQL的運動,為對應(yīng)的工作選擇最恰當(dāng)?shù)墓ぞ卟攀钦_的模式。
大多數(shù)非關(guān)系數(shù)據(jù)庫都具有快速和可伸縮的特性。通過放棄關(guān)系存儲模型和架構(gòu),關(guān)系數(shù)據(jù)庫便可脫離由緊密結(jié)合的架構(gòu)所帶來對其施加的限制。應(yīng)用程序也無需再鏈接數(shù)據(jù)庫內(nèi)表中的數(shù)據(jù)。
MongoDB和CouchDB以及RavenDB(RavenDB是基于Mocrosoft .NET Framework編寫的)等文檔數(shù)據(jù)庫除了某些特定的轉(zhuǎn)換外,通常都是通過HTTP為其提供數(shù)據(jù),然后將數(shù)據(jù)存儲為JSON(JavaScript Object Notation)格式的文檔,并提供多種語言的API接口。這三款開源的文檔數(shù)據(jù)庫都將簡潔、速度和可伸縮性作為其設(shè)計的重要指標(biāo)。RavenDB的創(chuàng)建者Ayende Rahien就表示“RavenDB的設(shè)計初衷就旨在快速寫入并讀取”。
NoSQL——關(guān)系數(shù)據(jù)庫的有力補充現(xiàn)今,NoSQL和文檔數(shù)據(jù)庫成為關(guān)系數(shù)據(jù)庫的有力補充(而非替代品),同時提供了更多的選擇。如果企業(yè)準(zhǔn)備將數(shù)據(jù)遷移,那么選擇NoSQL的重要標(biāo)準(zhǔn)就是要看CAP(Consistency、Availability和Partition Tolerance),也就是我們所說的一致性、可用性和分區(qū)容忍性。但CAP原則要求在分布式系統(tǒng)只能選擇一致性、可用性和分區(qū)容忍性其中的兩項。所以如果企業(yè)認(rèn)為一致性是重要的那么關(guān)系數(shù)據(jù)庫理應(yīng)是優(yōu)先選擇的對象。
例如在銀行等應(yīng)用領(lǐng)域,一致性是非常重要的,這要求必須隨時考慮每個數(shù)據(jù)塊。而CAP原則中的可用性也不容忽視,某些領(lǐng)域的數(shù)據(jù)可用性要比等待所有交易數(shù)據(jù)收集齊全更為重要。最后在水平縮放時,分區(qū)容忍性對于文檔數(shù)據(jù)庫顯得尤為關(guān)鍵。但MongoDB并不支持復(fù)雜的事務(wù),只支持少量的原子操作,所以不適用于“轉(zhuǎn)帳”等對事務(wù)和一致性要求很高的場合。這就要求需要一個關(guān)系數(shù)據(jù)庫來對交易進(jìn)行過高級別的控制。
文檔數(shù)據(jù)庫的關(guān)鍵特性RESTful HTTP API
RESTful API設(shè)計就是為了消除創(chuàng)建松散耦合服務(wù)時的依賴關(guān)系,這也正是過去分布式體系結(jié)構(gòu)的缺陷。雖然要映射到一些協(xié)議需要依賴于元數(shù)據(jù)的可用性以及方法等,但REST API的設(shè)計目標(biāo)就是不依賴于任何通信協(xié)議。
眾多NoSQL數(shù)據(jù)庫都可通過RESTful的方式訪問。這樣可以通過URI的方式建立數(shù)據(jù)庫連接,而查詢和命令則通過HTTP實現(xiàn)。MongoDB和CouchDB都提供了特定語言的API接口,以便編寫和執(zhí)行查詢、更新。但MongoDB的默認(rèn)設(shè)置仍然是使用TCP與數(shù)據(jù)庫進(jìn)行連接。而RavenDB則具備基于.NET的客戶端API,可簡化與數(shù)據(jù)庫的交互過程。
單個記錄中的相關(guān)數(shù)據(jù)
大多數(shù)人都錯誤的認(rèn)為非關(guān)系數(shù)據(jù)庫是一種包含沒有相對關(guān)系結(jié)構(gòu)的記錄的文件。而文檔數(shù)據(jù)庫中存儲的數(shù)據(jù)包含形狀數(shù)據(jù)——具有節(jié)點的樹。數(shù)據(jù)庫中的每個記錄都是以文檔形式存在的。并具備自我描述的功能,而不依賴于任何其他文檔。
示例代碼1:文檔數(shù)據(jù)庫(MongoDB)中的典型事例
示例代碼2 CouchDB示例
示例代碼3 包含字符串?dāng)?shù)據(jù)、數(shù)字和數(shù)組的簡單結(jié)構(gòu)。還可在對象內(nèi)嵌入對象,以獲得更復(fù)雜的文檔結(jié)構(gòu)。
唯一鍵所有數(shù)據(jù)庫都需要鍵。如果不提供鍵系統(tǒng)則會自動在內(nèi)部創(chuàng)建一個鍵。鍵對于數(shù)據(jù)庫的索引功能至關(guān)重要。自身域中要求有已知鍵,在上面的示例代碼中存在對“users/203907”的引用。這正式RavenDB利用鍵值并允許用戶定義文檔間關(guān)系的方式。
以JSON格式存儲數(shù)據(jù)共同點都是使用JSON存儲器數(shù)據(jù)。事實上,,CouchDB和RavenDB(以及其他許多數(shù)據(jù)庫)均采用JSON格式存儲數(shù)據(jù)。MongoDB對JSON使用稱之為“二進(jìn)制JSON”(BSON)的轉(zhuǎn)換,以便能夠執(zhí)行二進(jìn)制序列化。BSON是數(shù)據(jù)的內(nèi)部表現(xiàn)形式,從編程的角度看開發(fā)者不會發(fā)現(xiàn)有任何區(qū)別。
JSON的簡潔性使其很容易將幾乎所有語言的對象結(jié)構(gòu)轉(zhuǎn)換為JSON。 因此,開發(fā)者可在應(yīng)用程序中定義對象,然后將其直接存儲在數(shù)據(jù)庫中。這使得開發(fā)人員不需要使用對象關(guān)系映射程序 (ORM) 不斷在數(shù)據(jù)庫架構(gòu)和類/對象架構(gòu)之間進(jìn)行轉(zhuǎn)換。
MongoDB BSON API的數(shù)據(jù)類型和約定列表添加了一種數(shù)據(jù)類型及其他一些數(shù)據(jù)類型,以便充實JSON中的可用內(nèi)容。而在一個單元中存儲和檢索相關(guān)數(shù)據(jù)可提供顯著的性能和可伸縮性的優(yōu)勢。數(shù)據(jù)庫不必四處查找常用的相關(guān)的數(shù)據(jù),因為數(shù)據(jù)都存儲在相同的位置。
類型的集合與數(shù)據(jù)庫交互時,應(yīng)用程序如何知道哪一項代表學(xué)生,哪一項代表書,以及哪一項代表博客文章? 數(shù)據(jù)庫使用集合這一概念解決了這一問題。 對于與特定集合(如學(xué)生集合)關(guān)聯(lián)的任何文檔(無論其架構(gòu)如何)都可在從該集合請求數(shù)據(jù)時對其進(jìn)行檢索。使用字段來指示類型也十分常見。這只是使搜索過程更加輕松,但哪些內(nèi)容應(yīng)進(jìn)入集合,哪些不應(yīng)進(jìn)入集合,由開發(fā)者的應(yīng)用程序決定。
架構(gòu)靈活的數(shù)據(jù)庫前面介紹的“示例代碼1”包含自己的架構(gòu)。 每個記錄負(fù)責(zé)自己的架構(gòu),甚至負(fù)責(zé)單個數(shù)據(jù)庫或集合中包含的架構(gòu)。并且一個學(xué)生記錄并不需要與另一學(xué)生記錄相匹配。開發(fā)者只需利用此靈活性來提高效率。例如,為什么存儲 null 值? 您可以在屬性(如“most_repeated class”)不具有值時執(zhí)行以下操作:
文檔數(shù)據(jù)庫和領(lǐng)域驅(qū)動開發(fā)規(guī)劃域類(可能成為數(shù)據(jù)庫中的文檔)時,開發(fā)者可查找通常最為獨立的數(shù)據(jù)(例如具有其明細(xì)項的訂單),并將其作為單個數(shù)據(jù)結(jié)構(gòu)加以關(guān)注。在訂購系統(tǒng)中,可能還有客戶和產(chǎn)品。但或許會在不需要訂單的客戶信息的情況下訪問該訂單,并且可能會在不需要訪問使用產(chǎn)品的訂單的情況下使用該產(chǎn)品。這意味著,盡管會發(fā)現(xiàn)許多機會來包含獨立數(shù)據(jù)結(jié)構(gòu)(如具有其明細(xì)項的訂單),但這并不表示在某些情形下可以不必或者不通過外鍵聯(lián)接數(shù)據(jù)。
每個數(shù)據(jù)庫都提供各種可用模式的指南,并為用戶指明使用哪些模式可以獲得最大成功。 例如MongoDB文檔討論稱為“上級數(shù)組”的模式,它可加快在聯(lián)接文檔時對相關(guān)數(shù)據(jù)的訪問速度。
在關(guān)系數(shù)據(jù)庫中,重復(fù)數(shù)據(jù)是個錯誤。 對數(shù)據(jù)庫進(jìn)行標(biāo)準(zhǔn)化可確保不出現(xiàn)此情況。 使用NoSQL數(shù)據(jù)庫(尤其是分發(fā)數(shù)據(jù)庫)時,對數(shù)據(jù)進(jìn)行逆規(guī)范化是必要且可接受的。
查詢和更新每個數(shù)據(jù)庫都附帶用于查詢和更新的API。盡管它們可能不是核心API的一部分,但多語言API是通過加載項提供的。其他查詢依賴預(yù)定義的視圖和稱為Map/Reduce的模式。此過程的映射階段使用這些視圖,并且各個數(shù)據(jù)庫的映射職責(zé)是不同的。映射還使數(shù)據(jù)庫能夠跨多個處理器分發(fā)查詢處理。化簡階段可獲取映射查詢(如果已分發(fā),則為多個查詢)的結(jié)果,并將數(shù)據(jù)聚合到要返回到客戶端的結(jié)果中。
盡管CouchDB要求開發(fā)者通過預(yù)定義的Map/Reduce視圖進(jìn)行查詢,但MongoDB(也使用視圖和Map/Reduce)另外提供執(zhí)行臨時查詢的功能。RavenDB允許使用預(yù)定義索引進(jìn)行查詢,但也支持臨時查詢,并將根據(jù)開發(fā)者的實際運行時查詢自動為其創(chuàng)建索引。但在大多數(shù)時候,當(dāng)不采用SQL數(shù)據(jù)庫的已知架構(gòu)和關(guān)系本質(zhì)時,開發(fā)者會丟失的一個功能是執(zhí)行臨時查詢的功能。通過嚴(yán)格控制查詢,文檔數(shù)據(jù)庫能夠?qū)崿F(xiàn)其快速性能。
數(shù)據(jù)庫變革有許多非關(guān)系數(shù)據(jù)庫都不屬于NoSQL范疇。但既然這扇門已經(jīng)敞開,就會鼓舞更多人去探索其可用的功能,并考慮如何改進(jìn)它。(李智/編譯)
原文鏈接:MSDN
<wb:share-button title="NoSQL數(shù)據(jù)庫技術(shù)特性解析之文檔數(shù)據(jù)庫 - 現(xiàn)今云計算的從業(yè)人員對NoSQL一詞并不感到陌生,雖然很多技術(shù)人員都長期從事關(guān)系數(shù)據(jù)庫的工作,但現(xiàn)在他們對NoSQL技術(shù)充滿期待。對于企業(yè)來說,從關(guān)系型數(shù)據(jù)庫到NoSQL數(shù)據(jù)庫轉(zhuǎn)變絕對是個需要深思熟慮的大改變。這涉及的不僅是軟件的變化,更多的是對于數(shù)據(jù)存儲上觀念性的變化。 CouchDB專家兼作者Bradley Holt認(rèn)為NoSQL并不是反SQL的運動,為對應(yīng)的工作選擇最恰當(dāng)?shù)墓ぞ卟攀钦_的模式。 大多數(shù)非關(guān)系數(shù)據(jù)庫都具有快速和可伸縮的特性。通過放棄關(guān)系存儲模型和架構(gòu),關(guān)系數(shù)據(jù)庫便可脫離由緊密結(jié)合的架構(gòu)" url="http://www.csdn.net/article/2012-01-06/310214" count="n" type="button" size="middle" >
上一篇 下一篇
本文編號:839694
本文鏈接:http://sikaile.net/wenshubaike/dxkc/839694.html