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

# PostgreSQL 池模型
<a name="pool"></a>

池模型是通过配置单个 PostgreSQL 实例（Amazon RDS 或 Aurora）并[使用行级安全 (RL](https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/) S) 来维护租户数据隔离来实现的。RLS 策略限制`SELECT`查询返回表中的哪些行，或者哪些行受到`INSERT``UPDATE`、和`DELETE`命令的影响。池模型将所有租户数据集中在单个 PostgreSQL 架构中，因此成本效益要高得多，维护所需的运营开销也更少。由于该解决方案是集中化的，因此监控该解决方案也要简单得多。但是，在池模型中监控租户特定的影响通常需要在应用程序中使用一些额外的工具。这是因为 PostgreSQL 默认不知道哪个租户在消耗资源。由于不需要新的基础架构，因此可以简化租户入门。这种敏捷性可以更轻松地完成快速、自动化的租户入职工作流程。

 ![\[SaaS PostgreSQL pool model\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-pool.png) 

尽管池模式通常更具成本效益且更易于管理，但它确实有一些缺点。在泳池模型中无法完全消除邻居噪音现象。但是，可以通过确保 PostgreSQL 实例上有适当的资源可用以及使用策略减少 PostgreSQL 中的负载（例如将查询卸载到只读副本或 Amazon）来缓解这种情况。 ElastiCache有效的监控在应对租户性能隔离问题方面也起着作用，因为应用程序工具可以记录和监控租户特定的活动。最后，一些SaaS客户可能认为RLS提供的逻辑分离是不够的，他们可能会要求采取额外的隔离措施。