摘要

多租户存储是构建和交付软件即服务（SaaS）解决方案的一个更具挑战性的方面。有多种策略可用于划分租户数据，每种策略都有一组独特的细微差别，从而形成您的多租户方法。更为复杂的是，需要将这些策略中的每一种映射到AWS提供的不同存储模型，如Amazon DynamoDB、Amazon关系数据库服务（Amazon RDS）和Amazon Redshift。尽管有一些高级主题可以普遍应用于这些技术，但每个存储模型都有自己的方法来确定多租户环境中的范围、管理和保护数据。本文为SaaS开发人员提供了一系列数据分区选项的见解，使他们能够确定哪种策略和存储技术的组合最符合SaaS环境的需求。

您的架构是否完善？

AWS良好架构框架有助于您了解在云中构建系统时所做决策的利弊。框架的六大支柱使您能够学习设计和运行可靠、安全、高效、经济高效和可持续系统的架构最佳实践。使用AWS管理控制台中免费提供的AWS良好架构工具，您可以通过回答每个支柱的一组问题，对照这些最佳实践检查工作负载。

在SaaS镜头中，我们专注于在AWS上构建软件即服务（SaaS）工作负载的最佳实践。

有关云架构参考架构部署、图表和白皮书的更多专家指南和最佳实践，请参阅AWS架构中心。

介绍

AWS为软件即服务（SaaS）开发人员提供了一系列丰富的存储解决方案，每个解决方案都有自己的范围、资源调配、管理和保护数据的方法。每个服务表示、索引和存储数据的方式为您的多租户策略添加了一组独特的考虑因素。作为SaaS开发人员，这些存储选项的多样性为您提供了将SaaS解决方案的存储需求与最符合您的业务和客户需求的存储技术相结合的机会。

在权衡AWS存储选项时，还必须考虑SaaS解决方案的多租户模型如何与每种存储技术相适应。正如存储有多种风格一样，也有多种风格的多租户分区策略。目标是找到存储和租户分区需求的最佳交集。

本文探讨了这个谜题的所有活动部分。它检查并分类通常用于实现多租户的模型，并帮助您权衡影响分区模型选择的利弊。它还概述了每个模型是如何在Amazon RDS、Amazon DynamoDB和Amazon Redshift上实现的。当您深入了解每种存储技术时，您将了解如何使用AWS构造来确定和管理多租户存储。

尽管本文为您提供了选择多租户分区策略的一般指导，但必须认识到，环境的业务、技术和运营维度通常会引入一些因素，这些因素也会影响您选择的方法。在许多情况下，SaaS组织采用本文中描述的变体的混合。

首先，您需要一个定义良好的概念模型来帮助您理解各种实现策略。

下图显示了在SaaS环境中划分租户数据时通常使用的三个基本模型思洛存储器、网桥和池。

每个分区模型采用非常不同的方法来管理、访问和分离租户数据。以下各节对模型进行了快速分解，使您能够在任何特定存储技术的上下文之外探索每个模型的价值和原则。

SaaS分区模型

筒仓模型

在思洛存储器模型中，租户数据的存储与任何其他租户数据完全隔离。用于表示租户数据的所有构造都被认为是该客户端在逻辑上“唯一”的，这意味着每个租户通常都有不同的表示、监视、管理和安全足迹。

桥梁模型

桥接模型通常是SaaS开发人员的一种极具吸引力的折衷方案。Bridge将租户的所有数据移动到单个数据库中，同时仍允许每个租户有一定程度的差异和分离。通常，通过为每个租户和allow创建单独的表来实现这一点，每个租户和允许表都有自己的数据表示（模式）。

水池模型

池模型表示多租户模式，其中租户共享系统的所有存储结构。租户数据被放置在一个公共数据库中，所有租户共享一个公共表示（模式）。这需要引入一个分区键，用于确定和控制对租户数据的访问。该模型倾向于简化SaaS解决方案的供应、管理和更新体验。它也很好地符合SaaS提供商所必需的持续交付和敏捷性目标。

设置背景

筒仓、桥梁和水池模型为我们的讨论提供了背景。当您深入了解每种AWS存储技术时，您将发现这些模型的概念元素是如何在特定的AWS存储技术上实现的。有些模型非常直接地映射到这些模型；其他人需要更多的创造力来实现每种类型的租户隔离。

值得注意的是，这些模型都同样有效。尽管我们将讨论每种方法的优点，但给定环境的监管、业务和遗留方面通常在最终选择的方法中起着重要作用。这里的目标是简单地介绍与每种方法相关的机制和权衡。

