将您的关系数据库扩展到 SaaS，第一部分：常见扩展模式 数据库博客

扩展您的关系型数据库以支持SaaS：第一部分：常见的扩展模式

文章重点

在SaaS软件即服务业务增长的过程中，维护租户体验是一个主要挑战，这包括确保随着租户数量的增加，性能和响应时间依然处于可接受的范围。SaaS提供商通常使用Amazon RDS和Amazon Aurora等关系型数据库，随着业务发展的需求，他们需要考虑如何有效地扩展数据库。

本文将探讨常见的关系型数据库扩展模式，并提供针对SaaS提供商的指导，以帮助理解何时以及如何实施这些扩展策略。

数据库扩展与SaaS分区模型

在深入了解数据库扩展之前，理解SaaS数据分区模型是非常重要的。可以使用的三个高层次的SaaS分区模型包括：

随着SaaS解决方案的扩展，单个数据库可能最终成为性能瓶颈，因此理解可选的扩展策略非常重要。

数据库扩展主要可以分为以下三类：

通常，结合多种扩展机制会带来最佳效果，一些扩展模式更适合于特定的分区模型和使用模式，本文系列将对此进行深入探讨。

通过额外的物理资源扩展现有架构

增加更多物理资源通常是SaaS提供商在扩展关系型数据库时的首选方式。虽然有物理资源增长的上限，但这是一个有效的扩展方式，无需进行可能影响核心业务目标的架构更改，尽管这会导致更高的基础设施成本。

垂直扩展

SaaS提供商常常选择垂直扩展作为首个扩展方式。这意味着提供更多的物理资源CPU、内存、网络，以支持更多的并发连接。您可以保留现有的分区模型，在不更改连接配置的情况下就扩展数据库。

在Amazon RDS中，您可以选择新的实例类型，将资源纵向扩展到任何可用的实例大小。这会重新启动实例，可能会有一些最小的停机时间，但使用Amazon Aurora Serverless v2则可在不影响服务的情况下进行扩展。这使其成为SaaS提供商处理可变数据库工作负载的理想选择。

对于独立模型，垂直扩展与非SaaS应用程序没有特殊的区别。然而，在桥接和池模型中，您需评估扩展的需求并考虑潜在的风险。扩展以容纳更多租户可能会增加性能影响事件的影响范围，比如“吵闹邻居”或基础设施故障。因此，如果由于单个租户影响其他租户的可用性而需要扩展，可以考虑限制该租户的性能，或者将其迁移到独立数据库中，以提供更好的服务体验。

通过读副本进行水平扩展

如果需要解决读取负载问题，使用读副本是一种可以提高性能而无需更改数据分区模型的方式。这还提供其他好处，例如可以将RDS读副本提升为独立实例，或将Aurora存储卷克隆到新集群，这能够提高可用性或促进数据库分片。

Aurora集群最多可以容纳15个读副本，可以一键配置。此外，Aurora读副本使用存储层复制，不会对主数据库造成传统复制方法造成的性能影响。通过引入多个读副本，可以在不影响使用主实例的服务的情况下，在SaaS产品中基于读取操作增加附加服务功能。

添加或删除读副本不需要停机。如果启用Aurora副本的自动扩展，则可以自动管理读副本的扩展，降低操作复杂性。

优化现有架构

另一种提高数据库性能的方式是优化现有架构，以提高数据库效率，而不改变分区模型。这种方法可以推迟扩展的需求，或仅仅通过提高性能改善租户服务体验。每种优化方法针对的具体用例不同，因此了解哪些方法适合您的产品是非常重要的。

微批处理

每个数据库请求都有与之相关的性能开销。如果您的SaaS应用程序有很多用户频繁发送请求，则数据库可能会受到处理大量并发请求的累积开销影响。通过将相似的请求批量处理，您可以减少这种影响，这种方式被称为微批处理。

当有许多用户进行频繁的小请求时，这种方法在所有分区模型中都是有效的。特别是在池模型中，因为它可以帮助您在每个数据库实例中支持更多租户，从而进一步提高操作效率。

您可能需要创建一种解决方案来处理微批处理，这将增加您的操作复杂性。在以下示例中，应用程序并不是直接写入数据库，而是写入Amazon Simple Queue ServiceAmazon SQS队列。随后，AWS Lambda函数轮询这个SQS队列，消费一批消息，并以原子方式将其写入数据库。

数据库表分区

大多数关系型数据库支持表分区，允许您将一个逻辑上大的数据库表划分成较小的物理部分。当您访问某个分区内的数据时，您不需要遍历整个父表来查找特定数据。这在池模型中尤其有利，因为您的SaaS应用程序使用一个大型多租户数据集。

通过使用分区键例如按日期或租户ID分段一个表。在数据库引擎的帮助下，可以使用范围、指定的键列表或对分区键的哈希值进行表分区。根表的访问保持不变，并且您无需重新架构查询以利用表分区的优势。

通过在池模型中将tenantid作为分区键，您可以在不重新架构应用程序代码的情况下提高特定租户查询的性能。以下图表展示了一个示例实现。

通过使用tenantid进行表分区，您可以超越单一物理资源的限制，将概念扩展到数据库分片中。我们将在本系列的第二部分中进一步探讨这一点。

数据库表分区可能引入热点问题，即某个分区成为性能瓶颈，需进行重平衡。同时，这也增加了管理分区的操作开销。如果您在使用Amazon RDS for PostgreSQL或Amazon Aurora PostgreSQL兼容版，您可以利用PostgreSQL的pgpartman扩展来自动化表分区的创建和维护。

