我意识到,根据Pg文档(http://www.postgresql.org/about/),可以在表中存储无限数量的行.但是,如果有的话,可用行数的"经验法则"是什么？
背景:我想为1300万个细胞存储几十年的每日读数.这可以达到13 M*(366 | 365)*20~9.5e10,或95 B行(实际上,大约120 B行).
因此,使用表分区,我设置了一个主表,然后按年继承表.将行分为每个表约5.2 B行.
每行是9个SMALLINT,两个INT,因此,26个字节.除此之外,每行23字节的Pg开销,每行得49个字节.因此,每张表,没有任何PK或任何其他索引,将在~0.25 TB的重量.
对于初学者,我只创建了上述数据的一部分,即只有大约250,000个单元格.我必须做一堆调整(创建适当的索引等),但现在的性能真的很糟糕.此外,每次我需要添加更多数据时,我都必须删除密钥并重新创建它们.保存的优点是,一旦加载了所有内容,它将是一个只读数据库.
有什么建议？任何其他分区策略？
Kon*_*rus 49
这不仅仅是"一堆调整(索引等)".这是至关重要的,也是必须的.
你发布了一些细节,但试试吧.
规则是:尝试找到最常用的工作集.看看它是否适合RAM.为其优化硬件,PG/OS缓冲区设置和PG索引/群集.否则查找聚合,或者如果它不可接受并且您需要完全随机访问,请考虑硬件可以在合理的时间内为您扫描整个表.
你的桌子有多大(千兆字节)？它与总RAM相比如何？您的PG设置是什么,包括shared_buffers和effective_cache_size？这是专用服务器吗？如果你有一个250-gig表和大约10 GB的RAM,这意味着你只能满足4%的表.
是否有通常用于过滤的列,例如州或日期？你能使用最常用的工作装置(比如上个月)吗？如果是这样,请考虑对这些列进行分区或聚类,并明确索引它们.基本上,您正在尝试确保尽可能多的工作集适合RAM.
如果不适合RAM,请不惜一切代价扫描桌子.如果您确实需要绝对随机访问,那么唯一可以使用的方法就是复杂的硬件.您需要一个持久的存储/ RAM配置,它可以在合理的时间内读取250 GB.
| 归档时间： |
|
| 查看次数： |
25429 次 |
| 最近记录： |