【正文】 并不是傳統(tǒng)意義上的關系數(shù)據(jù)庫，而是一個高可用的模式 （采用了最終一致性數(shù)據(jù)模型） ，是云中的非結構化數(shù)據(jù)存儲，可以使用它存儲和獲取包含鍵的值。每個 19 條目可以包含最多 256 個鍵 值對。SDB 當前還不支持垮域查詢。 與傳統(tǒng)的關系型數(shù)據(jù)庫相比， SDB 無需預定義模式，單個屬性允許多個值，支持自動索引， 維護比典型的數(shù)據(jù)庫簡單得多，因為不需要設置或配置任何東西。 Amazon 自動地為數(shù)據(jù)編制索引，可以在任何時候任何地方訪問索引。 然而 SDB 沒有事務（ Transaction）的概念，不支持連接（ join）操作，且返回的結果不支持排序操作。您可以把注意力放在更重要的方面。 AWS 服務的綜合使用如圖 8 所示。 Google App Engine 可讓您在 Google 的基礎架構上運行您的網絡 20 應用程序。使用 Google App Engine，將不再需要維護服務器：您只需上傳您的應用程序，它便可立即為您的用戶提供服務?；蛘?，您可以使用 域上的免費域名來為您的應用程序提供服務。 Google App Engine 支持以幾種編程語言編寫的應用程序。 App Engine 還提供一個專用的 Python 運行時環(huán)境，該環(huán)境包括一個快速 Python 解釋器和 Python 標準庫。 圖 9 Google App Engine 架構圖 21 在 App Engine 中，您只需為您使用的資源付費。您的應用程序使用的資源，如存儲空間和帶寬以千兆字節(jié)衡量，并以有競爭力的費率收費。 可以免費開始使用 App Engine。為您的應用程序啟用付費后，您的免費配額將提高，您只需為使用的超過免費水平的資源付費。 （ 1）應用程序環(huán)境 通過 Google App Engine，即使在負載很重和數(shù)據(jù)量極大的情況下，也可以輕松構建能安全運行的應用程序。各環(huán)境均為網絡應用程序開發(fā)提供標準協(xié)議和常用技術。在這個環(huán)境中，用戶可以開發(fā)使用自己的應用程序，沙盒將開發(fā)者開發(fā)的應用程序隔離在自身的安全可靠的環(huán)境中，該環(huán)境和網絡服務器的硬件、系統(tǒng)以及物理位置完全無關，并且沙盒僅提供開發(fā)人員對基礎操作系統(tǒng)的有限訪問權限。沙盒將您的應用程序隔離在它自己的安全可靠環(huán)境中，該環(huán)境與網絡服務器的硬件、操作系統(tǒng)和物理位置無關。其他計算機只能通過在標準端口上進行 HTTP（或 HTTPS）請求來連接至該應用程序。應用程序只能讀取通過應用程序代碼上傳的文件。 ? 應用程序代碼僅在 響應網絡請求或 cron job 時運行，且任何情況下必須在 30 秒鐘內返回響應數(shù)據(jù)。 （ 3） Java 運行時環(huán)境 可以使用常用 Java 網絡開發(fā)工具和 API 標準開發(fā)在 Java 運行時環(huán)境中運行的應用程序。 該環(huán)境包括 Java SE 運行時環(huán)境 (JRE) 6 平臺 和庫。只要應用程序不超過沙盒的限制，就可以使用任何 JVM 字節(jié)碼或庫功能。 您的應用程序使用 Java 標準 API 來訪 問大多數(shù) App Engine 服務。應用程序可使用 JavaMail API 通過 App Engine 郵件服務發(fā)送電子郵件。 App Engine 還包括低級 API 以使用其服務實現(xiàn)額外適配器或直接從應用程序使用。 通常， Java 開發(fā)人員使用 Java 編程語言和 API 來實現(xiàn) JVM 的網絡應用程序。 （ 4） Python 運行時環(huán)境 通過 App Engine 的 Python 運行時環(huán)境，您可以使用 Python 編程語言實現(xiàn)應用程序，并在優(yōu)化的 Python 解釋器上運行。您還可以利用針對 Python 網絡應用程序開發(fā)的多種成熟的庫和框架，例如 Django。將 在未來版本中考慮對于 Python 3 的額外支持。當然，不是該庫的所有功能都可以在沙盒環(huán)境中運行。 23 為方便起見，主要功能不受該運行時環(huán)境支持的標準庫中的多個模塊已被禁用，而導入這些模塊的代碼將引發(fā)錯誤。用 C 語言編寫的擴展不受支持 。 App Engine 還提供了一個稱為 webapp 的簡單 Python 網絡應用程序框架，從而可以輕松開始構建應用程序。 （ 5） 數(shù)據(jù)存儲區(qū) App Engine 提供了一個強大的分布式數(shù)據(jù)存儲服務，其中包含查詢引擎和事務功能。 該 App Engine 數(shù)據(jù)存儲區(qū)與傳統(tǒng)關系數(shù)據(jù)庫不同。查詢可以檢索按屬性值過濾和分類的指定種類的實體。 數(shù)據(jù)存儲區(qū)實體是 “無架構 ”的。 Java JDO/JPA 接口和 Python 數(shù)據(jù)存儲區(qū)接口包括用于在您的應用程序內應用和執(zhí)行結構的功能。 數(shù)據(jù)存儲區(qū)高度 一致 并使用 樂觀并發(fā)控制 。應用程序可以在一個事務中執(zhí)行多項數(shù)據(jù)存儲區(qū)操作（全部成功或者全部失敗，從而確保數(shù)據(jù)的完整性）。一個事務操作一個組內的實體。應用程序可以在實體創(chuàng)建時將實 體分配到組。應用程序使用戶可以通過 Google 帳戶登錄，并可以訪問與該帳戶關聯(lián)的電子郵件地址和可顯示的名稱。 Google 帳戶還省去只為您的應用程序實現(xiàn)用戶帳戶系統(tǒng)的麻煩。 用戶 API 還可告知應用程序當前用戶是否是應用程序的注冊管理員。 （ 7） App Engine 服務 App Engine 提供了多種服務，從而可讓您在管理應用程序的同時執(zhí)行常規(guī)操作。網址抓取服務使用檢索許多其他 Google 產品的網頁的高速 Google 基礎架構來檢索網絡資源。郵件服務使用 Google 基礎架構發(fā)送電子郵件。 Memcache 對于那些不需要數(shù)據(jù)存儲區(qū)的持久性存儲和事務功能的數(shù)據(jù)（例如臨時數(shù)據(jù)或從數(shù)據(jù)存儲區(qū)復制到緩存以進行高速訪問的數(shù)據(jù)）很有用。使用該 API，您可以對 JPEG 和 PNG 格式的圖像進行縮放、裁剪、旋轉和翻轉。 ? 數(shù)據(jù)庫 API： Google App Engine 的數(shù)據(jù)庫使用了簡單的 API 來為童虎提供查詢引擎和事務存儲服務，并且這些服務都運行在 Google 的可擴展結構上。 Google App 能夠 inede 數(shù)據(jù)庫 API 擁有一個用于定義數(shù)據(jù)模型的機制，用于描述試題類型。查詢結果一 Model 類的實例形式返回尸體，并且 Model嘞可以被修改并且放到數(shù)據(jù)庫中。 （ 8） 開發(fā)工作流 分別針對 Java 和 Python 的 App Engine 軟件開發(fā)工具包 (SDK) 包括可以 在您的本地計算機上模擬所有 App Engine 服務的網絡服務器應用程序。該網絡服務器還可以模擬安全沙 25 盒環(huán)境，包括檢查是否嘗試訪問在 App Engine 運行時環(huán)境下不允許的系統(tǒng)資源。創(chuàng)建了您的應用程序的代碼、靜態(tài)文件和配置文件后，即可運行該工具上傳數(shù)據(jù)。 構建已在 App Engine 上運行的應用程序的新發(fā)行版 時，可以將新發(fā)行版作為新版本上傳?？梢栽谂f版本仍運行的同時在 App Engine 上測試新版本。 SDK 以 Zip 文件提供。 SDK 還包括用于運行開發(fā)服務器和上傳應用程序的命令行工具。該 SDK 以 Zip 文件形式提供，對于 Windows 和 Mac OS X 還提供安裝程序。您可以使用它創(chuàng)建新應用程序、配置域名、更改您的應用程序當前的版本、檢查訪問權限和錯誤日志以及瀏覽應用程序數(shù)據(jù)存儲區(qū)。通過免費帳戶發(fā)布的應用程序可使用多達 500MB 的存儲空間和多達每月 500 萬次的頁面瀏覽量。 每個開發(fā)人員帳戶最多可注冊 10 個應用程序。配額決定應用程序在一個日歷天中可以使用的給定資源的量。 有些功能會施加與配額無關的限制，以保護系統(tǒng)的穩(wěn)定性。如果該應用程序花費的時間過長，則進程會被終止并且服務器將向用戶返回錯誤代碼。 26 服務限制的另一示例是查詢返回的結果數(shù)。本該返回更多結果的查詢只能返回該最大值。 試圖破壞或濫用配額（例如同時在多個帳戶上操作應用程序）違反 服務條款 ，并可能導致應用程序被禁用或帳戶 關閉。 Google Apps Google 企業(yè)應用套件有助于全面提升企業(yè)的運作效率。 ? Google Talk： 免費的全球文字通信和語音通話。 （ 2） 協(xié)作與發(fā)布 ? Google 文檔 ： 創(chuàng)建并共享文檔，實現(xiàn)實時協(xié)作。 ? 初始頁 ： 從同一位置訪問個人收件箱、日歷、文件和所需信息，并搜索網絡 ? Page Creator： 管理員可輕松創(chuàng)建并發(fā)布網頁。 ? API 延展 ： 與現(xiàn)有的 IT 系統(tǒng)或第三方解決方案集成。其中 GFS 提供了海量數(shù)據(jù)存儲和訪問的能力， MapReduce 使得海量信息的并行處理變得簡單易行， Chubby 保證了分布式環(huán)境下并發(fā)操作的同步問題， Bigtable使得海量數(shù)據(jù)的管理和組織十分方便。 GFS 使用廉價的商用機器構建分布式文件系統(tǒng)，將容錯任務交由文件系統(tǒng)來完成，利用軟件的方法解決系統(tǒng)可靠性問題，這樣可以使得存儲的成本成倍下降。 Client 是 GFS 提供給應用程序的訪問接口，一庫文件的形式提供。 Chunk Server 負責具體的存儲工作，它的數(shù)目直接決定了 GFS 的規(guī)模。這種設計實現(xiàn)了控制流和數(shù)據(jù)流的分離，降低了 Master 的負載。 圖 10 GFS 系統(tǒng)架構圖 GFS 的系統(tǒng)管理技術包括： ? 大規(guī)模集群安裝技術 ? 故障檢測技術 ? 節(jié)點動態(tài)加入技術 ? 節(jié)能技術 相對于傳統(tǒng) 的分布式文件系統(tǒng)， GFS 針對 Google 應用的特點多方面進行了簡化，從而在一定規(guī)模下達到成本、可靠性、性能的最佳平衡。 ? 采用中心服務器模式 中心服務器模式大大簡化了設計，降低了實現(xiàn)難度。但是中心服務器模型使得 Master 極易成為系統(tǒng)性能 和可靠性上的瓶頸。 GFS 文件系統(tǒng)將緩存的任務交給我本地文件系統(tǒng)，有本地文件系統(tǒng)實現(xiàn)緩存，減少了數(shù)據(jù)一致性的復雜度。 2) POSIX 接口提供的功能更為豐富，在實現(xiàn)過程中可以利用更多的特性，而不像內核變成那樣首先。 4) 用戶臺下， Master 和 Chunk Server 都以進程的方式運行，單個進程不會影響到整個操作系統(tǒng)，從而可以對其進行充分優(yōu)化。 5) 用戶臺下， GFS 和操作系統(tǒng)運行在不同的空間，兩者耦合性降低，從而方便 GFS 自身和內核的單獨升級。通常與 POSIX 兼容的借口需要在操作系統(tǒng)內核級實現(xiàn)，而 GFS 在應用層實現(xiàn)。 3) 專用接口直接和 Client、 Master、 Chunk Server 交互，減少了操作系統(tǒng)之間上下文的切換，降低了復雜度，提高了效率。與傳統(tǒng)的分布式程序設計相比， MapReduce 封裝了并行處理、容錯處理、本地化計算、負載均衡等細節(jié)，還提供了一個簡單而強大的接口，可以把大尺度的計算自動地并發(fā)和分布執(zhí)行。 MapeReduce操作 which 由 M 個 Map 操作和 R 各 Reduce 操作一起完成的。 MapReduce 操作的執(zhí)行流程如圖 11 所示。 GFS 使用 Chubby 來選取一個 GFS 主服務器， Bigtable 使用 Chubby 指定一個主服務器并發(fā)現(xiàn)、控制與其相關的字表服務器。 Chubby 系統(tǒng)本質上是一個分布式的、存儲大量小文件的文件系統(tǒng)，它所有的操作都是在文件的基礎上完成的， Chubby 的文件系統(tǒng)與 UNIX 類似。 30 支持粗粒度的簡易型鎖服務：建議性的粗粒度鎖服務在用戶訪問某個被鎖定的文件時不會阻止，且持有鎖的時間較長，減少頻繁換鎖帶來的系統(tǒng)開銷，提高了系統(tǒng)的性能。 ? 支持緩存機制： 通過一致性緩存將常用信息保存在客戶端，避免頻繁訪問主服務器。服務器端由五個副本構成一 Chubby 單元。 Chubby 31 的 基本架構如圖所示。通信過程如圖所示。 Bigtable 對存儲在其中的數(shù)據(jù)不做任何解析，一律看做字符串，具體數(shù)據(jù)結構的實現(xiàn)由用戶自行處理。 Bigtable 不支持一般意義上的事務，表中數(shù)據(jù)根據(jù)行關鍵字排序，使用詞典序；列關鍵字被組織成列族，族是 Bigtable 訪問控制的基本單元；不同版本的數(shù)據(jù)通過時間戳來區(qū)分。Bigtable 主要由三部分組成：客戶端程序庫（ Client Library）、一個主服務器（ Master 32 Server）和多個子表服務器（ Tablet Server）。 ? 主服務器 主服務器 主要進行元數(shù)據(jù)的操作以及子表服務器之間的負載調度問題，幾乎不與客戶端進行通信。子表服務器在初始化 時從 Chubby 得到一個獨占鎖，子表服務器基本信息以此保存在 Chubby 的服務器目錄中，主服務器通過檢測這個目錄獲取最新的子表服務器信息，并定期向子表服務器詢問獨占鎖的狀態(tài)。 SSTable 中的數(shù)據(jù)被劃分成塊（ Block），在 SSTable 的結尾有一個索引，保存 SStable 中塊的位置信息。子表由 SSTable 和日志構成，子表的地址為三層結構，如圖 16 所示 。數(shù)據(jù)壓縮氛圍此壓縮、合并壓縮、主壓縮三種壓縮形式。 圖 16 SSTable 地址結構 ? 性能優(yōu)化 1）局部性 群組 ： Bigtable 允許用戶將原本并不存儲在一起的數(shù)據(jù)以列族為單位，根據(jù)需要組織在一個單獨的 SSTable 中，以構成一個局部性群組。 2）壓縮 33 3）布隆過濾器 ：這是一個很