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

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连接限制的情况下有效满足其应用程序的数据访问模式。

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