大型 postgres 表的最佳实践答案

【问题标题】：Best practice for massive postgres tables大型 postgres 表的最佳实践
【发布时间】：2020-02-01 08:19:14
【问题描述】：

我有一个包含 3 个字段（用户名、目标值、分数）的表，由用户名 (~400,000) 和目标值 (~4000) 的完整交叉和计算分数在外部生成，总行数约为 16 亿.

我在这张表上的所有查询都将采用

的格式

SELECT *
FROM _table
WHERE target_values IN (123, 456)

我的初始版本包括关于 target_values 的 BTREE 索引，但我最终花了 45 分钟对索引进行 BITMAP HEAP SCAN。我也一直在研究 BRIN 索引、分区和表集群，但由于将每种方法应用于表需要数小时，我无法完全强制每个选项并测试性能。

对于在 Postgres 10 中处理具有非常“块状”数据的单个海量表有哪些建议？

【问题讨论】：

【解决方案1】：

如果表是两个数据集的交叉连接，为什么不存储各个表并根据需要计算连接？数据库擅长于此。

根据您的描述，如果您在表上运行CLUSTER 以按索引顺序物理重写它，我预计性能会有所提高。那么你将不得不访问更少的表块。

不幸的是CLUSTER 会花费很长时间，导致表格不可用并且必须定期重复。

另一种可能更好的方法是按target_value 对表进行分区。 4000个分区有点多，不妨用列表分区把几个分区捆绑成一个分区。

这将允许您的查询仅在几个分区上执行快速顺序扫描。它还将使 autovacuum 的工作更轻松。

然而，底线是，如果您从一个表中选择很多行，它总是需要很长时间。

【讨论】：

遗憾的是，分数生成是由 Spark 使用 ML 模型在外部完成的，所以我无法即时存储和计算。
顺便说一句，你有推荐的最大分区数吗？ 50？ 100？ 500？
PostgreSQL 版本越高，可以高效处理的分区越多。使用 v12（昨天发布）您可以处理 4000 个分区。你应该运行一些测试。许多分区的问题是规划时间可能会增加很多。