数据库 – Postgres中的数千个表 – 反模式?

我正在研究一种从摄像头收集快照的软件,并将该快照的记录保存到快照表中.我们有数千个摄像头和数亿个快照记录.每个快照记录仅包含少量数据 – id,camera_id,时间戳和注释(字符串字段以获取其他信息).

我们开始注意到某些查询中的性能问题,主要是在给定时间范围内获取大量快照.除了升级Postgres运行的硬件之外,我们还在寻找其他方法来改善整个系统的性能.

在使用MongoDB之前,团队有类似的情况,一个用于摄像头,一个用于快照.他们切换到为每个摄像头使用单独的快照表,从而产生了数千个快照表.这样可以将性能提高10倍而不会出现新问题.

现在我们在Postgres面临同样的问题.即使上述解决方案有效,但似乎并不是数据库可以优化的东西.在Postgres做同样的事情会是一个疯狂的想法吗?您通常使用的许多表中是否存在已知限制?我无法找到这个用例的好信息.

最佳答案 看起来分区可能对您有用,但我看到一个说明
large numbers (>100) of partitions can be detrimental的说明.您可能需要几千个分区,但如果您的查询一次不涉及多个分区,这可能不会产生负面影响.从Evercam的知识中,他们可能不会.

点赞