选择多租户分区存储模型策略受到许多不同因素的影响。如果您正在从现有解决方案迁移，您可能会倾向于采用筒仓模型，因为它可以创建最简单、最干净的方式来过渡到多租户，而无需重写SaaS应用程序。如果您的监管或行业动态需要一个更独立的模型，那么池模型的效率和灵活性可能会为您打开通向快速、持续发布环境的道路。这里的关键是要认识到，您选择的战略将由您环境中的业务和技术考虑因素的组合驱动。

在以下各节中，我们重点介绍了每个模型的优点和缺点，并为您提供了一组定义良好的数据点，作为更广泛评估的一部分。您将了解每个模型如何影响您与敏捷性目标保持一致的能力，而敏捷性目标通常是采用SaaS模型的核心。在为SaaS环境选择架构策略时，请考虑该策略如何影响您在零停机环境中快速构建、交付和部署版本的能力。

评估权衡

如果您将三个分区模型（筒仓、桥和池）放在一个谱上，您将看到与采用任何一种策略相关的自然紧张关系。在一个模型中被列为优势的质量通常在另一模型中被表示为劣势。例如，筒仓模型的原则和价值体系往往与池模型的原则与价值体系相反。

分区模型权衡

上图突出了这些相互竞争的原则。在图的顶部，您将看到所表示的三个分区模型。左边是筒仓模型的优点和缺点。在右边，我们为池模型提供了类似的列表。桥梁模型有点混合了这些考虑因素，因此代表了极端情况下的利弊。

筒仓模型权衡

在完全独立的数据库中表示租户数据可能很有吸引力。除了简化现有单租户解决方案的迁移之外，这种方法还解决了一些租户可能对运行完全共享的基础设施的担忧。

优点

思洛对具有严格监管和安全约束的SaaS解决方案很有吸引力-在这些环境中，您的SaaS客户对其数据必须如何与其他租户隔离有非常明确的期望。思洛存储器模型允许您为租户提供一个选项，在租户数据之间创建一个更具体的边界，并让您的客户感觉到他们的数据存储在一个更专用的模型中。

跨租户的影响是有限的——这里的想法是，通过隔离思洛存储器模型，您可以确保一个租户的活动不会影响另一个租户。该模型允许租户特定的调整，其中系统的数据库性能SLA可以根据给定租户的需要进行调整。用于调整数据库的旋钮和刻度盘通常也具有到筒仓模型的更自然的映射，这使得配置以租户为中心的体验更加简单。

可用性是在租户级别进行管理的，最大限度地减少了租户的停机风险-每个租户都在自己的数据库中，您不必担心数据库停机可能会波及所有租户。如果一个租户存在数据问题，则不太可能对系统的其他租户产生不利影响。

缺点

资源调配和管理更为复杂——无论何时引入每租户的基础设施，都会引入另一个移动部分，必须逐个租户进行配置和管理。例如，您可以想象一个孤立的数据库解决方案会如何影响系统的租户登录体验。您的注册过程需要自动化，以便在注册过程中创建和配置数据库。这当然是可以实现的，但它增加了一层复杂性，也增加了SaaS环境中的潜在故障点。

您查看租户活动并对其做出反应的能力会受到影响-使用SaaS，您可能需要一种管理和监控体验，以提供跨租户的系统运行状况视图。您希望主动预测数据库性能问题，并以更全面的方式对策略作出反应。然而，筒仓模型使您更加努力地寻找和引入工具，以创建覆盖所有租户的聚合的、系统范围的健康视图。

思洛存储器模型的分布式影响了您跨租户有效分析和评估性能趋势的能力—每个租户都将数据存储在自己的思洛存储器中，您只能在以租户为中心的模型中管理和调整服务负载。这基本上导致引入一组一次性设置和策略，您必须独立管理和调整这些设置和策略。这可能既效率低下，又可能造成开销，从而削弱您快速响应客户需求的能力。

筒仓限制了成本优化—筒仓模型的一次性特性可能会限制您调整存储资源消耗的能力，这可能是最显著的缺点。

池模型权衡

池模式代表了SaaS生活方式的终极承诺。使用池模型，您的重点是为租户提供统一的方法，使您能够优化租户存储资源调配、迁移、管理和监控。

优点

