有經驗的數據庫管理員稱這些新興數據庫為“玩具”，認為它們有很嚴重的威脅，而這些威脅就是來自這些新興的數據庫。一些傲慢的家伙為新興數據庫很好用，速度很快，滿足他們手頭的需求，置威脅于不顧。

非關系型數據庫正在吸引人們的注意，因為它們可以忽略許多的規則，而這些規則正是經驗豐富的數據庫管理員積累的深刻教訓。問題是現在這些規則的條條款款已成為一種束縛，使得很難創建一個真正強大的、讓多臺計算機一起運行的數據庫系統。因為所有的Web應用程序設計者都夢想構建一個多機運行的應用程序，保存所有用戶的所有數據，要想做到這些，有些老的規則需要避開，甚至是打破。

首當其沖的事情就是摒棄舊的JOIN操作。大學生曾經嚴格的按照課后作業的要求，如何標準化數據，將一個表格劃分為許多的部分。那個時候磁盤非常貴，數據標準化工作顯得額外重要。問題當數據分散在不同機器上的時候，JOIN操作真的使得速度變得很慢。現在磁盤空間非常便宜，許多數據模型并沒有從數據標準化中受益，因此JOIN操作很容易就被摒棄。

立即一致性和最終一致性的差別依賴數據的重要性來定。那些聽到這些新興數據庫就要拿心臟病藥的保守者通常是銀行的程序員，它們希望確保每天結束后收支相等。畢竟銀行的領導不能忍受由于失敗的數據庫事務而導致帳目出錯。

但是許多現代的Web站點不會因為某個事務失效而不能運行的。我看見Facebook經常有小故障。不會因為某些評論數據丟失了就不能運行了。這些網站不會像銀行那樣苛刻關注帳目清算，它們不需要關系數據庫所有的功能。(一些人開玩笑說銀行應該把購買Oracle許可證的錢拿出來成立一個基金，賠償那些因為失敗的事務操作導致錢丟失的人們。)

為了更好地理解這些非關系型數據庫的擴展層，我撿了幾個進行測試，構建了幾個測試應用程序。發現它們主要的命令操作不會超過這三個：插入、更新、刪除。有一些提供群集，有一些只能提供某種服務，有一些夸大其詞說接管整個服務器棧，有一些比其它的數據庫提供更好的AJAX工具。但是，他們中沒有一個合適，它們都不能供銀行來使用。

文中我沒有介紹其它幾個有趣的數據庫，一是由于本文篇幅限制，二是因為它們和我以下提到的幾個沒有多大的區別。舉個例子，Sun公司正在構建一個關系型數據庫，稱之為Derby，用Java虛擬機一起使用。Oracle也有它自己的嵌入式數據庫，叫做BerkeleyDB，但是現在稱之為OracleEmbeddedDatabase。有些程序員甚至創建了低費用的程序庫，將對象直接寫入到磁盤中。這些產品也延伸了“數據庫”這幾個字眼的含義，但是我不準備在這里陳述它們。

AmazonSimpleDB數據庫

