Question

我将时间序列模拟结果存储在PostgreSQL中。 db模式是这样的。

table SimulationInfo (
    simulation_id integer primary key,
    simulation_property1, 
    simulation_property2, 
    ....
)
table SimulationResult (  // The size of one row would be around 100 bytes
    simulation_id integer,
    res_date Date,
    res_value1,
    res_value2,
    ...
    res_value9,
    primary key (simulation_id, res_date)

）

我通常根据simulation_id和res_date查询数据。

我根据simulation_id的范围值将SimulationResult表划分为200个子表。完全填充的子表有10~15百万行。目前大约有70个子表完全填满，数据库大小超过100 gb。将很快填充200个子表，当它发生时，我需要添加更多子表。

但是我读了这个answers，其中说了几十个分区没有意义。所以我的问题如下。

超过几十个分区没有意义？为什么？我检查了200个子表上的执行计划，它只扫描相关的子表。所以我猜测每个子表越小越好的分区必须更好。
如果应该限制分区数量，例如50，那么在一个表中有数十亿行是没有问题的吗？考虑到像我这样的架构，没有大问题可以有多大表？

Answer 1

拥有那么多分区可能是不明智的，是的。拥有分区的主要原因不是使索引查询更快（在大多数情况下它们不是这样），而是为了提高必须根据可以证明不能保持的约束顺序扫描表的查询的性能对于某些分区;并改进维护操作（如真空，或删除大批旧数据，这可以通过在某些设置中截断分区等来实现）。

也许不是使用simulation_id的范围（这意味着你总是需要越来越多的分区），你可以使用它的哈希进行分区。这样，所有分区都以相似的速率增长，并且存在固定数量的分区。

分区太多的问题是系统不准备处理锁定太多对象，例如。也许200工作正常，但是当你达到一千以上时它不会很好地扩展（根据你的描述听起来不太可能）。

每个分区有数十亿行没有问题。

所有这一切，显然特别关注适用于每种情况。这一切都取决于你要运行的查询，以及你计划长期使用数据的方式（即你要保留所有数据，存档，删除最旧的，......？）

不要超过几十个分区有意义吗？

1 个答案: