首页 > 代码库 > 亿级数据的高并发通用搜索引擎架构设计(转-张宴)

亿级数据的高并发通用搜索引擎架构设计(转-张宴)

[文章作者:张宴 本文版本:v1.0 最后修改:2008.12.09 转载请注明原文链接:http://blog.zyan.cc/post/385/]

  曾经在七月,写过一篇文章──《基于Sphinx+MySQL的千万级数据全文检索(搜索引擎)架构设计》,前公司的分类信息搜索基于此架构,效果明显,甚至将很大一部分带Where条件的MySQL SQL查询,都改用了Sphinx+MySQL搜索。但是,这套架构仍存在局限:一是MySQL本身的并发能力有限,在200~300个并发连接下,查询和更新就比较慢了;二是由于MySQL表的主键与Sphinx索引的ID一一对应,从而无法跨多表建立整站查询,而且新增加类别还得修改配置文件,比较麻烦;三是因为和MySQL集成,无法发挥出Sphinx的优势。

  最近,我设计出了下列这套最新的搜索引擎架构,目前已经写出“搜索查询接口”和“索引更新接口”的beta版。经测试,在一台“奔腾四 3.6GHz 双核CPU、2GB内存”的普通PC机,7000万条索引记录的条件下,“搜索查询接口”平均查询速度为0.0XX秒(查询速度已经达到百度、谷歌、搜狗、中国雅虎等搜索引擎的水平,详见文章末尾的“附2”),并且能够支撑高达5000的并发连接;而“索引更新接口”进行数据分析、入队列、返回信息给用户的全过程,高达1500 Requests/Sec。

  “队列控制器”这一部分是核心,它要控制队列读取,更新MySQL主表与增量表,更新搜索引擎数据存储层Tokyo Tyrant,准实时(1分钟内)完成更新Sphinx增量索引,定期合并Sphinx索引。我预计在这周写出beta版。

点击在新窗口中浏览此图片

  图示说明:
  1、搜索查询接口:
  ①、Web应用服务器通过HTTP POST/GET方式,将搜索关键字等条件,传递给搜索引擎服务器的search.php接口;
  ②③、search.php通过Sphinx的API(我根据最新的Sphinx 0.9.9-rc1 API,改写了一个C语言的PHP扩展sphinx.so),查询Sphinx索引服务,取得满足查询条件的搜索引擎唯一ID(15位搜索唯一ID:前5位类别ID+后10位原数据表主键ID)列表;
  ④⑤、search.php将这些ID号作为key,通过Memcache协议一次性从Tokyo Tyrant中mget取回ID号对应的文本数据。
  ⑥⑦、search.php将搜索结果集,按查询条件,进行摘要和关键字高亮显示处理,以JSON格式或XML格式返回给Web应用服务器。

  2、索引更新接口:
  ⑴、Web应用服务器通过HTTP POST/GET方式,将要增加、删除、更新的内容告知搜索服务器的update.php接口;
  ⑵、update.php将接收到的信息处理后,写入TT高速队列(我基于Tokyo Tyrant做的一个队列系统);
  注:这两步的速度可达到1500次请求/秒以上,可应对6000万PV的搜索索引更新调用。

  3、搜索索引与数据存储控制:
  ㈠、“队列控制器”守护进程从TT高速队列中循环读取信息(每次50条,直到末尾);
  ㈡、“队列控制器”将读取出的信息写入搜索引擎数据存储层Tokyo Tyrant;
  ㈢、“队列控制器”将读取出的信息异步写入MySQL主表(这张主表按500万条记录进行分区,仅作为数据永久性备份用);
  ㈣、“队列控制器”将读取出的信息写入MySQL增量表;
  ㈤、“队列控制器”在1分钟内,触发Sphinx更新增量索引,Sphinx的indexer会将MySQL增量表作为数据源,建立增量索引。Sphinx的增量索引和作为数据源的MySQL增量表成对应关系;
  ㈥、“队列控制器”每间隔3小时,短暂停止从TT高速队列中读取信息,并触发Sphinx将增量索引合并入主索引(这个过程非常快),同时清空MySQL增量表(保证了MySQL增量表的记录数始终只有几千条至几十万条,大大加快Sphinx增量索引更新速度),然后恢复从TT高速队列中取出数据,写入MySQL增量表。

  本架构使用的开源软件:
  1、Sphinx 0.9.9-rc1
  2、Tokyo Tyrant 1.1.9
  3、MySQL 5.1.30
  4、Nginx 0.7.22
  5、PHP 5.2.6

  本架构自主研发的程序:
  1、搜索查询接口(search.php)
  2、索引更新接口(update.php)
  3、队列控制器
  4、Sphinx 0.9.9-rc1 API的PHP扩展(sphinx.so)
  5、基于Tokyo Tyrant的高速队列系统



  附1:MySQL FullText、Lucene搜索、Sphinx搜索的第三方对比结果:
  1、查询速度:
  MySQL FullText最慢,Lucene、Sphinx查询速度不相上下,Sphinx稍占优势。
  点击在新窗口中浏览此图片

  2、建索引速度:
  Sphinx建索引速度是最快的,比Lucene快9倍以上。因此,Sphinx非常适合做准实时搜索引擎。

  3、详细对比数据见以下PDF文档:  

下载文件
点击这里下载文件





  附2:国内各大中文搜索引擎搜索速度分析:
  以“APMServ张宴”为关键字,比较在各大中文搜索引擎的搜索速度:
  1、百度:
  ①、第一次搜索
  点击在新窗口中浏览此图片

  ②、第二次搜索
  点击在新窗口中浏览此图片

  分析:百度对第一次搜索的搜索结果做了Cache,所以第二次查询非常快。



  2、谷歌:
  ①、第一次搜索
  点击在新窗口中浏览此图片

  ②、第二次搜索
  点击在新窗口中浏览此图片

  分析:谷歌也对第一次搜索的搜索结果做了Cache,但两次查询跟百度同比,都要慢一些。



  3、搜狗:
  ①、第一次搜索
  点击在新窗口中浏览此图片

  ②、第二次搜索
  点击在新窗口中浏览此图片

  ③、第三次搜索
  点击在新窗口中浏览此图片

  分析:搜狗疑似对第一次搜索的搜索结果做了短暂的Cache,第二次搜索速度非常快,第三次搜索的速度比第二次搜索的速度慢。搜狗第一次搜索的速度跟百度差不多。



  4、中国雅虎:
  ①、第一次搜索
  点击在新窗口中浏览此图片

  ②、第二次搜索
  点击在新窗口中浏览此图片

  分析:搜索结果没有做Cache。中国雅虎的搜索速度跟百度第一次搜索的速度差不多。



  5、网易有道:
  ①、第一次搜索
  点击在新窗口中浏览此图片

  ②、第二次搜索
  点击在新窗口中浏览此图片

  分析:有道对第一次搜索的搜索结果做了Cache。但是,跟谷歌一样,两次搜索同比都要较百度、搜狗、中国雅虎慢一些。



Tags: linux , php , sphinx , search , tokyotyrant , ttserver , tokyocabinet , mysql , google , 百度 , 谷歌 , 搜狗 , 雅虎 , 有道
技术大类 » 搜索引擎技术 | 评论(85) | 引用(1) | 阅读(96748)

linvo Email Homepage
2008-12-9 12:34
强~不知道那些搜索门户网站的构架怎样
jk
2008-12-9 12:42
怀疑百度显示的时间不是实际检索花费的时间。
大菠萝 Email Homepage
2008-12-9 12:46
感觉Baidu和Google一样快呀。用FireBug查看页面载入时间。Baidu :165ms,Google:154ms。
张宴 回复于 2008-12-9 12:56
搜索引擎显示的都只是索引查询时间,页面载入时间不包含在内。
outrace
2008-12-9 13:00
Sphinx 不支持非int类型的id。这点很讨厌。
ttserver对php内容无法反序列化,不支持压缩,这两点也很讨厌。

要是没有这几个问题就好了。
ptubuntu Email Homepage
2008-12-9 14:27
对开发程序还是不懂.不过这对我来说可以多学习一些.不过觉的google他们做的比较复杂的.可想而知.
cyt
2008-12-9 15:24
这套东西离google、baidu还差好远好远。。
fei
2008-12-9 17:13
有没有这么夸张啊?
dugu
2008-12-9 17:30
想用到实践中。
cncaiker
2008-12-9 22:34
会发布吗?非常期待smile
jeck Homepage
2008-12-9 22:49
强,佩服的五体投地!更期待在高负荷的生产环境中的数据
dd_macle
2008-12-10 03:41
学习...
gs
2008-12-10 07:23
sina wants to develop his own search engine
ttplay
2008-12-10 12:03
一句话解释:
一个人将记录写到了缓存,数据库中并更新索引,
另一个人通过索引从缓存或数据库中读出记录.
grin
plantegg
2008-12-11 23:19
从原理上讲你这个是不可能赶上google/baidu/sogou那些的,虽然看起来和Lucene(Java写得,你也没做任何优化吧)差不多,Lucene搜索结果也是要考虑相关性、排名等等(所以在每篇文章中命中次数是要统计的,不是找到一次就了事),不知道Sphinx有这些没?没有的话这个比较对Lucene太不公平 :)

