多租用戶 SaaS 資料庫租用模式Multi-tenant SaaS database tenancy patterns

本文說明各種可用的多租用戶 SaaS 應用程式的租用戶模型。This article describes the various tenancy models available for a multi-tenant SaaS application.

在設計多租用戶 SaaS 應用程式時,您必須小心選擇最適合您的應用程式需求的租用模型。When designing a multi-tenant SaaS application, you must carefully choose the tenancy model that best fits the needs of your application. 租用模型可決定每個租用戶的資料如何對應至儲存體。A tenancy model determines how each tenant’s data is mapped to storage. 您所選的租用模型會影響應用程式的設計和管理。Your choice of tenancy model impacts application design and management. 稍後切換到不同的模型有時所費不貲。Switching to a different model later is sometimes costly.

A.A. SaaS 概念與術語SaaS concepts and terminology

在軟體即服務 (SaaS) 模型中,公司將不會出售軟體的「授權」 。In the Software as a Service (SaaS) model, your company does not sell licenses to your software. 而是讓每位客戶向公司支付租金,使每位客戶成為公司的「租用戶」 。Instead, each customer makes rent payments to your company, making each customer a tenant of your company.

每個租用戶支付租金後,便可以存取 SaaS 應用程式元件,並將資料儲存於 SaaS 系統中。In return for paying rent, each tenant receives access to your SaaS application components, and has its data stored in the SaaS system.

「租用戶模型」 一詞是指組織租用戶儲存資料的方式:The term tenancy model refers to how tenants' stored data is organized:

  • 單一租用戶:  每個資料庫只會儲存來自一個租用戶的資料。Single-tenancy:  Each database stores data from only one tenant.
  • 多租用戶:  每個資料庫都會儲存來自多個不同租用戶的資料 (搭配保護資料隱私權的機制)。Multi-tenancy:  Each database stores data from multiple separate tenants (with mechanisms to protect data privacy).
  • 另外還提供混合式租用戶模型。Hybrid tenancy models are also available.

B.B. 如何選擇適當的租用模型How to choose the appropriate tenancy model

一般情況下,租用模型不會影響應用程式的功能,但可能會影響整體解決方案的其他層面。In general, the tenancy model does not impact the function of an application, but it likely impacts other aspects of the overall solution. 下列準則可用來評估每個模型:The following criteria are used to assess each of the models:

  • 延展性:Scalability:

    • 租用戶的數目。Number of tenants.
    • 每一租用戶的儲存體。Storage per-tenant.
    • 彙總儲存體。Storage in aggregate.
    • 工作負載。Workload.
  • 租用戶隔離:  資料隔離和效能 (某個租用戶的工作負載是否會影響其他人)。Tenant isolation:  Data isolation and performance (whether one tenant’s workload impacts others).

  • 每一租用戶的成本:  資料庫成本。Per-tenant cost:  Database costs.

  • 部署複雜度:Development complexity:

    • 結構描述的變更。Changes to schema.
    • 查詢的變更 (模式所要求)。Changes to queries (required by the pattern).
  • 操作複雜度:Operational complexity:

    • 監視和管理效能。Monitoring and managing performance.
    • 結構描述管理。Schema management.
    • 還原租用戶。Restoring a tenant.
    • 災害復原。Disaster recovery.
  • 自訂能力:  輕鬆支援租用戶專屬或租用戶類別專屬的結構描述自訂。Customizability:  Ease of supporting schema customizations that are either tenant-specific or tenant class-specific.

租用討論著重於「資料」 圖。The tenancy discussion is focused on the data layer. 但請考慮一下「應用程式」 層。But consider for a moment the application layer. 應用程式層會被視為龐大的實體。The application layer is treated as a monolithic entity. 如果您將應用程式分割成許多小元件,您所選的租用模型可能會改變。If you divide the application into many small components, your choice of tenancy model might change. 就使用的租用和儲存體技術或平台而論,您可以將某些元件視為與其他元件不同。You could treat some components differently than others regarding both tenancy and the storage technology or platform used.

