PostgreSQL的模式（schemas）在多租户应用程序中的应用

Question

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

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

似乎只有一个模式（在租户之间共享表）比为每个租户分别设置一个模式会导致更好的性能。但这让我感到奇怪。我认为相反，因为较小表上的索引往往比较大表上的索引轻。

为什么将数据分散在许多小表中（在多个模式中），而不是将数据分散在几个大表中（在单个模式中），性能会更差呢？

- viniciussss

---

我认为这篇文章更多地涉及了Rails开发人员，而不是PostgreSQL。但是，在没有任何代码的情况下，这篇文章可能会被关闭。 - Mike Sherrill 'Cat Recall'

Answer 1

性能并不一定更差。正如文章所解释的那样，取决于您的应用程序设计和工作负载，有特定条件使方案方法更好或更糟。让我解释一下“租户模式”与“共享表格”方法的权衡：

租户模式 在您拥有相对较少但非常大的租户时效果最佳。例如会计应用程序，只有付费订阅用户。使其成为更好的选项的因素包括：

• 少量租户每个租户都有大量数据
• 相对简单的模式，每个租户没有太多的表格
• 需要自定义某些租户的模式
• 可以利用每个租户的数据库角色
• 需要将租户的数据从一个服务器迁移到另一个服务器
• 可以在云中为每个租户启动专用应用服务器

使其成为性能较差的选项的因素包括：

• 很多小租户每个租户有很少的数据
• 无状态连接方式，在其中每个请求都可能是任何租户
• 客户端库或ORM缓存所有表格元数据（例如ActiveRecord）
• 需要有效、高性能的连接池和/或缓存
• VACUUM和其他PostgreSQL管理操作在1000多个表格之间扩展较差。

租户模式是否对迁移/模式更改不利，实际上取决于您如何进行这些更改。它不适用于快速推出通用模式更改，但适用于作为逐步推出方案更改的部署。

共享表格 在您有很多租户，并且大多数租户都非常少数据时效果更好。例如社交媒体移动应用程序，允许免费帐户，因此有数千个废弃帐户。使共享表格模型受益的其他因素包括：

• 对于连接池来说更好，因为所有连接可以使用同一个池
• 由于总表格较少，更易于PostgreSQL管理
• 对于迁移和模式更改来说更好，因为只有一个“组”表格

共享表的主要缺点是需要在应用层的每一个查询上添加租户过滤条件。这也存在问题，因为：

• 连接许多表的查询可能性能较差，因为租户过滤会影响查询规划
• 行数增长到1亿的表可以导致特定的性能和维护问题
• 没有方法进行租户特定的应用程序更改或模式升级
• 迁移租户之间的成本更高

因此，“哪种模型表现更好”实际上取决于哪些折衷最严重。

还有一种混合模型“租户视图”，其中实际数据存储在共享表中，但每个应用程序连接使用安全隔离视图查看数据。这具有每个模型的某些权衡。主要是它具有租户模式模型的安全性优势，但同时也有两个模型的一些性能缺点。

- FuzzyChef

---

这是我读过的关于在多租户应用程序中使用（或不使用）PostgreSQL模式的最佳信息。我仍然不知道为什么拥有许多小表格（和模式）的性能比拥有少量大型表格更差。但是，现在我肯定可以决定哪种设置是适合我的情况的理想选择。非常感谢！ - viniciussss

我不同意。他甚至说：“我的猜想是，如果不是硬性的限制，那么至少也有一个软性、建议性的上限，来限制你在一个postgres数据库中存储的表/索引数量。” 问题似乎是postgres不能很好地处理大量的表。 - viniciussss

大量表格存在一些特定问题，比如备份和VACUUM等管理任务。但是，“大量表格”指的是数万个甚至十万个，而不是几百个。并且这些问题不会影响SELECT查询。如果您阅读了该博客文章，就会发现拥有许多表格的主要问题在ActiveRecord方面（只是为您提供信息，我已从事PostgreSQL性能工作19年）。 - FuzzyChef

当一位PostgreSQL极客谈论“许多表”时，他们指的是非常多。欲了解更多，请参阅来自The Billion Tables Project的幻灯片/视频：https://www.pgcon.org/2013/schedule/events/595.en.html - FuzzyChef

如果@FuzzyChef能够提及每个“数量”部分的大致范围，那就太好了。租户数量、表格数量等。 - KBN