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

Posted 2023-02-27

【中文标题】PostgreSQL 用于多租户应用程序的模式

【英文标题】：PostgreSQL's schemas for multi-tenant applications

【发布时间】：2017-11-15 09:37:44

【问题描述】：

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

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

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

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

【问题讨论】：

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

【参考方案1】：

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

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

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

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

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

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

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

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

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

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

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

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

【讨论】：

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

您链接到的文章非常清楚地解释了他们的性能问题与应用程序有关，而不是对单个表的查询。

我不同意。他甚至说：“我的猜测是有一个上限 — 如果不是硬上限，那么至少是一个软的、推荐的上限 — 关于您存储在一个 postgres db 中的表/索引等的数量”。问题似乎是 postgres 不能很好地处理大量表。

大量表存在一些特定问题，即备份和 VACUUM 等管理任务。但是，通过“大量表”，我们说的是成千上万的 10 或 100，而不是几百。这些问题不会影响 SELECT 查询。如果您阅读博客文章，那么拥有许多表的主要问题在于 ActiveRecord 方面（仅供参考，我从事 PostgreSQL 性能研究已有 19 年了）。

当一个 PostgreSQL 极客谈论“许多表”时，他们的意思是 很多。有关更多信息，请参阅 The Billion Tables Project 的幻灯片/视频：pgcon.org/2013/schedule/events/595.en.html