云計算推波助瀾 非關系數據庫蓄勢待發
前面為大家介紹了淺談云計算的發展之路，下面為大家介紹“云計算推波助瀾 非關系數據庫蓄勢待發”的態勢。
在過去的日子，當你有數據需要存儲管理的時候，辦法很簡單：安裝一個正式的數據庫，將需要存儲的數據錄入進去，讓系統幫你進行分類管理，而你只需要花時間去選擇哪家數據庫提供商。現在事情并非如此，一些新興數據庫工具開始泛濫，賦予了“數據庫”這幾個字眼更多的含義，打破了傳統數據庫關系模型。有經驗的數據庫管理員稱之為“玩具”，認為它們有很嚴重的威脅，而這些威脅就是來自這些新興的數據庫。一些傲慢的家伙為新興數據庫很好用，速度很快，滿足他們手頭的需求，置威脅于不顧。
非關系型數據庫正在吸引人們的注意，因為它們可以忽略許多的規則，而這些規則正是經驗豐富的數據庫管理員積累的深刻教訓。問題是現在這些規則的條條款款已成為一種束縛，使得很難創建一個真正強大的、讓多臺計算機一起運行的數據庫系統。因為所有的Web應用程序設計者都夢想構建一個多機運行的應用程序，保存所有用戶的所有數據，要想做到這些，有些老的規則需要避開，甚至是打破。
首當其沖的事情就是摒棄舊的JOIN操作。大學生曾經嚴格的按照課后作業的要求，如何標準化數據，將一個表格劃分為許多的部分。那個時候磁盤非常貴，數據標準化工作顯得額外重要。問題當數據分散在不同機器上的時候，JOIN操作真的使得速度變得很慢。現在磁盤空間非常便宜，許多數據模型并沒有從數據標準化中受益，因此JOIN操作很容易就被摒棄。
立即一致性和最終一致性的差別依賴數據的重要性來定。那些聽到這些新興數據庫就要拿心臟病藥的保守者通常是銀行的程序員，它們希望確保每天結束后收支相等。畢竟銀行的領導不能忍受由于失敗的數據庫事務而導致帳目出錯。
但是許多現代的Web站點不會因為某個事務失效而不能運行的。我看見Facebook經常有小故障。不會因為某些評論數據丟失了就不能運行了。這些網站不會像銀行那樣苛刻關注帳目清算，它們不需要關系數據庫所有的功能。(一些人開玩笑說銀行應該把購買Oracle許可證的錢拿出來成立一個基金，賠償那些因為失敗的事務操作導致錢丟失的人們。)
為了更好地理解這些非關系型數據庫的擴展層，我撿了幾個進行測試，構建了幾個測試應用程序。發現它們主要的命令操作不會超過這三個：插入、更新、刪除。有一些提供群集，有一些只能提供某種服務，有一些夸大其詞說接管整個服務器棧，有一些比其它的數據庫提供更好的AJAX工具。但是，他們中沒有一個合適，它們都不能供銀行來使用。
文中我沒有介紹其它幾個有趣的數據庫，一是由于本文篇幅限制，二是因為它們和我以下提到的幾個沒有多大的區別。舉個例子，Sun公司正在構建一個關系型數據庫，稱之為Derby，用Java虛擬機一起使用。Oracle也有它自己的嵌入式數據庫，叫做Berkeley DB，但是現在稱之為Oracle Embedded Database。有些程序員甚至創建了低費用的程序庫，將對象直接寫入到磁盤中。這些產品也延伸了“數據庫”這幾個字眼的含義，但是我不準備在這里陳述它們。
Amazon SimpleDB數據庫
SimpleDB是Amazon推進云計算服務計劃中最為高級和最似云技術的組件之一。一旦你簽約雇傭Amazon的服務，獲得通行密碼，你就能將包含鍵值的Web Service XML文件裝載到SimpleDB中去，只要你持續支付費用，它將一直為你存儲這些數據。你不需要考慮安裝任何應用程序或者備份什么。Amazon在它的Web service墻后已經為你隱藏了所有這些工作。
SimpleDB是兩級分層結構。最上面的一級是"domain"，第二級是"item"。在你選擇domain 和item 名之后，你就寫入了鍵值。SimpleDB相對來說有豐富的API,擁有對數據排序能力，甚至具備計算出匹配查詢結果的item數目的能力。你甚至能寫查詢語句，可以查詢那些不從某個特定字符串開始的值。這或許和我們使用的SQL和Oracle數據有很大的區別，但是這些低租金的數據庫也有自身的缺點，甚至不能對結果集進行排序。
SimpleDB設計初衷是和Amazon的Simple Storage Service (S3)一起使用的，但是每對鍵值的大小限制在1024字節。這對于很多的字符串來說，已經足夠了，但是對于許多的內容引擎是不夠的。因此你在S3中存儲的是數據的指針。
現在使用類似JOIN這樣的操作還有一些限制，需要多種調用。每個查詢只能運行5秒鐘。結果僅能保持250個item。每個item僅有250對。還有許多的常見操作有限制，有人開始思考SimpleDB是給我們的生活帶來了便捷或是麻煩。
Amazon開始重寫API，企圖得到更多更好的認證。到2009年9月，整個SSL都會運行call，提供安全和認證。Amazon也增加了安全機制，使用更多的復雜的哈希算法來將更多的請求打包。這些僅僅是Amazon取得的小的改進。
該公司也創建了更多的程序庫，讓服務的使用更加簡單。這里有許多的軟件包和主流以及一些少見的語言結合使用。文檔相當廣泛，很容易找到。通常你可以很快啟動你的工作，開始存儲數據所用的時間也縮短了。
現在價格也很合適。Amazon最近將存儲的價格從1.5美元降到25美分每G字節。公司將收費透明化，目的是激勵用戶來計劃他們的消費預算。
Amazon有一套先進的條款來處理使用期限問題。有許多的條款來處理你可能遇到的問題，有一些吸引了我的注意力。舉個例子，Amazon申明，“我們可能刪除最近6個月存在SimpleDB中卻沒有訪問的內容，但是不用負任何責任。”這對于只是為了給系統做測試的人來說很容易接受。從措辭來看，Amazon此舉的目地就是為了保持它的數據中心良好運行。
還有其他的一些問題。舉個例子，使用期限條款包括一長列禁止數據，如“助長非法活動”，帶有“種族、性別、宗教、國籍、殘疾、性取向、年齡”歧視的數據都是禁止的。這存在一個問題。想像一下如果為某個教堂開展反男同性戀婚姻運行了一個網站。這聽起來你確實有性取向歧視。但是，如果你是開展男同性戀婚姻的宣傳活動，反對這些教堂的呢，這個時候還能說你是在歧視這些基本的宗教信仰嗎?
我對那些正在分析處理這些抱怨的律師感到遺憾，但是至少他們可以高枕無憂了，因為他們知道這些數據可以以任何理由或者是沒有理由的刪除掉。如果你僅使用免費的服務，Amazon不會給你任何通知，就會刪除你的數據，但是你如果是付費用戶，就承諾有60天的提醒通知，在期限內你就能將你的數據處理好。
Google App Engine
Google App Engine本質上不是一個數據庫。他是一種云技術，用于分布式Python應用程序，它是和自己隱藏在內部某個地方的數據庫一起工作的。不首先通過應用程序層來訪問數據庫是不可能的。但是封裝一個數據庫命令和格式化請求數據并不困難，因此我們可以認為App Engine是一個數據庫，只不過這個數據庫附加了一個以Python語言寫的嵌入程序。
這種額外定制的層非常有用。許多關于其它“玩具”數據庫的抱怨圍繞在某個缺少的操作導致不能找到正確的結果。如果你想給這里的數據庫增加一些功能，你能夠用Python語言自己開發出來。如果你想要有JOIN操作，你能自己用Python語言寫，也能同時定制內存緩存器。這對于那些讓用戶存儲他們自己數據的Web應用程序特別有用。如果你需要增加安全控制權限，限制每個用戶看到自己應該看到的內容，你也可以用Python語言實現。
App Engine數據存儲比Amazon的SimpleDB更具結構結構性，它的結構性很大一部分來自Python的對象模型。你存儲的不是成對的鍵值，而是Python對象，這些對象被定義成非常類似于SQL模式。你能為每列設置數據類型，在你需要的列之間進行索引。事務機制也深深的和Python聯系在一起，因為每個事務實際上就是一個Python函數。這么說有一些過分簡單化，因為對這個Python函數還是有一系列的限制的(如每個數據項只能更新一次)。好的消息是Google數據項正在創建特殊的事務方法，對一些普通行為(如“創建”或者“更新”一行)進行抽象。
檢索有意做成類似于SQL查詢，實際上，Google提供它自己的類SQL語言，GQL。使用的時候，GQL被解析成查詢語句。App Engine還有一套基于Python的方法集，方法集合拴在一起處理數據集合和查詢。你不需要浪費分析查詢周期。
值得一提的是Python棧包括了一些最好的數據庫也不具備的功能特性。有一個程序庫來操作圖像文件，通過剪切和Goolge特有的“I feel lucky”功能對圖片進行修補。你也可以將數據存儲為Goolge文檔，電子表格和日程數據項。起初App Engine看起來僅僅像是一個數據庫，但是你也能容易的在Google棧里進行數據抽取。
直到幾周前，App Engine還在測試階段，使用它是免費的。只要你的使用空間大小在基本的限額之內，它仍舊是免費的。另外，Google的收費機制和Amazon極為相似。存儲的價格比Amazon的更便宜(每月每G字節12美分)，帶寬的收費是相同的(10美分沒G字節)。
Google的使用期限責任制與Amazon的不同。你需要制定一個個人隱私策略，保護你用戶的數據。如果你的用戶違反了版權規定，你必須反應給DMCA(千禧年數字版權法)，你不這么做的話，Google將會為你這么做。Google保留在任何時間以任何理由刪除內容的權利。“你同意Google刪除、丟失任何存儲內容和服務試用期傳送內容、保持的通信而不負任何責任。”
這些條款越來越受到關注。現在Google承諾在決定注銷賬戶前預留90天的時間讓你將數據從服務器取走。其它受關注的條款在DMCA的問題上，這使得許多人都不解。
存在這么一個問題，如果你決定離開Google或者說Google讓你離開時該怎么辦。Google發布了一個不錯的開發工具，讓你輕松在本地機器上測試你的應用程序。使用這些工具在你機器上測試是沒有技術問題的，除非你沒有支持類云技術的功能。包括測試在內的數據存儲自身是不會自動復制自己的，但是在自己本地機器上卻能實現其它的功能。像以前一樣，有一些法律問題，因為“許可證的唯一目的就是讓你使用和享受提供服務的好處。”
Apache CouchDB數據庫
毫無疑問我們需要使用云技術來享受這些新的服務。CouchDB是眾多開源項目中的一個，該項目構建了一個用于存儲key-value pairs的數據庫。這個項目使用Erlang語言編寫的，受Apache 軟件基金支持。你可以下載源文件在任何機器上安裝，然后編譯運行它們。使用它是沒有費用的，除了你需要花錢購置服務器。
CouchDB與Amazon的工具是相似的，但是它有一些特別之處。你仍舊以行的形式來存儲key-value pairs，但是這些key-value pairs可以是任何標準的JSON(JavaScript Object Notation)數據類型，如布爾和數字類型。值的范圍不局限于1024字節長度的字符串，有辦法可以讓其存儲長數值，甚至是圖形。所有的請求和響應格式化為JavaScript。沒有基于XML的Web Services，只有JSON.
最大的不同在于寫查詢語句。CouchDB可以通過JavaScript單獨寫map functions和reduce functions。一個簡單的查詢或許僅僅就是一個map function，帶有一個“If”子句來測試數據比某個數值大還是小。只有在你試圖計算統計由map functions查詢的數據時才會用到reduce functions。發現計算行的個數很容易辦到，但是也有可能丟失了一些其它很酷的特性，因為map function只能由JavaScript來寫。我除了發現計算出匹配的數目，至于其他的非學術的用途我還沒有弄清楚。文檔包括了一個給人印象很深刻的reduction function，用來歸并統計的，但是我不知道CouchDB真的是否是處理這類事情的正確工具，如果你需要更復雜的統計，妥當的就是堅持使用傳統的數據庫，獲得統計報表。
這個項目還有一些限制的。項目的首頁稱之為“一種分布式，容錯，自由面向文檔模式的數據庫，”沒有一些人工干預你是不會獲得分布式和容錯功能的。CouchDB有一個好看的AJAX用戶界面，包含了一個form表單，能讓你復制數據庫。但是還不是自動的。
CouchDB計劃會增加存取控制和安全模式，但是沒有以文檔的形式展示出來，在API中也沒顯示。他們設計的初衷就是使用純JavaScript，取代SQL,或者其他的語言，這是一個好的主意，你不會獲得或者失去權限閱讀文檔，你能寫JavaScript函數來返回true或者false結果。
使用純JavaScript也并非壞事。當我使用這些數據庫的時候，我很快發現有人能夠在客戶端開發一個安全模型層，使用一些不錯的加密技術。在客戶端加強安全控制，就能減少服務器端的工作，我在《半透明數據庫》一文中有一些介紹。
這個特點正在驅使一些極端用戶使用CouchDB作為整個服務器棧。J. Chris Anderson，項目的委托人之一，寫了一篇文章，證明CouchDB是一個應用程序服務器的全部所需。用于顯示和與數據交互的業務邏輯是用JavaScript編寫的，從CouchDB下載后是一個JSON數據包。
在Anderson的眼里，當所有的功能都能用JavaScript實現，在服務器上使用Ruby、Python、Java、 PHP沒有什么大的意義。這種看法或許有些極端，因為總會遇到一些情況，客戶機器不能保證能正確的實現一些功能，客戶端的客戶比我們知道的東西少。像CouchDB這種輕量級的工具使得人們開始考慮完成一項工作真正需要多少代碼。
Persevere數據庫
初一看，Persevere數據庫像其它大多數數據庫一樣。將鍵值對錄入進去，它就將其存儲起來。但是，這只是一個開頭。Persevere提供了完善的對象分級結構，使得用戶可以給數據庫增加更多的結構，提供比上一代傳統數據庫更多的form。Persevere更多的表現出是一種JavaScript對象的后端存儲設備，JavaScript對象由像Dojo這樣的AJAX工具包創建。
Persevere引以為自豪的是它的“schema-free”，這一特點使得它與其它數據庫有很大的區別。Persevere可以讓你隨心所欲的增加schema。Persevere并非把分級結構的頂層稱為一個domain(SimpleDB這么稱呼),也不稱之為文檔(CouchDB這么稱呼)，Persevere稱之為對象，它甚至可以讓你創建對象的子類。如果你想違背規則，你也能堅持某些字段使用某一類型，但是這是不推薦的。Schema規則是可選的。
由于Persevere與Dojo連接緊密，Persevere提供了大量的連通性。你可以創建網格，樹形窗口小部件，接著將其直接鏈接到JsonRestStore，窗口小部件讓你編輯數據。 你可以通過20行的JavaScript代碼就能遠程訪問一個數據庫。
我遇到過許多的小的誤操作，這些誤操作可能是由于我缺乏經驗導致，而不是潛在的Bug。當我準確的弄清楚如何做的時候，一些操作就會正確啟動。Persevere本身并不是特別需要掌握，但是AJAX框架是你直接面對的。來自Dojo的文檔比大多數AJAX框架要好，但是你得花一些時間來學習Dojo，才能掌握隱藏在Persevere表面后的潛在復雜性問題。
云技術和群集
嘗試了這些數據庫之后，我能明白為什么有人會一直稱它們為“玩具”。它們功能有限，即便有新的功能，但是這些新的功能會約束你的選擇。許多次我意識到SQL世界的標準功能讓生活更加簡單。許多基于標準SQL的工具，如報表引擎，不能連接這些新興的數據庫。使用MySQL或者Oracle這些數據庫能夠完成許多重大的功能。
但是，這不代表將來在我的項目中我不去使用這些新興的數據庫。它們是固態數據存儲，與AJAX集成得如此緊密，使得開發更加容易。另外，多數Web站點不需要MySQL或者Oracle的所有功能，JOIN-free模式對許多普通數據結構仍舊非常有用，包括一對多關，一對一關系型數據，甚至多對一關系。
另一個問題是是否使用云技術或者構建你自己的群集。Google和Amzon都提供多機服務承諾，CouchDB和Persevere是不能匹敵的。Persevere團隊聲稱在將來將會擴展。但是很難預料Amazon和Google的承諾有多好。如果Amazon和Google丟失了一個硬盤怎么辦?如果它們丟失了一個機架怎么辦?他們還沒有做出很清晰的承諾和使用期限所負的責任。
舉個例子，Amazon的條款重復聲明了很多次：“我們對于為授權的訪問、改變、刪除、損害、丟失任何你的內容、應用程序，或者你提交的數據、服務帳號都不負責任。”
我不是說在責備Amazon或者是Google，因為誰都不知道誰應該對丟失的事務負最終的責任。有可能是任何一個程序員，實際上也很難判斷誰破壞的。但是，我們知道更多信息會更好。SimpleDB中的數據是存儲在RAID磁盤中嗎?當同一地區發生地震，颶風或者火災時別的地區另外的備份嗎?在線備份社區正準備開始提供這類服務的細節了，但是云技術還沒有計劃這樣做。
所有這些顧慮讓我們清楚的認識到他們仍舊是玩具數據庫，打破了傳統數據庫的規則，對那些可以忍受數據丟失的應用程序是合適的。它們很有趣，有快，在價格方面也很合適，你的注意力可以不用放在選擇數據庫提供商，而是放在如何解決沒有JOIN操作怎么辦的問題上。
這就是我要為大家介紹的全部內容，希望大家從中有所收獲。
【編輯推薦】
