mysql 百万级数据插入更新速度问题

大家好^^

我现在正在作毕业设计 题目是构建一个搜索引擎

现在已经实现了crawler，代码全是自己写的，没有参开其他的open source,所以完全没有学习人家的开源的思想，比如nutch,然后再所以没有用文件作url的库，用的是mysql 5.0的innodb表，数据库中一共有12张表，分别是vUrls(以访问的url)，urls_0到urls_10(这11张表代表了11中不同权重的未访问的url)。（还是自己懒，写文件还要多代码，现在已经代码比较乱了）。

表结构：
1. 未访问表中有MD5和url字段，其中MD5字段是char(32)类型、主键，url是TEXT类型。
2. 已访问表中有ID(自增、主键)，MD5和url（类型同上）

操作主要集中在未访问表上，己访问表现在只是用来看看，程序中还是放在内存中。(以下未经说明针对未访问表)

程序中开了多线程通过socket下载网页，一个线程专门解析hyberlink,一个线程专门储存网页（文件形式），开了11个线程（11个权重）并发将解析出来的超链存入数据库。

1. 存入数据库前，这些url先放入一个阻塞队列，满100个时，batch进数据库。
2. 为了削去重复的url我在程序中使用了 replace语句，保证插入数据库的url是唯一的。
3. 有两个队列轮流充满待访问的url共socket提取下载，当一个空的时候另一个从数据库中提取 <100 个url充满。这样轮流让socket线程提取，轮流充满，保证socket线程不断。这里的逻辑是从权重最大的表开始看看如果记录条数>0(select count(*))，就select...limit 100 ，只取一张表的数据，不管取出的记录有没有100个，有就行,然后根据MD5把这些记录删掉.程序稳定后（我指uv.url表中的数据量 > 100，最多也就程序运行开始后十几秒的事），就都是batch出100个了。

现在的问题是:
在下载了 >10^5 张网页的时候（最大的权重url表中的行 >10^6），数据库GRUD速度明显跟不上了，因为innodb是锁行的，所以一个时候并发的查询多的时候会锁较长时间，这时候线程会waiting,有次测试 ,竟然数据库被索直到timeout。

然后自己看mysql的manual，优化，改了buffer-pool-size，又把死锁退出的时间调长了点，说实话，数据库这东西的优化是细活，硬活，而且我一直没存过海量，实在是看不出，也想不出什么好的优化方法。

大家看看，都来讨论讨论。

PS 1：
1. 其实要是search一个区域的网站的话，比如我们学校的所有网站的所有网页，我想能下载下150000张的网页，就够了吧（说错了 别扔我）。但是我想把毕设做得好些，想搞定网页数据量 10^6 的（天网那群人写的那本什么书上写到原始的天网就单机下载索引了 10^6 个网页）
2. 请问大家这样用数据库的方案可行不？(我指有教学性质的 单机版的 毕业设计式的 SE)

PS 2：
我使用数据库做urlDB的原因其实就是与其自己写代码控制urlDB,不如相信数据库的能力，比如并发的管理，GRUD的优化能力 etc. 没想到现在竟然反被束缚了，其导致的后果就是网页的下载速度从占满带宽到由于数据库的查询访问而将到 <20% 的地步。

评论

13 楼 waldenlake 2008-02-08  

引用

记得北大天网在这方面还特自豪，印象中采用了所谓的最小距离法......

看天网那本书这个部份时，其实觉得这个方法还不错

12 楼 waldenlake 2008-02-08  

引用

如果lz只是做搜索引擎的毕设，我建议楼主把注意力集中在搜索本身上，而不是网络爬虫上。毕竟在你通过爬虫抓取到html页面后还有大量的工作要做。

很好的建议，已经和导师联系缩小了题目的范围。

引用

content方面不用太过注重它的retrieval，而应该在它的refinement方面考虑多一点。

已经看了大量的paper了^^

11 楼 wainwen 2008-02-04  

xiaolin0105 写道

...
总之，数据库其实可以不用，把精力集中在index, query和relevancy上面，这才是search的core。

很中肯的建议

感觉LZ的毕业设计题目有点大，应该和导师协商，是将所有的搜索问题都囫囵过一遍，还是集中在某个更具体的问题上。其实光是爬虫问题，就足够写N篇论文了