灵活性—一旦您的所有租户数据集中在一个存储结构中，您就可以更好地创建工具和生命周期，以支持一种简化的通用方法，快速为所有租户部署存储解决方案。这种灵活性也扩展到您的入职流程。使用池模型，您不需要为注册SaaS服务的每个租户提供单独的存储基础架构。您可以简单地配置新租户，并使用该租户的ID作为索引，从所有租户使用的共享存储模型中访问租户的数据。

存储监控和管理更简单—在池模型中，使用工具和聚合分析来总结租户存储活动更为自然。这里可以利用您用来管理单个存储模型的日常工具来构建系统运行状况的全面、跨租户视图。使用池模型，您可以更好地引入可用于主动响应系统事件的全局策略。通常，将数据统一到单个数据库和共享表示中简化了多租户存储、部署和管理体验的许多方面。

其他选项有助于优化SaaS解决方案的成本足迹-成本机会通常以性能调整的形式出现。例如，您可以将吞吐量优化作为一个策略应用于所有租户（而不是逐个租户管理单独的策略）。

池提高了部署自动化和操作灵活性—池模型的共享特性通常会降低数据库部署自动化的总体复杂性，这与SaaS对持续频繁发布新产品功能的需求非常吻合。

缺点

灵活性意味着管理规模和可用性的门槛更高—想象一下在池化多租户环境中存储中断的影响。现在，不是只有一个客户倒下，而是所有客户都倒下了。这就是为什么采用池模型的组织也倾向于在其环境的自动化和测试方面投入更多的资金。池式解决方案需要主动监控解决方案和健壮的版本控制、数据和模式迁移。发布必须顺利进行，租户问题需要得到有效捕捉和解决。

池对租户数据分布的管理提出了挑战—在某些情况下，租户数据的大小和分布也可能成为池存储的挑战。租户往往会在您的系统上施加不同程度的负载，这些变化可能会破坏您的存储性能。池模型需要更多地考虑您将使用哪些机制来解释租户负载的这些变化。数据的大小和分布也会影响数据迁移的方式。这些问题通常是特定存储技术所特有的，需要逐个解决。

共享环境的共享性质可能会在某些领域遇到阻力——对于某些SaaS产品，客户将需要一个筒仓模型来满足其法规和内部数据保护要求。

混合：商业妥协

对于许多组织来说，战略的选择并不像选择筒仓、桥梁或池模型那么简单。您的租户和您的企业将对您选择存储策略的方式产生重大影响。

在某些情况下，团队可能会确定一小部分需要筒仓或桥梁模型的租户。一旦他们做出了这一决定，他们就认为必须使用该模型实现所有存储。这人为地限制了您接受可能对池模式开放的租户的能力。事实上，这可能会增加一层租户的成本或复杂性，因为他们不需要筒仓或桥梁模型的属性。

一种可能的折衷方案是构建一个完全支持池存储的解决方案作为基础。然后，您可以为那些需要孤立存储解决方案的租户创建一个单独的数据库。下图提供了这种方法的一个实例。

混合筒仓/池存储

这里，我们有两个租户（租户1和租户2）正在利用思洛存储器模型，其余租户在池存储模型中运行。数据访问层将开发人员从租户的底层存储中隐藏起来，从而神奇地将其抽象出来。

尽管这可能会增加数据访问层和管理配置文件的复杂性，但它也可以为您的业务提供一种方式，将您的产品分层，以代表两个世界的最佳。

Amazon Redshift为您的多租户思维带来了额外的变化。Amazon Redshift专注于构建高性能集群，以容纳大型数据仓库。AmazonRedshift还对您可以在每个集群中创建的构造设置了一些限制。考虑以下限制：

• 每个群集60个数据库
• 每个数据库256个schemas 
• 每个数据库500个并发连接
• 50个并发查询

通过访问群集，可以访问群集中的所有数据库

您可以想象这些限制如何影响交付给Amazon Redshift的规模和性能。您还可以看到这些限制如何影响您使用Amazon Redshift进行多租户的方法。如果您的目标是适度的租户数量，这些限制可能对您的解决方案影响不大。然而，如果您的目标是大量租户，则需要将这些限制因素纳入您的总体战略。

以下部分重点介绍了在AmazonRedshift上实现每种多租户存储模型时常用的策略。

筒仓模型

在AmazonRedshift上实现租户的真正筒仓模型隔离需要为每个租户提供单独的集群。通过集群，您可以在租户之间创建定义良好的边界，这通常是确保客户的数据与跨租户访问成功隔离所必需的。这种方法最好地利用了AmazonRedShift中的自然安全机制，因此您可以使用IAM策略和数据库权限的组合来控制和限制租户对集群的访问。IAM控制整个群集管理，数据库权限用于控制对群集内数据的访问。

