共用方式為

使用 Azure) 建置 Real-World Cloud Apps 的資料分割策略 (

  • 發行項

作者： Rick Anderson、 Tom Dykstra

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

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

我們稍早已瞭解如何新增和移除 Web 服務器，以調整雲端應用程式的 Web 層。 但如果它們全都達到相同的資料存放區，則應用程式的瓶頸會從前端移至後端，而資料層最難以調整。 在本章中，我們將探討如何將資料分割成多個關係資料庫，或結合關係資料庫儲存體與其他資料儲存體選項，來調整資料層。

設定資料分割配置最好事先完成，原因與先前所述的相同原因：在應用程式處於生產環境中之後，很難變更您的資料儲存策略。 如果您難以預先考慮不同的方法，當您的應用程式當機或停止運作一段時間時，您可以避免在重新組織應用程式的資料和資料存取碼時發生「Twitter 時間」。

三個數據儲存體的 Vs

若要判斷您是否需要資料分割策略及其應該是什麼，請考慮三個關於資料的問題：

  • 磁片區 – 您最終會儲存多少資料？ 幾 GB？ 數百 GB？ Tb？ PB？
  • 速度 – 您的資料成長率為何？ 這是未產生大量資料的內部應用程式嗎？ 客戶將上傳影像和影片的外部應用程式？
  • 不同 – 您將儲存哪些類型的資料？ 關聯式、影像、索引鍵/值組、社交圖表？

如果您認為要有大量的磁片區、速度或多樣性，您必須仔細考慮哪種分割配置最適合讓您的 app 在成長時有效率且有效率地調整，並確保不會遇到任何瓶頸。

資料分割基本上有三種方法：

  • 垂直資料分割
  • 水平資料分割
  • 混合式資料分割

垂直資料分割

垂直部分就像依資料行分割資料表：一組資料行進入一個資料存放區，另一組資料行會進入不同的資料存放區。

例如，假設我的應用程式會儲存人員的相關資料，包括影像：

資料表

當您將此資料表示為數據表並查看不同種類的資料時，您可以看到左側的三個數據行具有可有效率地由關係資料庫儲存的字串資料，而右邊的兩個數據行基本上是來自影像檔案的位元組陣列。 將影像檔資料儲存在關係資料庫中，而且許多人可能這麼做，因為它們不想將資料儲存至檔案系統。 它們可能沒有檔案系統能夠儲存所需的資料磁片區，或可能不想管理個別的備份和還原系統。 此方法適用于內部部署資料庫和雲端資料庫中的少量資料。 在內部部署環境中，只讓 DBA 負責處理所有專案可能會比較容易。

但在雲端資料庫中，儲存體相對昂貴，而且大量的映射可能會使資料庫的大小成長超過其有效率運作的限制。 您可以垂直分割資料來解決這些問題，這表示您為數據表中的每個資料行選擇最適當的資料存放區。 此範例可能最適合的是將字串資料放在關係資料庫中，並將影像放在 Blob 儲存體中。

垂直分割的資料表

將映射儲存在 Blob 儲存體而非資料庫比在內部部署環境中更實用，因為您不需要擔心設定檔案伺服器或管理儲存在關係資料庫外部之資料的備份和還原：Blob 儲存體服務會自動為您處理的所有作業。

這是我們在修正 It 應用程式中實作的資料分割方法，我們將查看 Blob 儲存體章節中的程式碼。 如果沒有此資料分割配置，而且假設平均映射大小為 3 MB，修正 It 應用程式就只能儲存大約 40，000 個工作，再達到資料庫大小上限 150 GB。 移除映射之後，資料庫可以儲存 10 倍的工作;您必須先考慮實作水準資料分割配置，才能更久。 隨著應用程式調整，您的費用會變慢，因為大部分的儲存體需求會進入非常便宜的 Blob 儲存體。

水平資料分割 (分區化)

水準部分就像依資料列分割資料表：一組資料列進入一個資料存放區，另一組資料列會進入不同的資料存放區。

假設有相同的資料集，另一個選項是將不同的客戶名稱範圍儲存在不同的資料庫中。

水準分割的資料表

您想要非常小心分區化配置，以確保資料平均分散，以避免作用點。 這個使用姓氏第一個字母的簡單範例不符合該需求，因為許多人都有以特定通用字母開頭的姓氏。 您早于預期會達到資料表大小限制，因為某些資料庫會變得非常大，但大部分的資料庫會維持在小。

水準資料分割的缺點是，可能很難跨所有資料執行查詢。 在此範例中，查詢必須從最多 26 個不同的資料庫繪製，以取得應用程式儲存的所有資料。

混合式資料分割

您可以結合垂直和水準資料分割。 例如，在範例資料中，您可以將影像儲存在 Blob 儲存體中，並水準分割字串資料。

已分割的資料表混合式資料表

分割生產應用程式

就概念上來說，您可以輕鬆地瞭解資料分割配置的運作方式，但任何資料分割配置都會增加程式碼複雜度，並引進許多您必須處理的新複雜度。 如果您要將映射移至 Blob 儲存體，當儲存體服務關閉時該怎麼辦？ 如何處理 Blob 安全性？ 如果資料庫和 Blob 儲存體不同步，會發生什麼事？ 如果您要進行分區化，您要如何處理所有資料庫的查詢？

只要您打算在進入生產環境之前進行規劃，即可管理複雜性。 許多不想要他們之後這麼做的人。 平均而言，我們的客戶諮詢小組 (CAT) 小組會從應用程式以真正大的方式離開的客戶，收到大約一個月的緊急電話，而且他們沒有進行此規劃。 他們說出如下的內容：「說明！ 我將所有專案放在單一資料存放區中，並在 45 天內用盡空間！」此外，如果您有許多商務邏輯內建于您存取資料存放區的方式，而且您有使用應用程式的客戶，則移轉時沒有好的時間可以關閉一天。 最後，我們經過了一段時間，協助客戶即時分割其資料，而不需要停機。 這是非常令人興奮且非常令人驚奇的，如果可以避免的話，就不想要參與！ 在前面思考這一點，並將其整合到您的應用程式中，如果應用程式稍後成長，您的生活會變得更容易。

總結

有效的資料分割配置可讓您的雲端應用程式在雲端中調整為數 PB 的資料，而不會有瓶頸。 而且，如果您已在內部部署資料中心執行應用程式，就不需要預付大量機器或廣泛的基礎結構。 在雲端中，您可以視需要以累加方式新增容量，而且您只需在使用時，就只需支付使用量的費用。

在下一章中，我們將瞭解如何將影像儲存在 Blob 儲存體中，修正 It 應用程式實作垂直分割。

資源

如需資料分割策略的詳細資訊，請參閱下列資源。

文件：

影片：

  • FailSafe：建置可調整、復原雲端服務。 Ulrich Homann、Marc Mercuri 和 Mark Simms 的九部分系列。 以非常無障礙且有趣的方式呈現高階概念和架構原則，其中包含來自 Microsoft Customer Advisory Team (CAT) 實際客戶經驗的故事。 請參閱第 7 集的資料分割討論。
  • 建置巨量：從 Windows Azure 客戶學到的課程 - 第 I 部分。Mark Simms 會討論分割配置、分區化策略、如何實作分區化，以及從 19：49 開始SQL Database同盟。 類似于 Failsafe 系列，但會深入探討更多操作說明詳細資料。

程式碼範例：

上一個下一個