C.C. 具有單一租用戶資料庫的獨立單一租用戶應用程式Standalone single-tenant app with single-tenant database

應用程式層級隔離Application level isolation

在此模型中,整個應用程式會重複安裝 (針對每個租用戶安裝一次)。In this model, the whole application is installed repeatedly, once for each tenant. 應用程式的每個執行個體都是獨立的執行個體,因此它決不會與任何其他獨立執行個體互動。Each instance of the app is a standalone instance, so it never interacts with any other standalone instance. 應用程式的每個執行個體只有一個租用戶,因此只需要一個資料庫。Each instance of the app has only one tenant, and therefore needs only one database. 租用戶本身全然擁有此資料庫。The tenant has the database all to itself.

只有一個單一租用戶資料庫的獨立應用程式設計。Design of standalone app with exactly one single-tenant database.

每個應用程式執行個體會安裝在不同的 Azure 資源群組中。Each app instance is installed in a separate Azure resource group. 資源群組可屬於軟體廠商或租用戶所擁有的訂用帳戶。The resource group can belong to a subscription that is owned by either the software vendor or the tenant. 在任一情況下,廠商可以為租用戶管理軟體。In either case, the vendor can manage the software for the tenant. 每個應用程式執行個體都會設定為連線至其對應的資料庫。Each application instance is configured to connect to its corresponding database.

每個租用戶資料庫都會部署為單一資料庫。Each tenant database is deployed as a single database. 此模型提供最強大的資料庫隔離。This model provides the greatest database isolation. 但是隔離要求將足夠的資源配置給每個資料庫,以處理其尖峰負載。But the isolation requires that sufficient resources be allocated to each database to handle its peak loads. 此處的重點是,彈性集區無法使用於部署在不同資源群組或不同訂用帳戶中的資料庫。Here it matters that elastic pools cannot be used for databases deployed in different resource groups or to different subscriptions. 從整體資料庫成本的觀點來看,此限制讓此獨立單一租用戶的應用程式模型成為最昂貴的解決方案。This limitation makes this standalone single-tenant app model the most expensive solution from an overall database cost perspective.

廠商管理Vendor management

即使應用程式執行個體是安裝於不同的租用戶訂用帳戶中,廠商仍可存取所有獨立應用程式執行個體中的所有資料庫。The vendor can access all the databases in all the standalone app instances, even if the app instances are installed in different tenant subscriptions. 透過 SQL 連線即可進行存取。The access is achieved via SQL connections. 此種跨執行個體的存取可以讓廠商集中進行結構描述管理和跨資料庫查詢,以便進行報告或分析。This cross-instance access can enable the vendor to centralize schema management and cross-database query for reporting or analytics purposes. 如果想要使用這種集中式管理,則必須部署可將租用戶識別碼對應到資料庫 URI 的目錄。If this kind of centralized management is desired, a catalog must be deployed that maps tenant identifiers to database URIs. Azure SQL Database 提供分區化程式庫,其可搭配 SQL 資料庫用來提供目錄。Azure SQL Database provides a sharding library that is used together with a SQL database to provide a catalog. 分區化程式庫已正式命名為彈性資料庫用戶端程式庫The sharding library is formally named the Elastic Database Client Library.

D.D. 每一租用戶一個資料庫的多租用戶應用程式Multi-tenant app with database-per-tenant

下一個模式會使用具有許多資料庫的多租用戶應用程式,所有都是單一租用戶資料庫。This next pattern uses a multi-tenant application with many databases, all being single-tenant databases. 為每個新租用戶佈建一個新資料庫。A new database is provisioned for each new tenant. 為每個節點新增更多資源,以垂直方式相應「增加」 應用程式層。The application tier is scaled up vertically by adding more resources per node. 或者,藉由新增更多節點,以水平方式相應「放大」 應用程式。Or the app is scaled out horizontally by adding more nodes. 縮放是以工作負載為基礎,並且與個別資料庫的數目或規模無關。The scaling is based on workload, and is independent of the number or scale of the individual databases.

