基于日期的最佳 Postgres 分区

Question

我正在寻找改进 Postgres（分区）表中数据删除的方法，而不是降低访问性能。

使用：Postgres 10.2

忽略一些不相关的列，我的表 transactions 包含这些列（省略了一些不相关的列）：

transaction_id PK
location
type
user_id
transaction_date

关于当前表的一些要点：

1. 在生产中，它有大约 1 亿行
2. 根据user_id（模100）对表进行分区（手动）。这意味着带有user_id 3 的用户的交易将转到transactions_3 和user_id 2356 将转到transactions_56。
3. 我们手动插入记录，因为 Postgres(10) 不支持这种开箱即用的分区，而且我们已经知道必须为其插入事务的用户（在检索时也是如此）

什么效果好：插入和检索，因为我们已经知道用户 - 我们知道要查看哪个表，因此不必遍历 100 个分区来找到它。 p>

什么没有：我们有一个经常删除旧数据的过程 - 基于用户订阅。但这通常会导致问题（空间问题），因为删除的数据不会立即释放。由于大量更新或删除活动导致表包含大量死行版本时，普通的 VACUUM 可能还不够（就像我们这里的情况）

我们希望如何改进这一点是能够根据交易日期将数据存储在分区中 - 然后能够在订阅结束时删除表。这将确保该空间立即再次可用。

简而言之，我们的主要目标是改进删除过程，以便立即恢复空间 - 同时确保访问性能不会恶化

对此我有几个问题：

1. 如果我们根据日期对表进行分区，我认为这（至少访问）会变慢，因为它现在必须扫描所有 100 个表以查看事务 ID 的位置？
2. 是否真的有可能实现这一点，保持事务检索与以前一样 - 同时改进删除过程。如果有，怎么做？
3. 我认为将它在日期和帐户上进行分区并不是一个真正可行的\好的解决方案 - 由于可以创建大量表？ （需要保留数据最长 2 年）
4. 为此，我们是否需要迁移到更新的 Postgres，比如 Postgres 14（它是最新的）。我知道升级到最新版本总是好的。但我想知道 - 如果不升级 Postgres 是否真的可以做到这一点。

希望在这里得到一些关于前进道路的指导。

Answer 1

首先：升级 PostgreSQL 将是一个非常好的主意，不仅因为哈希分区是在 v10 之后引入的，还因为自 v10 以来分区的性能和功能有了许多改进。

我感觉您现在使用的分区方案（自制散列分区）对您没有多大帮助。您无法通过简单的DROP TABLE（这很好）来摆脱客户，并且在一个分区中删除 1000 万行并不比在单个大表中删除它们更有趣。相反，一旦 autovacuum 完成，相对膨胀会更多。唯一的优点是 autovacuum 会更有效地工作，因为它可以单独处理每个分区。

回答您的问题：

1. 是的，分区使大多数查询变慢；希望不会慢很多。这就是你要付出的代价。

2. 不，您的查询会变慢一些（与分区数量成正比，因此请保持适度）。

3. 您可以根据这两个条件进行分区，因为分区也可以是分区表。但我怀疑这是否真的是一个好主意，因为我怀疑您当前的分区方案是否真的有益。

4. 是的，至少使用 v12，最好是 v14。