Azure的NoSQL技術

作者: 張天雷來源: infoQ 發布時間: 2014-12-25 16:34 閱讀: 4117 次推薦: 6 原文鏈接 [收藏]

　　長期以來，傳統關系型數據庫占據了數據存儲的大片江山。但是隨著互聯網web2.0網站的興起，傳統的關系數據庫在應付web2.0網站，特別是超大規模和高并發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題。NoSQL，泛指非關系型的數據庫，由于其本身的特點得到了非常迅速的發展。

　　作為云計算領域大型廠商的Azure云，對NoSQL技術有一系列很好的支持。Azure云將數據大概分為兩種：運行時數據和分析數據。所謂運行時數據就是云計算應用在運行過程中產生的數據，比如購物車添加的某個商品，比如人力資源系統中員工信息以及股票交易系統里的股票買入賣出價格。所謂分析數據，則是通過對運行時數據進行分析后的數據，比如對用戶購買數據進行分析后得到的市場預測或者用戶購買行為建模數據。這些數據隨著應用的運行不斷積累，通常來講要比運行時數據大得多。雖然這種分類不是那么清晰，但是業界通常用這種方式來選擇是否使用NoSQL技術。如下圖所示：

　　圖中的綠色部分，就是Azure云提供的數據庫相關工具，而黑色部分則是可以運行在Azure云上的其他數據庫相關工具。在NoSQL方面，Azure可以提供如下服務：

　　文檔存儲

　　使用Azure的DocumentDB，類似MongoDB。它包括了一系列由JSON格式構成的文檔。注意這里面的Document跟以往微軟Word軟件給出的Document不是一個意思。下圖給出了DocumentDB的一個例子：

　　從例子可以看出，DocumentDB跟關系數據庫最大的區別，也是NoSQL數據庫的最大特點，就是它沒有特定的Schema，并將全部的數據以字符串的形式存儲。在訪問數據的時候，通常通過NoSQL給定的RESTful接口進行增刪查改數據，可一次提交一個或多個類似SQL的查詢語句。RESTful接口支持的語言很多如.NET、Node.js、JavaScript和Python等。

　　跟大多數的NoSQL數據庫一樣，DocumentDB可以處理海量數據。其數據存儲可以分布在多臺機器，而且為了防止數據訪問出錯，DocumentDB還對一份數據進行了多份備份。當然多備份通常意味著對數據更新和修改的成本會增加，這就需要開發者自己來權衡開發效率和開發效果了。DocumentDB提供了四種數據訪問格式：增強型，最慢但是可以保證數據的正確性。過期數據標注型，告訴開發者正在訪問的數據是否過期，讓開發者決定是否對數據進行更新。會話型，同一個應用內部可以保證數據的正確性，不保證跨應用的數據正確性。快速型，提供最快的數據訪問速度，但是返回過期數據的概率也是最大的。

　　DocumentDB是Azure的內置服務，用戶無需安裝就可以創建新的數據庫和數據集合。并且它通過“運算能力單元”（Capacity Units）來保證在多租戶的情況下單一用戶的性能需要。此外Azure云存儲還提供MongoDB、RavenHQ和Redis等其他NoSQL技術。

　　對于開發者來講，從本地通過Visual Studio對DocumentDB進行訪問是輕而易舉的事情。他們只需要通過NuGet包管理工具下載安裝DocumentDB.NET開發包，就可以從容地創建數據庫和數據集合、修改JSON文檔以及查詢等。如果開發者想要在一次transaction中修改多個文檔，則可通過服務端腳本來開發類似SQL Procedure來完成，從一定程度商來講，現代化的JavaScript腳本取代了傳統的T-SQL，使得開發者用起來更加得心應手。

　　關于DocumentDB的入門教程可以參考Gaston Hillar在Dobbs給出的教程。

　　Key/value存儲

　　使用Azure的Tables，類似Riak，來滿足快速訪問大量數據的需求。比如一個電商應用，存儲了大量的在線購物車。數據非常簡單，就是用戶感興趣想要購買的商品列表。而且開發者對這些數據的操作也相對簡單，就是對一個特定的購物車鍵值進行讀和寫。

　　這種情況下，不能使用傳統的關系型數據庫。因為它限制了購物車的數量。因此對于這種大規模簡單數據的讀寫操作，Azure云開發了Tables來幫助開發者更好的完成。

