读取大数据文件并写入postgresql的各种执行效率对比

数据量为一周的数据，总共有"9515903"条

01.单进程计算单个文件并马上导库，反复循环。总需要耗时867.717042459

 

02.尝试多进程读取每个数据，再合并数据，写库。总需要耗时442.614129279秒。

其中数据读取时间为214.04秒，数据合并时间为241.19秒

 

03.尝试多进程读取每个数据，然后在进程内写库（未成功的写库）

 

04.设置一个写库进程反复循环，然后有四个读文件进程.总需要耗时：227.64907325299998秒

 

肉眼可见04的方法最好，一个写库进程在后台不断在堆栈中取数据写入数据库，其他进程在前段不断读取文件再推入堆栈中。

postgresql因为是多进程的，03的方法理论可行。但是实际上没有成功，估计是因为多进程写库的同一个表，导致出现的问题。

 

这次的程序第一个坎是，在用copy_from向数据库导入数据之前一定要将游标复位。

output.seek(0)好多的网上教程没有提到这一点。

 

这次的程序第二个坎是，丢弃data列数据。因为data列的字段有各种各样的符号，经常导致导入数据格式不正确，考虑先不导入该列，之后需要的话，再导入到一个新数据库的表中。

 

这次的程序第三个坎是，多进程调用必须用堆栈之类的传递数据，不能直接简单的调用变量。manager.Queue()应该是现在最简单的堆栈了。当时想用callback函数，一直没有成功。

 

这次的程序第四个坎是，多进程中一个完全不同的后台写库进程，不能跟其他的进程一样的调用方式，因为要是用pool的方式的话，就是反复的开启该进程。

 

这次的程序第五个坎是，pool的读文件进程执行完毕之后需要怎么停止写库的进程。从进程计数，到写库计数，都不能合适解决，后来想到多执行N次（不知道为什么变成死循环），最后找到Queue.join()函数。开始还被函数的简单介绍给误导。最后发现需要将Queue.task_done()函数跟Queue.join()函数配合使用才对。

 

 

代码放在github上了

https://github.com/afst37/l