背景:我想存储几十年的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个单元格。我必须做一堆调整(创建适当的索引等),但性能是非常可怕的现在。此外,每次我需要添加更多的数据,我将不得不删除键和重新创建它们。保存的恩典是,一旦一旦加载,它将是一个只读数据库。
有什么建议么?任何其他分区策略?
它不只是“一堆调整(索引等)”。这是至关重要的,必须做的。你贴了几个细节,但让我们试试。
规则是:尝试并找到最常见的工作集。看看它是否适合RAM。优化硬件,PG / OS缓冲区设置和PG索引/集群。否则查找聚合,或者如果它不可接受,并且您需要完全随机访问,请考虑什么硬件可以在合理的时间扫描整个表。
你的桌子有多大(以千兆字节)?它如何与总RAM进行比较?你的PG设置是什么,包括shared_buffers和effective_cache_size?这是一个专用服务器吗?如果你有一个250Gig表和大约10GB的RAM,这意味着你只能适应4%的表。
是否有任何列通常用于过滤,如状态或日期?你最常使用的工作集(只有上个月)吗?如果是这样,请考虑对这些列进行分区或聚类,并对其进行索引。基本上,你试图确保尽可能多的工作集合适合RAM。
避免扫描表,如果它不适合在RAM中。如果你真的需要绝对的随机访问,唯一可用的方法是真正复杂的硬件。您将需要一个持久存储/ RAM配置,可以在合理的时间读取250 GB。
总结以上是内存溢出为你收集整理的PostgreSQL表中的最大(可用)行数全部内容,希望文章能够帮你解决PostgreSQL表中的最大(可用)行数所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)