思洛存储器模型为您提供了为每个租户创建优化体验的机会。使用AmazonRedshift，您可以配置集群中节点的数量和类型，以便创建针对每个租户的负载配置文件的环境。您还可以将此作为优化成本的策略。

正如我们在其他思洛存储器模型中所看到的那样，该模型的挑战在于，每个租户的集群都必须作为入职流程的一部分进行配置。自动化此过程并吸收与资源调配过程相关的额外时间和开销会给您的部署足迹增加一层复杂性。它也会对分配新租户的速度产生一些影响。

桥梁模型

桥梁模型在Amazon Redshift上没有自然映射。从技术上讲，您可以为每个租户创建单独的模式。然而，您可能会遇到AmazonRedshift限制256个模式的问题。在有大量租户的环境中，这根本无法扩展。在桥接模式中，安全性也是Amazon Redshift面临的挑战。当您被授权为AmazonRedshift集群的用户时，您可以访问该集群中的所有数据库。这就需要对SaaS应用程序实施更细粒度的访问控制。

考虑到桥接模型的动机和这些技术考虑，大多数SaaS提供商考虑在Amazon Redshift上使用这种方法似乎不切实际。即使您的解决方案可以管理这些限制，客户也可能无法接受隔离配置文件。最终，最好的答案是对任何需要隔离的租户简单地使用筒仓模型。

水池模型

在AmazonRedshift上构建池模型与我们讨论过的其他存储模型非常相似。其基本思想是将所有租户的数据存储在一个具有共享数据库和表的AmazonRedshift集群中。在这种方法中，通过引入表示唯一租户标识符的列来划分租户的数据。

这种方法提供了我们在其他游泳池模型中看到的大部分优点。当然，通过将所有租户数据存储在一个AmazonRedshift集群中，整体管理、监控和灵活性都得到了改善。

并发连接的限制为在AmazonRedshift上实现池模型增加了一定的难度。通过500个并发连接的上限，许多多租户SaaS环境可以很快超过这个限制。这并不能消除池模型的争用。相反，它将更多的责任推给SaaS开发人员，以制定有效的策略来管理如何以及何时使用和释放这些连接。

有一些常见的方法来解决连接管理问题。开发人员通常利用基于客户端的缓存来限制他们对Amazon Redshift的实际连接需求。连接池也可以应用于此模型。开发人员需要选择一种策略，以确保在不超过AmazonRedshift连接限制的情况下有效满足其应用程序的数据访问模式。

采用池模型还意味着要关注在共享基础设施中运行时出现的典型问题。例如，数据的安全需要一些应用程序级别的策略来限制跨租户访问。此外，您可能需要不断调整和优化环境的性能，以防止任何一个租户降低其他租户的体验。

DynamoDB如何确定数据范围和管理数据的性质为您如何处理多租户增加了一些新的变化。尽管一些存储服务与传统的数据分区策略很好地保持一致，但DynamoDB对思洛存储器、网桥和池模型的映射略不直接。使用DynamoDB，在选择多租户策略时，您必须考虑一些其他因素。

接下来的章节将探讨AWS机制，这些机制通常用于在DynamoDB上实现每个多租户分区方案。

筒仓模型

在研究如何在DynamicDB上实现思洛存储器模型之前，必须首先考虑服务的作用域和控制数据访问的方式。与RDS不同，DynamicDB没有数据库实例的概念。相反，在DynamoDB中创建的所有表都是区域内某个帐户的全局表。这意味着该区域中的每个表名对于给定帐户都必须是唯一的。

带DynamoDB表的筒仓模型

如果您在DynamoDB上实现了一个思洛存储器模型，则必须找到某种方法来创建一个或多个与特定租户关联的表的分组。该方法还必须创建这些表的安全、受控视图，以满足思洛存储器客户的安全要求，防止任何跨租户数据访问的可能性。

上图显示了如何实现租户范围的表分组的一个示例。请注意，为每个租户创建了两个表（Account和Customer）。这些表还具有一个在表名称前附加的租户标识符。这解决了DynamoDB的表命名要求，并在表及其关联租户之间创建了必要的绑定。

通过引入IAM政策，也可以访问这些表。您的配置过程需要自动为每个租户创建策略，并将该策略应用于给定租户拥有的表。