每一租用戶一個資料庫的多租用戶應用程式設計。Design of multi-tenant app with database-per-tenant.

針對租用戶自訂Customize for a tenant

如同獨立應用程式模式,使用單一租用戶資料庫可提供強大的租用戶隔離。Like the standalone app pattern, the use of single-tenant databases gives strong tenant isolation. 在模型只會指定單一租用戶資料庫的任何應用程式中,可以針對其租用戶自訂和最佳化任何一個指定資料庫的結構描述。In any app whose model specifies only single-tenant databases, the schema for any one given database can be customized and optimized for its tenant. 此自訂作業不會影響應用程式中的其他租用戶。This customization does not affect other tenants in the app. 或許一個租用戶所需的資料可能超過所有租用戶所需的基本資料欄位。Perhaps a tenant might need data beyond the basic data fields that all tenants need. 此外,額外的資料欄位可能需要索引。Further, the extra data field might need an index.

如果每一租用戶一個資料庫,很容易就能達成一或多個個別租用戶的結構描述自訂。With database-per-tenant, customizing the schema for one or more individual tenants is straightforward to achieve. 應用程式廠商必須設計一些程序來小心管理大規模的結構描述自訂。The application vendor must design procedures to carefully manage schema customizations at scale.

彈性集區Elastic pools

當資料庫部署於相同的資源群組時,可以將它們分組為彈性集區。When databases are deployed in the same resource group, they can be grouped into elastic pools. 集區會提供符合成本效益的方式來共用橫跨多個資料庫的資源。The pools provide a cost-effective way of sharing resources across many databases. 相較於要求每個資料庫大到足以容納它所遭遇的使用量尖峰,此集區選項的成本比較低。This pool option is cheaper than requiring each database to be large enough to accommodate the usage peaks that it experiences. 即使集區資料庫會共用資源的存取權,它們仍可達到較高程度的效能隔離。Even though pooled databases share access to resources they can still achieve a high degree of performance isolation.

每一租用戶一個資料庫的多租用戶應用程式設計 (使用彈性集區)。Design of multi-tenant app with database-per-tenant, using elastic pool.

Azure SQL Database 會提供設定、監視和管理共用所需的工具。Azure SQL Database provides the tools necessary to configure, monitor, and manage the sharing. 這兩個集區層級和資料庫層級的效能計量可在 Azure 入口網站中,並透過 Azure 監視器記錄檔。Both pool-level and database-level performance metrics are available in the Azure portal, and through Azure Monitor logs. 計量可供深入了解彙總與租用戶特有的效能。The metrics can give great insights into both aggregate and tenant-specific performance. 個別的資料庫可以在集區之間移動,以將保留的資源提供給特定租用戶。Individual databases can be moved between pools to provide reserved resources to a specific tenant. 這些工具可讓您以符合成本效益的方式確保良好效能。These tools enable you to ensure good performance in a cost effective manner.

每一租用戶一個資料庫的作業規模Operations scale for database-per-tenant

Azure SQL Database 平台有許多管理功能的設計用來大規模管理大量資料庫,例如超過 100,000 個資料庫。The Azure SQL Database platform has many management features designed to manage large numbers of databases at scale, such as well over 100,000 databases. 這些功能可讓每一租用戶一個資料庫的模式看似合理。These features make the database-per-tenant pattern plausible.

