数据库设计模式-服务设计与商业模式设计

在设计多租户 SaaS 应用程序时，您必须仔细选择最适合您的应用程序需求的租户模型。 租户模型决定了每个租户的数据如何映射到存储。 您选择的租户模型会影响应用程序的设计和管理。 稍后切换到另一种模型有时代价高昂。 以下是对备选租户模型的讨论。

01 如何选择合适的租户模式

一般来说，租赁模式不会影响应用程序的功能，但可能会影响整体解决方案的其他方面。 以下标准用于评估每个模型：

可扩展性

租户数量级

每个租户的存储级别

整体存储

工作量

租户隔离

数据隔离和性能（一个租户的负载是否影响其他租户）

每租户成本

数据库成本

开发复杂度

数据结构变化

查询语句的变化

操作复杂度

性能监控

数据结构模式管理

租户数据恢复

灾难恢复

可定制性

易于根据租户的需求自定义架构

此租户讨论的重点是数据层。 但是考虑应用层。 应用层被视为一个整体实体。 如果您将应用程序分成许多小组件，您对租户模型的选择可能会改变。您可以根据所使用的租户和存储技术或平台区别对待其他组件

02 独立单租户应用+独立单租户数据库应用层隔离

在此模型中，需要为每个租户重复安装整个应用程序。 应用程序的每个实例都是一个独立的实例，因此它不与任何其他独立实例交互。 每个应用程序实例只有一个租户，因此只需要一个数据库。 租户拥有自己的数据库。

每个应用程序实例都安装在一个独立的 Azure 资源组中。 资源组可以属于软件供应商或租户拥有的订阅。 在任何一种情况下，供应商都可以为租户管理软件。 每个应用程序实例都配置为连接到其相应的数据库。

每个租户数据库都部署为一个独立的数据库。 此模型提供最大的数据库隔离。 但隔离要求为每个数据库分配足够的资源来处理其峰值负载。 这里重要的是弹性池不能用于部署在不同资源组或不同订阅中的数据库。 从整体数据库成本的角度来看，这种限制使这种独立的单租户应用程序模型成为最昂贵的解决方案。

供应商管理

提供者可以访问所有独立应用程序实例中的所有数据库，即使应用程序实例安装在不同的租户订阅中。 访问是通过 SQL 连接实现的。 这种跨实例访问可以使供应商能够集中模式管理和跨数据库查询以进行报告或分析。 如果需要这种集中管理，则必须部署一个将租户标识符映射到数据库 URI 的目录。 Azure SQL 数据库提供了一个分片库，它与 SQL 数据库一起提供目录。 分区库正式命名为Elastic Database Client Library。

03 支持多租户应用+每个租户独立数据库

此模式使用具有多个数据库的多租户应用程序，每个数据库对应一个租户。 为每个新租户提供一个新数据库。 通过为每个节点添加更多资源来垂直扩展应用层。 或者通过添加更多节点来横向扩展应用层。 根据应用程序工作负载进行扩展数据库设计模式，并且独立于单个数据库的数量或大小。

租户定制

与独立应用程序模式一样，使用单租户数据库可提供强大的租户隔离。 任何给定数据库的模式都可以为租户定制和优化。 此自定义不会影响应用程序中的其他租户。 租户可能需要超出所有租户所需的基本数据字段的数据。 此外，附加数据字段可能需要索引。

每个租户一个数据库，很容易为一个或多个单独的租户定制模式。 应用程序供应商必须设计程序以仔细管理模式定制。

弹性池

当数据库部署在同一个资源组中时，可以将它们分组为弹性数据库池。 这些池提供了一种跨多个数据库共享资源的经济高效的方式。 与要求每个数据库都足够大以适应其遇到的使用高峰相比，此池选项的成本更低。 即使池化数据库共享对资源的访问，它们仍然可以实现高度的性能隔离。

Azure SQL 数据库提供配置、监控和管理共享所需的工具。 池级别和数据库级别的性能指标均可在 Azure 门户中和通过 Log Analytics 获得。 这些指标提供了对总体和特定租户性能的洞察。 可以在池之间移动单个数据库，为特定租户提供保留资源。 这些工具使您能够以经济高效的方式确保良好的性能。

操作可扩展性

Azure SQL 数据库平台具有许多管理功能，旨在管理大量数据库，例如超过 100,000 个数据库。 这些特性使每个租户的数据库模式变得合理。

例如，假设系统只有一个 1000 个租户的数据库作为其唯一的数据库。 数据库可能有 20 个索引。 如果系统转换为拥有 1000 个单租户数据库，则索引数量将增加到 20,000 个。 在 SQL 数据库中，默认情况下启用自动索引作为自动优化的一部分。 Auto Indexing 为您管理所有 20,000 个索引及其持续的创建和删除优化。 这些自动操作发生在单个数据库中，不受其他数据库中类似操作的协调或限制。 自动索引在繁忙的数据库中和在繁忙的数据库中处理索引的方式不同。 如果必须手动完成如此庞大的管理任务，这种类型的索引管理定制在每个租户数据库规模上是不切实际的。

此外，在可扩展性管理方面，它还具有以下特点：

* 内置备份

* 高可用性

* 磁盘加密

* 性能遥测

自动化

可以通过 devops 模型编写和交付管理操作。 这些操作甚至可以自动化并在应用程序中公开。

例如，您可以自动将单个租户恢复到较早的时间点。 恢复只需要恢复存储租户的单租户数据库。 此恢复对其他租户没有影响，确认管理操作处于每个租户的粒度级别。

04 单应用支持多租+单数据库支持多租

