使用 Azure) 建置Real-World雲端應用程式 (資料儲存體選項

作者 ：Rick Anderson、 Tom Dykstra

下載修正專案 或 下載電子書

使用 Azure 電子書建置真實世界雲端應用程式是以 Scott Guthrie 開發的簡報為基礎。 其說明 13 種模式和做法，可協助您成功開發雲端的 Web 應用程式。 如需電子書的相關資訊，請參閱 第一章。

大部人員都習慣使用關聯式資料庫，而在設計雲端應用程式時，他們會嘗試尋找其他資料儲存體選項。 結果可能是次佳效能、高費用或更糟，因為 NoSQL (非關聯式) 資料庫可以更有效率地處理某些工作。 當客戶要求我們協助解決重大資料儲存問題時，通常是因為其具有關系資料庫，其中一個 NoSQL 選項會更好。 在這些情況下，如果客戶在將應用程式部署至生產環境之前已實作 NoSQL 解決方案，則較好。

另一方面，假設 NoSQL 資料庫可以正常或足夠地執行一切作業也是錯誤的。 所有資料儲存工作沒有單一最佳資料管理選擇;不同的資料管理解決方案已針對不同的工作進行優化。 大部分真實世界的雲端應用程式都有各種不同的資料儲存需求，而且通常會由多個資料儲存解決方案的組合來提供最佳服務。

本章的目的是要讓您更廣泛地瞭解雲端應用程式可用的資料儲存體選項，以及有關如何選擇符合您案例的基本指引。 在開發應用程式之前，最好先留意可用的選項，並思考其優缺點。 在生產應用程式中變更資料儲存選項可能非常困難，例如在飛機進行飛行時必須變更 Jet 引擎。

Azure 上的資料儲存體選項

雲端可讓您更輕鬆地使用各種關聯式和 NoSQL 資料存放區。 以下是您可以在 Azure 中使用的一些資料儲存體平臺。

下表顯示四種類型的 NoSQL 資料庫：

• 索引鍵/值資料庫 會針對每個索引鍵值儲存單一序列化物件。 適合用來儲存大量資料，也就是您要在其中取得指定索引鍵值的一個項目，而且不必根據項目的其他屬性進行查詢。

  Azure Blob 儲存體 是金鑰/值資料庫，其運作方式類似雲端中的檔案儲存體，其索引鍵值對應至資料夾和檔案名。 您可以依檔案資料夾和檔案名擷取檔案，而不是藉由搜尋檔案內容中的值。

  Azure 資料表儲存體 也是索引鍵/值資料庫。 每個值都稱為類似資料列的 實體 (，資料分割索引鍵和資料列索引鍵) 識別，而且包含多個 屬性 (類似于資料行，但資料表中的所有實體都不需要共用相同的資料行) 。 查詢索引鍵以外的資料行非常沒有效率，因此應該避免。 例如，您可以使用一個資料分割來儲存使用者設定檔資料，以儲存單一使用者的相關資訊。 您可以將使用者名稱、密碼雜湊、生日等資料儲存在一個實體的個別屬性中，或儲存在相同分割區中的個別實體中。 但您不想查詢具有指定日期範圍的所有使用者，也無法在設定檔資料表與另一個資料表之間執行聯結查詢。 資料表儲存體比關係資料庫更可調整且成本較低，但無法啟用複雜的查詢或聯結。

• Documentdatabase 是 索引鍵/值資料庫，其值為 檔。 此處的「檔」不用於Word或 Excel 檔的意義，但表示具名欄位和值的集合，其中任何一個都可以是子檔。 例如，在訂單歷程記錄資料表中，訂單檔可能有訂單號碼、訂單日期和客戶欄位;和客戶欄位可能有名稱和位址欄位。 資料庫會以 XML、YAML、JSON 或 BSON 等格式來編碼欄位資料;或可以使用純文字。 除了索引鍵/值資料庫之外，設定檔資料庫的功能，就是能夠查詢停用字詞段，並定義次要索引，讓查詢更有效率。 這項功能可讓檔資料庫更適合需要根據準則擷取資料的應用程式，比檔索引鍵的值更複雜。 例如，在銷售訂單歷程記錄檔資料庫中，您可以查詢各種欄位，例如產品識別碼、客戶識別碼、客戶名稱等等。 MongoDB 是熱門的檔資料庫。

• 資料行系列資料庫 是索引鍵/值資料存放區，可讓您將資料儲存結構成稱為資料行系列的相關資料行集合。 例如，人口普查資料庫可能會有一組資料行，其中一個資料行 (第一個、中間、最後一個) 、一個群組用於人員的位址，另一個群組用於人員設定檔資訊 (DOB、性別等。) 。 然後，資料庫可以將每個資料行系列儲存在個別的資料分割中，同時保留與相同索引鍵相關的一個人的所有資料。 然後，您可以讀取所有設定檔資訊，而不需要讀取所有名稱和位址資訊。 Cassandra 是熱門的資料行系列資料庫。

• 圖形資料庫 會將資訊儲存為物件和關聯性的集合。 圖形資料庫的目的是讓應用程式有效率地執行查詢，以周遊物件網路及其之間的關聯性。 例如，物件可能是人力資源資料庫中的員工，而您可能想要協助查詢，例如「尋找直接或間接為 Scott 工作的所有員工」。 Neo4j 是熱門的圖形資料庫。

相較于關係資料庫，NoSQL 選項為非結構化資料的儲存和分析提供更大的延展性和成本效益。 取捨是它們不會提供關係資料庫豐富的查詢性和健全的資料完整性功能。 NoSQL 適用于 IIS 記錄資料，這牽涉到大量，而不需要聯結查詢。 NoSQL 不適用於銀行交易，這需要絕對資料完整性，而且牽涉到許多其他帳戶相關資料的關聯性。

此外，還有稱為 NewSQL 的新資料庫平臺類別，可將 NoSQL 資料庫的延展性與關係資料庫的可查詢性和交易完整性結合在一起。 NewSQL 資料庫是專為分散式儲存體和查詢處理所設計，這通常很難在 「OldSQL」 資料庫中實作。 NuoDB 是可在 Azure 上使用的 NewSQL 資料庫範例。

Hadoop 和 MapReduce

您可以儲存在 NoSQL 資料庫中的大量資料，可能難以及時有效地分析。 若要這樣做，您可以使用 Hadoop 之類的架構來實作 MapReduce 功能。 基本上，MapReduce 程式會執行下列動作：

• 選取資料存放區，只限制您實際需要分析的資料，以限制需要處理的資料大小。 例如，您想要知道使用者基底的生日年數，因此您只選取使用者設定檔資料存放區中的生日。
• 將資料分解成元件，並將其傳送至不同的電腦進行處理。 電腦 A 會計算 1950-1959 日期、電腦 B 執行 1960-1969 等等的人員數目。這組電腦稱為 Hadoop 叢集。
• 完成元件上的處理之後，將每個元件的結果放回一起。 您現在有一份相對簡短的清單，說明每個生日有多少人，而且計算此整體清單中的百分比工作是可管理的。

在 Azure 上， HDInsight 可讓您使用 Hadoop 的強大功能，處理、分析和取得巨量資料的新見解。 例如，您可以使用它來分析網頁伺服器記錄：

• 啟用 Web 服務器記錄至儲存體帳戶。 這會將 Azure 設定為將記錄寫入 Blob 服務，以取得應用程式的每個 HTTP 要求。 Blob 服務基本上是雲端檔案儲存體，而且它與 HDInsight 完美整合。

  

• 當應用程式取得流量時，Web 服務器 IIS 記錄會寫入 Blob 儲存體。

  

• 在入口網站中，按一下 [新增 - 資料服務 - HDInsight - 快速建立]，然後指定 HDInsight 叢集名稱、叢集大小 (HDInsight 叢集資料節點數目) ，以及 HDInsight 叢集的使用者名稱和密碼。

  

您現在可以設定 MapReduce 作業來分析記錄，並取得下列問題的解答：

• 我的應用程式在一天中的哪些時間會取得最多或最少的流量？
• 我的流量來自哪個國家/地區？
• 我流量來自之區域的平均鄰近地區收入為何。 (有一個公用資料集可讓您依 IP 位址提供鄰近收入，而且您可以比對網頁伺服器記錄中的 IP 位址。)
• 鄰近地區收入如何與網站中的特定頁面或產品相互關聯？

接著，您可以使用這類問題的答案，根據客戶有興趣或可能購買特定產品的可能性，以廣告為目標。

如 自動化所有專案一章所述，您可以在入口網站中執行的大部分函式都可以自動化，包括設定和執行 HDInsight 分析作業。 典型的 HDInsight 腳本可能包含下列步驟：

• 布建 HDInsight 叢集，並將其連結至儲存體帳戶以進行 Blob 儲存體輸入。
• 將 MapReduce 作業可執行檔上傳至 HDInsight 叢集 (.jar 或) .exe檔案。
• 提交 MapReduce，將輸出資料儲存至 Blob 儲存體。
• 請等待工作完成。
• 刪除 HDInsight 叢集。
• 存取 Blob 儲存體的輸出。

藉由執行所有動作的腳本，您可以將布建 HDInsight 叢集的時間量降到最低，以將成本降到最低。

平臺即服務 (PaaS) 與基礎結構即服務 (IaaS)

先前列出的資料儲存體選項包括平臺即服務 (PaaS) 和基礎結構即服務 (IaaS) 解決方案。 PaaS 表示我們管理硬體和軟體基礎結構，而您只需要使用服務即可。 SQL Database是 Azure 的 PaaS 功能。 您會要求資料庫，並在幕後設定和設定 VM，並在其上設定資料庫。 您沒有 VM 的直接存取權，而且不需要加以管理。IaaS 表示您設定、設定及管理在資料中心基礎結構中執行的 VM，並放置任何您想要的 VM。 我們提供預先設定 VM 映射的資源庫，以供一般 VM 組態使用。 例如，您可以安裝 Windows Server 2008、Windows Server 2012、BizTalk Server、Oracle WebLogic Server、Oracle Database 等預先設定的 VM 映射。

Azure 供應專案的 PaaS 資料解決方案包括：

• Azure SQL Database (先前稱為 SQL Azure) 。 以SQL Server為基礎的雲端關係資料庫。
• Azure 資料表儲存體。 索引鍵/值 NoSQL 資料庫。
• Azure Blob 儲存體。 雲端中的檔案儲存體。

針對 IaaS，您可以執行可載入至 VM 的任何專案，例如：

• 關係資料庫，例如SQL Server、Oracle、MySQL、SQL Compact、SQLite 或 Postgres。
• 索引鍵/值資料存放區，例如 Memcached、Redis、Cassandra 和 Riak。
• 資料行資料存放區，例如 HBase。
• 檔資料庫，例如 MongoDB、RavenDB 和 CouchDB。
• 圖形資料庫，例如 Neo4j。

IaaS 選項提供您幾乎無限制的資料儲存體選項，而且其中許多選項特別容易使用，因為您可以使用預先設定的映射來建立 VM。 例如，在管理入口網站中，移至[虛擬機器]，按一下 [映射] 索引標籤，然後按一下 [流覽 VM Depot]。

接著您會看到 數百個預先設定的 VM 映射清單，而且您可以從預先安裝資料庫管理系統的映射建立 VM，例如 MongoDB、Neo4J、Redis、Cassandra 或 CouchDB：

Azure 可讓 IaaS 資料儲存體選項盡可能容易使用，但 PaaS 供應專案有許多優點，可讓它們在許多案例中更具成本效益且實用：

• 您不需要建立 VM，只需使用入口網站或腳本來設定資料存放區。 如果您想要 200 TB 的資料存放區，您可以按一下按鈕或執行命令，並在幾秒內可供您使用。
• 您不需要管理或修補服務所使用的 VM;Microsoft 會自動為您執行此動作。 您不需要擔心設定基礎結構來調整或高可用性;Microsoft 會為您處理所有專案。
• 您不需要購買授權;授權費用包含在服務費用中。
• 您只需依據使用量付費。

Azure 中的 PaaS 資料儲存體選項包含協力廠商提供者的供應專案。

選擇資料儲存選項

並非所有案例都適合使用任何方法。 如果有人說這項技術是答案，第一件事就是「問題是什麼？」，因為不同的解決方案已針對不同的專案優化。 關聯式模型有明確的優點;這就是為什麼一直都是這麼久的時間。 但也有 SQL 的缺點，可透過 NoSQL 解決方案來處理。

我們通常會看到最佳作法是組合方法，您可以在單一解決方案中使用 SQL 和 NoSQL。 即使人們說他們採用 NoSQL，如果您深入探討他們執行的動作，通常會發現他們使用的是數個不同的 NoSQL 架構：他們使用的是 CouchDB和 Redis， 而 Riak 用於不同的專案。 即使是大量使用 NoSQL 的 Facebook，也會針對服務的不同部分使用不同的 NoSQL 架構。 混合和比對資料儲存方法的彈性是雲端的其中一個好事，因為很容易使用多個資料解決方案，並將其整合到單一應用程式中。

以下是當您選擇方法時要思考的一些問題：

資料語意	- 您儲存關聯式或非結構化資料) 的核心資料儲存和資料存取語意 (為何？ 非結構化資料，例如媒體檔案最適合在 Blob 儲存體中;相關資料的集合，例如產品、庫存、供應商、客戶訂單等，最適合在關係資料庫中。
查詢支援	- 查詢資料有多簡單？ - 可以有效率地詢問哪些類型的問題？ 索引鍵/值資料存放區非常適合取得具有索引鍵值的單一資料列，但不適用於複雜的查詢。 針對您一律取得特定使用者的使用者設定檔資料存放區，索引鍵/值資料存放區可以正常運作;針對您想要根據關係資料庫的各種產品屬性取得不同群組的產品類別目錄，可能會更好。 NoSQL 資料庫可以有效率地儲存大量資料，但您必須以應用程式查詢資料的方式來建構資料庫，這讓臨機操作查詢更難執行。 透過關系資料庫，您幾乎可以建置任何類型的查詢。
功能投影	- 是否可以執行伺服器端的問題、匯總等？ 如果我從 SQL 中的資料表執行 SELECT COUNT (*) ，它會非常有效率地在伺服器上執行所有工作，並傳回我正在尋找的數位。 如果我想要從不支援匯總的 NoSQL 資料存放區進行相同的計算，這是沒有效率的「未系結查詢」，而且可能會逾時。即使查詢成功，我仍必須從伺服器擷取所有資料，並計算用戶端上的資料列。 - 可以使用哪些語言或類型的運算式？ 透過關系資料庫，我可以使用 SQL。 使用一些 NoSQL 資料庫，例如 Azure 資料表儲存體，我將會使用 OData，而我所做的一切都是篩選主鍵，並取得投影 (選取可用欄位的子集) 。
簡化延展性	- 資料需要調整的頻率和多少？ - 平臺是否以原生方式實作向外延展？ - 新增/移除容量 (大小和輸送量) 有多簡單？ 關係資料庫和資料表不會自動分割，使其可調整，因此難以調整超過特定限制。 NoSQL 資料存放區，例如 Azure 資料表儲存體原本會分割所有專案，而且幾乎沒有新增分割區的限制。 您可以將資料表儲存體調整為 200 TB，但資料庫大小上限為 500 GB，Azure SQL資料庫的大小上限為 500 GB。 您可以將關聯式資料分割成多個資料庫來調整關聯式資料，但設定應用程式以支援該模型牽涉到許多程式設計工作。
檢測與管理性	- 平臺檢測、監視和管理有多簡單？ 您必須持續瞭解資料存放區的健康情況和效能，因此您必須預先知道平臺提供哪些計量可供免費使用，以及您必須自行開發的專案。
Operations	- 在 Azure 上部署和執行的平臺有多簡單？ Paas？ Iaas？ Linux？ 資料表儲存體和SQL Database很容易在 Azure 上設定。 不是內建 Azure PaaS 解決方案的平臺需要更多心力。
API 支援	- 是否有 API 可供輕鬆使用平臺？ 針對 Azure 資料表服務，有一個 SDK 具有支援 .NET 4.5 非同步程式設計模型的 .NET API。 如果您要撰寫 .NET 應用程式，相較于沒有 API 或較不完整的應用程式的另一個索引鍵/值資料行資料存放區平臺，撰寫及測試 Azure 資料表服務的程式碼會比較容易。
交易完整性和資料一致性	- 平臺是否必須支援交易，以確保資料一致性？ 為了追蹤傳送的大量電子郵件，效能和低資料儲存成本可能比資料平臺中交易或參考完整性的自動支援更為重要，讓 Azure 資料表服務成為不錯的選擇。 針對追蹤銀行帳戶餘額或採購單，提供強式交易保證的關係資料庫平臺會是較佳的選擇。
業務持續性	- 備份、還原和災害復原有多簡單？ 生產資料即將損毀，而且您需要復原函式。 關係資料庫通常具有更精細的還原功能，例如還原到某個時間點的能力。 瞭解您考慮的每個平臺都有可用的還原功能，是需要考慮的重要因素。
成本	- 如果多個平臺可以支援您的資料工作負載，它們如何比較成本？ 例如，如果您使用 ASP.NET 身分識別，您可以將使用者設定檔資料儲存在 Azure 資料表服務或Azure SQL資料庫中。 如果您不需要SQL Database的豐富查詢功能，您可能會選擇 Azure 資料表，因為其成本會比指定的儲存體量少很多。

我們通常建議先知道每個類別中問題的答案，再選擇您的資料儲存體解決方案。

此外，您的工作負載可能會有特定需求，某些平臺可支援比其他平臺更好的需求。 例如：

• 您的應用程式是否需要稽核功能？
• 您的資料需求為何 -- 您需要自動化封存或清除功能嗎？
• 您有特殊安全性需求嗎？ 例如，資料包括 PII (個人識別資訊) ，但您必須確定 PII 已從查詢結果中排除。
• 如果您有一些因為法規或技術原因而無法儲存在雲端的資料，您可能需要雲端資料儲存平臺，以利與內部部署儲存體整合。

示範 – 在 Azure 中使用SQL Database

Fix It 應用程式會使用關係資料庫來儲存工作。 自動化所有專案一章中顯示的環境建立Windows PowerShell腳本會建立兩個SQL Database實例。 按一下 [ SQL Database ] 索引標籤，即可在入口網站中看到這些專案。

使用入口網站建立資料庫也很容易。

按一下[新增] -- Data Services -- SQL Database -- Quick Create，輸入資料庫名稱，選擇帳戶中已經有的伺服器或建立新的伺服器，然後按一下 [建立SQL Database]。

等候數秒，且您已準備好在 Azure 中使用資料庫。

因此，Azure 會在幾秒內執行，這可能需要一天或一周或更長的時間才能在內部部署環境中完成。 而且，由於您可以輕鬆地在腳本中或使用管理 API 自動建立資料庫，因此只要您的應用程式已針對此專案進行程式設計，就可以透過將資料分散到多個資料庫來動態相應放大。

這是平臺即服務模型的範例。 您不需要管理伺服器，我們會這麼做。 您不需要擔心備份，我們會這麼做。 它在高可用性中執行 – 資料庫中的資料會自動複寫到三部伺服器。 如果電腦故障，我們會自動容錯移轉，而且您不會遺失任何資料。 伺服器會定期修補，您不需要擔心。

按一下按鈕，即可取得所需的確切連接字串，並可立即開始使用新的資料庫。

儀表板會顯示所使用的連線歷程記錄和儲存體數量。

您可以在入口網站中管理資料庫，或使用您已熟悉的SQL Server工具，包括SQL Server Management Studio (SSMS) 和 Visual Studio 工具SQL Server 物件總管 (SSOX) 和伺服器總管。

另一個好事是定價模式。 您可以使用免費的 20 MB 資料庫開始開發，而實際執行資料庫從每月大約 $5 開始。 您只需支付實際儲存在資料庫中的資料量，而不是容量上限。 您不需要購買授權。

SQL Database很容易調整。 針對修正 It 應用程式，我們在自動化腳本中建立的資料庫上限為 1 gig。 如果您想要將它相應增加至 150 gig，您可以直接進入入口網站並變更該設定，或執行 REST API 命令，並在幾秒內有 150 gig 資料庫，您可以將資料部署至其中。

這是雲端的威力，可快速且輕鬆地建置基礎結構，並立即開始使用。

修正 It 應用程式使用兩個 SQL 資料庫，一個用於成員資格 (驗證和授權) ，另一個用於資料，而您只需要進行布建並調整它。 您先前已瞭解如何透過Windows PowerShell腳本布建資料庫，現在也已瞭解如何在入口網站中執行。

使用 ADO.NET 的 Entity Framework 與直接資料庫存取

修正 It 應用程式會使用 Entity Framework 存取這些資料庫，Microsoft 建議的 ORM (.NET 應用程式的物件關聯式對應程式) 。 ORM 是一項絕佳的工具，可協助開發人員提高生產力，但在某些情況下，生產力會犧牲效能降低。 在真實世界的雲端應用程式中，您將不會選擇使用 EF 或使用直接 ADO.NET -- 您將同時使用這兩者。 當您撰寫可與資料庫搭配運作的程式碼時，取得最大效能並不重要，而且您可以利用使用 Entity Framework 取得的簡化程式碼和測試。 在 EF 額外負荷會造成無法接受的效能的情況下，您可以藉由呼叫預存程式，使用 ADO.NET 撰寫和執行自己的查詢。

無論您使用何種方法來存取資料庫，都想要盡可能減少「聊天」。 換句話說，如果您可以取得一個較大查詢結果集中所需的所有資料，而不是數十個或數百個較小的結果集，這通常是較佳的。 例如，如果您需要列出學生及其註冊的課程，通常最好是取得一個聯結查詢中的所有資料，而不是在一個查詢中取得學生，並針對每個學生的課程執行個別查詢。

修正 It 應用程式中的 SQL 資料庫和 Entity Framework

在 [修正 It] 應用程式中， FixItContext 衍生自 Entity Framework DbContext 類別的 類別會識別資料庫，並指定資料庫中的資料表。 內容會指定工作 (資料表) 的實體集，而程式碼會傳入連接字串名稱的內容。 該名稱是指Web.config檔案中定義的連接字串。

public class MyFixItContext : DbContext
{
    public MyFixItContext()
        : base("name=appdb")
    {
    }

    public DbSet<MyFixIt.Persistence.FixItTask> FixItTasks { get; set; }
}

Web.config檔案中的連接字串名為 appdb， (此處指向本機開發資料庫) ：

<connectionStrings>
    <add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;Initial Catalog=aspnet-MyFixIt-20130604091232_4;Integrated Security=True" providerName="System.Data.SqlClient" />
    <add name="appdb" connectionString="Data Source=(localdb)\v11.0; Initial Catalog=MyFixItContext-20130604091609_11;Integrated Security=True; MultipleActiveResultSets=True" providerName="System.Data.SqlClient" />
  </connectionStrings>

Entity Framework 會根據實體類別中包含的 FixItTask 屬性建立FixItTasks資料表。 這是簡單的 POCO (Plain Old CLR Object) 類別，這表示它不會繼承自 Entity Framework 或具有任何相依性。 但是 Entity Framework 知道如何根據其建立資料表，並執行 CRUD (create-read-update-delete) 作業。

public class FixItTask
{
    public int FixItTaskId  { get; set; }
    public string CreatedBy { get; set; }
    [Required]
    public string Owner     { get; set; }
    [Required]
    public string Title     { get; set; }
    public string Notes     { get; set; }
    public string PhotoUrl  { get; set; }
    public bool IsDone      { get; set; } 
}

修正 It 應用程式包含存放庫介面，用於處理資料存放區的 CRUD 作業。

public interface IFixItTaskRepository
{
    Task<List<FixItTask>> FindOpenTasksByOwnerAsync(string userName);
    Task<List<FixItTask>> FindTasksByCreatorAsync(string userName); 

    Task<MyFixIt.Persistence.FixItTask> FindTaskByIdAsync(int id);

    Task CreateAsync(FixItTask taskToAdd);
    Task UpdateAsync(FixItTask taskToSave);
    Task DeleteAsync(int id);
}

請注意，存放庫方法都是非同步，因此所有資料存取都可以以完全非同步方式完成。

存放庫實作會呼叫 Entity Framework 非同步方法來處理資料，包括 LINQ 查詢，以及插入、更新和刪除作業。 以下是用來查閱修正 It 工作的程式碼範例。

public async Task<FixItTask> FindTaskByIdAsync(int id)
{
    FixItTask fixItTask = null;
    Stopwatch timespan = Stopwatch.StartNew();

    try
    {
        fixItTask = await db.FixItTasks.FindAsync(id);
        
        timespan.Stop();
        log.TraceApi("SQL Database", "FixItTaskRepository.FindTaskByIdAsync", timespan.Elapsed, "id={0}", id);
    }
    catch(Exception e)
    {
        log.Error(e, "Error in FixItTaskRepository.FindTaskByIdAsynx(id={0})", id);
    }

    return fixItTask;
}

您也會注意到這裡還有一些計時和錯誤記錄程式碼，我們將在 稍後的監視和遙測一章中查看。

在 Azure 中的 VM (IaaS) 中選擇 SQL Database (PaaS) 與 SQL Server

SQL Server和Azure SQL Database 是兩者的核心程式設計模型完全相同。 您可以在這兩個環境中使用大部分相同的技能。 您甚至可以在開發和雲端中使用SQL Server資料庫，以及雲端中的SQL Database實例，也就是修正 It 應用程式設定的方式。

或者，您可以在雲端中執行與內部部署相同的SQL Server，方法是將它安裝在 IaaS VM 上。 對於某些繼承應用程式，在 VM 中執行SQL Server可能是較佳的解決方案。 因為SQL Server資料庫是在專用 VM 上執行，所以其資源比在共用伺服器上執行的SQL Database資料庫更多。 這表示SQL Server資料庫可能較大，但仍能正常執行。 一般而言，資料庫大小和資料表大小越小，使用案例越適合SQL Database (PaaS) 。

以下是有關如何在兩個模型之間進行選擇的一些指導方針。

Azure SQL Database (PaaS)	虛擬機器中的 SQL Server (IaaS)
專業人員 - 您不需要建立或管理 VM、更新或修補 OS 或 SQL;Azure 會為您執行此工作。 - 內建高可用性，具有資料庫層級 SLA。 - TCO) (擁有權總成本低，因為您只需支付使用 (不需要授權) 的費用。 - 適用于處理大量較小的資料庫， < (=500 GB，每個) 。 - 輕鬆動態建立新的資料庫以啟用向外延展。	優點- 與內部部署SQL Server的功能相容。 - 可以使用 VM 層級 SLA，透過 2 個以上 VM 中的AlwaysOn實作SQL Server高可用性。 - 您可以完全控制 SQL 的管理方式。 - 可以重複使用您已經擁有的 SQL 授權，或按一小時付費。 - 適用于處理較少但較大的 (1 TB+) 資料庫。
缺點- 相較于內部部署SQL Server (缺少CLR 整合、TDE、壓縮支援、) SQL Server Reporting Services等，某些功能差距 - 資料庫大小限制 500GB。	缺點- 更新/修補程式 (OS 和 SQL) 是您的責任 - 建立和管理 DB 是您的責任 - 每秒的磁片 IOPS (輸入/輸出作業) 限制為大約 8000 (到 16 個數據磁片磁碟機) 。

如果您想要在 VM 中使用SQL Server，可以使用自己的SQL Server授權，也可以按小時付費。 例如，在入口網站或透過 REST API，您可以使用SQL Server映射來建立新的 VM。

當您建立具有SQL Server映射的 VM 時，我們會根據您的 VM 使用量，依小時將SQL Server授權成本按比例計算。 如果您有一個專案只會執行數個月，則按小時付費會比較便宜。 如果您認為您的專案會持續數年，則以平常的方式購買授權會比較便宜。

摘要

雲端運算讓混搭資料儲存的方法更加實用，以符合您應用程式的需求。 如果您要建置新的應用程式，請仔細考慮這裡所列的問題，以挑選在應用程式成長時繼續正常運作的方法。 下一章將說明一些可用來合併多個資料儲存方法的資料分割策略。

資源

如需詳細資訊，請參閱下列資源。

選擇資料庫平臺：

• Highly-Scalable解決方案的資料存取：使用 SQL、NoSQL 和 Polyglot 持續性。 Microsoft 模式和實務所撰寫的電子書，深入探討雲端應用程式可用的不同資料存放區類型。
• Microsoft 模式和做法 - Azure 指引。 請參閱資料一致性入門、資料複寫和同步處理指引、索引資料表模式、具體化檢視模式。
• 基底：Acid 替代專案。 關於資料一致性與延展性之間取捨的文章。
• 七周中的七個資料庫：新式資料庫和 NoSQL 移動指南。 作者：Eric Redmond 和 Jim R. Wilson。 強烈建議您自行介紹目前可用的資料儲存平臺範圍。

在SQL Server與SQL Database之間選擇：

• 適用于SQL Database指引的進階預覽版。 SQL Database Premium 的簡介，以及何時可透過 SQL Database Web 和 Business 版本來選擇。
• (Azure SQL資料庫) 的指導方針和限制。 連結至SQL Database限制檔的連結入口網站頁面，包括著重于SQL Database不支援的SQL Server功能。
• Azure 虛擬機器中的SQL Server。 連結至在 Azure 中執行SQL Server檔的連結入口網站頁面。
• Scott Guthrie 說明 Azure 中的 SQL Database。 Scott Guthrie SQL Database的 6 分鐘影片簡介。
• Azure 虛擬機器中SQL Server的應用程式模式和開發策略。

在 ASP.NET Web 應用程式中使用 Entity Framework 和 SQL Database

• 使用 MVC 5 搭配 EF 6 消費者入門。 九部分教學課程系列會逐步引導您建置使用 EF 的 MVC 應用程式，並將資料庫部署至 Azure 和SQL Database。
• 使用 Visual Studio ASP.NET Web 部署。 十二部分教學課程系列，深入瞭解如何使用 EF Code First 部署資料庫。
• 將具有成員資格、OAuth 和SQL Database的安全 ASP.NET MVC 5 應用程式部署至 Azure 網站。 逐步教學課程會逐步引導您建立使用驗證的 Web 應用程式、將應用程式資料表儲存在成員資格資料庫中、修改資料庫架構，以及將應用程式部署至 Azure。
• ASP.NET 資料存取內容對應。 使用 EF 和SQL Database的資源連結。

在 Azure 上使用 MongoDB：

• Azure 上的 MongoDB Atlas。 入口網站頁面，以取得在 Azure 上執行 MongoDB Atlas 的相關檔。
• 建立 Azure 網站，以連線到在 Azure 中虛擬機器上執行的 MongoDB。 示範如何在 ASP.NET Web 應用程式中使用 MongoDB 資料庫的逐步教學課程。

Azure 上的 HDInsight (Hadoop) ：

• HDInsight。 Azure網站上的入口網站至 HDInsight 檔。
• Hadoop 和 HDInsight：Azure 中的巨量資料。 在 Azure 上引進 Hadoop 的 MsDN Magazine 文章，作者為一篇，由一位在 Azure 上介紹 Hadoop 的 Terkaly 和 Ricardo Linuxlobos。
• Microsoft 模式和做法 - Azure 指引。 請參閱 MapReduce 模式。

上一個下一個