搜索引擎设计实用教程(5)-以百度为例

    Cache是目前实用的搜索引擎都必备的功能,因为研究表明用户的查询有相当比例(30%-40%)是重复的,而且大多数重复的用户查询会在较短的间隔时间被再次重复访问.比如说目前"芙蓉姐姐"成为街头巷议的美谈,那么不仅张三想搜索"芙蓉姐姐",王二麻子同样也想搜索,以免被隔壁的李四笑话赶不上时代潮流.既然大家的关注焦点是差不多的,那么没有必要每次接受到查询后都从索引库里面查找,把大量的用户查询放到CACHE里面,肯定能够节省不少计算资源.

   那么如何设计一个CACHE能够更加有效的节省计算资源呢?我们还是照旧分析一下百度是如何做的,当然,因为CACHE分析可以获得的外部信息非常少而且即使是获得的信息也不太可靠所以分析起来难度还是比较大的,所以下面的分析中有很大的比例是猜测的成分.

  CACHE设计主要关注两个大的方面:

   一个是CACHE的结构是怎样的?是只设计一个CACHE就拉倒呢?还是设计两级CACHE乃至三级CACHE?当然这里的二级三级不是咱们大老爷们们喜闻乐见的电影分级标准,而是优先级别的意思,你别指望从三级CACHE里面看到的都是清凉图片.

  第二个方面是采取何种替换算法?毕竟CACHE是宝贵的资源,当CACHE里面已经被塞满的时候,把哪个记录踢出CACHE才合算呢?

  我们看看百度的CACHE结构是怎样的.经过分析加推测,百度的CACHE系统可能有三个CACHE,用鲁迅先生的说法:百度有三个加快查询匹配的结构,其中一个是CACHE,另外一个也是CACHE,还有一个同样是CACHE.也就是说有一级CACHE,有二级CACHE,还有三级CACHE.

   这个一级CACHE是相当容易看出来的,我们可以随便想一个比较古怪的查询,之所以这样是避免CACHE里面已经保存了这个查询条件,以免影响我们的判断,比如说用"可见阿斯蒂芬健康法",这个查询够怪了吧,不会有哪位老兄象我一样无聊到要查这个东西吧,提交给百度,百度提示"找到相关网页约9,890篇,用时0.236秒",至于这个查询是否在CACHE里面,除了上帝,我估计连百度设计CACHE系统的技术人员也不知道.接着我们再次把这个查询提交给百度,百度提示"找到相关网页约9,890篇,用时0.001秒",嗯,这下有了一些线索了,看看时间的变化,从0.236秒到0.001秒(当然,分析CACHE是相当困难的,因为可以看到的线索太少,这里如果只凭借搜索时间是无法判断是否从CACHE里面存取的,必须结合几个方面:时间变化,找到的页面个数以及首页内容排序是否变化.如果找到页面个数不变,首页内容排序不变,即使时间变得很大,也极有可能是从CACHE里面获得的结果),从时间变化和返回结果以及首页排序来说,虽然我不知道第一次查询是否从CACHE里面返回结果,但是可以肯行的是第二次查询肯定是从CACHE里面获取的.再用其它几个例子测试,你会发现,只要是你两次提交同样的查询,第二次返回时间总是0.001秒.这明显是从第一级CACHE取得的结果,也就是说如果百度第一次检索发现查询不在一级CACHE里面,那么立即把这个查询调入一级CACHE.同时,这个一级CACHE是完全精确匹配的,如果查询有任何细微的变化,那么都无法从一级CACHE里面找到,百度对于一级CACHE的匹配很有可能是采用HASH计算,这样速度会相当快.我们可以设想百度的一级CACHE里面记录结构如下:

     HASH_id--->|record1|record2...

   当然,上面是个简略的表达,还有很多其它的信息比如加入CACHE的时间长短以及命中次数等其它信息.

   二级CACHE是否存在呢?为了能够将故事讲明白,在分析其它CACHE是否存在之前,我们首先需要介绍一下搜索引擎的索引.

   简单来说,搜索引擎的最核心的索引是倒排文档,这种数据结构是为了加快信息提取的速度,倒排文档的结构如下:

     word-->||....

     倒排文档记录了哪些文件出现过词汇word,上面的结构表明了doc_id1,doc_id2一直到doc_idk这么K个文档都出现过单词word.有了这个数据结构,假设用户的查询是单词"word",那么直接查找倒排文档表,就能把包含单词word的网页信息全部提取出来,然后按照一定规则排序输出即可.假设用户的查询有两个单词"word1 word2",那么从倒排文档里面提取包含word1的网页ID列表,再提取包含word2的网页ID列表,然后求两个列表的交集(搜索引擎一般假设用户查询是"与"的关系)这个交集里面的网页就是同时包含word1和word2的页面,然后按照一定规则排序输出,对于包含更多查询词汇的用户查询,基本上道理是一样的.

    好了,我们在转回来分析二级CACHE的问题,假设让我们来设计CACHE系统的话,一个最容易想到的方法是设立两个CACHE,一个放在内存,另外一个放在磁盘,两者都采取精确匹配,如果在内存CACHE里面没有找到,那么就到磁盘CACHE里面查找,如果找到则只执行一次磁盘I/O就可以输出结果,如果还是没有找到,那么在索引库里面按照切分好的单词进行查找,一方面切分出多少单词,就查找索引几次,另外一方面索引库总是远远大于磁盘CACHE,所以搜索时间肯定比磁盘CACHE查找慢.所以我们可以假定百度的二级CACHE是存储在磁盘的常用用户查询,当然至于百度是否有这么个CACHE我也不知道,全当猜测好了.

