多租用戶 SaaS 資料庫租用模式
適用於： 
Azure SQL 資料庫
本文說明多租用戶 SaaS 應用程式可用的各種租用模型。
設計多租用戶 SaaS 應用程式時，您必須仔細選擇最適合您應用程式需求的租用模型。 租用模型會決定每個租用戶的資料如何對應至儲存體。 您選擇的租用模型會影響應用程式設計和管理。 後期切換至不同的模型有時成本高昂。
A. SaaS 概念和術語
在軟體即服務 (SaaS) 模型中，您的公司不會銷售軟體授權。 相反地，每位客戶都會向貴公司支付租金，讓每位客戶成為貴公司的租用戶。
支付租金之後，每個租用戶都可以獲得您 SaaS 應用程式元件的存取權，並將其資料儲存在 SaaS 系統中。
租用模型一詞是指租用戶儲存資料的組織方式：
- 單一租用：每個資料庫只會儲存一個租用戶的資料。
- 多重租用：每個資料庫都會儲存來自多個不同租用戶的資料 (具有保護資料隱私權的機制)。
- 也可以使用混合式租用模型。
B. 如何選擇適當的租用模型
一般而言，租用模型不會影響應用程式的功能，但可能會影響整體解決方案的其他層面。 下列準則可用來評定每個模型：
可擴縮性：
- 租用戶數目。
- 每個租用戶儲存體。
- 儲存體匯總。
- 工作負載。
租用戶隔離：資料隔離和效能 (一個租用戶的工作負載是否影響其他租用戶)。
每一租用戶成本：資料庫成本。
開發複雜度：
- 結構描述的變更。
- 查詢的變更 (模式所需)。
作業複雜度：
- 監視和管理效能。
- 結構描述管理。
- 還原租用戶。
- 災害復原。
可自訂性：輕鬆支援租用戶特定或租用戶類別特定的結構描述自訂。
租用討論著重於資料層。 但請考慮應用程式層的情形。 應用程式層會被視為整合型實體。 如果您將應用程式分成許多小型元件，則您選擇的租用模型可能會變更。 您可以針對租用和使用的儲存技術或平台，以不同的方式處理某些元件。
C. 具有單一租用戶資料庫的獨立單一租用戶應用程式
應用程式層級隔離
在此模型中，會針對每個租用戶重複安裝整個應用程式一次。 應用程式的每個執行個體都是獨立執行個體，因此它永遠不會與任何其他獨立執行個體互動。 應用程式的每個實例只有一個租用戶，因此只需要一個資料庫。 租用戶獨自完整擁有資料庫。
每個應用程式執行個體都會安裝在個別的 Azure 資源群組中。 軟體廠商或租用戶可能擁有擁有資源群組的訂用帳戶。 不論是哪一種情況，廠商都可以管理租用戶的軟體。 每個應用程式執行個體都會設定為連線到其對應的資料庫。
每個租用戶資料庫都會部署為單一資料庫。 此模型可提供最佳的資料庫隔離。 但是隔離需要配置足夠的資源給每個資料庫，以處理其尖峰負載。 在此，重要的是，彈性集區不能用於部署在不同資源群組或不同訂用帳戶中的資料庫。 這項限制讓此獨立單一租用戶應用程式模型成為整體資料庫成本觀點中最昂貴的解決方案。
廠商管理
即使應用程式執行個體安裝在不同的租用戶訂用帳戶中，廠商仍可存取所有獨立應用程式執行個體中的所有資料庫。 存取是透過 SQL 連線達成的。 此跨執行個體存取可讓廠商集中進行結構描述管理和跨資料庫查詢，以供報告或分析之用。 如果需要這種集中式管理，部署目錄時，就必須將租用戶識別碼對應至資料庫統一資源識別項 (URI)。 Azure SQL 資料庫提供分區化程式庫，可搭配用來提供目錄。 分區化程式庫正式命名為彈性資料庫用戶端程式庫。
D. 具有每個租用戶一個資料庫的多租用戶應用程式
下一個模式使用具有許多資料庫的多租用戶應用程式，資料庫全都是單一租用戶資料庫。 系統會為每個新租用戶佈建新的資料庫。 應用程式層會藉由為每個節點新增更多資源來垂直擴大。 或者，應用程式會藉由新增更多節點來水平相應增加。 縮放是以工作負載為基礎，且與個別資料庫的數目或級別無關。
為租用戶自訂
如同獨立應用程式模式，使用單一租用戶資料庫可提供強式租用戶隔離。 在任何模型只指定單一租用戶資料庫的應用程式中，任何一個指定資料庫的結構描述都可以針對其租用戶自訂和最佳化。 此自訂不會影響應用程式中的其他租用戶。 也許租用戶需要的資料可能超出所有租用戶所需的基本資料欄位。 此外，額外的資料欄位可能需要索引。
使用每個租用戶一個資料庫模型時，為一個或多個個別租用戶自訂結構描述相當簡單。 應用程式廠商必須設計程序，謹慎地大規模管理結構描述自訂。
彈性集區
當資料庫部署在相同的資源群組中時，可以將資料庫分組為彈性集區。 集區提供了符合成本效益的方式跨許多資料庫共用資源。 此集區選項比要求每個資料庫足夠大以容納其體驗的尖峰使用量的選項便宜。 即使集區資料庫共用資源的存取權，它們仍可達到高度的效能隔離。
Azure SQL 資料庫提供設定、監視和管理共用所需的工具。 集區層級和資料庫層級的效能計量都可以在 Azure 入口網站中，以及透過 Azure 監視器記錄取得。 計量可以提供彙總效能和租用戶特定效能的深入解析。 個別資料庫可以在集區之間移動，以將保留資源提供給特定租用戶。 這些工具可讓您以符合成本效益的方式確保良好的效能。
每個租用戶一個資料庫的作業規模
Azure SQL 資料庫有許多管理功能，其設計目的是大規模管理大量資料庫，例如遠遠超過 100,000 個資料庫。 這些功能讓每個租用戶一個資料庫模式變得合理。
例如，假設系統只有一個 1000 租用戶資料庫作為其唯一的資料庫。 資料庫可能有 20 個索引。 如果系統轉換成擁有 1,000 個單一租用戶資料庫，索引的數量就會上升至 20,000 個。 在 Azure SQL 資料庫自動調整中，根據預設，會啟用自動編製索引功能。 自動編製索引會為您管理所有 20,000 個索引，及其持續建立和卸除的最佳化。 這些自動化動作會在個別資料庫中發生，而且不會與其他資料庫中的類似動作產生協調或受其限制。 自動編製索引會以不同方式處理忙線資料庫中的索引與較不忙線資料庫中的索引。 如果必須手動完成這個龐大的管理工作，在每個租用戶一個資料庫的規模上進行這種索引管理自訂是不切實際的。
妥善調整的其他管理功能包括下列各項：
- 內建備份。
- 高可用性。
- 磁碟上加密。
- 效能遙測。
自動化
可以透過 devops 模型編寫管理作業指令碼並提供管理作業。 作業甚至可以在應用程式中自動化並公開。
例如，您可以將單一租用戶自動恢復到先前的時間點。 恢復只需要還原一個儲存租用戶的單一租用戶資料庫。 此還原不會影響其他租用戶，這可確認管理作業在每個個別租用戶的細微層級執行。
E. 具有多租用戶資料庫的多租用戶應用程式
另一個可用的模式是將許多租用戶儲存在多租用戶資料庫中。 應用程式執行個體可以有任意數目的多租用戶資料庫。 多租用戶資料庫的結構描述必須有個一或多個租用戶識別碼資料行，以便選擇性地擷取來自任何指定租用戶的資料。 此外，結構描述可能需要一些只供租用戶子集使用的資料表或資料行。 不過，靜態程式碼和參考資料只會儲存一次，並由所有租用戶共用。
犧牲租用戶隔離
資料：多租用戶資料庫一定會犧牲租用戶隔離。 多個租用戶的資料會一起儲存在一個資料庫中。 在開發期間，請確定查詢永遠不會公開來自多個租用戶的資料。 SQL Database 支援列層級安全性，這可以強制從查詢傳回的資料範圍設定為單一租用戶。
處理：多租用戶資料庫會在其所有租用戶之間共用計算和儲存體資源。 資料庫可以整體監視，以確保其有令人滿意的效能。 不過，Azure 系統沒有內建方法來監視或管理個別租用戶使用這些資源的方式。 因此，多租用戶資料庫會增加遇到有雜訊鄰居的風險，其中一個過度活躍租用戶的工作負載會影響相同資料庫中其他租用戶的效能體驗。 更多應用程式層級監視可以監視租用戶層級的效能。
較低廉的費用
一般而言，多租用戶資料庫的每租用戶成本最低。 單一資料庫的資源成本低於對等大小的彈性集區。 此外，針對租用戶只需要有限的儲存體的情況，可能會將數百萬個租用戶儲存在單一資料庫中。 任何彈性集區都不能包含數百萬個資料庫。 不過，每個集區包含 1,000 個資料庫的解決方案，在擁有 1,000 個集區時，會達到百萬級規模，而有可能變得難以管理。
以下將討論多租用戶資料庫模型的兩種變化，分區化多租用戶模型是最具彈性且可調整的。
F. 具有單一多租用戶資料庫的多租用戶應用程式
最簡單的多租用戶資料庫模式會使用單一資料庫來託管所有租用戶的資料。 隨著新增更多的租用戶，資料庫會相應增加更多儲存體和計算資源。 雖然一律有最終縮放比例限制，但此相應增加可能是所需的一切。 不過，在達到該限制之前，資料庫就會變得難以管理。
在多租用戶資料庫中實作著重於個別租用戶的管理作業，變得更為複雜。 而且這些作業可能大規模地變得無法接受地緩慢。 其中一個範例是僅針對一個租用戶資料的時間點還原。
G. 具有分區化多租用戶資料庫的多租用戶應用程式
大部分的 SaaS 應用程式一次只能存取一個租用戶的資料。 此存取模式可讓租用戶資料散發到多個資料庫或分區，其中任何一個租用戶的所有資料都包含在一個分區中。 分區化模型結合多租用戶資料庫模式，幾乎允許無限縮放。
管理分區
分區化會增加設計和作業管理的複雜性。 必須有目錄，才能在其中維護租用戶與資料庫之間的對應。 此外，管理分區和租用戶母體需要管理程序。 例如，必須為新增和移除分區，以及在分區之間移動租用戶資料設計程序。 其中一種調整方式是新增分區，並填入新的租用戶。 在其他時候，您可能會將密集填入的分區分割成兩個較不密集填入的分區。 在移動或中止數個租用戶之後，您可以將疏鬆填入的分區合併在一起。 合併會產生更具成本效益的資源使用率。 租用戶也可能在分區之間移動，以平衡工作負載。
SQL Database 提供了分割/合併工具，可與分區化程式庫和目錄資料庫搭配運作。 所提供的應用程式可以分割和合併分區，而且可以在分區之間移動租用戶資料。 應用程式也會在這些作業期間維護目錄，在移動受影響的租用戶之前將其標示為離線。 移動之後，應用程式會再次以新的對應更新目錄，並將租用戶重新標示為上線。
較小的資料庫更容易管理
藉由將租用戶散發到多個資料庫，分區化多租用戶解決方案會產生更容易管理的較小資料庫。 例如，將特定租用戶還原到先前的時間點，現在牽涉到從備份還原較小的單一資料庫，而不是包含所有租用戶的較大資料庫。 可以選擇每個資料庫的資料庫大小和租用戶數目，以平衡工作負載和管理工作。
結構描述中的租用戶識別碼
根據所使用的分區化方法，會對資料庫結構描述施加額外的條件約束。 SQL Database 分割/合併應用程式需要結構描述包含分區金鑰，這通常是租用戶識別碼。 租用戶識別碼是所有分區資料表之主索引鍵中的前置元素。 租用戶識別碼可讓分割/合併應用程式快速找出並移動與特定租用戶關聯的資料。
分區的彈性集區
分區化多租用戶資料庫可以置於彈性集區中。 一般而言，集區中有許多單一租用戶資料庫，與在少數多租用戶資料庫中擁有許多租用戶一樣，都符合成本效益。 當有大量相對閒置中的租用戶時，多租用戶資料庫會比較有利。
H. 混合式分區化多租用戶資料庫模型
在混合式模型中，所有資料庫的結構描述中都有租用戶識別碼。 資料庫全都能夠儲存多個租用戶，而且資料庫可以分區化。 因此，從結構描述的意義上說，它們全都是多租用戶資料庫。 但實際上，其中有些資料庫只包含一個租用戶。 不管怎樣，儲存在指定資料庫中的租用戶數量對資料庫結構描述沒有任何影響。
移動租用戶
您可以隨時將特定租用戶移至其自己的多租用戶資料庫。 您可以隨時改變主意，並將租用戶移回包含多個租用戶的資料庫。 當您佈建新的資料庫時，也可以將租用戶指派給新的單一租用戶資料庫。
在可識別租用戶群組的資源需求之間有很大的差異時，混合式模型就會大放異彩。 例如，假設針對參與免費試用的租用戶不保證與訂閱租用戶相同層級的高效能。 此原則可能是，將免費試用階段中的租用戶儲存在所有免費試用租用戶之間共用的多租用戶資料庫中。 當免費試用租用戶訂閱基本服務層級時，可以將該租用戶移至另一個可能擁有較少租用戶的多租用戶資料庫。 支付進階版服務層級的訂閱者可以移至自己的新單一租用戶資料庫。
集區
在此混合式模型中，訂閱者租用戶的單一租用戶資料庫可以置於資源集區中，以減少每個租用戶的資料庫成本。 在每個租用戶一個資料庫模型中也會這樣做。
I. 比較租用模型
下表摘要說明主要租用模型之間的差異。
| 測量 | 獨立應用程式 | 每個租用戶一個資料庫 | 分區化多租用戶 |
|---|---|---|---|
| 調整 | 中 (1-100 s) | 高 (1-100,000 s) | 無限制 (1-1,000,000 s) |
| 租用戶隔離 | 高 | 高 | 低；除任何單一租用戶之外 (僅在 MT 資料庫中)。 |
| 每個租用戶的資料庫成本 | 高；會針對尖峰調整大小。 | 低；使用集區。 | 最低；適用於 MT 資料庫中的小型租用戶。 |
| 效能監控和管理 | 僅限每個租用戶 | 彙總 + 每個租用戶 | 彙總；每個租用戶，但僅限於單一租用戶。 |
| 開發複雜度 | 低 | 低 | 中；因為分區化。 |
| 作業複雜度 | 低到高。 個別簡單，大規模複雜。 | 低到中。 模式可大規模解決複雜度。 | 低到高。 個別租用戶管理很複雜。 |