【WatchStor獨家譯文】12月，Amazon發布了SimpleDB產品的測試版。SimpleDB是Amazon Web Services——也就是AWS——工具套裝的一部分。Amazon SimpleDB給那些使用基于云技術應用軟件的公司提供了一個存儲簡單數據場所。對用戶來說，這個產品特別適用于快速查找資料的場合。

    該公司的這項工作已經開始了一段時間了；事實上早在一年前Amazon就推出了這個計劃的早期版本，一些用戶已經從那個時候開始使用該產品了。在那之后，Amazon又對SimpleDB做了許多調整改進工作，很明顯這是Amazon在聽從客戶建議之后所做的努力。

    現在推出的這個測試版（任何人都可以使用）與客戶理想中的最終產品越來越接近。我現在已經決定試用一下，因為我是Visual Studio的研發者，我所選擇的工具是C#Visual Studio庫（Amazon也為其他包括Java，Perl和PHP在內的平臺提供了幾種官方庫）。

    使用

    SimpleDB采用了一種很獨特的存儲方法，使人們可以在云基礎的應用軟件上存儲簡單數據。這種方法與電子表格程序類似，并且一定是非關聯性的。（這讓我想起了Google的BigTable。這個軟件能通過Google App Engine運用到一個叫DataStore的小型表格中去。）當SimpleDB不能滿足你的要求時，Amazon還提供許多其它的數據庫。 比如說公司提供Amazon Simple Storage用于存儲文件。EC2（彈性計算云）是這個軟件的主要云平臺，在這個平臺上，你可以運行任何數據庫服務器，其中也包括了SQL服務器。這就意味著你并不是只能選擇SimpleDB。

    總覽

    SimpleDB（與Google的DataStore相類似）的主要宗旨就是閱讀速度快。雖然并非全部的網站都需要快速進行資料檢索，但至少絕大部分的網站有這樣的需求，而且它們對資料檢索速度的要求遠遠高于對資料存儲的要求。Amazon的自有網站就是一個典型的例子。人們在Amazon的網上瀏覽書籍和其它產品，一定希望很快就能打開相應的網頁。此時，除了記錄下你的瀏覽歷史之外，基本上沒有什么資料存儲工作。人們可不想苦苦等待這些網頁慢慢打開。但又比如說當人們在Amazon的論壇上發帖時，***的帖子發布過程會有延遲——這段時間雖然很短，但大家還是可以發現。可顯然大家對這個現象表現出了相當的寬容。總的來說，對絕大部分人來說，讓他們滿意的應該是可以快的閱讀速度以及相對來說可能慢一些的書寫速度。這些就是SimpleDB（與Google DataStore）提供的主要功能。

    盡管現在市場上大部分的數據庫都是關系型的（并且采用的是SQL語言），可以肯定的是SimpleDB一定是非關聯性的。用戶并不是在表格相同的條條框框里創建資料，而是創建一個稱為域的資料集用于存放資料項。每一個資料項能夠有多種“屬性”，每一個屬性都可以單獨命名。

    這些就是SimpleDB與傳統的關系型數據庫大不相同的地方。SimpleDB提供的樣本文件就是很好的例子。假定你想創建一個域用于存儲產品信息。對你來說，一項產品有可能是一件衣服，這件衣服可能會有多種屬性，比如說顏色，尺寸等等。另一項產品可能又是一件與衣服完全不同的產品，比如說是一個汽車引擎。汽車引擎的屬性里不包括顏色與尺寸，但是卻會有其他內容，比如說型號、生產年份等等。

    在一個關系型數據庫里，上文所說的那種情況有兩種解決辦法。一種就是創建兩個不同的表格，另一個就是創建一個表格，但這個表格里會含有對某些產品來說并不存在的屬性名稱。（例如對汽車引擎來說，尺寸這一欄將留空。）但是在SimpleDB里，尺寸這一條在汽車引擎項里并不存在，同樣對套衫這一項來說，也不會出現品牌和型號這類的條款。但是汽車引擎和套衫可以同時存儲在一個單獨的域里。

    你可以在同一個域里創建下述數據：   

 l  Item1: Category=Clothes; SubCategory=Sweater; Name=Cathair Sweater; Color=Siamese, Size=Small, Medium, Large.

 l  項1：Category=Clothes; SubCategory=Sweater; Name=Cathair Sweater; Color=Siamese, Size=Small, Medium, Large.

 l  Item2: Category=Car Parts; SubCategory=Engine; Name=Turbos; Make=Audi; Model=S4; Year=2000,2001,2002.

 l  項2：Category=Car Parts; SubCategory=Engine; Name=Turbos; Make=Audi; Model=S4; Year=2000,2001,2002.

    要注意的是，兩項產品同時擁有屬性目錄，支目錄以及品牌這三項。但是其它的屬性卻是各自產品特有的。同時還要注意的是同一個屬性值可以同時存儲多個數值。對項1套衫來說，尺寸這項就有三個值，分別是：小，中和大。對項2引擎來說，生產年份同樣有三個值：2000，2001和2002。

    庫以及訪問方法

    我提到過我選擇了C#庫。這里我想說明一點：這些庫是Amazon自己編寫的，但并不是唯一可供選擇的庫。SimpleDB的界面訪問可以從下面兩種方法中任意選一個：一是作為網絡服務器（運用SOAP），另一個是REST（Representational State Transfer，代表性狀態傳輸）。C#庫包括了許多不同的類型和方法，這些類和方法都可以和SimpleDB互動。這些庫會自動以一種隱蔽的方式創建URL，同時將它們發送到網絡服務器，等待反饋。反饋將以下面的形式出現：（順便提一句，如果你對REST非常感興趣，網上有很多關于Amazon在創建自身界面時是否打破了非官方REST條例的討論。這篇文章里就這個問題我不打算做更深入的討論。但是如果你們對這些信息有興趣的話，上網以SimpleDB REST為關鍵詞用google搜索一下就可以找到這類信息。）

    既然C#庫可以簡單地創建了REST請求，同時也閱讀了反饋，事實上這個時候就可以開始著手創建你自己的類型庫了。我想隨著時間的推移，我們可以看到更多更好的庫，因為Amazon現在創建的這個并不是十分的復雜。但既然這只是一個面向REST訪問的庫，所以我并不打算以這一個庫為標準對SimpleDB的產品進行評判（我建議你們也別這樣做）。

    但是我的確有一個很關心的問題，那就是：所有的反饋都是以

       
   
    Height
    1
   
   
    Width
    2
   
   
   
    12345678-1234-1234-1234-123456789012
    0.0000012345
   
   

    這樣要回到雙整數將要浪費很多空間。雙整數只需要幾個字節就可以存儲下來，而這樣的反饋大小卻超過了400字節。如果你要做的是大量的數據修補工作，上述說的差異將會對結果造成巨大的影響。（這就意味著你將要確認自己將會批量訪問數據而并非單獨訪問。多項數據資料可以僅出現一項反饋）

    體驗SimpleDB

    C#庫可能的確是有一些過于簡單，但它運行良好。我可以很容易地把資料輸入到SimpleDB服務器上。我運行編碼創建域，從域里添加和移除資料，同時還可以將這些資料在域里進行排列。這些工作都進行得十分順利。事實上這些就足夠了，這也是SimpleDB所運求的——簡潔。它是用于存儲資料的。至于判定到底哪些是你的網站需要上傳的資料，這可就是你自己的任務了。

    當然利用C#庫也給我們出了一個有趣的思考題：在處理網絡相關問題的時候，C#通常意義上是一個基于服務器的語言。這就表示你可能需要將你的網站的主機建立在Amazon的EC2或者是你自己的網站上。這個網站一定要是一個ASP.NET站點，同時你將要創建C#代碼以達到和AmazonDB服務器互動的目的。接下來你的客戶將會瀏覽你的網站，他們根本不會知道在后臺你的站點正在Amazon的服務器上存儲資料。

    但是這種現象合理嗎？你建了一個自己的網站，但用的卻不是自己的數據。你必須將你自己的服務器連接到位于另一個網絡里的另一臺服務器上才能獲取數據。這樣有意義嗎？這個問題的答案取決于你們自己，我不能代替你們做出回答，但是這個問題擺在我們面前，沒有辦法忽略。

    對基于服務器代碼來說還有另一個選擇，那就是把你網站的主機設在EC2上。這樣結果會比上面的方法好一些。EC2支持Windows服務器，你可以創建ASP.NET站點。（如果你不想用ASP.NET的話，你也可以在EC2上使用其它平臺和語言。）雖然這個方法比上面的方法好一些，但是你的服務器依舊需要連接上SimpleDB來進行資料處理。

    當然，還有另一種可能性就是轉向網絡2.0版，創建一個可以生成包涵JavaScript代碼網頁的網站；這些網頁可以利用AJAX連接上正確的網站。但這樣做的話，將會帶來很大的安全風險，因為你不會希望你的客戶的瀏覽器可以直接從你的SimpleDB域上讀寫資料吧。此外，在默認情況下瀏覽器甚至不允許JavaScript利用AJAX訪問那些擁有與主機不同URL域的網站。

    還有另一種選擇就是采用一種混合的辦法，你可以讓你的服務器先向SimpleDB服務器提出請求，然后再返回。

    如果你打算利用SimpleDB創建一個站點的話，上述問題都十分重要，需要好好思考。通常情況下，我認識大家一般會將他們的基于服務器的代碼放在EC2這個主機上，顯然Amazon也是這樣想的。如果你真的這樣做的話，在考慮安全問題的同時，你還要就你應該如何獲得這些數據以及利用瀏覽器可以干什么仔細權衡利弊。

    結論：一個特別的方法

    總的來說，SimpleDB對那些不需要進行關聯的資料來說是一個非常好的方法。但這種方法是不是適用于每一種場合呢？答案是不。最普遍的例子就是，已經完全規范化的客戶數據庫、產品數據庫和銷售數據庫將非常不適應這樣的情況，除非你先從客戶數據庫中找到每一個客戶的ID，再從銷售域中找到每一個客戶所購買產品的ID，然后再去產品域中找到那個客戶所購買的產品列表，***人工將它們關聯起來。這個工作量極大，但通過一個關系型數據庫，一個簡單的兩線或者三級SQL連接就可以輕松把這個工作完成。

    不管怎么樣，如果你只是需要能夠快速查找資料，并不需要把這些資料關聯起來的話（比如說讓產品表單符合一些既定的標準），SimpleDB將是你最好的選擇。【WatchStor獨家譯稿，未經許可禁止轉載。合作伙伴請注明原作者及出處為WatchStor.com】