对于PostgreSQL表来说，多大太大？

Question

我正在为我的公司设计一个RoR项目，我们的开发团队已经遇到了一些关于设计的争论，特别是数据库。

我们有一个名为消息的模型，需要持久化。这是一个非常非常小的模型，除了 id 之外只有三个 db 列，但是当我们投入生产时，可能会有很多这样的模型。我们每天看到多达 1，000，000 次插入。模型将只能由其上的两个外键搜索，这些外键可以索引。同样，这些模型永远不必被删除，但我们也不必在它们大约三个月大后保留它们。

那么，我们想知道的是，在 Postgres 中实现此表是否会带来严重的性能问题？有没有人有使用非常大的SQL数据库的经验来告诉我们这是否会成为一个问题？如果是这样，我们应该选择什么选择？

Answer 1

另一种显著提高表查询速度的方法是

此外，对于非常大的表，最好在外键上创建索引。

例子：

1. 假设我们在名为ccbank的数据库中有一个名为investment的表
2. 假设查询中最常用的索引是（bankid，record_date）

以下是创建和群集索引的步骤：

1. psql-c"删除索引investment_bankid_rec_dt_idx；"ccbank
2. psql-c"创建投资指数investment_bankid_rec_dt_idx（ban孩子，record_date）；"
3. psql-c"集群投资investment_bankid_rec_dt_idx；"
4. 真空数据库-d ccbank-z-v-t投资

在步骤 1-2 中，我们将旧索引替换为新的优化索引。在第 3 步中，我们对表进行聚类：这基本上将数据库表按索引的物理顺序排列，以便当 PostgreSQL 执行查询时，它会缓存最有可能的下一行。在步骤 4 中，我们清空数据库以重置查询计划程序的统计信息。

Answer 2

每个表的行数本身不会成为问题。

所以粗略地说，90天每天100万行是9000万行。在不知道你在做什么的所有细节的情况下，我看不出Postgres有什么理由不能处理这个问题。

根据您的数据分布，您可以混合使用索引、过滤索引和某种表分区来加快速度，一旦您发现可能存在或可能不存在性能问题。据我所知，您在任何其他RDMS上的问题都是一样的。如果您在一个过程中只需要3个月的数据设计来修剪您不再需要的数据。这样，您将在表上拥有一致的数据量。您很幸运，您知道将存在多少数据，根据您的数据量测试它，看看您会得到什么。测试一个有9000万行的表可能很容易：

select x,1 as c2,2 as c3
from generate_series(1,90000000) x;

https://wiki.postgresql.org/wiki/FAQ

Limit   Value
Maximum Database Size       Unlimited
Maximum Table Size          32 TB
Maximum Row Size            1.6 TB
Maximum Field Size          1 GB
Maximum Rows per Table      Unlimited
Maximum Columns per Table   250 - 1600 depending on column types
Maximum Indexes per Table   Unlimited