为 SaaS 应用程序选择数据库

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

• 应用程序的数据模型

• 数据的访问模式

• 数据库延迟要求

• 数据完整性和事务完整性要求（原子性、一致性、隔离性和持久性或 ACID）

• 跨区域可用性和恢复要求

下表列出了应用程序数据要求和特征，并在 AWS 数据库产品的背景下对其进行了讨论：兼容 Aurora PostgreSQL 和适用于 PostgreSQL 的 Amazon RDS（关系），以及亚马逊 DynamoDB（非关系）。当你试图在关系型和非关系型操作数据库产品之间做出决定时，你可以参考这个矩阵。

数据库	SaaS 应用程序数据要求和特征
	数据模型	访问模式	延迟要求	数据和交易完整性	跨区域可用性和恢复
关系型 （兼容 Aurora PostgreSQL 和适用于 PostgreSQL 的亚马逊 RDS）	关系型或高度标准化型。	不必事先进行彻底的计划。	最好是更高的延迟容忍度；默认情况下，使用 Aurora 以及通过实现只读副本、缓存和类似功能可以实现更低的延迟。	默认情况下，保持高数据和交易完整性。	在 Amazon RDS 中，您可以创建用于跨区域扩展和故障转移的只读副本。Aurora 主要实现这一过程的自动化。对于跨多个的主动-主动配置 AWS 区域，您可以将写入转发与 A urora 全局数据库结合使用。
非关系型 （亚马逊 DynamoDB）	通常是非规范化的。这些数据库利用模式对many-to-many关系、大型项目和时间序列数据进行建模。	在生成数据模型之前，必须彻底了解数据的所有访问模式（查询）。	借助诸如亚马逊 DynamoDB 加速器 (DAX) 之类的选项，延迟非常低，可以进一步提高性能。	以牺牲性能为代价的可选交易完整性。数据完整性问题已转移到应用程序上。	使用全局表轻松实现跨区域恢复和主动-主动配置。（只有在单个 AWS 地区才能实现 ACID 合规性。）

某些多租户 SaaS 应用程序可能具有独特的数据模型或特殊情况，上表中未包含的数据库可以更好地满足这些需求。例如，时间序列数据集、高度互联的数据集或维护集中式交易账本可能需要使用不同类型的数据库。分析所有可能性超出了本指南的范围。有关 AWS 数据库产品以及它们如何从高层次满足不同用例的完整列表，请参阅《Amazon Web Services 概述》白皮书的 “数据库” 部分。

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

在 Amazon RDS 和 Aurora 之间进行选择

在大多数情况下，我们建议使用兼容 Aurora PostgreSQL 而不是亚马逊 RDS for PostgreSQL。下表显示了在这两个选项之间做出决定时应考虑的因素。

DBMS 组件	Amazon RDS for PostgreSQL	兼容 Aurora PostgreSQL
可扩展性	复制延迟几分钟，最多 5 个只读副本	复制延迟不到一分钟（对于全局数据库，复制延迟通常小于 1 秒），最多 15 个只读副本
崩溃恢复	检查点间隔 5 分钟（默认情况下），可能会降低数据库性能	使用并行线程进行异步恢复，可实现快速恢复
故障转移	除了崩溃恢复时间外，还有 60-120 秒	通常大约 30 秒（包括崩溃恢复）
存储	最大 IOPS 为 256,000	IOPS 仅受 Aurora 实例大小和容量的限制
高可用性和灾难恢复	两个可用区，带备用实例，跨区域故障转移到只读副本或复制的备份	默认为三个可用区，使用 Aurora 全球数据库进行跨区域故障转移，主动-主动配置跨 AWS 区域 写入转发
备份	在备份窗口期间，可能会影响性能	自动增量备份，不影响性能
数据库实例类	查看 Amazon RDS 实例类列表	查看 Aurora 实例类列表

在上表中描述的所有类别中，兼容Aurora PostgreSQL通常是更好的选择。但是，对于中小型工作负载，Amazon RDS for PostgreSQL 可能仍然有意义，因为它有更多的实例类可供选择，可能会以牺牲Aurora更强大的功能集为代价，提供更具成本效益的选择。