Postgresql表中最大(可用)的行数

我意识到,根据Pg文档( http://www.postgresql.org/about/ ),可以在表中存储无限数量的行。 但是,对于可用的行数(如果有的话),“经验法则”是什么?

背景:我想存储1300万个细胞的几十年的日常读数。 可以达到13M *(366 | 365)* 20〜9.5e10或95B行(实际上大约120B行)。

所以,使用表分区,我build立一个主表,然后按年份inheritance表。 这将行分成〜5.2 B每行。

每行有9个SMALLINT,两个INT,所以有26个字节。 除此之外,每行23字节的Pg开销,每行得到49字节。 所以,没有任何PK或任何其他指标的每张表格的重量约为0.25 TB。

对于初学者来说,我只创build了上述数据的一个子集,也就是只有大约25万个单元格。 我必须做一些调整(创build合适的索引等),但是现在的性能真的很糟糕。 此外,每次我需要添加更多的数据,我将不得不放弃钥匙,并重新创build它们。 节约的优点是一旦所有的东西都被加载,它将是一个只读的数据库。

有什么build议么? 任何其他的分区策略?

这不仅仅是“一堆调整(索引等)”。 这是至关重要的,也是必须的。

你发布了一些细节,但是我们试试吧。

规则是:尝试并find最常见的工作集。 看看它是否适合在RAM中。 优化硬件,PG / OS缓冲区设置和PG索引/集群。 否则,寻找聚合,或者如果它是不可接受的,你需要完全随机访问,想想什么样的硬件可以在合理的时间扫描整个表。

你的桌子有多大(千兆字节)? 它如何比较总RAM? 你的PG设置是什么,包括shared_buffers和effective_cache_size? 这是一个专门的服务器? 如果你有一个250G的表和大约10GB的RAM,这意味着你只能适应4%的表。

是否有任何通常用于过滤的列,如状态或date? 你可以使用最常用的工作集(如上个月)吗? 如果是这样,请考虑对这些列进行分区或集群,并确定将它们编入索引。 基本上,你试图确保尽可能多的工作集适合内存。

如果不适合在RAM中,请不惜一切代价扫描表。 如果你真的需要绝对的随机访问,唯一可以使用的方法是非常复杂的硬件。 您需要持久的存储/ RAMconfiguration,可以在合理的时间内读取250 GB。