sql - Postgres-一张巨型桌子与10k +分开的桌子-分区

在过去的两年中，我们尝试了许多不同的数据库引擎和数据库样式，以解决需要同时具有NoSQL和RDBMS软件包功能的特定问题。我们选择了RDBMS和Postgres。

我们已经对许多不同的场景进行了性能测试，结果表明Postgres一直可以很好地处理所有事情，但是我们知道模拟不是生产过程，其他人在大规模数据库方面的体验也大不相同。

一个巨人与许多小家伙之间的冲突是一个很好的论据，但我的问题是有关适度的硬件在规模上的效率（适度的硬件始于小型Linux VPS机顶盒，随着需求的增长而越来越大）。

我们只有一个表（5列，2个索引（1个是三元索引）），很容易超过10亿行。如果我们改为说10（或什至100k）个表会稀释服务器资源，因为由于表的剪切数，索引是否不能全部保存在ram中？如果将数据拆分，则几乎所有10k表都将被读/写，因此就没有这样的特定活动表。

在讨论分区时，由于所有分区都会很热，因此我认为，鉴于读/写活动的广泛分布，这样做也会带来有限的收益。

所以我的问题是：“如果资源有限，将数据分区到一个表中或将其拆分成多个表时，Postgres会变得效率低下吗？是否只有一个表索引和几乎所有表索引才能获得效率？活动集中在表格的末尾。”

听起来分区不会带来很多好处。如果您过度使用并进行1万个分区，则可能会有很多开销。即使您做一些更合理的事情（例如100个分区），如果使用触发器将元组定向到正确的分区，那仍然会带来很多开销。但是从将数据装入RAM的角度来看，拆分索引应该不是什么大问题。不论是否分区，总数据量几乎都是相同的。

即使没有很好的分区键，进行分区的一些好处也可能是：

您（或自动真空工作人员）可以分别清理每个分区。与一张巨型表不同，这可以在分区上并行发生。而且，如果是串行的，您仍然具有以下优点：可以离散地进行最终处理。如果工作台真空吸尘器在完成之前被打断，例如通过系统维护，它将失去许多已完成的工作，需要重复进行；巨型表可能是一个主要问题。
如果需要添加索引，可以将它们并行添加到不同的分区。或者，您可以将它们串行添加，但是具有大量的小型维护窗口，而不是一个大型维护窗口。
如果您需要重新编制索引（例如，以解决索引膨胀问题）与添加索引具有相同的好处。
如果需要添加存储，但不能在线扩展RAID，则可以将分区迁移到其他表空间。尽管您可能也可以在先前未分区的表中的其他表空间中添加分区，但是这样做的好处可能不是很多。