另一种可用的模式是将多租户存储在多租户数据库中。 一个应用程序实例可以有任意数量的多租户数据库。 多租户数据库的模式必须有一个或多个租户标识符列，以便可以有选择地检索来自任何给定租户的数据。 此外，该模式可能需要一些仅由一部分租户使用的表或列。 但是，静态代码和引用数据仅存储一次并由所有租户共享。

牺牲租户隔离

数据：多租户数据库必然会牺牲租户隔离。 多个租户的数据一起存储在一个数据库中。 在开发期间，确保查询不会暴露来自多个租户的数据。 SQL 数据库支持行级安全性，这将查询返回的数据强制限制为单个租户。

处理：多租户数据库在所有租户之间共享计算和存储资源。 可以监视整个数据库以确保其性能可接受。 然而，Azure 系统没有内置的方式来监控或管理各个租户对这些资源的使用。 因此，多租户数据库增加了遇到嘈杂邻居的风险，其中一个过于活跃的租户的工作负载会影响同一数据库中其他租户的性能体验。 额外的应用层监控可以监控租户层性能。

更低的花费

通常，多租户数据库的租户成本最低。 独立数据库的资源成本低于相同大小的弹性池。 此外，对于租户仅需要有限存储的情况，潜在的数百万租户可能存储在单个数据库中。 没有弹性池可以包含数百万个数据库。 但是，每个池包含 1000 个数据库的解决方案可能会扩展到数百万，可能变得难以管理。

下面讨论了多租户数据库模型的两种变体，其中分片多租户模型是最灵活和可扩展的。

05 单应用支持多租+单库支持多租（不分片）

最简单的多租户数据库模式使用一个独立的数据库来托管所有租户的数据。 随着更多租户的加入，数据库会随着存储和计算资源的增加而扩展。 可能需要这样的放大倍数，但总有一个最终限制。 但是数据库设计模式，在达到此限制之前，数据库将变得难以管理。

在多租户数据库中实现单个租户的管理操作要复杂得多。 这些大规模的操作可能会变得慢得令人无法接受。 一个非常糟糕的例子是试图在某个时间点只恢复一个租户的数据。

06 支持多租户的单应用+支持多租户的单数据库（分片）

大多数 SaaS 应用程序一次只能访问一个租户的数据。 这种访问模式允许租户数据分布在多个数据库或分片中，其中任何一个租户的所有数据都包含在单个分片中。 结合多租户数据库模式，分片模型允许几乎无限的规模。

管理分片

分片增加了设计和运营管理的复杂性。 需要维护租户与数据库映射关系的目录。 此外，还需要管理程序来管理分片和租户数量。 例如，程序必须设计为添加和删除分片，以及在分片之间移动租户数据。 一种扩展方式是添加一个新分片并用新租户填充它。 在其他时候，您可能会将一个人口密集的分片分成两个人口密度较低的分片。 在多个租户移动或停止生产后，人口减少的分片可能会合并在一起。 整合将使资源的利用更具成本效益。 租户也可以在分片之间移动以平衡工作量。

SQL 数据库提供了一个拆分/合并工具，用于与分片库和目录数据库一​​起使用。 提供的应用程序可以拆分和合并分片，并可以在分片之间移动租户数据。 该应用程序还在这些操作期间维护目录，在移动之前将受影响的分片租户标记为离线。 移动后，应用程序使用新映射再次更新目录并将租户标记为重新联机。

较小的数据库更易于管理

通过跨多个数据库分布租户，分片多租户解决方案可以生成更小的数据库，更易于管理。 例如，将特定租户恢复到以前的时间点现在涉及从备份恢复单个较小的数据库，而不是包含所有租户的较大数据库。 您可以选择数据库大小和每个数据库的租户数量以平衡工作负载和管理。

shema中的租户标识ID

根据所使用的分片方法，可能会对数据库模式施加额外的约束。 SQL 数据库拆分/合并应用程序要求架构包含分片 KEY，通常是租户标识符 ID。 租户标识ID是所有分表的主键中的主要元素。 租户标识符使拆分/合并应用程序能够快速定位和移动与特定租户关联的数据。

分片弹性池

分片的多租户数据库可以放在弹性池中。 通常，在一个池中拥有许多单租户数据库与在几个多租户数据库中拥有许多租户一样具有成本效益。 当存在大量相对不活跃的租户时，多租户数据库是有利的。

混合分片多租户数据库

在混合模型中，所有数据库的模式中都有租户标识符。 这些数据库能够存储多个租户，并且数据库可以拆分。 所以在架构意义上，它们都是多租户数据库。 然而，实际上，其中一些数据库只包含一个租户。 无论如何，存储在给定数据库中的租户数量对数据库架构没有影响。

移动租户

您可以随时将特定租户迁移到他们自己的多租户数据库。 在任何时候，您都可以改变主意，将租户移回具有多个租户的数据库。 供应新数据库时，您还可以将租户分配给新的单租户数据库。

当可识别的租户组的资源需求存在很大差异时，混合模式就会大放异彩。 例如，假设参与免费试用的租户无法保证与订阅租户相同级别的高性能。 免费试用阶段可能适用于租户的策略存储在所有免费试用租户共享的多租户数据库中。 当免费试用租户订阅基本服务级别时，租户可以移动到另一个租户较少的多租户数据库。 支付高级服务级别费用的用户可以迁移到新的单租户数据库。

水池

在这种混合模型中，用户租户的单租户数据库可以放置在资源池中，以降低每个租户的数据库成本。 这也是在每个租户模型的数据库中完成的。

租户模式比较