具有大量表（例如：100 万表）的 postgresql 的性能？答案

【问题标题】：Performance of postgresql with large numbers of tables (EG: 1 million tables)?具有大量表（例如：100 万表）的 postgresql 的性能？
【发布时间】：2011-10-23 13:35:12
【问题描述】：

考虑到 pgsql 在文件系统上为每个表存储 1 个文件并在 pg_catalog 中搜索每个查询以进行查询计划，单个 pgsql 数据库中可以保持良好性能的最大表数是多少？

EG：pgsql 可以处理单个数据库中的 100 万个表吗？假设使用的文件系统是 ext4 并且每个表包含的数据非常少，所以磁盘存储容量过大不是问题。问题实际上来自 (1) 文件系统上有 100 万个文件的影响和 (2) pg_catalog 中有 100 万个条目的影响。

来自这个线程 (2005)，http://postgresql.1045698.n5.nabble.com/GENERAL-Maximum-number-of-tables-per-database-and-slowness-td1853836.html - 它在下面说（但我不知道这些天仍然适用多少）：

Benjamin Arai 写道：

目前每个数据库的最大表数是多少？此外，是否有更多的表会以任何方式降低性能吗？

在大多数情况下，答案是否定的。然而，一旦你接近 6 位数表计数， pg_catalog 最终是相当庞大的。问题是查询规划器必须检查每个查询的 pg_catalog 以查看什么索引可用，统计数据和值分布是什么，等，以建立最佳计划。在某些时候，一个非常大的 pg_catalog 可能会开始让您的系统陷入瘫痪。

...

William Yu 写道：

Benjamin Arai 写道：

目前每个数据库的最大表数是多少？此外，是否有更多的表会以任何方式降低性能吗？

在大多数情况下，答案是否定的。然而，一旦你接近 6 位数表计数， pg_catalog 最终是相当庞大的。

您还必须考虑使用 10 对性能的影响数据库目录中的数千个文件。虽然有些较新文件系统并没有特别担心，很多'em陷入困境当目录中有超过几千个条目时进行查找。

【问题讨论】：

我认为没有人能回答这个问题。

标签： postgresql filesystems max ext4

【解决方案1】：

您不必将一百万个文件保存在一个目录中。您可以使用CREATE TABLESPACE 在不同的目录或不同的磁盘上安排空间。我对 pg_catalog 的内部结构一无所知，但我可以想象它如何首先按表空间缩小搜索范围，从而显着减少搜索时间。

但这与文件系统中通常存在一百万个文件或 pg_catalog 的实际（非想象）问题可能存在的问题不同。

应该很容易做一个简单的（并且可能是误导性的）测试。使用您最喜欢的脚本语言创建一百万个表，每个表有五或六列。

【讨论】：

我对此表示怀疑。表空间是内部存储机制。架构更有可能提供帮助。
由于查询中没有指定表空间，现在如何搜索？
PostgreSQL 存储表空间名称和对象名称。例如，存储特定表的表空间位于system catalog pg_tables。
对，但是它怎么知道要搜索哪个表空间？
模式和表名是逻辑的，不是物理的。他们告诉 PostgreSQL 什么你想要（合乎逻辑的）。他们没有告诉 PostgreSQL 在哪里可以找到你想要的磁盘（物理）。这就是表空间的作用。如果您创建一百万个表（逻辑），默认情况下，所有表都将最终位于磁盘上的单个目录中（物理）。模式（逻辑）不会改变这一点。创建256个唯一表空间（物理），可以将每个目录的表数减少到4000左右。

【解决方案2】：

一般来说，据我认识的那些使用过大量表（数以千计）的人说，规划开销会随着数据库中表数量的增加而增加。我认识的那些遇到过这个问题的人不得不为这个问题找到解决方案，但没有向我说明这些解决方案是什么。发生的是数据库规划器，为了确定执行查询的最佳方式，必须根据表和列查找信息，因此这需要在系统目录中搜索数据，而系统目录会随着时间的推移变得越来越臃肿。这会影响计划时的每个查询。

基本问题是，在规划时，您必须考虑表格（需要在表格上查找内容）和列以及列上的数据。有趣的是 pg_class 在 oid 上有一个索引，在 relnamespace 上有一个索引，但在 relname 上没有一个索引，而且你不能轻易地创建一个。系统表中唯一的索引是 UNIQUE 约束，因此我看不出除了更改系统目录（在源级别或授予您执行此操作的权限）之外，您可以如何解决此问题。

我还希望性能会缓慢下降，因此您不能对此进行硬性限制。因此，它取决于给定工作负载的可接受性能。

如果你有那么多表，我会先看看其中有多少可以分解到其他数据库中。

tl; dr：预计大量表会出现性能问题。预计必须有创意才能解决这些问题。

【讨论】：

具有大量表的数据库通常具有它们，因为它们是以编程方式创建的。也就是说，计划并不是特别相关。表被用作自然关系但原子（在域中）事物的对象粒度级别。我正在考虑可能具有不同形状的批处理的结果集之类的东西，其中对最近数据的有效访问远比将数十亿行转储到单个过宽的表中重要得多。
Planning 是数据库规划器，它必须查找表上的信息。我正在编辑它以使其更清晰。
@AaronBertrand 实际上，我认为 Chris 的回答得到了改进，因为我的评论以一种方式而不是另一种方式解释了“计划”。
@BarryKelly，实际上，任何了解数据库性能的人（包括任何问这个问题的人）都会知道在这种情况下“计划开销”是什么。答案的改进仅适用于那些出于好奇而处理此类问题、缺乏足够的背景知识来制定有效解决方案的人。
但我们都必须从某个地方开始，所以这是一种改进，只是不适合问问题的人。

【解决方案3】：

这个 blog 和这个 question 包括 cmets 对这个问题有更多的了解。

回答您的问题：这取决于“同时仍保持良好性能”部分。您究竟如何看待“仍然表现出色”？究竟有什么工作量？

让我重新表述你的问题：一个人能忍受多少牙痛？一样的答案！

但在这两种情况下，真正的问题是：你为什么要真正关心？在这两种情况下，更好的解决方案是采取措施消除原因并尽快进入无痛状态。

【讨论】：