这种方法实现了筒仓模型的基本隔离目标，在每个租户的数据之间定义了清晰的边界。它还允许逐个租户进行调整和优化。您可以调整两个特定区域：

• Amazon CloudWatch度量可以在表级别捕获，从而简化了存储活动租户度量的聚合。
• 表写入和读取容量（以每秒输入和输出（IOPS）衡量）应用于表级别，允许您为每个租户创建不同的扩展策略。

这种模式的缺点往往更多地体现在运营和管理方面。显然，使用这种方法，租户的操作视图需要了解租户表命名方案，以便在以租户为中心的上下文中过滤和显示信息。该方法还为需要与这些表交互的任何代码添加了一层间接层。与DynamoDB表的每次交互都需要插入租户上下文，以将每个请求映射到相应的租户表。

采用基于微服务架构的SaaS提供商也有另一层考虑。对于微服务，团队通常将存储责任分配给各个服务。每个服务都可以自由决定如何存储和管理数据。这可能会使DynamoDB上的隔离情况变得复杂，需要您扩展表的数量以适应每个服务的需求。它还添加了作用域的另一个维度，其中每个服务的每个表都标识其与服务的绑定。

为了抵消这些挑战并更好地与DynamoDB最佳实践保持一致，请考虑为所有租户数据提供一个表。此方法提供了多种效率，并简化了解决方案的资源调配、管理和迁移配置文件。

在大多数情况下，使用单独的DynamoDB表和IAM策略来隔离租户数据可以满足思洛存储器模型的需要。您唯一的其他选择是考虑前面描述的链接帐户筒仓模型。然而，如前所述，链接帐户隔离模型还存在其他限制和考虑因素。

桥梁模型

对于DynamoDB，桥梁模型和筒仓模型之间的界限非常模糊。本质上，如果您使用网桥模型的目标是为每个客户端提供一个具有一次性模式变化的单一帐户，那么您可以看到如何使用前面描述的思洛存储器模型实现这一点。

对于桥接器，唯一的问题是您是否可以放宽筒仓模型中描述的一些隔离要求。您可以通过取消引入任何表级IAM策略来实现这一点。假设您的租户不需要完全隔离，您可以认为删除IAM策略可以简化您的资源调配方案。然而，即使在桥上，隔离也有好处。因此，尽管放弃IAM隔离可能很有吸引力，但利用可以限制跨租户访问的结构和策略仍然是一个很好的SaaS实践。

水池模型

在DynamoDB上实现池模型需要您后退一步，并考虑服务如何管理数据。由于数据存储在DynamoDB中，服务必须不断评估和划分数据以实现规模。而且，如果您的数据分布均匀，您可以简单地依靠这种底层分区方案来优化SaaS租户的性能和成本分布。

这里的挑战是，多租户SaaS环境中的数据通常没有统一的分布。SaaS租户有各种各样的形状和大小，因此，他们的数据并不统一。SaaS供应商很常见的情况是，最终只有少数租户占用了他们大部分的数据。

了解了这一点，您可以看到它是如何在DynamicDB之上实现池模型的。如果您简单地将租户标识符映射到DynamoDB分区键，您将很快发现您还创建了分区“热点”。想象一下，有一个非常大的租户会破坏DynamoDB如何有效地划分数据。这些热点会影响解决方案的成本和性能。由于密钥分布不理想，您需要提高IOPS以抵消热分区的影响。对更高IOPS的需求直接转化为解决方案的更高成本。

为了解决这个问题，您必须引入一些机制来更好地控制租户数据的分布。您需要一种不依赖单个租户标识符来划分数据的方法。这些因素都导致了一条路径，您必须创建一个辅助分片模型，以将每个租户与多个分区键相关联。

让我们看一个例子，说明你如何为生活带来这样的解决方案。首先，您需要一个单独的表，我们称之为“租户查找表”，以捕获和管理租户到其对应的DynamoDB分区键的映射。下图显示了如何构建租户查找表的示例。

引入租户查找表

此表包括两个租户的映射。与这些租户关联的项目具有包含与租户关联的每个表的分片信息的属性。在这里，我们的租户都有其Customer和Account表的分片信息。还要注意，对于每个租户表组合，有三条信息表示表的当前分片配置文件。这些是：

• ShardCount-表示当前与表关联的碎片数。
• ShardSize-每个碎片的当前大小
• ShardId-映射到租户的分区键列表（用于表）