例如,假設系統以包含 1000 個租用戶的資料庫作為其唯一的一個資料庫。For example, suppose a system has a 1000-tenant database as its only one database. 此資料庫可能有 20 個索引。The database might have 20 indexes. 如果系統轉變成擁有包含 1000 個單一租用戶的資料庫,則索引的數量會提升至 20,000 個。If the system converts to having 1000 single-tenant databases, the quantity of indexes rises to 20,000. 自動微調的 SQL Database 中,預設會啟用自動編製索引功能。In SQL Database as part of Automatic tuning, the automatic indexing features are enabled by default. 自動編製索引功能可為您管理 20,000 個索引與其進行中的 create 和 drop 最佳化。Automatic indexing manages for you all 20,000 indexes and their ongoing create and drop optimizations. 這些自動化動作會發生於個別資料庫中,而且不受其他資料庫中的類似動作所調配或限制。These automated actions occur within an individual database, and they are not coordinated or restricted by similar actions in other databases. 在忙碌的資料庫與較不忙碌的資料庫中,自動化索引編製功能會以不同的方式處理索引。Automatic indexing treats indexes differently in a busy database than in a less busy database. 如果必須以手動方式完成此大量管理工作,則在每一租用戶一個資料庫的規模中,這種索引管理自訂作業可能不切實際。This type of index management customization would be impractical at the database-per-tenant scale if this huge management task had to be done manually.

可縮放自如的其他管理功能包括:Other management features that scale well include the following:

  • 內建備份。Built-in backups.
  • 高可用性。High availability.
  • 在磁碟上加密。On-disk encryption.
  • 效能遙測。Performance telemetry.

自動化Automation

可以將管理作業編寫為指令碼,並透過 devops 模型提供。The management operations can be scripted and offered through a devops model. 這些作業甚至可以在應用程式中自動執行並且公開。The operations can even be automated and exposed in the application.

例如,您可以將單一租用戶自動復原到較早的時間點。For example, you could automate the recovery of a single tenant to an earlier point in time. 復原只需要還原儲存租用戶的一個單一租用戶資料庫。The recovery only needs to restore the one single-tenant database that stores the tenant. 此還原並不會影響其他租用戶,這就確認管理作業屬於每個個別租用戶的精細層級。This restore has no impact on other tenants, which confirms that management operations are at the finely granular level of each individual tenant.

E.E. 具有多租用戶資料庫的多租用戶應用程式Multi-tenant app with multi-tenant databases

另一個可用模式是在多租用戶資料庫中儲存許多租用戶。Another available pattern is to store many tenants in a multi-tenant database. 應用程式執行個體可以有任意多個多租用戶資料庫。The application instance can have any number of multi-tenant databases. 多租用戶資料庫的結構描述必須有一或多個租用戶識別碼資料行,如此才能選擇性地擷取任何指定租用戶中的資料。The schema of a multi-tenant database must have one or more tenant identifier columns so that the data from any given tenant can be selectively retrieved. 此外,結構描述可能需要只由部份租用戶使用的一些資料表或資料行。Further, the schema might require a few tables or columns that are used by only a subset of tenants. 不過,靜態程式碼與參考資料只會儲存一次,並由所有租用戶共用。However, static code and reference data is stored only once and is shared by all tenants.

犧牲租用戶隔離Tenant isolation is sacrificed

資料:  多租用戶資料庫必定會犧牲租用戶隔離。Data:  A multi-tenant database necessarily sacrifices tenant isolation. 多個租用戶的資料會一起儲存在一個資料庫中。The data of multiple tenants is stored together in one database. 在開發期間,確保查詢決不會公開來自多個租用戶的資料。During development, ensure that queries never expose data from more than one tenant. SQL Database 支援資料列層級的安全性,其可強制查詢所傳回的資料範圍限於單一租用戶。SQL Database supports row-level security, which can enforce that data returned from a query be scoped to a single tenant.

