65000数据采集的一点经验

sushy

偶采集某商用数据库。

由于数据库有防批量设置，且必须使用代理。因此造成了不少的麻烦。

开始的时候贪多，一个任务采集20000条，采地址和采数据同时进行。结果采地址的时候内存飙到150M，采数据的时候出现无法数据库死锁的问题。

后来偶进行了一些改进。一个任务采集10000条。先采集地址。地址采集完以后重启火车头，采数据。对没有采集完毕的直接在数据库中调整。进一步采集。

把任务做成规则，方便下个任务采集。

每次一个任务完成以后再添加新的任务。每个任务使用不同的表。



由于偶下面的任务不需要上传，所以删除了id ,已采，已发，缩略图，PageUrl，处理中等各列。因为ID列是自动更新的,所以ID必须删除。

然后直接应用SQL的insert语言进行整合。整合完毕压缩数据库。然后再添加一个自动增加的ID列。这样，一个完美的数据库就别整合出来了。

由于偶是标准版的，不能采集数据，所以偶用SQL语言将文档网址列导出到.txt文档中。由于偶已经整合完毕，所以导出了65000余列。

导出的网址每行是有""的，添加到迅雷或者快车之前必须将两端的“”去掉。5M的.TXT文件用记事本打开，修改，内存飙到100M，CPU99%，这种方法不可取。建议大家使用写字板打开和修改。

得到5.5M的TXT文档后，导入迅雷。如果一次性导入65000条，CPU100%不说，迅雷也变成了蜗牛。偶将这个5M的数据分割成12个文件。一次性导入4000条进去，结果迅雷丢了很多数据。这是偶不愿意看到的。所以偶又导入一次，迅雷自动过滤掉已经采集的。这样连续三次才全部搞定。

后来将每个文本文件再分割成3个，每个文本里面含有1500左右的数据。导入迅雷后轻松采集。郁闷的是，快车有智能命名功能，不是偶想要的原始文件名，这也需要大家采集的时候注意。

偶的经验是，分步采集，然后合并。

HOHO，偶拿到了一个90M的数据库，和65000的文档，爽啊。

当然由于采集之前没有考虑太多，所以导致了一些问题，如文档网址列，偶采集了相对地址后直接入库，后来在数据库中修改 列，用了sql语言，呵呵，查了很多资料。

初次采集，完美成功。

偶建议大家能买VIP就用VIP，如果我有VIP的采其他文件功能，可能就不需要后来搞文本，搞迅雷，这么麻烦了，火车头就自动把这一切做好了。


没有得到商业许可的情况下，不建议学偶采集商业数据库


偶一小文，和大家分享愉快心情。e

[ 本帖最后由 sushy 于 2007-12-1 20:44 编辑 ]

vus520

总的来说,就是数据量太大,不好处理!

数据一大,ACCESS慢不说,快车呀迅雷呀,火车呀,都慢起来了!
你说的100M已经很不错了,不知道我为什么一开火车内存一般都在1000M左右,一般情况下,内存只占用600M左右!

采集内容稍微多一些的,基本上要假死半分钟~~

sushy

我估计和你的表太大了有关系。我采集10000记录网址的时候表才5M，采集完毕才13M左右。把所有的表整合在一起一共90M。由于每个表采集的任务少，所以速度快，且一点都不卡。

vus520

同时,小说站例外~~

哈哈,2000篇文章Mysql数据库可以上两个G~~~
Access我采集到900M就不敢再动了~~~

bbbcb365

兄弟你每次采200条信息,保证你们的机器以及网络都能受得了.呵呵

sushy

原帖由 bbbcb365 于 2007-12-2 09:52 发表
兄弟你每次采200条信息,保证你们的机器以及网络都能受得了.呵呵

机器和网络受的了，人就疯了

cofcn

你们牛,5万就出来现摆,呵呵...
我单条任务,最多时,搞到15万,也没见如何,想办法解决就是了,呵呵,我批量采集,除了被采网站的内容少外,大都在一万左右,刷新开在10MS,线程开在5个,对方网站晕倒了:)
百度的硬件防火墙,也照样对付他,哈

火车头大数据采集方面,做的很欠缺.

sunway888

謝謝分享,支持樓主