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

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组织非常有吸引力。