　　Key/Value存儲的思想很簡單，根據一個特定的鍵值，來增刪查改跟其相關的數據。在Azure Tables中，數據存儲在分區中，每個分區存儲一些實體，而實體則有屬性。每個屬性都有名字和類型比如整數或者字符和日期。每個實體都有一個屬性是分區的Key，整個這個分區的所有實體的該屬性都是一樣的值。每個實體還有另外一個屬性行值，用來區分同一個分區內的各個實體。因此，開發者想要訪問某一個實體，就可以通過分區Key和行Key來定位它。

　　如同其它的NoSQL數據庫，Tables沒有Schema的概念。分區中的每個實體都可以包含不同數量的屬性，只保留對應用最重要的部分數據。在上面圖中的例子里，A1所對應的實體可能包含名字、國籍、年齡以及上次登錄的日期。而A2則只包括了名字、國籍和年齡。不管數據是什么類型的，Tables都可以保證這些實體的快速訪問。當然要注意的是，Tables對數據的訪問相對來講比較簡單，不提供存儲過程或者出發這類功能。類似DocumentDB，Tables也對數據進行了多備份的處理，所以哪怕是幾臺機器失效，數據也會盡可能的被保護。此外，跟DocumentDB不同的是，Tables對數據的一致性也有很好的處理，這意味著開發者總是會得到最后修改過的數據。Tables還提供跨數據中心的存儲，讓開發者將數據存儲在Azure不同地區的數據中心里，通過異步來更新數據的改動。

　　最后，Tables最吸引人的地方，實際上是其低廉的價格。雖然這跟開發者選用的存儲形式有關系，比如跨數據中心存儲會稍微貴一些，但是整體上來講是比DocumentDB要便宜的。這么便宜是因為基本上這都是一些存儲費用，Tables并不保證CPU資源。總之Tables這種Key/Value形式的存儲非常簡單、可擴展而且價格低廉，是很多應用開發的首選。

　　列對象存儲

　　使用Azure的HBase，類似Cassandra。主要是為了應對這樣的場景：之前使用了傳統的關系型數據庫，但是隨著業務的增長，關系型數據庫無法容納這么多的數據。而經過研究發現這些數據很多都是稀疏的，即大部分字段都是沒有值的。就可以使用列優先的數據庫來進行存儲。

　　再舉一個例子，比如現在有個應用想要存儲關于很多網頁的數據。一行數據描述一個網頁，每一列都是關于這個網頁的一些信息。通常來講，都會有很多行，因為網頁很多，而且也會有很多列，因為網頁的信息包含方方面面。但是大部分的字段都是空的，因為不是每個網頁都包含了方方面面。如下圖所示：

　　跟Tables不太一樣的是，以列為先的HBase，還是有一點點Schema的味道，將其稱作“列組”。上面的例子還是存儲了Tables里面同樣的例子數據。列組使用一個特定的命名來區分彼此，組內則維持原有的列名字。注意，類似關系數據庫，每一列不一定都被填滿，但是這種獨特的將列劃分的組織形式，使得HBase能夠將稀疏數據做進一步的處理和優化存儲。跟DocumentDB和Tables不同，HBase并沒有以文檔或者實體的形式來看待數據，而是只有當新的數據需要存儲的時候，才會為某一行增加新的列。

　　HBase跟傳統數據庫也有不同的地方，即存儲的內容沒有類型的區別，每個字段存儲的都是bytestring。而且每個字段都可以保留相當長的歷史數據以及不同版本的數據，這對于需要訪問先前數據的應用就有用了。此外，為了跨機器存儲，HBase還將不同的行組合起來形成Region區域，當然這對于應用開發者來講是透明的。這就跟DocumentDB的容器和Tables中的分區不一樣了，這些都是開發者在創建數據庫的時候必須手動給定的。

　　HBase并不提供查詢語言，應用只需提供列組、列名稱和行Key就可以訪問對應的數據，這種訪問方式類似上面提到的Key/Value Tables。下表給出了Azure云中支持的數據庫類型的比較：

　　大數據分析

　　使用Azure的HDInsight，類似Hadoop。在大數據這個概念深入人心之前，應用開發者對數據所做的，就是保證應用的功能性。比如讓用戶完成購買、招聘新人、更新游戲排名榜之類的。但是，隨著越來越多歷史數據的積累，分析運行時數據的模式、趨勢以及相關信息能夠讓開發者獲得更進一步對應用的認識，獲取第一手的評估資料。因此，Azure云還為開發者提供了商業智能相關的數據庫支持，如數據倉庫等。對于分析數據來講，傳統的關系數據庫技術就顯得不是很合適了，因為這種數據可能并不能用關系來表示。

　　非常贊的是，開源的Hadoop軟件給了我們分析這種數據的可能，Azure包含了多種Hadoop相關技術，如下：