Postgres中有成千上万张表格-一种反模式？

Question

我正在开发一个从相机收集快照并将该快照的记录保存到快照表中的软件。我们有数千台摄像机和数亿个快照记录。每个快照记录仅包含少量数据-id，camera_id，时间戳和注释（字符串字段，以获取其他信息）。

我们开始注意到某些查询中的性能问题，主要是在给定时间范围内获取大量快照。除了升级Postgres所运行的硬件之外，我们还在寻找提高整个系统性能的替代方法。

在使用MongoDB之前，该团队也遇到了类似的情况，其中一个表用于相机，一个表用于快照。他们切换到为每个摄像机使用单独的快照表，从而产生了数千个快照表。这将性能提高了10倍，而不会引起新的问题。

现在，我们在Postgres上面临着同样的问题。即使上述解决方案有效，但似乎并没有针对数据库进行优化。在Postgres中做同样的事情会是一个疯狂的想法吗？通常使用的表数量是否存在已知限制？在该用例中，我找不到很好的信息。

Answer 1

看起来分区可能对您有用，但我看到一条注释说大量（> 100）的分区可能是有害的。您可能需要数千个分区，但如果您的查询一次不涉及多个分区，这可能不会产生负面影响。根据我对 Evercam 的了解，他们可能不会。