话说同志们在爬取数据的时候如何保存已经访问过的url和队列?对于爬取过的url,我使用redis的set来保存,访问队列是用list来保存,数据量是直线上升,内存不大,也只有4g,扛不住。不知道以前的方法是什么?
光阴似箭催人老,日月如移越少年。
队列和判断是否访问我都是用的MySQL,考虑到Redis的持久化特性不是很好,而且当时也没想过用Redis或者其他的,暂时现在用MySQL也没什么问题。 具体的做法就是对url的md5值做唯一索引,每次查询都很快,表结构也简单。 队列的话使用的是查表的形式,SQL如下(具体status是表示一些自己定义的状态): select * from t_down_task where status = 0 order by id limit 1; 定期删除已经执行完的任务
http://en.wikipedia.org/wiki/Bloom_fi...
4G内存可以开很大的BloomFilter了,每个URL只需要几个比特,URL长度无关。BloomFilter有一定错误率(比如千分之一、百分之一,取决于配置),会导致漏爬一些网页,但不会重复爬。
如果4G内存开BloomFilter还不够的话,楼主更需要考虑的问题是怎么存爬出来的网页。
md5的hash存储在数据量不是很大的时候,存在KV存储中还是比较靠谱的,索引量很大的话,估计不太够用,就得使用带空间压缩的一些特别算法,比如上面有人提到的bloom filter
也有人把这个算法存储用Memcache协议实现了,http://code.google.com/p/mc-bloom-fil...
一些持久化的k/v数据库可以考虑采用,我建议可以用leveldb。
这种还是不要用redis来做了,直接用文件系统
已经采集过的url通过MD5成16进制字符串,然后每4个字符作为一层目录,最后4个字符作为文件名,文件内容为空即可
判断url有没有采集过,直接把当前url MD5以后,按照上述规则生成文件路径,直接判断文件路径是否存在即可。
顶bloomfilter。可以这样使用:使用leveldb来存储url,然后查询的时候先用bloomfilter挡掉大部分不在库里面的的url,这样应该就差不多了。 lz要爬多少url?如果url非常多,比如上亿,有hadoop的话也可以用hadoop做新url和老url的去重,MapReduce很快的
队列和判断是否访问我都是用的MySQL,考虑到Redis的持久化特性不是很好,而且当时也没想过用Redis或者其他的,暂时现在用MySQL也没什么问题。
具体的做法就是对url的md5值做唯一索引,每次查询都很快,表结构也简单。
队列的话使用的是查表的形式,SQL如下(具体status是表示一些自己定义的状态):
select * from t_down_task where status = 0 order by id limit 1;
定期删除已经执行完的任务
http://en.wikipedia.org/wiki/Bloom_fi...
4G内存可以开很大的BloomFilter了,每个URL只需要几个比特,URL长度无关。BloomFilter有一定错误率(比如千分之一、百分之一,取决于配置),会导致漏爬一些网页,但不会重复爬。
如果4G内存开BloomFilter还不够的话,楼主更需要考虑的问题是怎么存爬出来的网页。
md5的hash存储在数据量不是很大的时候,存在KV存储中还是比较靠谱的,索引量很大的话,估计不太够用,就得使用带空间压缩的一些特别算法,比如上面有人提到的bloom filter
也有人把这个算法存储用Memcache协议实现了,http://code.google.com/p/mc-bloom-fil...
一些持久化的k/v数据库可以考虑采用,我建议可以用leveldb。
这种还是不要用redis来做了,直接用文件系统
已经采集过的url通过MD5成16进制字符串,然后每4个字符作为一层目录,最后4个字符作为文件名,文件内容为空即可
判断url有没有采集过,直接把当前url MD5以后,按照上述规则生成文件路径,直接判断文件路径是否存在即可。
顶bloomfilter。可以这样使用:使用leveldb来存储url,然后查询的时候先用bloomfilter挡掉大部分不在库里面的的url,这样应该就差不多了。
lz要爬多少url?如果url非常多,比如上亿,有hadoop的话也可以用hadoop做新url和老url的去重,MapReduce很快的