處理:  多租用戶資料庫會讓其所有租用戶共用計算和儲存體資源。Processing:  A multi-tenant database shares compute and storage resources across all its tenants. 此種資料庫可以整體進行監視,確保其效能可以接受。The database as a whole can be monitored to ensure it is performing acceptably. 不過,Azure 系統沒有內建方法可監視或管理個別租用戶對於這些資源的使用。However, the Azure system has no built-in way to monitor or manage the use of these resources by an individual tenant. 因此,多租用戶資料庫會提高遇到吵雜芳鄰的風險,以致其中一個過度活躍租用戶的工作負載影響到同一個資料庫中其他租用戶的效能體驗。Therefore, the multi-tenant database carries an increased risk of encountering noisy neighbors, where the workload of one overactive tenant impacts the performance experience of other tenants in the same database. 其他應用程式層級的監視功能可以監視租用戶層級的效能。Additional application-level monitoring could monitor tenant-level performance.

成本較低Lower cost

一般而言,多租用戶資料庫的每一租用戶成本最低。In general, multi-tenant databases have the lowest per-tenant cost. 單一資料庫的資源成本會低於同樣大小的彈性集區。Resource costs for a single database are lower than for an equivalently sized elastic pool. 此外,在租用戶只需要有限儲存體的情況下,單一資料庫中可能會儲存數百萬個租用戶。In addition, for scenarios where tenants need only limited storage, potentially millions of tenants could be stored in a single database. 沒有任何彈性集區可以包含數百萬個資料庫。No elastic pool can contain millions of databases. 不過,包含 1000 個集區且每個集區有 1000 個資料庫的方案可以到達數以百萬計的規模,但是有變得難以管理的風險。However, a solution containing 1000 databases per pool, with 1000 pools, could reach the scale of millions at the risk of becoming unwieldy to manage.

接著會討論多租用戶資料庫模型的兩種變形,其中的分區化多租用戶模型最具彈性且最能擴充。Two variations of a multi-tenant database model are discussed in what follows, with the sharded multi-tenant model being the most flexible and scalable.

F.F. 具有單一多租用戶資料庫的多租用戶應用程式Multi-tenant app with a single multi-tenant database

這個最簡單的多租用戶資料庫模式會使用單一資料庫來裝載所有租用戶的資料。The simplest multi-tenant database pattern uses a single database to host data for all tenants. 隨著更多租用戶的新增,資料庫會相應增加更多儲存體和計算資源。As more tenants are added, the database is scaled up with more storage and compute resources. 雖然一定有終極規模限制,但是此相應增加是有必要的。This scale up might be all that is needed, although there is always an ultimate scale limit. 不過,在達到該限制之前,資料庫早已變得難以管理。However, long before that limit is reached the database becomes unwieldy to manage.

相較於在多租用戶資料庫中實作管理,著重於個別租用戶的管理作業更為複雜。Management operations that are focused on individual tenants are more complex to implement in a multi-tenant database. 而且這些作業的速度可能會變得非常慢。And at scale these operations might become unacceptably slow. 例如,僅僅一個租用戶的資料時間點還原作業。One example is a point-in-time restore of the data for just one tenant.

G.G. 具有分區化多租用戶資料庫的多租用戶應用程式Multi-tenant app with sharded multi-tenant databases

大部分 SaaS 應用程式一次只會存取一個租用戶的資料。Most SaaS applications access the data of only one tenant at a time. 這種存取模式可讓租用戶資料分散於多個資料庫或分區,而任何一個租用戶的所有資料會容納在一個分區中。This access pattern allows tenant data to be distributed across multiple databases or shards, where all the data for any one tenant is contained in one shard. 與多租用戶資料庫模式結合的分區化模型,幾乎沒有規模限制。Combined with a multi-tenant database pattern, a sharded model allows almost limitless scale.

具有分區化多租用戶資料庫的多租用戶應用程式設計。Design of multi-tenant app with sharded multi-tenant databases.

管理分區Manage shards