搜索引擎Cache命中率一般在60%略高的样子,索引所用的内存都是几百G几百G的

你这个只对增量增加敏感,好像删除的话不能更新索引吧?

不过不得不赞一下你这个也相当棒:)
张宴 回复于 2008-12-12 09:35
当然,Google/Baidu/Sogou的权重计算算法要更复杂,索引数量为几亿到几十亿,也要多很多。为什么文中的搜索结果Google会慢一些,Google网页索引数量已经达到惊人的一万亿(见:http://www.readwriteweb.com/archives/google_hits_one_trillion_pages.php),这么大的数量级,索引比百度慢一些,也是正常的。

所以,相对而言,我的这套索引单台机器支撑1亿索引,达到Google/Baidu/Sogou的查询速度,算不错了。

至于和Lucene的比较,Sphinx拥有下列与Lucene所对应的权重计算模式,那个PDF文档已经在各种类型下与Lucene进行比较:
SPH_RANK_PROXIMITY_BM25, default ranking mode which uses and combines both phrase proximity and BM25 ranking.
SPH_RANK_BM25, statistical ranking mode which uses BM25 ranking only (similar to most other full-text engines). This mode is faster but may result in worse quality on queries which contain more than 1 keyword.
SPH_RANK_NONE, disabled ranking mode. This mode is the fastest. It is essentially equivalent to boolean searching. A weight of 1 is assigned to all matches.
SPH_RANK_WORDCOUNT, ranking by keyword occurrences count. This ranker computes the amount of per-field keyword occurrences, then multiplies the amounts by field weights, then sums the resulting values for the final result.
SPH_RANK_PROXIMITY, added in version 0.9.9, returns raw phrase proximity value as a result. This mode is internally used to emulate SPH_MATCH_ALL queries.
SPH_RANK_MATCHANY, added in version 0.9.9, returns rank as it was computed in SPH_MATCH_ANY mode ealier, and is internally used to emulate SPH_MATCH_ANY queries.

增量索引能够实现索引的增加、更新。索引的删除更简单,Sphinx支持属性标记,假如正常状态is_delete属性为0,那么删除就将is_delete属性标记为1,属性标记是在内存中进行的,在Sphinx停止时自动写入磁盘,非常快,因而删除索引可以说是实时的。在合并索引时,通过--merge-dst-range参数,即可排除掉被标记为删除的索引。
dd
2008-12-12 11:36
牛,向你学习,虽然现在有些还是看不懂
EOOD
2008-12-12 18:07
不得不说 Sphinx 与GOOGLE BAIDU 甚至 lucene 都没有可比性
Syu
2008-12-12 21:46
不知道张宴遇到过一个问题没.
我发现凡带 [ ] 号的会对检索结构有严重干扰.
bluepower
2008-12-22 00:16
请问你的柘朴图是用什么软件画的?
rrddd
2008-12-26 16:53
还行
1111
2008-12-27 17:39
请问你的柘朴图是用什么软件画的?
我也想知道?
张宴 回复于 2008-12-30 16:37
亿图 4.1