至于三级CACHE是否存在的问题,只能说很可能存在,之所以这么说,这里面有部分证据因素,也有部分推理因素。我们先说一下三级CACHE应该存在的推理因素,通过上面的分析,我们已经确认的是:百度的一级CACHE是存在的,而且是完全精确匹配.如果有两个查询:查询1:"芙蓉 姐姐" 查询2:"芙蓉 姐夫" 假设第一个查询已经进入一级CACHE,再搜索第二个查询的时候,因为一级CACHE要求精确匹配,所以第二个查询会被认为没有在CACHE找到,如果二级CACHE存在,也同样无法找到,那么这两个查询单词都必须从索引里面提取,但是事实上两个查询是存在交集"芙蓉"这个词汇的,没有理由每次都从索引里面提取,更合理的方式是把常用单词的倒排文档信息放在另外一个内存的CACHE里面,假设用户新的查询经过分词后包含若干单词,如果发现这个三级CACHE包含这个单词那么直接从CACHE里面读取,如果CACHE没有那么需要通过读磁盘文件来获得单词的倒排文档信息,这个CACHE的作用主要是节省磁盘I/O时间,直接在内存读取信息当然比读取磁盘快很多.所以从道理上是应该有这么一个在内存的三级CACHE的.

   接着提供一些证据来确认,输入查询"流浪",百度提示"找到相关网页约11,000,000篇,用时0.001秒",说明这个查询是在一级CACHE里面找到的,修改查询为"流浪 流浪"百度提示为"找到相关网页约11,000,000篇,用时0.144秒",从时间信息看说明一级CACHE里面没有找到,另外由于找到的页面没有变化,首页内容排序没有变化,所以很有可能是从CACHE里面读取的,当然这只能是一种可能性,并不能排除是从磁盘读取的.另外一个证据,输入查询"流浪 在线",百度提示"找到相关网页约2,080,000篇,用时0.174秒",修改查询为"在线 流浪",百度返回信息"找到相关网页约2,080,000篇,用时0.178秒 ",同时首页排序没有变化,另外时间0.178秒也不是很长. 所以很有可能是从CACHE里面读取的,当然同样并不能排除是从磁盘读取的.然而,如果一个查询是从磁盘读取的,那么必然查询越长,磁盘读写次数越多,时间越慢.但是构造一个很长的查询"在线 流浪 在线 流浪 在线 流浪 在线 流浪",百度提示"找到相关网页约2,080,000篇,用时0.179秒",时间基本上没有增加,页面排序也没有变化,所以有很大的可能是采用了上面讲的第三级CACHE。

   至于CACHE淘汰算法,现有的成熟并常用的CACHE淘汰算法包括LRU,SLRU,FBR,LRU/2等等,因为研究表明如果CACHE足够大的话,这些算法的效率尽管有细微的差别,但是总体上差不多,在实现的时候选择最简单的一个即可.

   所以,归纳上面的叙述内容,可以得到如下的三级CACHE算法:

   1.存在三级CACHE,一级CACHE在内存中,采取完全精确匹配,二级CACHE在磁盘中,采取完全精确匹配,三级CACHE在内存中,采取非完全精确匹配;

   2.得到用户查询编码,HASH计算得到HASH编码,在一级CACHE里面查找,如果找到输出,同时该查询命中次数计数器加1;

   3.如果在一级CACHE没有命中,则在二级CACHE精确查找,如果找到输出,同时该查询命中次数计数器加1并将该查询相关信息加载到一级CACHE;

   4.如果在二级CACHE没有找到,用户查询分词,判断组成查询的各个词汇是否在三级CACHE里面存在,如果存在则直接得到倒排文档列表,如果不存在则从索引库里面查找该词汇的倒排文档列表,并将该词汇及其倒排文档列表加入三级CACHE,计算各个查询词汇倒排文档列表的交集,并将其放入一级CACHE和二级CACHE;

  


/*版权声明:可以任意转载,转载时请务必标明文章原始出处和作者信息 .*/

搜索引擎设计实用教程(5)-以百度为例 之五:CACHE结构

中科院软件所 张俊林

2006年1月4日

[百度分享]以求医为例谈搜索引擎排序算法的基础原理

08-08

