Java開發2.0

Java開發2.0 - 使用Amazon SimpleDB進行雲端儲存，第1部分 - 開始使用SimpleDB和Amazon SDK

在整個系列中，我和您了分享大量非關係型資料存放區，統稱為 NoSQL。在一篇最近的文章中，我向您展示了一個面向文檔的資料存放區 （CouchDB）與面向模式的關係型資料庫的巨大區別。此外，CouchDB 的整個 API 是 REST 式的，且支援不同的查詢方式：JavaScript 中定義 的 MapReduce 功能。很顯然，這是對傳統 JDBC 的一個很大突破。

我最近還寫了 Google 的 Bigtable 相關內容，它不是一種關係型 或面向文檔的資料解決方案（且它偶爾不支援 JDBC）。Bigtable 就是 所謂的鍵 / 值儲存。也就是說，它是 無模式的，一般支援您儲存的任何內容，不管是一個停車罰單一實例、比賽列表還是比賽中的參賽者。 Bigtable 的無模式形式提供了大量靈活性，因而支援快速開發。

Bigtable 不是惟一可供我們選擇的鍵 / 值資料存放區。Amazon 有自己的雲端式的鍵 / 值儲存式 Amazon SimpleDB。Bigtable 是通過 Google App Engine 提供的一個抽象公開給 Java 開發人員的，而 Amazon SimpleDB 是通過 web 服務介面公開的。因此，您可以通過 web 和 HTTP 操作 SimpleDB 資料存放區。Amazon 的 Web Service 基礎設施之上的綁定使得我們可以自己選擇語言來使用 SimpleDB，包括 PHP、Ruby 、C# 和 Java 語言。

這個月，我將通過 Amazon 的官方 SDK 向您介紹 SimpleDB。我將使用另一個比賽相關樣本展示這個而強大的、雲端式的資料存放區更加不同 的一面：字典式搜尋。

SimpleDB 簡介

在底層，SimpleDB 是一個可大規模伸縮、用 Erlang 編寫的高可用資料存放區。從概念上講，它就像 Amazon 的 S3。但是 S3 有對象位於 bucket 中，而 SimpleDB 在邏輯上被定義為包含項目的域。SimpleDB 也允許項目包含屬性。將一個 域看作是 S3 中的一個 bucket 或關係意 義中的一個表（或更準確地講，Bigtable 的 “kind” 概念）。不過要注意，不要將關係性投射到 SimpleDB 的概念中，因為它最終會像 Bigtable 一樣無模式。域可以有多重專案（類似於行），且項目可以有多個屬性（類似於關係型表中的列）。

SimpleDB 的‘最終一致性’

CAP theorem表明，一個分布式系統不能同時高度可用、可伸縮並確保一致性；確實，一個分布式系統任何時候僅支援這三個特質中的兩種 。相應地，SimpleDB 可以確保一個高度可用、可伸縮的資料存放區，但不支援即時一致性。SimpleDB 支援的是 最終一致性，這並不像您想象的 那樣糟糕。

對於 Amazon 來說，最終一致性是指一切在 幾秒內在所有節點（不過在一個地區內）上都變得一致。在這一小段時間內，兩個並發進程可 能會讀取同一資料的兩個不同執行個體，而在此期間您換來的是大規模可靠性和一個實惠的價格。（您只需向提供類似可靠性的商業實體漫天要價 ，從而查看其區別。）

屬性是真正的名 / 值對（有點像 Bigtable，不是嗎？）且 “對” 並不局限於一個值。也就是說，一個屬性名稱可以有一個相關值集合（或 列表）；例如，一個詞項目可以有多重定義的屬性值。此外，SimpleDB 內的所有資料都以 String形式表示，這明顯不同於 Bigtable 或甚至 是一個 RDBMS，後者通常支援混合資料類型。

SimpleDB 的單資料類型屬性值方法有利有弊，這取決於您如何去看待它。不管是利是弊，它確實隱含著查詢的運行方式（不久將介紹更多 相關內容）。SimpleDB 也不支援跨域聯結的概念，因此您不能查詢多個域中的項目。不過，您可以通過執行多個 SimpleDB 並在您這一端執行 聯結來克服此局限。

項目 本身沒有主鍵（就像 Bigtable 一樣）。一個項目的主鍵或惟一標識符是項目的名稱。SimpleDB 非常智能，能夠在發出一個複本建立 請求時更新一個項目，只要該項目的屬性已被更改。

與其他 Amazon Web Services 一樣，SimpleDB 通過 HTTP 公開一切內容，因而有多種方式可與之互動。在 Java 中，我們的選項從 Amazon 自己的 SDK（我們會在接下來的例子中用到）到一個名為 Topica 的流行項目，甚至到成熟的 JPA 實現（我們將在第 2 部分探討）。