postgresql - Postgres中大表分区的标准和策略

Question

我们正在考虑将我们的应用程序迁移到多租户数据库。目前，该应用程序使用每个租户一个数据库运行。目前约有400名租户。合并后，最大的表将有大约 10 亿行，并且会随着租户的增加而增长。租户的大小差异很大，仅一个租户在该表中就有 1.8 亿条记录，有些不到 100 万条。数以亿计的还有其他几张桌子，大多数桌子的数量要少得多。我主要关注的是大型表的可伸缩性规划，我将专注于最大的表。它的参数是它是一个链接/多对多表，其中包含创建者和创建日期的基本审计字段（尽管我质疑这些字段是否甚至是必要的）。日期/时间与此无关，这是一个分配表，始终适用。记录可以被删除或插入，而不是更新，有时是批量的，可能不经常发生，但随时可能发生。我认为两个外键的数据基数都相对较高，尽管我不确定高基数与记录总数的比率是什么。从某种角度来看，拥有 1.8 亿条记录的租户对于一个外键有大约 100,000 条不同的记录，而对于另一个外键则有 165,000 条。同时，另一个客户有大约 180,000 条记录，一个字段中有 500 个不同的值，另一个字段有 5000 个。正如我所说，有很多可变性。我不确定什么构成高基数与记录总数的比率。从某种角度来看，拥有 1.8 亿条记录的租户对于一个外键有大约 100,000 条不同的记录，而对于另一个外键则有 165,000 条。同时，另一个客户有大约 180,000 条记录，一个字段中有 500 个不同的值，另一个字段有 5000 个。正如我所说，有很多可变性。我不确定什么构成高基数与记录总数的比率。从某种角度来看，拥有 1.8 亿条记录的租户对于一个外键有大约 100,000 条不同的记录，而对于另一个外键则有 165,000 条。同时，另一个客户有大约 180,000 条记录，一个字段中有 500 个不同的值，另一个字段有 5000 个。正如我所说，有很多可变性。

我上面描述的那种表（数十亿行，高数据基数，不是基于时间的，租户分段，随时批量插入/删除）在我描述的那种场景（400多个具有不同数据量的租户）中是分区的好人选？我现在担心这一点的原因是，我在许多地方读到，如果您提前计划分区而不是在表格之后尝试分区，那么处理分区的痛苦会小得多在不需要停机时间或跳过箍的情况下，它是巨大且难以使用的。在这一点上，我主要关心的不是查询数据，我用一个有 10 亿条记录的表进行了测试，并且使用适当的索引选择查询运行得非常快。我更担心读/写/删除的并发性，由于锁等而陷入阻塞。如果分区是必要的，那么好的策略是什么？按租户划分？只是将大的分开并将较小的捆绑在一起？

标签： postgresqlscalability

Answer 1

鉴于您说查询性能不是问题，我能想到考虑分区的唯一原因是使大规模清除更容易完成。

您是否制定了合同或法律保留政策？

最常见的情况是使用时间段作为您的分区键，以便滚动旧数据只是删除分区的问题，但由于您明确指出日期/时间不相关，我看不出这有什么帮助。

您是否经常滚动/滚动单个客户？是否有清除或保留要求？如果是这样，那么无论分区有多不平衡，按客户进行分区都是有意义的，因为您可以清除大客户的数据而不会影响其他客户对其数据的访问。

至于任何并发问题，按客户划分应该有助于将这些问题包含在显示大量活动的特定客户中。

我建议彻底测试，原因如下：

• 我没有看到多个活动分区在起作用，因为我只使用时间序列分区
• 我没有深入研究PostgreSQL 12 的外键增强功能，我想知道两边都有分区表的外键是否会使删除分区复杂化
• 我从未探索过数据库可以包含的分区数量的实际限制

我可能会根据我的经验阅读有关分区的问题，但是您是否考虑过每个客户的架构？