使用此机制，您可以控制如何为每个表分配数据。查找表的间接性为您提供了一种根据租户存储的数据量动态调整租户分片方案的方法。数据占用量特别大的租户将获得更多碎片。因为该模型在逐个表的基础上配置分片，所以您可以更精确地控制租户的数据需求映射到特定的分片配置。这使您能够更好地将分区与租户数据配置文件中经常出现的自然变化相一致。

尽管引入租户查找表为您提供了一种解决租户数据分布问题的方法，但它并不是免费的。这个模型现在引入了一个间接级别，您必须在解决方案的数据访问层中解决这个问题。与其使用租户标识符直接访问数据，不如先查看该租户的碎片映射，然后使用这些标识符的联合来访问租户数据。下面的示例Customer表显示了如何在此模型中表示数据。

具有碎片ID的客户表

在本例中，ShardID是租户查找表的直接映射。租户查找表包括Customer表的两个单独的碎片标识符列表，一个用于Tenant1，一个为Tenant2。这些碎片标识符与您在示例客户表中看到的值直接相关。请注意，实际租户标识符从未出现在此Customer表中。

管理碎片分发

这个模型的机制并不特别复杂。当你考虑如何实施一个有效地分发数据的策略时，这个问题会变得更加有趣。如何检测租户何时需要额外的碎片？您可以收集哪些度量和标准来自动化此过程？您的数据和域的特性如何影响您的数据配置文件？没有一种单一的方法可以为每一种解决方案普遍解决这些问题。一些SaaS组织根据其客户洞察手动调整这一点。其他人有更自然的标准来指导他们的方法。

这里概述的方法是处理数据分布的一种方法。最终，您可能会发现我们所描述的原则与您的环境需求最为吻合。关键之处在于，如果采用池模型，请注意DynamoDB如何划分数据。盲目移动数据而不考虑数据将如何分布，可能会破坏SaaS解决方案的性能和成本。

动态优化IOPS

SaaS环境的IOPS需求很难管理。租户在系统上的负载可能会有很大变化。将IOPS设置为最坏情况下的最大值会破坏根据实际负载优化成本的愿望。

相反，请考虑实现一个动态模型，其中表的IOPS根据应用程序的负载配置文件实时调整。DynamicDynamicDB是一个可配置的开源解决方案，您可以使用它来解决这个问题。

支持多种环境

当您考虑DynamoDB概述的策略时，请考虑在多个环境（QA、开发、生产等）下如何实现这些模型中的每一个。对多个环境的需求会影响您如何进一步划分您的体验，以将AWS上的每一种存储策略分开。例如，使用网桥和池模型，您可以在表名中添加一个限定符，以提供环境上下文。这增加了一点误导，您必须将其考虑到表名的配置和运行时解析中。

迁移效率

DynamoDB的无模式特性为SaaS提供商提供了真正的优势，允许您将更新应用于应用程序并迁移租户数据，而无需引入新的表或复制。DynamoDB简化了在SaaS版本之间迁移租户的过程，允许您在最新版本的SaaS解决方案上同时托管灵活租户，同时允许其他租户继续使用早期版本。

权衡权衡

当您确定哪种模型最符合您的业务需求时，每种模型都需要考虑权衡。筒仓模式可能看起来很有吸引力，但资源调配和管理增加了复杂性，从而削弱了解决方案的灵活性。支持单独的环境和创建独特的表组无疑会影响自动化部署的复杂性。该桥代表了DynamicDB上筒仓模型的轻微变化。因此，它反映了我们在筒仓模型中发现的大部分内容。

DynamoDB上的池模型提供了一些显著的优势。数据的整合占地面积简化了资源调配、迁移以及管理和监控体验。它还允许您在跨租户的基础上调整读写IOPS，从而采用更加多租户的方法来优化消费和租户体验。这使您能够对性能问题做出更广泛的反应，并带来了将成本降至最低的机会。这些因素往往使池模型对SaaS组织非常有吸引力。

在关系数据库上交付了这么多早期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上的思洛存储器模型可能会降低资源调配自动化的痛点。然而，与池模型相关的成本和管理效率往往令人信服。当您考虑这些模型将如何与您的持续交付环境保持一致时，这一点尤为重要。

多租户存储选项的矩阵可能令人望而生畏。确定能够代表灵活性、隔离性和可管理性的最佳组合的解决方案可能是一项挑战。尽管考虑所有选项很重要，但在多租户存储思维中不断考虑灵活性也是至关重要的。SaaS组织的成功通常很大程度上取决于其解决方案中的灵活性。

