如何确定Postgres与Timescale的合理分区数量？

问题背景 #

我们维护两张TimescaleDB的hypertables：

• Readings表：存储所有设备上报的原始读数，目前约有4.5亿条记录，占用655GB存储空间；设备规模当前约1000台，部分设备每秒上报，其余每分钟上报，每台设备平均上报10种读数，未来设备规模可能增长至100万台。
• LatestReadings表：仅保留每台设备各类型读数的最新记录，单设备对应记录数等于其上报的读数类型数（例如某设备上报温度、位置两类读数，该表仅保留2条最新记录）。

由于写入速率极高，我们计划对LatestReadings表基于UUID列做哈希分区，且仅使用单块存储设备（分区数规则为1×N），核心需求是确定合理的N值。

数据库规格 #

• 8核CPU
• 64GB内存
• Postgres总存储空间已超850GB

核心问题 #

如何确定LatestReadings表哈希分区的合理数量？

基于关键因素的分析与结论 #

结合调研的核心影响因素，逐一推导：

• 存储设备数量：仅用单块存储，分区数无需考虑多设备对齐，只需保证单设备内的分区效率。
• 分区大小控制：
  当前LatestReadings表记录数为1000台×10种读数=10000条；未来100万台设备时，记录数将达100万×10=1000万条。假设单条记录平均大小1KB，未来总数据量约10GB。按100MB~数GB的分区大小范围，需匹配后续的2^N规则调整。
• **哈希分区数的2^{N规则**：哈希分区数取2的幂次能保证数据分布均匀，避免倾斜。结合未来数据量，可选值有8（2}3）、16（2^{4）、32（2}5）。
• CPU核心数与查询chunks数量：服务器为8核CPU，查询涉及的分区数建议不超过核心数，避免CPU过载。取8个分区时，每个核心可对应处理一个分区的扫描，效率最优。
• 数据访问频率适配：LatestReadings表存储的是各设备最新读数，属于高频访问数据（需频繁更新和查询），适合用较小分区提升读写性能。

最终建议 #

综合以上因素，建议将LatestReadings表的哈希分区数设置为8（2^3）：

• 符合2^N的哈希分区最佳实践，数据分布均匀；
• 匹配8核CPU配置，查询时核心资源利用效率最优；
• 未来100万台设备时，单分区大小约1.25GB，处于100MB~数GB的合理区间；
• 适配高频访问场景，小分区能有效提升读写速率，应对高写入压力。

内容的提问来源于stack exchange，提问作者4strodev