Postgres上具有许多表的应用程序的数据库或模式

时间:2015-07-04 14:11:45

标签: postgresql database-administration

我正在我的webapp上推出一项新功能,最终将使用户能够在数据库中创建动态表。随着时间的推移,我预计这可能会导致数千或数万个表被创建。

我理解postgres doesn't have explicit limits关于数据库中表的数量,但是如果该数字太大,性能可能会降低。为了减轻这种影响,我正在考虑将底层存储分解为不同的数据库或不同的schemas。我的主要问题是:这些选择之一是否比其他选择更好?如果是这样,为什么?使用模式实现起来似乎更容易,但是我不确定这是否会真正解决可能出现的一些潜在的长期性能问题。

请注意,这些表是完全独立的 - 因此不必担心需要与其他表连接。

另外,假设我正在处理可能让我遇到麻烦的恶意和/或意外用户能够创建数据库表的任何验证。

1 个答案:

答案 0 :(得分:1)

来自手册的Database File Layout

  

每个表和索引都存储在一个单独的文件中。

所以,这是第一个要考虑的问题。除非使用不同的表空间,否则您应该拥有一个文件系统,它可以很好地处理单个目录中的大量文件。

请注意,即使在相同的模式或同一个数据库中也可以有不同的表空间,因此使用不同的模式可能是出于其他原因,例如具有相同名称的表(实际上,PostgreSQL中的模式只是一个分区命名空间的方法。)

对于数据库,我认为只有数据库的解决方案可能对你有好处,我认为每个数据库都可能带来非常重要的开销。

最后:由于系统使用自己的目录,这是一组关系表,我想你可以很好地扩展,也许你需要在目录表上添加一些索引,如果它们不存在的话。

最后一条建议:在投入时间和资源之前,对其进行模拟,通过编程方式生成一千个表,用随机数据填充它们,并在假设下模拟它们的使用系统的负载。