PostgreSQL的多租户应用程序架构

Question

我正在学习multi-tenant应用程序以及如何使用PostgreSQL的模式。

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

似乎只有一个模式（在租户之间共享表）会比为每个租户分配一个模式产生更好的性能。但我觉得很奇怪。我认为相反，因为较小的表上的索引往往比较大的表上的索引更轻。

如果在很多小表（在多个模式中）中分隔数据，而不是将数据分成几个大表（在单个模式中），为什么性能会更差？

Answer 1

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

当您拥有相对较少数量的相当大的租户时，

租户架构是最佳选择。一个例子是会计应用程序，只有付费订阅用户。使其成为更好表现选项的事情包括：

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

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

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

租户架构是否对迁移/架构更改有害，实际上取决于您的工作方式。对于快速推出通用模式更改很不好，但有利于将模式更改部署为跨租户的逐步部署。

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

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

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

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

那么哪种模式“表现更好”实际上取决于哪种权衡会伤害你最坏的情况。

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