您选择的存储技术和隔离模式直接影响您轻松部署新特性和功能的能力。数据的结构和内容的形状经常会发生变化，以支持新功能，这意味着您的基础存储模型必须适应这些变化而不需要停机。在支持这种无缝迁移方面，每个隔离模型都有利弊。当你考虑你的选择时，给这些因素适当的权重。

尽管筒仓、桥梁和水池模型都具有敏捷性，但您可以应用通用原则来帮助您尽可能保持敏捷。一个关键原则是，需要尽量减少租户数据的一次性变化，这一点非常明显，但有时会违反。例如，思洛存储器和桥接器模型可能会导致存储变化，从而使您将新功能作为单个自动化事件的一部分推送给所有SaaS客户的能力变得复杂。团队通常使用自动化和连续部署来限制多租户存储策略带来的摩擦。

当您制定存储战略时，请期待并接受存储需求不断发展的现实。SaaS客户的需求是一个不断变化的目标，您今天选择的存储模式可能不适合明天。AWS还将继续推出新的功能和服务，这些功能和服务将为您提供新的机会，以增强您的存储方法。

AWS为开发人员提供了广泛的存储服务，每种服务都可以组合应用，以满足SaaS租户不同的成本和性能要求。这里的关键是不要人为地将您的存储策略限制在任何一种AWS服务或存储技术上。

在分析应用程序的存储需求时，请采取更精细的方法，将给定存储服务的优势与应用程序各个组件的特定需求相匹配。例如，DynamoDB可能非常适合一种应用程序服务，而RDS可能更适合另一种应用。如果您的解决方案使用微服务架构，其中每个服务都有自己的存储视图，请考虑哪种存储技术最适合每个服务的配置文件。在组成应用程序的一组微服务中发现一系列不同的存储解决方案并不罕见。

这一战略还为将存储作为分层SaaS解决方案的另一种方式创造了机会。每一层基本上都可以利用一个单独的存储战略，提供不同级别的性能和SLA，以区分解决方案各层的价值主张。通过使用此方法，您可以更好地将租户层与他们对基础架构施加的成本和负载相一致。

数据安全必须是SaaS提供商的首要任务。当采用多租户策略时，您的组织需要一个强大的安全策略，以确保租户数据得到有效保护，防止未经授权的访问。保护这些数据并传达您的系统已采用适当的安全措施，对于获得SaaS客户的信任至关重要。

您选择的存储策略可能使用AWS支持的常见安全模式。例如，静态数据加密是一种横向策略，可以在任何模型中普遍应用。这提供了一个基本的安全级别，确保即使存在对数据的未经授权的访问，如果没有解密信息所需的密钥，也将是无用的。

现在，当您查看思洛存储器、网桥和池模型的安全配置文件时，您将注意到每种模型在实现安全性方面的其他变化。例如，您会发现AWS身份和访问管理（Amazon IAM）在如何确定和控制对租户数据的访问方面存在细微差别。通常，思洛存储器和网桥模型与IAM策略更自然，因为它们可以用于限制对整个数据库或表的访问。一旦您转换到池模型，您可能无法利用IAM来确定对数据的访问范围。相反，更多的责任转移到应用程序服务的授权模型上。这些服务必须使用用户的身份来解析它们在共享表示中对数据的范围和控制。

隔离和安全

支持租户隔离对于某些组织和域来说是至关重要的。即使在虚拟化环境中，数据也是分离的，这一概念对于具有特定监管或安全要求的SaaS提供商来说也是必不可少的。

在考虑每个AWS存储解决方案时，请考虑如何在每个AWS存储服务上实现隔离。正如您将看到的，在RDS上实现隔离与在DynamicDB上实现隔离看起来非常不同。在选择存储策略和评估客户的安全考虑事项时，请考虑这些差异。

作为一般的体系结构原则，开发人员通常尝试引入层或框架，以集中和抽象其应用程序的水平方面。这里的目标是集中和标准化策略和租户解决策略。例如，您可以引入一个数据访问层，将租户上下文注入到数据访问请求中。这将简化开发并限制开发人员对租户身份如何在系统中流动的了解。

设置此层还为您提供了更多策略和策略选项，这些策略和策略可能因租户而异。它还为集中配置和跟踪存储活动创造了一个自然的机会。

SaaS客户的存储需求并不简单。SaaS的现实是，您的业务领域、客户和遗留问题会影响您如何确定多租户存储选项的组合最能满足您的业务需求。

