本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# SaaS 数据分区模型
<a name="data-partitioning-models"></a>

SaaS 开发人员面临的挑战之一是设计架构模式，用于在多租户环境中表示和组织数据。这些多租户存储机制和模式通常被称为[数据分区](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/data-partitioning.html)。

在多租户 SaaS 环境中，区分数据分区和[租户](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/tenant-isolation.html)隔离非常重要。这些概念虽然相关，但不是同义词。数据分区是指为每个租户存储数据的方法。但是，仅仅分区并不能保证租户隔离。必须采取其他措施来确保一个租户的数据无法被另一个租户访问。

多[租户 SaaS](https://aws.amazon.com/solutions/guidance/multi-tenant-architectures-on-aws/) 系统中常用的三种数据分区模型包含三种：孤岛、池和混合。您对任何模型的选择取决于以下因素：
+ 合规
+ [吵闹的邻居](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/noisy-neighbor.html)
+ 分层策略
+ 业务需求
+ 租户隔离需求

此外，上可用的每种数据库类型 AWS 通常都提供一组独特的数据分区和租户隔离模型。在查看如何组织租户图以支持解决方案的各种需求时，请考虑 Amazon Neptune 提供的模型。

许多人ISVs从以下断言之一开始在 Neptune 上进行设计：
+ 该ISV解决方案要求在不同的集群中对客户进行物理隔离。
+ 该ISV解决方案需要诸如命名数据库或传统关系数据库管理系统中的架构之类的结构。

经过考虑，ISVs意识到这些断言是不正确的，因为在几乎所有工作负载下，他们的每个客户的数据库中都有一个断开连接的图表。实施本文档中讨论的数据建模和访问指南可以防止跨越这些数据界限，并维护客户数据隐私。

本指南描述了[筒仓模型和[池模型](pool-model.md)](silo-model.md)，但大多数人ISVs选择池模型是出于成本和运营效率考虑。该指南简要讨论了一种混合模型，该模型结合了筒仓和池模型的各个方面。有些人为其最大的客户ISVs使用混合模型，以满足图表大小的监管或合规性要求。