【SaaS架构】SaaS存储策略--RDS上的多租户

在关系数据库上交付了这么多早期SaaS系统之后，开发人员社区已经建立了一些常见的模式来解决这些环境中的多租户问题。事实上，RDS具有到筒仓、网桥和池模型的更自然的映射。

RDS中数据的构造和表示在很大程度上是非管理关系环境的扩展。例如，MySQL中可用的基本机制也可以在RDS中使用。这使得在所有RDS风格上实现多租户相对简单。

以下部分概述了在RDS上实现分区模型时常用的各种策略。

筒仓模型

您可以通过多种方式在AWS上实现筒仓模式。然而，实现隔离的最常见和最简单的方法是为每个租户创建单独的数据库实例。通过实例，您可以实现一个通常满足客户法规遵从性需求的分离级别，而无需调配完全独立的帐户。

RDS实例作为思洛存储器

上图显示了可以在RDS上实现的基本思洛存储器模型。这里，为每个租户提供了两个单独的实例。

该图描述了每个租户实例的主数据库和两个读取副本。这是一个可选概念，旨在强调如何使用此方法为每个租户设置和配置优化的、高度可用的策略。

桥梁模型

在RDS上实现桥接模型符合我们在所有存储模型中看到的相同主题。基本方法是为所有租户利用单个实例，同时为该数据库中的每个租户创建单独的表示。这就需要有配置和运行时表解析来将每个表映射到给定的租户。

网桥模型为您提供了在迁移租户数据时使用不同模式和一些灵活性的租户的机会。例如，您可以让不同的租户在给定的时间点运行不同版本的产品，并逐个租户逐步迁移模式更改。

下图提供了一个在RDS上实现网桥模型的方法示例。在此图中，您有一个RDS数据库实例，其中包含Tenant1和Tenant2的单独客户表。

RDS上的网桥模型示例

这个示例强调了在租户级别具有模式变化的能力。Tenant1的模式有一个Status列，而该列被删除，并由Tenant2使用的性别列替换。

这里的另一个选择是为实例中的每个租户引入单独数据库的概念。RDS的术语各不相同。一些RDS存储容器将其称为数据库；其他人将其标记为模式。

具有独立表/模式的RDS网桥

上图提供了该替代桥梁模型的图示。注意，我们为每个租户创建了数据库，然后租户拥有自己的表集合。对于一些SaaS组织，这更自然地确定了租户数据的管理范围，避免了将命名传播到单个表的需要。

这个模型很有吸引力，但它可能不是最适合所有类型的RDS。某些RDS容器限制了可以为实例创建的数据库/模式的数量。例如，SQL Server容器每个实例只允许30个数据库，这对于大多数SaaS环境来说可能是不可接受的。

尽管网桥模型允许租户之间的变化，但重要的是要知道，通常情况下，您仍然应该采用限制模式更改的策略。每次引入模式更改时，您都可以在不占用任何停机时间的情况下，成功地将SaaS租户迁移到新模型。因此，尽管该模型简化了这些迁移，但它不会促进一次性租户模式或租户数据表示的定期更改。

水池模型

RDS的池模型依赖于传统的关系索引方案来划分租户数据。作为将所有租户数据移动到共享基础结构模型的一部分，您将租户数据存储在单个RDS实例中，租户共享公共表。这些表使用唯一的租户标识符进行索引，该标识符用于访问和管理每个租户的数据。

具有共享模式的RDS池模型

上图提供了运行中的池模型的示例。这里，具有一个Customer表的单个RDS实例保存应用程序所有租户的数据。RDS是RDBMS，因此所有租户必须使用相同的模式版本。RDS不像DynamoDB，它有一个灵活的模式，允许每个租户在一个表中有一个唯一的模式。

单个实例限制中的因子

我们描述的许多模型主要集中于将数据存储在单个实例中，并在该实例中划分数据。根据SaaS环境的大小和性能需求，使用单个实例可能不符合租户数据的配置文件。RDS对单个实例中可存储的数据量有限制。以下是限额明细：

• MySQL、MariaDB、Oracle、PostgreSQL–6 TB
• SQL Server–4 TB
• Aurora–64 TB

此外，单个实例还引入了资源争用问题（CPU、内存、I/O）。

在单个实例不切实际的情况下，自然的扩展是引入一种分片方案，其中租户数据分布在多个实例中。使用这种方法，您可以从一小部分碎片实例开始。然后，不断观察租户数据的配置文件并扩展实例的数量，以确保没有单个实例达到限制或成为瓶颈。

权衡权衡

使用RDS的权衡相当简单。主要主题通常更多地是交易管理和灵活的供应复杂性。总体而言，RDS上的思洛存储器模型可能会降低资源调配自动化的痛点。然而，与池模型相关的成本和管理效率往往令人信服。当您考虑这些模型将如何与您的持续交付环境保持一致时，这一点尤为重要。