在PostgreSQL中使用许多模式而不是仅使用一种模式的利弊？

对于拥有30万个帐户（并且还在不断增长）的大型SAAS应用程序（由PostgreSql 9.4支持），每个帐户使用模式对数据进行分区与将所有数据置于一个模式中并使用外键进行数据交换的利弊是什么？在查询中将其分区？

我知道过去使用许多模式时pg_dump的速度很慢，但不确定今天是否是如此。我也知道数据库结构的任何更改都必须在所有模式上进行。而且我知道，从正面来看，将模式从一台物理服务器移动到另一台物理服务器很容易，并且可以从备份中还原模式，更不用说以这种方式分区数据了。

那么，我缺少哪些利弊？

postgresql database-design schema multi-tenant

— 哈雷尔
source

看起来都不好。单个巨大的表（“垂直增长”）很难管理，而大量的架构（“水平增长”）也很难管理。

— DanielVérité15年

我正在重建一个具有该帐户数量（甚至更多用户）的旧系统。它使用一种共享方法（使用mySql），并且就性能而言可以正常工作。我关心的是保持该性能水平，但要增加其可维护性。

— Harel'3

@Harel我很好奇，您是否尝试过使用400k架构或切换到其他架构/技术？

— sthzg

在深入研究之后，我放弃了这个想法。我要创建的模式数量会击败任何对此的实际使用。我在每条记录中都使用了良好的旧帐户ID字段。不过，我所做的就是放弃数字自动增量ID取而代之的是UUID，这意味着我可以很容易地将整个帐户从一个数据库转移到另一个数据库，而不必担心破坏完整性。

— 哈雷尔

显然，您正在处理每个用户模式中的相同表。您是否考虑过继承？对于某些用例，它可以为您提供两全其美的体验。也有一些限制。您可以为每个用户使用单独的架构，并且仍然非常方便地一次搜索所有用户表。

有关：

除此之外，至少必须提到授予/撤消特权，这对于单独的模式来说要简单得多。

— 欧文·布兰德斯特
source

我将研究继承。但是，我关心的是这里的规模。在我读过的所有地方，人们都在谈论多租户模式策略，但指的是数十，数百或数千个模式。一处提到20K模式。问题是-400K模式太多了吗？它会导致文件描述符疯狂并杀死服务器吗？我在推吗？

— Harel'3

另外，我打算将租户数据（帐户和用户）保留在公共架构中，同时将架构本身保持为实际用户数据。该数据不会在架构之间共享，也永远不会在架构之间共享。

— Harel'3

我认为，继承不会在这里帮助我。共享方法使用具有向用户或租户强制性外键的单一模式，因此恐怕继承不会获得任何好处。

— Harel'3

从本文influitive.io/…看来，多模式模式对于大量租户不是一个好方法。列tenant_id（古老的方式）会更好。

— 张晓辉