当您选择一个数据库来存储操作数据时，必须考虑数据的结构、它将回答哪些查询、它将以多快的速度提供答案以及数据平台本身的弹性。除了这些一般考虑因素外，软件即服务（SaaS）对运营数据的影响，如性能隔离、租户安全以及多租户SaaS应用程序数据的典型特性和设计模式。本指南讨论了这些因素如何应用于将AmazonWebServices（AWS）上的PostgreSQL数据库用作多租户SaaS应用程序的主要操作数据存储。具体来说，本指南重点介绍了两个AWS管理的PostgreSQL选项：Amazon Aurora PostgreSQL Compatible Edition和Amazon Relational Database Service（Amazon RDS）for PostgreSQL。

目标业务成果

本指南详细分析了使用Aurora PostgreSQL Compatible和Amazon RDS for PostgreSQL的多租户SaaS应用程序的最佳实践。我们建议您使用本指南中提供的设计模式和概念，为您的多租户SaaS应用程序提供Aurora PostgreSQL Compatible或Amazon RDS for PostgreSQL的实现并使其标准化。

本规范性指南有助于实现以下业务成果：

• 为您的用例选择最佳的AWS管理PostgreSQL选项–本指南将数据库使用的关系和非关系选项与SaaS应用程序进行比较。它还讨论了Aurora PostgreSQL Compatible和Amazon RDS for PostgreSQL的最佳用例。这些信息将有助于为您的SaaS应用程序选择最佳选项。
• 通过采用SaaS分区模型实施SaaS最佳实践–本指南讨论并比较了适用于PostgreSQL数据库管理系统（DBMS）的三种广泛的SaaS分区模型：池、桥接和筒仓模型及其变体。这些方法捕获SaaS最佳实践，并在设计SaaS应用程序时提供灵活性。SaaS分区模型的实施是保持最佳实践的关键部分。
• 在池SaaS分区模型中有效使用RLS–行级安全性（RLS）通过基于用户或上下文变量限制可以查看的行，支持在单个PostgreSQL表中强制执行租户数据隔离。当您使用池分区模型时，需要RLS来防止跨租户访问。

对于许多多租户SaaS应用程序，选择一个操作数据库可以提炼为关系数据库和非关系数据库之间的选择，或者两者的组合。要做出决定，请考虑以下高级应用程序数据要求和特征：

• 应用程序的数据模型
• 数据的访问模式
• 数据库延迟要求
• 数据完整性和事务完整性要求（原子性、一致性、隔离性和持久性或ACID）
• 跨区域可用性和恢复要求

下表列出了应用程序数据需求和特性，并在AWS数据库产品的上下文中讨论了它们：Aurora PostgreSQL Compatible和Amazon RDS for PostgreSQL（关系型），以及Amazon DynamoDB（非关系型）。当您试图在关系型和非关系型操作数据库产品之间做出选择时，可以参考此矩阵。

一些多租户SaaS应用程序可能具有独特的数据模型或特殊情况，上表中未包含的数据库可以更好地为其提供服务。例如，时间序列数据集、高度连接的数据集或维护集中交易分类账可能需要使用不同类型的数据库。分析所有可能性超出了本指南的范围。有关AWS数据库产品的全面列表以及它们如何在高级别上满足不同的用例，请参阅《亚马逊Web服务概述》白皮书的数据库部分。

本指南的其余部分重点介绍支持PostgreSQL的AWS关系数据库服务：Amazon RDS和Aurora PostgreSQL Compatible。DynamoDB需要一种不同的方法来优化SaaS应用程序，这超出了本指南的范围。有关DynamoDB的更多信息，请参阅AWS博客文章《使用AmazonDynamoDB分区池多租户SaaS数据》。

在Amazon RDS和Aurora之间选择

在大多数情况下，我们建议使用Aurora PostgreSQL Compatible over Amazon RDS for PostgreSQL。下表显示了在选择这两个选项时应考虑的因素。

在上表中描述的所有类别中，Aurora PostgreSQL Compatible通常是更好的选择。然而，AmazonRDS for PostgreSQL对于中小型工作负载可能仍然有意义，因为它有更多的实例类选择，可能会以Aurora更强大的功能集为代价提供更具成本效益的选项。有关详细的比较，请参阅AWS博客文章AmazonRDS For PostgreSQL或AmazonAurora PostgreSQL是我更好的选择吗？

本节提供了关于在多租户SaaS应用程序中实现托管PostgreSQL的常见问题的答案。

AWS提供哪些托管PostgreSQL选项？

