公司数据库中某表数据量达到了4亿多条,在增加索引以及相关的初步优化后效果不理想。因此,决定采用PostgresSQL的表分区,按照日期将该表的数据分散到各个分区上。
在分区表以及各个子表全部建立完毕后,发现服务器硬盘不足。那个大表大概占据了83G左右的空间,而服务器只有43G可用。如果,直接采用insert into new_table select * from old_table的话,势必会造成服务器硬盘空间不够。而如果向公司申请新增硬盘的话,整个流程相当复杂,再说了,如果把数据完全导入到新的分区表中的话,旧表就没用了。
第一次尝试,自己写了数据库程序按照10k为单位进行导入,放入事务中,插入成功10k,然后就把旧表的10k删除。在用screen执行程序后,周末休息。今天上班检查发现才导入成功了不到200万的数据,然后简单计算以后,大吃一惊,要完全导入完成竟然需要约200多天。OMG!完成一次动作竟然需要10min。放弃!
第二次,自己写好数据库约束规则,然后利用pg_restore将大量数据灌进去。结果发现数据竟然存在父表之中,而子表中一条数据也没有。但是手动插入数据,数据就会根据约束进入相关子表。仔细看文档后发现
[color=darkred]“COPY FROM 会激活所有触发器和检查约束。不过,不会激活规则。”[/color]
唉! 然后,清理数据库环境后,正式开始全面灌数...
在分区表以及各个子表全部建立完毕后,发现服务器硬盘不足。那个大表大概占据了83G左右的空间,而服务器只有43G可用。如果,直接采用insert into new_table select * from old_table的话,势必会造成服务器硬盘空间不够。而如果向公司申请新增硬盘的话,整个流程相当复杂,再说了,如果把数据完全导入到新的分区表中的话,旧表就没用了。
第一次尝试,自己写了数据库程序按照10k为单位进行导入,放入事务中,插入成功10k,然后就把旧表的10k删除。在用screen执行程序后,周末休息。今天上班检查发现才导入成功了不到200万的数据,然后简单计算以后,大吃一惊,要完全导入完成竟然需要约200多天。OMG!完成一次动作竟然需要10min。放弃!
第二次,自己写好数据库约束规则,然后利用pg_restore将大量数据灌进去。结果发现数据竟然存在父表之中,而子表中一条数据也没有。但是手动插入数据,数据就会根据约束进入相关子表。仔细看文档后发现
[color=darkred]“COPY FROM 会激活所有触发器和检查约束。不过,不会激活规则。”[/color]
唉! 然后,清理数据库环境后,正式开始全面灌数...