PostgreSQL 用于多租户应用程序的模式

Question

我正在学习multi-tenant 应用程序以及如何使用 PostgreSQL 的架构来实现此目的。

研究该主题后，我最终找到了an article，其中作者描述了在多租户应用程序中使用 PostgreSQL 模式时的糟糕体验。主要问题是迁移性能不佳和数据库资源使用率高。

似乎只有一个架构（在租户之间共享表）会比为每个租户使用一个单独的架构带来更好的性能。但这对我来说感觉很奇怪。我会认为相反，因为较小表上的索引往往比较大表上的索引更轻。

为什么在许多小表中（在多个模式中）中分离数据时，性能会比在几个大表中（在单个模式中）中分离时更差？

Answer 1

性能不一定会变差。正如文章所解释的，根据您的应用程序设计和工作负载，存在使架构方法更好或更差的特定条件。让我解释一下“租户模式”与“共享表”方法的权衡：

tenant-schema 最适合当您拥有相对较少数量的相当大的租户时。这方面的一个例子是会计应用程序，只有付费订阅用户。使其成为您更好的选择的因素包括：

• 少量租户，每个租户都有大量数据
• 一个相对简单的架构，每个租户没有很多表
• 需要自定义某些租户的架构
• 能够利用每个租户的数据库角色
• 要求将租户的数据从一台服务器迁移到另一台服务器
• 能够在您的云中为每个租户启动专用应用服务器

使其成为性能不佳的选项的因素包括：

• 很多租户，每个人的数据都很少
• 无状态连接方法，其中每个请求都可以是任何租户
• 为所有表缓存元数据的客户端库或 orm（如 ActiveRecord）
• 对高效、高性能连接池和/或缓存的要求
• VACUUM 和其他 PostgreSQL 管理操作存在问题，无法在 1000 个表中扩展。

租户模式是否不利于迁移/模式更改实际上取决于您如何执行它们。这不利于快速推出通用模式更改，但有利于将模式更改部署为跨租户逐步推出。

shared-table 更适用于有很多租户，而很多租户的数据很少的情况。这方面的一个例子是社交媒体移动应用程序，它允许免费帐户，因此有数千个废弃的帐户。使共享表模型受益的其他因素是：

• 更适合连接池，因为所有连接都可以使用同一个池
• 更适合 PostgreSQL 管理，因为表总数较少
• 更适合迁移和架构更改，因为只有一组“表”

共享表的主要缺点是需要将租户过滤条件附加到应用程序层的每个查询中。这也是有问题的，因为：

• 连接多个表的查询可能性能不佳，因为租户过滤器会影响查询计划
• 增长到 1 亿行的表可能会导致特定的性能和维护问题
• 无法进行特定于租户的应用程序更改或架构升级
• 在服务器之间迁移租户的成本更高

因此，哪种模型“表现更好”实际上取决于哪种权衡对您的伤害最大。

还有一个混合模型，“租户视图”，实际数据存储在共享表中，但每个应用程序连接使用security barrier views 来查看数据。这对每个模型都有一些权衡。首先，它具有租户模式模型的安全优势，同时也具有两种模型的一些性能缺陷。