尽管没有一种策略能够普遍适用于每个环境，但很明显，某些模型确实与SaaS交付模型的核心原则更为一致。总的来说，任何AWS存储技术上基于池的存储方法都与管理和操作多租户环境的统一方法的需求相一致。将所有租户放在一个共享的存储库和表示中可以简化和统一您的方法的操作和部署足迹，从而实现跨租户的健康和性能视图。

筒仓和桥梁模型当然有自己的位置，对于一些SaaS提供商来说，这是绝对必要的。这里的关键是，如果你沿着这条路走下去，敏捷性会变得更加复杂。某些AWS存储技术更适合支持独立租户存储方案。例如，在RDS上构建思洛存储器模型比在DynamicDB上构建要简单。通常，每当您依赖链接帐户作为分区模型时，您将解决更多的资源调配、管理和扩展难题。

除了实现多租户的机制之外，请考虑每种AWS存储技术的概要如何满足多租户应用程序功能的不同需求。考虑租户将如何访问数据，以及数据的形状需要如何演变以满足租户的需求。您越能将应用程序分解为自主服务，就越能为每个服务选择和选择单独的存储策略。

在研究了这些服务和分配方案之后，您应该对指导您选择多租户存储策略的模式和拐点有了更好的理解。AWS为SaaS提供商提供了丰富的服务和结构，可以组合这些服务和结构来满足任何数量的多租户存储需求。

数据迁移是竞争SaaS存储模型评估中经常忽略的领域之一。然而，对于SaaS，请考虑您的架构选择将如何影响您不断部署新特性和功能的能力。尽管需要强调性能和一般租户体验，但也必须考虑存储解决方案如何适应数据基础表示的不断变化。

迁移和多租户

每种多租户存储模型都需要自己独特的方法来处理数据迁移。在思洛存储器和网桥模型中，您可以逐个租户迁移数据。您的组织可能会发现这一点很有吸引力，因为它允许您谨慎地迁移每个SaaS租户，而不会让所有租户都面临迁移错误的可能性。然而，这种方法可能会给部署生命周期的整体协调带来更多复杂性。

在池模型中迁移数据既有吸引力，也有挑战性。在一方面，池模型中的迁移提供了一个单一点，一旦迁移，所有租户都可以成功地转换到新的数据模型。另一方面，在池迁移过程中引入的任何问题都可能影响您的所有租户。

从一开始，您就应该考虑数据迁移如何适合您的整体多租户SaaS战略。如果您尽早将这种迁移编排融入到您的交付管道中，那么您将在发布过程中获得更大程度的灵活性。

最小化侵入性变化

作为经验法则，在考虑系统中的数据将如何演变时，您应该遵循明确的政策和原则。只要可能，团队应该支持与早期版本向后兼容的数据更改。如果您能够找到最小化对应用程序数据表示的更改的方法，那么将限制将数据转换为新表示的高开销。

您可以利用常用的工具和技术来协调迁移过程。事实上，尽管最小化侵入性更改对SaaS开发人员来说非常重要，但这并不是SaaS领域独有的。因此，这超出了我们将在本文中讨论的范围。

在深入了解每个存储服务的细节之前，让我们看看如何使用AWS链接帐户在任何AWS存储解决方案之上实现思洛存储器模型。要使用此方法实现筒仓，您的解决方案需要为每个租户提供单独的链接帐户。这可以真正实现筒仓，因为租户的整个基础设施与其他租户完全隔离。

链接账户方法依赖于合并账单功能，该功能允许客户将子账户与整体付款人账户相关联。这里的想法是，即使每个租户都有单独的链接账户，这些租户的账单仍然是汇总的，并作为单个账单的一部分提交给付款人账户。

下图显示了如何使用链接帐户实现思洛存储器模型的概念视图。在这里，您有两个拥有独立账户的租户，每个租户都与一个付款人账户相关联。通过这种隔离，您可以自由利用任何可用的AWS存储技术来存放租户的数据。

具有链接帐户的筒仓模型

乍一看，对于那些需要筒仓环境的SaaS提供商来说，这似乎是一个非常有吸引力的策略。它当然可以简化个别租户的管理和迁移的某些方面。构建租户成本视图也会更加简单，因为您可以在链接账户级别汇总AWS费用。

即使有这些优点，链接帐户筒仓模型也有重要的局限性。例如，资源调配当然更复杂。除了创建租户的基础设施外，您还需要自动创建每个链接帐户并调整需要的任何限制。然而，更大的挑战是规模。AWS对您可以创建的链接账户数量有限制，这些限制不太可能与将创建大量新SaaS租户的环境相一致。