文章来源:[url=http://stblog.baidu-tech.com/?p=121]http://stblog.baidu-tech.com/?p=121[/url]rn rnrn rnrnrn我们向搜索引擎提交一个查询,搜索引擎会从先到后列出大量的结果,这些结果排序的标准是什么呢?这个看似简单的问题,却是信息检索专家们研究的核心难题之一。rnrn  为了说明这个问题,我们来研究一个比搜索引擎更加古老的话题:求医。比如,如果我牙疼,应该去看怎样的医生呢?假设我只有三种选择:rnrnA医生,既治眼病,又治胃病; rnB医生,既治牙病,又治胃病,还治眼病; rnC医生,专治牙病。 rn  A医生肯定不在考虑之列。B医生和C医生之间,貌视更应该选择C医生,因为他更专注,更适合我的病情。假如再加一个条件:B医生经验丰富,有二十年从医经历,医术高明,而C医生只有五年从医经验,这个问题就不那么容易判断了,是优先选择更加专注的C医生,还是优先选择医术更加高明的B医生,的确成了一个需要仔细权衡的问题。rnrn  至少,我们得到了一个结论,择医需要考虑两个条件:医生的专长与病情的适配程度;医生的医术。大家肯定觉得这个结论理所当然,而且可以很自然地联想到,搜索引擎排序不也是这样吗,既要考虑网页内容与用户查询的匹配程度,又要考虑网页本身的质量。但是,怎么把这两种因素结合起来,得到一个,而不是两个或多个排序标准呢?假如我们把这两种因素表示成数值,最终的排序依据是把这两个数值加起来,还是乘起来,或是按决策树的办法把它们组织起来?如果是加起来,是简单相加,还是带权重加呢?rnrn  我们可以根据直觉和经验,通过试错的办法,把这两个因素结合起来。但更好的办法是我们能找到一个明确的依据,最好能跟数学这样坚实的学科联系起来。说起来,依据朴素的经验,人类在古代就能建造出高楼;但要建造出高达数百米的 摩天大厦,如果没有建筑力学、材料力学这样坚实的学科作为后盾,则是非常非常困难的。同理,依据朴素的经验构建的搜索引擎算法,用来处理上万的网页集合应该是没问题的;但要检索上亿的网页,则需要更为牢固的理论基础。rnrn  求医,病人会优先选择诊断准确、治疗效果好的医生;对于搜索引擎来说,一般按网页满足用户需求的概率从大到小排序。如果用q表示用户给出了一个特定的查询,用d表示一个特定的网页满足了用户的需求,那么排序的依据可以用一个条件概率来表示:rnrnP(d|q)rnrn这个简单的条件概率,将搜索引擎排序算法与概率论这门坚实的学科联系了起来,这就像在大海中航行的船只装备了指南针一样。利用贝叶斯公式,这个条件概率可以表示为:rn[align=center][img=http://hi.csdn.net/attachment/201108/8/0_13127710146a8C.gif][/img][/align]rn可以清楚地看到,搜索引擎的排序标准,是由三个部分组成的:查询本身的属性P(q);网页本身的属性P(d);两者的匹配关系P(q|d)。对于同一次查询来说,所有网页对应的P(q)都是一样的,因此排序时可以不考虑,即rnrn[align=center][img=http://hi.csdn.net/attachment/201108/8/0_1312771030yN91.gif][/img][/align]rn公式左边,是已知用户的查询,求网页满足该用户需求的概率。搜索引擎为了提高响应用户查询的性能,需要事先对所有待查询的网页做预处理。预处理时,只知道网页,不知道用户查询,因此需要倒过来计算,即分析每个网页能满足哪些需求,该网页分了多大比例来满足该需求,即得到公式右边的第一项P(q|d),这相当于上文介绍的医生的专门程度。比如,一个网页专门介绍牙病,另一个网页既介绍牙病又介绍胃病,那么对于“牙疼”这个查询来说,前一个网页的P(q|d)值就会更高一些。rnrn  公式右边的第二项P(d),是一个网页满足用户需求的概率,它反映了网页本身的好坏,与查询无关。假如要向一个陌生人推荐网页(我们并不知道他需要什么),那么P(d)就相当于某个特定的网页被推荐的概率。在传统的信息检索模型中,这一个量不太被重视,如传统的向量空间模型、BM25模型,都试图只根据查询与文档的匹配关系来得到排序的权重。而实际上,这个与查询无关的量是非常重要的。假如我们用网页被访问的频次来估计它满足用户需求的概率,可以看出对于两个不同的网页,这个量有着极其巨大的差异:有的网页每天只被访问一两次,而有的网页每天被访问成千上万次。能够提供如此巨大差异的量,竟长期被传统的搜索引擎忽略,直到Google发明了pagerank并让它参与到排序中。Pagerank是对P(d)值的一个不错的估计,这个因素的加入使搜索引擎的效果立即上升到了一个新的台阶。rnrn  这个公式同样回答了上文提出的问题,网页与查询的匹配程度,和网页本身的好坏,这两个因素应该怎样结合起来参与排序。这个公式以不可辩驳的理由告诉我们,如果网页与查询的匹配程度用P(q|d)来表示,网页本身的好坏用P(d)来表示,那么应该按它们的乘积来进行排序。在现代商业搜索引擎中,需要考虑更多更细节的排序因素,这些因素可能有成百上千个,要把它们融合起来是更加复杂和困难的问题。rnrnBy 相关性小组 jianglingrnrn

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试

关闭