搜索中的查重问题也有很多种，url是比较基本的，还有一个更有意思的查重问题，就是页面内容的查重。特别对国内，一篇好文章到处转载，小处略有不同，大处基本一样，作为搜索引擎需要识别出这类一气化三青来。记得北大天网在这方面还特自豪，印象中采用了所谓的最小距离法：根据词频，计算出两篇文章的距离，距离足够近，就认为两者是同一篇文章的不同变体。这种对比所需计算量更大，不知道天网能搞出什么不传之秘来^_^

10 楼 xiaolin0105 2008-02-04  

javaeyes 写道

看你喜欢闭门造车。
多看看别人的实现，也许会好很多。比如你这个url去重，用Bloomfilter的话比MD5放内存就要好多了。

你这种人多了对中国的未来是个打击。不管好坏，lz至少去试过了，自己思考了，虽然可能会走弯路，但是这是学习过程中不可避免的，如果我是lz的导师，我会很欣赏这样的学生。

我不敢说能给lz什么建议，只是说点自己小小的看法。曾经在一家搜索引擎公司实习过一段时间，公司的搜索平台是不用数据库来保存url的，根本就没有rdb,所有东西都是存储在自己的file system上的。

如果lz只是做搜索引擎的毕设，我建议楼主把注意力集中在搜索本身上，而不是网络爬虫上。毕竟在你通过爬虫抓取到html页面后还有大量的工作要做，content方面不用太过注重它的retrieval，而应该在它的refinement方面考虑多一点。。。这里有篇search engine的简单介绍，我觉得还可以，http://www.infotoday.com/searcher/may01/liddy.htm

总之，数据库其实可以不用，把精力集中在index, query和relevancy上面，这才是search的core。

9 楼 guile 2008-02-03  

首先对Url匹配是耗时的，一个简单的改进是换成MD5匹配，当然如果你喜欢，还可以考虑Bloomfilter算法，不过区区几百万数据也范不着。反正无论如何应该避免url匹配。

url的md5放到大列表里恐怕也有些问题，删除、增加的开销都比较大，最终还是会才用哈希或者查找树的方式，100万md5也不是30M的事情，假设你用的java,32位的MD5如果按字符串的格式存储，每条需要的存储空间约是80个字节，加上哈希的开销，大约1万条会耗费1M，所以内存开销大概会在180M到200M之间。

访问磁盘是不对的，无论如何都应该避免大量的随机磁盘读取，而且也没有必要考虑加锁，加锁的代价可能会大于倒霉时一个网页抓了两遍的代价。简单的做法是扔掉RDBMS，这东西负担太多了，完全没有必要使用它。

8 楼 ztka 2008-01-17  

楼主，你大概每秒插入多少数据？

7 楼 javaeyes 2008-01-15  

看你喜欢闭门造车。
多看看别人的实现，也许会好很多。比如你这个url去重，用Bloomfilter的话比MD5放内存就要好多了。

6 楼 waldenlake 2007-11-14  

昨天把mysql5.0卸了  换了5.1
看看新版的partition的by key 怎么样，原理也就是把主键哈希，将一个表的数据分成若干子表。
但是性能怎么样，还待测试。

5 楼 nihongye 2007-11-14  

增加一个url的hashcode字段, 就算几百万数据，照样飞快

4 楼 waldenlake 2007-11-12  

waldenlake 写道

nihongye 写道

引用

为了削去重复的url我在程序中使用了 replace语句，保证插入数据库的url是唯一的。

问题应该出在这条语句上，对url的全匹配肯定耗费时间。

我也这么认为，不知道如果从数据库端优化的话有没有什么好方法？

我现在想的是把所有未访问的url的MD5开一个大列表放内存中，算了算一百万也就30M。

但是这样还是有点不行，毕竟现在数据库中就有了5*10^6个url，要是将他们的MD5放到mem,还是大。
当然，我可以在程序中控制url的数量，比如，是否在指定的IP段中，是否指定的请求头内容。
不过link还是大

3 楼 waldenlake 2007-11-12  

nihongye 写道

引用

为了削去重复的url我在程序中使用了 replace语句，保证插入数据库的url是唯一的。

问题应该出在这条语句上，对url的全匹配肯定耗费时间。

我也这么认为，不知道如果从数据库端优化的话有没有什么好方法？

我现在想的是把所有未访问的url的MD5开一个大列表放内存中，算了算一百万也就30M。

2 楼 rtdb 2007-11-12  

用数据库实现队列，性能上不会太理想。

1 楼 nihongye 2007-11-12  

引用

为了削去重复的url我在程序中使用了 replace语句，保证插入数据库的url是唯一的。

问题应该出在这条语句上，对url的全匹配肯定耗费时间。