分區化會增加設計和操作管理的複雜度。Sharding adds complexity both to the design and operational management. 需要有目錄,才能維護租用戶與資料庫之間的對應。A catalog is required in which to maintain the mapping between tenants and databases. 此外,需要有管理程序才能管理分區和租用戶填入。In addition, management procedures are required to manage the shards and the tenant population. 例如,必須設計一些程序來新增和移除分區,以及在分區之間移動租用戶資料。For example, procedures must be designed to add and remove shards, and to move tenant data between shards. 其中一種調整方式是新增分區,並在其中填入新的租用戶。One way to scale is to by adding a new shard and populating it with new tenants. 其他時候,您可能會將密集填入的分區分割成兩個比較不密集填入的分區。At other times you might split a densely populated shard into two less-densely populated shards. 移動或中斷數個租用戶之後,您可能會將稀疏填入的分區合併在一起。After several tenants have been moved or discontinued, you might merge sparsely populated shards together. 合併會導致更加符合成本效益的資源使用率。The merge would result in more cost-efficient resource utilization. 租用戶也可能會在分區之間移動,以平衡工作負載。Tenants might also be moved between shards to balance workloads.

SQL Database 提供可搭配分區化程式庫和目錄資料庫運作的分割/合併工具。SQL Database provides a split/merge tool that works in conjunction with the sharding library and the catalog database. 所提供的應用程式可以分割及合併分區,而且可以在分區之間移動租用戶資料。The provided app can split and merge shards, and it can move tenant data between shards. 此應用程式也可在這些作業期間維護目錄,並將受影響的租用戶標示為離線,再移動它們。The app also maintains the catalog during these operations, marking affected tenants as offline prior to moving them. 移動之後,應用程式會以新的對應再次更新目錄,並將租用戶標示回線上。After the move, the app updates the catalog again with the new mapping, and marking the tenant as back online.

較小的資料庫比較容易管理Smaller databases more easily managed

藉由將租用戶分散到多個資料庫,分區化多租用戶方案便可產生比較容易管理的較小資料庫。By distributing tenants across multiple databases, the sharded multi-tenant solution results in smaller databases that are more easily managed. 例如,將特定租用戶還原至先前的時間點,現在牽涉到從備份 (而非包含所有租用戶的較大資料庫) 還原單一較小資料庫。For example, restoring a specific tenant to a prior point in time now involves restoring a single smaller database from a backup, rather than a larger database that contains all tenants. 您可以選擇資料庫大小和每個資料庫的租用戶數目,來平衡工作負載與管理投入量。The database size, and number of tenants per database, can be chosen to balance the workload and the management efforts.

結構描述中的租用戶識別碼Tenant identifier in the schema

視使用的分區化方法而定,可能為對資料庫結構描述強加其他條件約束。Depending on the sharding approach used, additional constraints may be imposed on the database schema. SQL Database 分割/合併應用程式要求結構描述包含分區化索引鍵,這通常是租用戶識別碼。The SQL Database split/merge application requires that the schema includes the sharding key, which typically is the tenant identifier. 租用戶識別碼是所有分區化資料表的主索引鍵中的前置元素。The tenant identifier is the leading element in the primary key of all sharded tables. 租用戶識別碼可讓分割/合併應用程式快速找出並移動與特定租用戶相關聯的資料。The tenant identifier enables the split/merge application to quickly locate and move data associated with a specific tenant.

分區的彈性集區Elastic pool for shards

分區化多租用戶資料庫可以置於彈性集區中。Sharded multi-tenant databases can be placed in elastic pools. 一般而言,一個集區中具有許多單一租用戶資料庫,與一些多租用戶資料庫中具有許多租用戶的成本效益相同。In general, having many single-tenant databases in a pool is as cost efficient as having many tenants in a few multi-tenant databases. 如果有大量相當不活躍的租用戶,多租用戶資料庫比較有優勢。Multi-tenant databases are advantageous when there are a large number of relatively inactive tenants.

H.H. 混合式分區化多租用戶資料庫模型Hybrid sharded multi-tenant database model