AWS为PostgreSQL提供Amazon Aurora PostgreSQL兼容和Amazon关系数据库服务（Amazon RDS）。AWS还拥有广泛的托管数据库产品目录。

哪种服务最适合SaaS应用程序？

您可以将Aurora PostgreSQL Compatible和Amazon RDS for PostgreSQL用于SaaS应用程序以及本指南中讨论的所有SaaS分区模型。这两种服务在可扩展性、故障恢复、故障切换、存储选项、高可用性、灾难恢复、备份以及每个选项可用的实例类方面存在差异。最佳选择将取决于您的具体用例。使用本指南中的决策矩阵为您的用例选择最佳选项。

如果我决定在多租户SaaS应用程序中使用PostgreSQL数据库，我应该考虑哪些独特的需求？

与SaaS应用程序使用的任何数据存储一样，最重要的考虑是维护租户数据隔离的方法。正如本指南中所讨论的，有多种方法可以通过AWS管理的PostgreSQL产品实现租户数据隔离。此外，对于任何PostgreSQL实现，您都应该考虑基于每个租户的性能隔离。

我可以使用哪些模型与PostgreSQL保持租户数据隔离？

您可以使用思洛存储器、网桥和池模型作为SaaS分区策略来维护租户数据隔离。有关这些模型及其如何应用于PostgreSQL的讨论，请参阅本指南中的PostgreSQL多租户SaaS分区模型一节。

如何使用多个租户共享的单个PostgreSQL数据库维护租户数据隔离？

PostgreSQL支持行级安全（RLS）功能，您可以使用该功能在单个PostgreSQL数据库或实例中强制租户数据隔离。此外，您可以在单个实例中为每个租户提供单独的PostgreSQL数据库，或在每个租户的基础上创建模式以实现此目标。有关这些方法的优点和缺点，请参阅本指南中的行级安全建议一节。

实现多租户的最佳方法取决于SaaS应用程序的需求。以下部分演示了在PostgreSQL中成功实现多租户的分区模型。

笔记

本节讨论的模型适用于Amazon RDS for PostgreSQL和Aurora PostgreSQL Compatible。本节中对PostgreSQL的引用适用于这两种服务。

PostgreSQL中有三种高级模型可用于SaaS分区：简仓、网桥和池。下图总结了简仓和池模型之间的权衡。桥梁模型是筒仓和水池模型的混合。

The following sections discuss each model in more detail.

Partitioning models:

• PostgreSQL silo model
• PostgreSQL pool model
• PostgreSQL bridge model
• Decision matrix

PostgreSQL 简仓模型

筒仓模型是通过为应用程序中的每个租户提供PostgreSQL实例来实现的。筒仓模型擅长租户性能和安全隔离，并完全消除了噪音邻居现象。当一个租户对系统的使用影响到另一个租户的性能时，就会出现噪声邻居现象。思洛存储器模型允许您专门为每个租户定制性能，并可能限制特定租户思洛存储器的中断。然而，通常推动筒仓模型采用的是严格的安全和监管约束。SaaS客户可以激发这些约束。例如，SaaS客户可能会因为内部限制而要求隔离他们的数据，SaaS提供商可能会额外收费提供此类服务。

尽管筒仓模型在某些情况下可能是必要的，但它有许多缺点。通常很难以经济高效的方式使用思洛存储器模型，因为跨多个PostgreSQL实例管理资源消耗可能很复杂。此外，该模型中数据库工作负载的分布式特性使得维护租户活动的集中视图变得更加困难。管理如此多独立操作的工作负载会增加操作和管理开销。筒仓模型还使租户注册变得更加复杂和耗时，因为您必须提供特定于租户的资源。此外，整个SaaS系统可能更难扩展，因为不断增加的租户特定PostgreSQL实例将需要更多的操作时间来管理。最后一个考虑是，应用程序或数据访问层必须维护租户到其关联PostgreSQL实例的映射，这增加了实现该模型的复杂性。

PostgreSQL池模型

池模型是通过提供单个PostgreSQL实例（Amazon RDS或Aurora）并使用行级安全性（RLS）来维护租户数据隔离来实现的。RLS策略限制SELECT查询返回表中的哪些行，或INSERT、UPDATE和DELETE命令影响哪些行。池模型将所有租户数据集中在一个PostgreSQL模式中，因此它更具成本效益，维护所需的操作开销也更少。由于其集中化，监控此解决方案也明显更简单。然而，在池模型中监视租户特定的影响通常需要在应用程序中使用一些附加的工具。这是因为PostgreSQL默认情况下不知道哪个租户正在消耗资源。由于不需要新的基础设施，因此简化了租户注册。这种灵活性使实现快速、自动化的租户入职工作流变得更加容易。