在进行任何维护操作时，您应考虑分区限制及锁定行为，因为这可能不适合许多租户共同使用同一数据库。与环境中的任何更改一样，要监控您的期望结果，适时进行调整。

数据聚合

SaaS提供商常常对数据集进行每用户或每租户的聚合，以向租户提供分析洞察。您可能会进行租户或跨租户的聚合，以提高数据集的多租户性能。这可能导致数据库同时处理在线事务处理OLTP和在线分析处理OLAP查询。

执行读取聚合的开销昂贵，可能影响租户。如果这种活动不可预测，则可能会挑战维持租户的一致性能水平，降低服务体验。在桥接和池模型中，这种影响更为显著，因为多个租户竞争相同的物理数据库资源，并可能同时运行竞争性聚合活动。

如果您的服务不需要来自这些聚合活动的实时数据，则可以预先计算结果。例如，您可以每三小时生成租户数据的分析，而不是实时计算。这有助于提供更均匀的数据库性能，租户服务体验会得到改善，因为结果可以立即获取而无需等待计算完成。您甚至可以在RDS for PostgreSQL或Aurora Postgresql数据库中使用pgcron来自动化这一活动。利用读副本输送这些结果可以进一步提高性能。

此外，您可以通过将分析查询转移到数据仓库如Amazon Redshift来进一步增强此能力。Aurora与Amazon Redshift之间的零ETL集成使您能够在事务数据库和分析数据库之间近乎实时地自动同步数据，而无需开发复杂的数据管道。

您需要评估用例以验证维护预计算过程的开销是否值得。如果您的数据访问模式很少执行这样的聚合，则不太可能获得正向的投资回报。

扩展数据库连接

数据库同时连接数是有限的，随着租户数量的增加，可能会达到这一限制，尤其是在桥接或池扩展模型中。这可能导致超时和不一致的性能。

实现数据库代理，如Amazon RDS Proxy，可以使您池化和共享数据库连接，从而进一步扩展数据库。有关RDS Proxy性能特性的更多详细信息，请参见建立和负载测试多租户SaaS数据库代理解决方案。另外，可以考虑使用连接无关的数据库接口，如RDS Data API。

引入特定用途的数据库

为了保持数据库性能与增长相匹配，您可能需要考虑更改数据库架构，以优化特定用例。一个方法是使用同一个数据库中的独立逻辑架构，每个架构针对不同的用例进行优化。

随着SaaS应用程序功能的发展，将一个数据集分解为多个数据集可能会带来好处。您可以隔离单个访问模式，并将其移动到目的性数据库中，而不是试图为多种不同的访问模式进行优化，最终得到最低共同分母。

例如，您可以使用NoSQL数据库如亚马逊DynamoDB处理高吞吐量的事务数据，或作为租户管理的键值存储。您还可以使用数据仓库如Amazon Redshift来处理聚合活动中的数据，从而为需要更高性能水平的租户引入新的服务层。您甚至可以引入在现有关系型数据库中难以实现的新功能，例如使用Amazon Neptune进行欺诈检测，从而为您现有的SaaS产品捕获新的市场。

引入特定用途的数据库会改变租户隔离的实施方式，可能需要您重新评估分区模型。尽管您可以保留分区模型，但租户隔离的实现方式可能会有所不同。在评估新数据库技术时，请将此考虑在内。

有关进一步的信息，我们建议遵循AWS WellArchitected Framework所提供的指导，特别是性能支柱中的数据库架构选择以及数据分析透视。

验证您的数据库扩展策略

您应彻底测试并验证您的扩展策略是否符合预期。度量Metrics在为这些决策提供数据方面起着重要作用。例如，您可以使用Amazon RDS 性能洞察以简单、自动化的方式监控数据库性能度量，或启用增强监控查看RDS数据库实例上的所有系统度量。力求将性能度量纳入操作管理任务中，以识别何时扩展未按预期工作，以及何时需要新扩展机制。

结论

随着您的SaaS应用程序的发展，您的数据库架构也会不断演变。在SaaS旅程中，您需要决定是继续扩展现有架构，还是更改架构以满足增长需求。您应基于度量支持您的决策，验证您的扩展策略是否有效，并保持这些见解，以识别何时需要额外的扩展方法。

在本文中，我们讨论了几种关系型数据库扩展方法及其与SaaS应用程序的相关性，以帮助您做出明智的决策。请参阅第二部分，我们将探讨数据库分片及其租户到相应数据集的路由管理。

关于AWS SaaS工厂

AWS SaaS工厂帮助任何阶段的SaaS旅程中的组织。无论是建立新产品，迁移现有应用程序，还是优化AWS上的SaaS解决方案，我们都可以提供帮助。访问AWS SaaS工厂见解中心以了解更多技术和业务内容及最佳实践。

我们鼓励您与您的客户代表联系，以查询参与模型并与AWS SaaS工厂团队合作。

关于作者

Dave Roberts 是高级解决方案架构师，AWS SaaS工厂团队的一员，他指导AWS合作伙伴在AWS上构建SaaS产品。除了谈论SaaS，他还喜欢制作吉他效果器，和家人一起去森林里度过时光。

Josh Hart 是亚马逊网络服务的首席解决方案架构师。他与英国的ISV客户合作，帮助他们在AWS上构建和现代化他们的SaaS应用程序。