PostgreSQL的多租户应用程序模式

Question

我正在学习多租户应用程序，以及如何使用PostgreSQL的模式来实现这一点。

在研究这个主题时，我发现了一篇文章，作者描述了在多租户应用程序中使用PostgreSQL模式时的糟糕体验。主要问题是迁移性能差和数据库资源使用率高。

似乎只有一个模式（在租户之间共享表）会比每个租户有一个单独的模式带来更好的性能。但我觉得很奇怪。我的想法正好相反，因为较小表上的索引往往比较大表上的索引轻。

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

Answer 1

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

租户模式在租户数量相对较少且相当大的情况下是最好的。这方面的一个例子是只有付费订阅用户的会计应用程序。使其成为更好的选择的因素包括：

• 少数租户每人都有大量数据

使其成为表现不佳的选择的因素包括：

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

租户模式是否不利于迁移/模式更改实际上取决于您的操作方式。这不利于快速推出通用模式更改，但有利于在租户中逐步部署模式更改。

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

• 对于连接池更好，因为所有连接都可以使用相同的池

共享表的主要缺点是需要在应用层的每个查询中附加租户筛选条件。这也有问题，因为：

• 连接多个表的查询可能会执行得很差，因为租户过滤器会中断查询规划
• 表的行数增加到1亿行可能会导致特定的性能和维护问题
• 无法进行租户特定的应用程序更改或架构升级
• 在服务器之间迁移租户的成本更高

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

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