尽管池模型通常更具成本效益且更易于管理，但它确实存在一些缺点。在池模型中，噪声邻居现象不能完全消除。然而，可以通过确保PostgreSQL实例上有适当的资源以及使用减少PostgreSQL中负载的策略（例如将查询卸载到读取副本或AmazonElastiCache）来减轻这种情况。有效的监控在响应租户性能隔离问题方面也发挥着作用，因为应用程序检测可以记录和监控租户特定的活动。最后，一些SaaS客户可能觉得RLS提供的逻辑分离不够，可能会要求额外的隔离措施。

PostgreSQL桥模型

PostgreSQL桥模型是集合方法和孤立方法的组合。与池模型一样，您为每个租户提供一个PostgreSQL实例。为了维护租户数据隔离，您使用PostgreSQL逻辑结构。在下图中，PostgreSQL数据库用于逻辑分离数据。

笔记

PostgreSQL数据库不指单独的Amazon RDS for PostgreSQL或Aurora PostgreSQL Compatible DB实例。相反，它引用PostgreSQL数据库管理系统的逻辑结构来分离数据。

您还可以通过使用单个PostgreSQL数据库实现网桥模型，每个数据库中都有租户特定的模式，如下图所示。

网桥模型与池模型一样受到邻居和租户性能隔离问题的困扰。它还需要在每个租户的基础上配置单独的数据库或模式，从而导致一些额外的操作和配置开销。它需要有效的监控，以快速响应租户的性能问题。它还需要应用程序检测来监视租户特定的使用情况。总体而言，网桥模型可以被视为RLS的替代方案，它通过需要新的PostgreSQL数据库或模式来略微增加租户的入职工作。与思洛存储器模型一样，应用程序或数据访问层必须维护租户到其关联PostgreSQL数据库或模式的映射。

决策矩阵

要决定应使用PostgreSQL的多租户SaaS分区模型，请参阅以下决策矩阵。该矩阵分析了这四个分区选项：

• 简仓–每个租户的单独PostgreSQL实例或集群。
• 桥与独立的数据库–单个PostgreSQL实例或集群中每个租户的独立数据库。
• 桥与独立的模式–单个PostgreSQL数据库、单个PostgreQL实例或集群中每个租户的独立模式。
• Pool–单个实例和模式中租户的共享表。

本节列出了本指南的一些重要内容。有关每一点的详细讨论，请单击相应章节的链接。

比较托管PostgreSQL的AWS选项

AWS提供了在托管环境中运行PostgreSQL的两种主要方法。（在本文中，托管意味着AWS服务部分或完全支持PostgreSQL基础设施和DBMS。）AWS上的托管PostgreSQL选项具有自动备份、故障切换、优化和PostgreSQL管理的好处。作为托管选项，AWS为PostgreSQL提供Amazon Aurora PostgreSQL兼容版和Amazon关系数据库服务（Amazon RDS）。通过分析PostgreSQL用例，您可以从这两个模型中选择最佳选择。有关更多信息，请参阅本指南中的“在Amazon RDS和Aurora之间进行选择”一节。

选择多租户SaaS分区模型

您可以从三种适用于PostgreSQL的SaaS分区模型中进行选择：思洛存储器、网桥和池。每个模型都有优点和缺点，您应该根据您的用例选择最理想的模型。Amazon RDS for PostgreSQL和Aurora PostgreSQL Compatible支持所有三种模型。选择模型对于在SaaS应用程序中保持租户数据隔离至关重要。有关这些模型的详细讨论，请参阅本指南中PostgreSQL的多租户SaaS分区模型一节。

对池SaaS分区模型使用行级安全性

使用PostgreSQL在池模型中维护租户数据隔离需要行级安全性（RLS）。这是因为在池模型中，基础设施、PostgreSQL数据库或基于每个租户的模式之间没有逻辑分离。RLS将隔离策略的实施集中在数据库级别，并消除了软件开发人员维护隔离的负担。您可以使用RLS将数据库操作限制到特定租户。有关更多信息和示例，请参阅本指南中的行级别安全建议一节。

池模型本质上只有一个PostgreSQL实例。因此，为高可用性设计应用程序至关重要。池数据库的故障或中断会导致应用程序降级或所有租户都无法访问。