SimpleDB設計初衷是和Amazon的SimpleStorageService(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天的提醒通知，在期限內你就能將你的數據取回。                        

  　SimpleDB是兩級分層結構。最上面的一級是"domain"，第二級是"item"。在你選擇domain和item名之后，你就寫入了鍵值。SimpleDB相對來說有豐富的API,擁有對數據排序能力，甚至具備計算出匹配查詢結果的item數目的能力。你甚至能寫查詢語句，可以查詢那些不從某個特定字符串開始的值。這或許和我們使用的SQL和Oracle數據有很大的區別，但是這些低租金的數據庫也有自身的缺點，甚至不能對結果集進行排序。

GoogleAppEngine

GoogleAppEngine本質上不是一個數據庫。他是一種云技術，用于分布式Python應用程序，它是和自己隱藏在內部某個地方的數據庫一起工作的。不首先通過應用程序層來訪問數據庫是不可能的。但是封裝一個數據庫命令和格式化請求數據并不困難，因此我們可以認為AppEngine是一個數據庫，只不過這個數據庫附加了一個以Python語言寫的嵌入程序。

這種額外定制的層非常有用。許多關于其它“玩具”數據庫的抱怨圍繞在某個缺少的操作導致不能找到正確的結果。如果你想給這里的數據庫增加一些功能，你能夠用Python語言自己開發出來。如果你想要有JOIN操作，你能自己用Python語言寫，也能同時定制內存緩存器。這對于那些讓用戶存儲他們自己數據的Web應用程序特別有用。如果你需要增加安全控制權限，限制每個用戶看到自己應該看到的內容，你也可以用Python語言實現。

AppEngine數據存儲比Amazon的SimpleDB更具結構結構性，它的結構性很大一部分來自Python的對象模型。你存儲的不是成對的鍵值，而是Python對象，這些對象被定義成非常類似于SQL模式。你能為每列設置數據類型，在你需要的列之間進行索引。事務機制也深深的和Python聯系在一起，因為每個事務實際上就是一個Python函數。這么說有一些過分簡單化，因為對這個Python函數還是有一系列的限制的(如每個數據項只能更新一次)。好的消息是Google數據項正在創建特殊的事務方法，對一些普通行為(如“創建”或者“更新”一行)進行抽象。

檢索有意做成類似于SQL查詢，實際上，Google提供它自己的類SQL語言，GQL。使用的時候，GQL被解析成查詢語句。AppEngine還有一套基于Python的方法集，方法集合拴在一起處理數據集合和查詢。你不需要浪費分析查詢周期。

值得一提的是Python棧包括了一些最好的數據庫也不具備的功能特性。有一個程序庫來操作圖像文件，通過剪切和Goolge特有的“Ifeellucky”功能對圖片進行修補。你也可以將數據存儲為Goolge文檔，電子表格和日程數據項。起初AppEngine看起來僅僅像是一個數據庫，但是你也能容易的在Google棧里進行數據抽取。

直到幾周前，AppEngine還在測試階段，使用它是免費的。只要你的使用空間大小在基本的限額之內，它仍舊是免費的。另外，Google的收費機制和Amazon極為相似。存儲的價格比Amazon的更便宜(每月每G字節12美分)，帶寬的收費是相同的(10美分沒G字節)。

Google的使用期限責任制與Amazon的不同。你需要制定一個個人隱私策略，保護你用戶的數據。如果你的用戶違反了版權規定，你必須反應給DMCA(千禧年數字版權法)，你不這么做的話，Google將會為你這么做。Google保留在任何時間以任何理由刪除內容的權利。“你同意Google刪除、丟失任何存儲內容和服務試用期傳送內容、保持的通信而不負任何責任。”

這些條款越來越受到關注。現在Google承諾在決定注銷賬戶前預留90天的時間讓你將數據從服務器取走。其它受關注的條款在DMCA的問題上，這使得許多人都不解。

存在這么一個問題，如果你決定離開Google或者說Google讓你離開時該怎么辦。Google發布了一個不錯的開發工具，讓你輕松在本地機器上測試你的應用程序。使用這些工具在你機器上測試是沒有技術問題的，除非你沒有支持類云技術的功能。包括測試在內的數據存儲自身是不會自動復制自己的，但是在自己本地機器上卻能實現其它的功能。像以前一樣，有一些法律問題，因為“許可證的唯一目的就是讓你使用和享受提供服務的好處。”

ApacheCouchDB數據庫

毫無疑問我們需要使用云技術來享受這些新的服務。CouchDB是眾多開源項目中的一個，該項目構建了一個用于存儲key-valuepairs的數據庫。這個項目使用Erlang語言編寫的，受Apache軟件基金支持。你可以下載源文件在任何機器上安裝，然后編譯運行它們。使用它是沒有費用的，除了你需要花錢購置服務器。

CouchDB與Amazon的工具是相似的，但是它有一些特別之處。你仍舊以行的形式來存儲key-valuepairs，但是這些key-valuepairs可以是任何標準的JSON(JavaScriptObjectNotation)數據類型，如布爾和數字類型。值的范圍不局限于1024字節長度的字符串，有辦法可以讓其存儲長數值，甚至是圖形。所有的請求和響應格式化為JavaScript。沒有基于XML的WebServices，只有JSON.

最大的不同在于寫查詢語句。CouchDB可以通過JavaScript單獨寫mapfunctions和reducefunctions。一個簡單的查詢或許僅僅就是一個mapfunction，帶有一個“If”子句來測試數據比某個數值大還是小。只有在你試圖計算統計由mapfunctions查詢的數據時才會用到reducefunctions。發現計算行的個數很容易辦到，但是也有可能丟失了一些其它很酷的特性，因為mapfunction只能由JavaScript來寫。我除了發現計算出匹配的數目，至于其他的非學術的用途我還沒有弄清楚。文檔包括了一個給人印象很深刻的reductionfunction，用來歸并統計的，但是我不知道CouchDB真的是否是處理這類事情的正確工具，如果你需要更復雜的統計，妥當的就是堅持使用傳統的數據庫，獲得統計報表。

這個項目還有一些限制的。項目的首頁稱之為“一種分布式，容錯，自由面向文檔模式的數據庫，”沒有一些人工干預你是不會獲得分布式和容錯功能的。CouchDB有一個好看的AJAX用戶界面，包含了一個form表單，能讓你復制數據庫。但是還不是自動的。

CouchDB計劃會增加存取控制和安全模式，但是沒有以文檔的形式展示出來，在API中也沒顯示。他們設計的初衷就是使用純JavaScript，取代SQL,或者其他的語言，這是一個好的主意，你不會獲得或者失去權限閱讀文檔，你能寫JavaScript函數來返回true或者false結果。

使用純JavaScript也并非壞事。當我使用這些數據庫的時候，我很快發現有人能夠在客戶端開發一個安全模型層，使用一些不錯的加密技術。在客戶端加強安全控制，就能減少服務器端的工作，我在《半透明數據庫》一文中有一些介紹。

這個特點正在驅使一些極端用戶使用CouchDB作為整個服務器棧。J.ChrisAnderson，項目的委托人之一，寫了一篇文章，證明CouchDB是一個應用程序服務器的全部所需。用于顯示和與數據交互的業務邏輯是用JavaScript編寫的，從CouchDB下載后是一個JSON數據包。

在Anderson的眼里，當所有的功能都能用JavaScript實現，在服務器上使用Ruby、Python、Java、PHP沒有什么大的意義。這種看法或許有些極端，因為總會遇到一些情況，客戶機器不能保證能正確的實現一些功能，客戶端的客戶比我們知道的東西少。像CouchDB這種輕量級的工具使得人們開始考慮完成一項工作真正需要多少代碼。