在混合式模型中,所有資料庫都有其結構描述中的租用戶識別碼。In the hybrid model, all databases have the tenant identifier in their schema. 這類資料庫能夠儲存多個租用戶,而且可以進行分區。The databases are all capable of storing more than one tenant, and the databases can be sharded. 所以就結構描述而言,這些全都是多租用戶的資料庫。So in the schema sense, they are all multi-tenant databases. 而實際上,其中有些資料庫只包含一個租用戶。Yet in practice some of these databases contain only one tenant. 不論如何,儲存在指定資料庫中的租用戶數量不會影響資料庫結構描述。Regardless, the quantity of tenants stored in a given database has no effect on the database schema.

四處移動租用戶Move tenants around

您可以隨時將特定租用戶移到它自己的多租戶資料庫。At any time, you can move a particular tenant to its own multi-tenant database. 您也可以隨時改變心意,將租用戶移回包含多個租用戶的資料庫。And at any time, you can change your mind and move the tenant back to a database that contains multiple tenants. 當您佈建新的資料庫時,您也可以將租用戶指派給新的單一租用戶資料庫。You can also assign a tenant to new single-tenant database when you provision the new database.

可辨識之租用戶群組的資源需求之間有很大差異時,混合式模型就會脫穎而出。The hybrid model shines when there are large differences between the resource needs of identifiable groups of tenants. 例如,假設不保證參與免費試用的租用戶能擁有與訂閱租用戶一樣高的效能等級。For example, suppose that tenants participating in a free trial are not guaranteed the same high level of performance that subscribing tenants are. 此原則可能適用於免費試用階段的租用戶,而且這些租用戶即將儲存在所有免費試用租用戶共用的多租用戶資料庫中。The policy might be for tenants in the free trial phase to be stored in a multi-tenant database that is shared among all the free trial tenants. 當免費試用租用戶訂閱基本服務層級時,可以將租用戶移到另一個可能有較少租用戶的多租用戶資料庫。When a free trial tenant subscribes to the basic service tier, the tenant can be moved to another multi-tenant database that might have fewer tenants. 支付進階服務層級費用的訂閱者可以移到其擁有的全新單一租用戶資料庫。A subscriber that pays for the premium service tier could be moved to its own new single-tenant database.

集區Pools

在此混合式模型中,可以將訂閱者租用戶的單一租用戶資料庫放在資源集區中,以降低每個租用戶的資料庫成本。In this hybrid model, the single-tenant databases for subscriber tenants can be placed in resource pools to reduce database costs per tenant. 這也可以在每一租用戶一個資料庫的模型中達成。This is also done in the database-per-tenant model.

I.I. 比較租用模型Tenancy models compared

下表摘要說明主要租用模型之間的差異。The following table summarizes the differences between the main tenancy models.

測量Measurement 獨立應用程式Standalone app 每一租用戶一個資料庫Database-per-tenant 分區化多租用戶Sharded multi-tenant
調整Scale Medium
1-1001-100s
非常高Very high
1-100,0001-100,000s
無限Unlimited
1-1,000,0001-1,000,000s
租用戶隔離Tenant isolation 非常高Very high High 低;任何單一租用戶除外 (亦即單獨在 MT DB 中)。Low; except for any single tenant (that is alone in an MT db).
每一租用戶的資料庫成本Database cost per tenant 高;針對尖峰調整大小。High; is sized for peaks. 低;使用集區。Low; pools used. 最低;適用於 MT DB 的小型租用戶。Lowest, for small tenants in MT DBs.
監視和管理效能Performance monitoring and management 僅限每一租用戶Per-tenant only 彙總 + 每一租用戶Aggregate + per-tenant 彙總;雖然是適用於單一物件的僅限每一租用戶。Aggregate; although is per-tenant only for singles.
部署複雜度Development complexity Low Low 中;由於分區化。Medium; due to sharding.
操作複雜度Operational complexity 低-高。Low-High. 個別時簡單,大規模時複雜。Individually simple, complex at scale. 低-中。Low-Medium. 模式可處理大規模時的複雜度。Patterns address complexity at scale. 低-高。Low-High. 個別租用戶管理很複雜。Individual tenant management is complex.
 

後續步驟Next steps