通过启用高可用性功能，AmazonRDS for PostgreSQL DB实例可以在两个可用性区域之间冗余。有关更多信息，请参阅Amazon RDS文档中的Amazon RDS高可用性（Multi-AZ）。对于跨区域故障切换，您可以在不同的AWS区域中创建读取副本。（此读取副本必须作为故障切换过程的一部分进行升级。）此外，您可以复制跨AWS区域复制的备份以进行恢复。有关更多信息，请参阅Amazon RDS文档中的将自动备份复制到另一个AWS区域。

Aurora PostgreSQL Compatible以能够承受多个可用区故障的方式自动备份数据。（请参阅Aurora文档中的Amazon Aurora的高可用性。）为了使Aurora更具弹性并更快地恢复，您可以在其他可用性区域中创建Aurora读取副本。您可以使用Aurora全局数据库将数据复制到另外五个AWS区域，以实现跨区域恢复和自动故障切换。（请参阅Aurora文档中的使用Amazon Aurora全球数据库。）

无论您使用的是Amazon RDS for PostgreSQL还是Aurora PostgreSQL Compatible，我们都建议您实施高可用性功能，以减轻所有使用池模型的多租户SaaS应用程序中断的影响。

需要行级安全性（RLS）来维护PostgreSQL池模型中的租户数据隔离。RLS将隔离策略的实施集中在数据库级别，并消除了软件开发人员维护隔离的负担。实现RLS的最常见方法是在PostgreSQL DBMS中启用此功能。RLS涉及根据指定列中的值过滤对数据行的访问。您可以使用两种方法来过滤对数据的访问：

将表中指定的数据列与当前PostgreSQL用户的值进行比较。该用户可以访问列中与登录的PostgreSQL用户等效的值。

将表中指定的数据列与应用程序设置的运行时变量的值进行比较。在该会话期间，可以访问列中与运行时变量等效的值。

第二个选项是首选的，因为第一个选项需要为每个租户创建一个新的PostgreSQL用户。相反，使用PostgreSQL的SaaS应用程序应该负责在运行时查询PostgreSQL时设置租户特定的上下文。这将产生强制执行RLS的效果。您还可以逐个表启用RLS。作为最佳实践，您应该在包含租户数据的所有表上启用RLS。

以下示例创建两个表并启用RLS。此示例将一列数据与运行时变量app.current_tempant的值进行比较。

-- Create a table for our tenants with indexes on the primary key and the tenant’s name

CREATE TABLE tenant (

    tenant_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,

    name VARCHAR(255) UNIQUE,

    status VARCHAR(64) CHECK (status IN ('active', 'suspended', 'disabled')),

    tier VARCHAR(64) CHECK (tier IN ('gold', 'silver', 'bronze'))

);

 

-- Create a table for users of a tenant

CREATE TABLE tenant_user (

    user_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,

    tenant_id UUID NOT NULL REFERENCES tenant (tenant_id) ON DELETE RESTRICT,

    email VARCHAR(255) NOT NULL UNIQUE,

    given_name VARCHAR(255) NOT NULL CHECK (given_name <> ''),

    family_name VARCHAR(255) NOT NULL CHECK (family_name <> '')

);

 

-- Turn on RLS

ALTER TABLE tenant ENABLE ROW LEVEL SECURITY;

 

-- Restrict read and write actions so tenants can only see their rows

-- Cast the UUID value in tenant_id to match the type current_setting

-- This policy implies a WITH CHECK that matches the USING clause

CREATE POLICY tenant_isolation_policy ON tenant

USING (tenant_id = current_setting('app.current_tenant')::UUID);

 

-- And do the same for the tenant users

ALTER TABLE tenant_user ENABLE ROW LEVEL SECURITY;

 

CREATE POLICY tenant_user_isolation_policy ON tenant_user

USING (tenant_id = current_setting('app.current_tenant')::UUID);

有关更多信息，请参阅PostgreSQL行级安全的多租户数据隔离博客。AWS SaaS工厂团队也在GitHub中提供了一些示例来帮助实现RLS。

工具书类

• SaaS Storage Strategies: Building a Multitenant Storage Model on AWS (AWS whitepaper)

• Is Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL a better choice for me? (AWS blog post)

• Cross-Region disaster recovery using Amazon Aurora Global Database for Amazon Aurora PostgreSQL (AWS blog post)

• Multitenant data isolation with PostgreSQL Row Level Security (AWS blog post)

• Working with Amazon Aurora PostgreSQL (Aurora documentation)

• PostgreSQL on Amazon RDS (Amazon RDS documentation)

合作伙伴

• Amazon Aurora for PostgreSQL Partners

• Amazon RDS for PostgreSQL Partners