admin管理员组

文章数量:1663953


http://zhuanlan.51cto/art/201702/531315.htm 深入浅出搜索架构引擎、方案与细节(上) http://zhuanlan.51cto/art/201702/532287.htm 就是这么迅猛的实现搜索需求 http://zhuanlan.51cto/art/201703/533480.htm 百度如何能实时检索到15分钟前新生成的网页 http://zhuanlan.51cto/art/201611/523275.htm 百度咋做长文本去重(一分钟系列) http://chuansong.me/n/357710846539 如何快速实现高并发短文检索


深入浅出搜索架构引擎、方案与细节(上)
一、缘起     《100亿数据1万属性数据架构设计》文章发布后,不少朋友对58同城自研搜索引擎E-search比较感兴趣,故专门撰文体系化的聊聊搜索引擎,从宏观到细节,希望把逻辑关系讲清楚,内容比较多,分上下两期。     主要内容如下,本篇(上)会重点介绍前三章:     (1)全网搜索引擎架构与流程     (2)站内搜索引擎架构与流程     (3)搜索原理、流程与核心数据结构     (4)流量数据量由小到大,搜索方案与架构变迁     (5)数据量、并发量、策略扩展性及架构方案     (6)实时搜索引擎核心技术     可能99%的同学不实施搜索引擎,但本文一定对你有帮助。

二、全网搜索引擎架构与流程      全网搜索的宏观架构长啥样?全网搜索的宏观流程是怎么样的
    全网搜索引擎的宏观架构如上图,核心子系统主要分为三部分(粉色部分):     (1)spider爬虫系统     (2)search&index;建立索引与查询索引系统,这个系统又主要分为两部分:         一部分用于 生成索引数据build_index         一部分用于 查询索引数据search_index     (3) rank打分排序系统           核心数据主要分为两部分(紫色部分):     (1)web网页库     (2)index索引数据
    全网搜索引擎的业务特点决定了, 这是一个“写入”和“检索”完全分离的系统:     【写入】         系统组成:由spider与search&index;两个系统完成         输入:站长们生成的互联网网页         输出:正排倒排索引数据         流程:如架构图中的1,2,3,4         (1)spider把互联网网页抓过来         (2)spider把互联网网页存储到网页库中(这个对存储的要求很高,要存储几乎整个“万维网”的镜像)         (3) build_index从网页库中读取数据,完成分词         (4) build_index生成倒排索引     【检索】         系统组成:由search&index;与rank两个系统完成         输入:用户的搜索词         输出:排好序的第一页检索结果         流程:如架构图中的a,b,c,d         (a) search_index获得用户的搜索词,完成分词         (b) search_index查询倒排索引,获得“字符匹配”网页,这是初筛的结果         (c) rank对初筛的结果进行打分排序         (d)rank对排序后的第一页结果返回
三、站内搜索引擎架构与流程      做全网搜索的公司毕竟是少数,绝大部分公司要实现的其实只是一个站内搜索,站内搜索引擎的宏观架构和全网搜索引擎的宏观架构有什么异同? 以58同城100亿帖子的搜索为例,站内搜索系统架构长啥样?站内搜索流程是怎么样的?
     站内搜索引擎的宏观架构如上图, 与全网搜索引擎的宏观架构相比,差异只有写入的地方:     (1)全网搜索需要spider要被动去抓取数据     (2)站内搜索是内部系统生成的数据,例如“发布系统”会将生成的帖子主动推给build_data系统           看似“很小”的差异,架构实现上难度却差很多:全网搜索如何“实时”发现“全量”的网页是非常困难的,而站内搜索容易实时得到全部数据。     对于spider、search&index;、rank三个系统:     (1) spider和search&index;是相对工程的系统     (2) rank是和业务、策略紧密、算法相关的系统,搜索体验的差异主要在此,而业务、策略的优化是需要时间积累的,这里的启示是:         a)Google的体验比Baidu好,根本在于前者rank牛逼         b)国内互联网公司(例如360)短时间要搞一个体验超越Baidu的搜索引擎,是很难的,真心需要时间的积累

四、搜索原理与核心数据结构 什么是正排索引?什么是倒排索引?搜索的过程是什么样的?会用到哪些算法与数据结构? 前面的内容太宏观,为了照顾大部分没有做过搜索引擎的同学,数据结构与算法部分从正排索引、倒排索引一点点开始。
  • 提问:什么是正排索引(forward index)?
    回答: 由key查询实体的过程,是正排索引。         表:t_user(uid, name, passwd, age, sex),由uid查询整行的过程,就是正排索引查询。         网页库:t_web_page(url, page_content),由url查询整个网页的过程,也是正排索引查询。         网页内容分词后,page_content会对应一个分词后的集合list。         简易的, 正排索引可以理解为Map<url, list<item>>,能够由网页快速(时间复杂度O(1))找到内容的一个数据结构。
  • 提问:什么是倒排索引(inverted index)?
    回答: 由item查询key的过程,是倒排索引。     对于网页搜索, 倒排索引可以理解为Map<item, list<url>>,能够由查询词快速(时间复杂度O(1))找到包含这个查询词的网页的数据结构。     举个例子,假设有3个网页:         url1 -> “我爱北京”         url2 -> “我爱到家”         url3 -> “到家美好”     这是一个正排索引Map。     分词之后:         url1 -> {我,爱,北京}         url2 -> {我,爱,到家}         url3 -> {到家,美好}     这是一个分词后的正排索引Map。     分词后倒排索引:         我 -> {url1, url2}         爱 -> {url1, url2}         北京 -> {url1}         到家 -> {url2, url3}         美好 -> {url3}     由检索词item快速找到包含这个查询词的网页Map就是倒排索引。      正排索引和倒排索引是spider和build_index系统提前建立好的数据结构,为什么要使用这两种数据结构,是因为它能够快速的实现“用户网页检索”需求(业务需求决定架构实现)。
  • 提问:搜索的过程是什么样的?
    假设搜索词是“我爱”,用户会得到什么网页呢?     (1)分词,“我爱”会分词为{我,爱},时间复杂度为O(1)     (2)每个分词后的item,从倒排索引查询包含这个item的网页list,时间复杂度也是O(1):         我 -> {url1, url2}         爱 -> {url1, url2}     (3)求list的交集,就是符合所有查询词的结果网页,对于这个例子,{url1, url2}就是最终的查询结果     看似到这里就结束了,其实不然, 分词和倒排查询时间复杂度都是O(1),整个搜索的时间复杂度取决于“求list的交集”,问题转化为了求两个集合交集。 字符型的url不利于存储与计算,一般来说每个url会有一个数值型的url_id来标识,后文为了方便描述,list<url>统一用list<url_id>替代。
  • list1和list2,求交集怎么求?

方案一:for * for,土办法,时间复杂度O(n*n) 每个搜索词命中的网页是很多的,O(n*n)的复杂度是明显不能接受的。倒排索引是在创建之初可以进行排序预处理,问题转化成两个有序的list求交集,就方便多了。
方案二: 有序list求交集,拉链法
有序集合1{1,3,5,7,8,9} 有序集合2{2,3,4,5,6,7} 两个指针指向首元素,比较元素的大小: (1)如果相同,放入结果集,随意移动一个指针 (2)否则,移动值较小的一个指针,直到队尾 这种方法的好处是: (1) 集合中的元素最多被比较一次,时间复杂度为O(n) (2) 多个有序集合可以同时进行,这适用于多个分词的item求url_id交集 这个方法就像一条拉链的两边齿轮,一一比对就像拉链,故称为拉链法
注:url_id是可以在插入时就持续保持有序的,这样拿出来之后就不用先排序了。这样写入稍微慢点,但是能实现一次排序多次使用。
方案三:分桶并行优化 数据量大时,url_id分桶水平切分+并行运算是一种常见的优化方法, 如果能将list1和list2分成若干个桶区间,每个区间利用多线程并行求交集,各个线程结果集的并集,作为最终的结果集,能够大大的减少执行时间。 举例: 有序集合1{1,3,5,7,8,9, 10,30,50,70,80,90} 有序集合2{2,3,4,5,6,7, 20,30,40,50,60,70}
求交集,先进行分桶拆分 (按照区间): 桶1的范围为[1, 9] 桶2的范围为[10, 100] 桶3的范围为[101, max_int]
于是: 集合1就拆分成 集合a{1,3,5,7,8,9} 集合b{10,30,50,70,80,90} 集合c{} 集合2就拆分成 集合d{2,3,4,5,6,7} 集合e{20,30,40,50,60,70} 集合e{}
每个桶内的数据量大大降低了, 并且每个桶内没有重复元素,可以利用多线程并行计算: 桶1内的集合a和集合d的交集是x{3,5,7} 桶2内的集合b和集合e的交集是y{30, 50, 70} 桶3内的集合c和集合d的交集是z{} 最终,集合1和集合2的交集,是x与y与z的并集,即集合{3,5,7,30,50,70}
方案四:bitmap再次优化 数据进行了水平分桶拆分之后, 每个桶内的数据一定处于一个范围之内,如果集合符合这个特点,就可以使用bitmap来表示集合
如上图,假设set1{1,3,5,7,8,9}和set2{2,3,4,5,6,7}的所有元素都在桶值[1, 16]的范围之内,可以用16个bit来描述这两个集合, 原集合中的元素x,在这个16bitmap中的第x个bit为1,此时两个bitmap求交集,只需要将两个bitmap进行“与”操作, 结果集bitmap的3,5,7位是1,表明原集合的交集为{3,5,7} 水平分桶,bitmap优化之后,能极大提高求交集的效率,但时间复杂度仍旧是O(n) bitmap 需要大量连续空间,占用内存较大
方案五:跳表skiplist 有序链表集合求交集,跳表是最常用的数据结构,它可以将有序集合求交集的复杂度由O(n)降至O(log(n))
集合1{1,2,3,4,20,21,22,23,50,60,70} 集合2{50,70} 要求交集,如果用拉链法,会发现1,2,3,4,20,21,22,23都要被无效遍历一次,每个元素都要被比对,时间复杂度为O(n),能不能每次比对“跳过一些元素”呢? 跳表就出现了:
集合1{1,2,3,4,20,21,22,23,50,60,70}建立跳表时,一级只有{1,20,50}三个元素,二级与普通链表相同 集合2{50,70}由于元素较少,只建立了一级普通链表 如此这般,在实施“拉链”求交集的过程中,set1的指针能够由1跳到20再跳到50, 中间能够跳过很多元素,无需进行一一比对,跳表求交集的时间复杂度近似O(log(n)),这是搜索引擎中常见的算法。

五、总结     文字很多,有宏观,有细节,对于大部分不是专门研究搜索引擎的同学,记住以下几点即可: (1)全网搜索引擎系统由spider, search&index;, rank三个子系统构成 (2)站内搜索引擎与全网搜索引擎的差异在于,少了一个spider子系统 (3)spider和search&index;系统是两个工程系统,rank系统的优化却需要长时间的调优和积累 (4)正排索引(forward index)是由网页url_id快速找到分词后网页内容list的过程 (5)倒排索引(inverted index)是由分词item快速寻找包含这个分词的网页list的过程 (6)用户检索的过程,是先分词,再找到每个item对应的list,最后进行集合求交集的过程 (7)有序集合求交集的方法有          a)二重for循环法,时间复杂度O(n*n)          b)拉链法,时间复杂度O(n)          c)水平分桶,多线程并行          d)bitmap,大大提高运算并行度,时间复杂度O(n)          e)跳表,时间复杂度为O(log(n))

六、下章预告     a)流量数据量由小到大,搜索方案与架构变迁-> 这个应该很有用,很多处于不同发展阶段的互联网公司都在做搜索系统,58同城经历过流量从0到10亿,数据量从0到100亿,搜索架构也不断演化着     b)数据量、并发量、策略扩展性及架构方案     c)实时搜索引擎核心技术 -> 站长发布1个新网页,Google如何做到15分钟后检索出来

就是这么迅猛的实现搜索需求
一、缘起 《深入浅出搜索架构(上篇)》详细介绍了: (1)全网搜索引擎架构与流程 (2)站内搜索引擎架构与流程 (3)搜索原理与核心数据结构
本文重点介绍: (4)流量数据量由小到大,常见搜索方案与架构变迁 (5)数据量、并发量、扩展性方案 只要业务有检索需求,本文一定对你有帮助。

二、检索需求的满足与架构演进     任何互联网需求,或多或少有检索需求,还是以58同城的帖子业务场景为例,帖子的标题,帖子的内容有很强的用户检索需求,在业务、流量、并发量逐步递增的各个阶段,应该如何实现检索需求呢?
  • 原始阶段-LIKE
    数据在数据库中可能是这么存储的:         t_tiezi(tid, title, content)     满足标题、内容的检索需求可以通过LIKE实现:         select tid from t_tiezi where content like ‘%天通苑%’     能够快速满足业务需求,存在的问题也显而易见:     (1)效率低,每次需要全表扫描,计算量大,并发高时cpu容易100%     (2)不支持分词
  • 初级阶段-全文索引
    如何快速提高效率,支持分词,并对原有系统架构影响尽可能小呢,第一时间想到的是建立全文索引:         alter table t_tiezi add fulltext(title,content)     使用match和against实现索引字段上的查询需求。     全文索引能够快速实现业务上分词的需求,并且快速提升性能(分词后倒排,至少不要全表扫描了),但也存在一些问题:      (1)只适用于MyISAM      (2)由于全文索引利用的是数据库特性,搜索需求和普通CURD需求耦合在数据库中:检索需求并发大时,可能影响CURD的请求;CURD并发大时,检索会非常的慢;      (3)数据量达到百万级别,性能还是会显著降低,查询返回时间很长,业务难以接受     (4) 比较难水平扩展
  • 中级阶段-开源外置索引
    为了解决全文索的局限性, 当数据量增加到大几百万,千万级别时,就要考虑外置索引了。      外置索引的核心思路是:索引数据与原始数据分离,前者满足搜索需求,后者满足CURD需求,通过一定的机制( 双写,通知(消息),定期重建 )来保证数据的一致性。     原始数据可以继续使用Mysql来存储,外置索引如何实施?Solr,Lucene,ES都是常见的开源方案。     楼主强烈推荐ES(ElasticSearch),原因是Lucene虽好,但始终有一些不足:     (1)Lucene只是一个库,潜台词是,需要自己做服务,自己实现高可用/可扩展/负载均衡等复杂特性     (2)Lucene只支持Java,如果要支持其他语言,还是得自己做服务     (3)Lucene不友好,这是很致命的,非常复杂,使用者往往需要深入了解搜索的知识来理解它的工作原理,为了屏蔽其复杂性,一个办法是自己做服务     为了改善Lucene的各项不足,解决方案都是“封装一个接口友好的服务,屏蔽底层复杂性”,于是有了ES:     (1)ES是一个以Lucene为内核来实现搜索功能,提供REStful接口的服务     (2)ES能够支持很大数据量的信息存储,支持很高并发的搜索请求     (3)ES支持集群,向使用者屏蔽高可用/可扩展/负载均衡等复杂特性     目前 58到家使用ES作为核心,实现了自己的搜索服务平台,能够通过在平台上简单的配置,实现业务方的搜索需求。     搜索服务数据量最大的“接口耗时数据收集”需求,数据量大概在7亿左右; 并发量最大的“经纬度,地理位置搜索”需求,线上平均并发量大概在600左右,压测数据并发量在6000左右。      结论:ES完全能满足10亿数据量,5k吞吐量的常见搜索业务需求,强烈推荐。
  • 高级阶段-自研搜索引擎
    当数据量进一步增加,达到10亿、100亿数据量;并发量也进一步增加,达到每秒10万吞吐;业务个性也逐步增加的时候,就需要自研搜索引擎了,定制化实现搜索内核了。

三、数据量、并发量、扩展性方案     到了定制化自研搜索引擎的阶段, 超大数据量、超高并发量为设计重点,为了达到“无限容量、无限并发”的需求,架构设计需要重点考虑“扩展性”,力争做到:增加机器就能扩容(数据量+并发量)。     58同城的自研搜索引擎E-search初步架构图如下:
(1)上层proxy(粉色)是接入集群,为对外门户,接受搜索请求,其无状态性能够保证增加机器就能扩充proxy集群性能 (2)中层merger(浅蓝色)是逻 辑集群,主要用于实现搜索合并,以及打分排 序, 业务相关的rank就在这一层实现,其无状态性也能够保证增加机器就能扩充merger集群性能 (3)底层searcher(暗红色大框)是 检索集群,服务和索引数据部署在同一台机器上,服务启动时可以加载索引数据到内存,请求访问时从内存中load数据,访问速度很快     (3.1)为了满足数据容量的扩展性, 索引数据进行了水平切分增加切分份数,就能够无限扩展性能,如上图searcher分为了4组     (3.2) 为了满足一份数据的性能扩展性,同一份数据进行了冗余,理论上做到增加机器就无限扩展性能,如上图每组searcher又冗余了2份 如此设计,真正做到做到增加机器就能承载更多的数据量,响应更高的并发量。

三、总结 为了满足搜索业务的需求,随着数据量和并发量的增长,搜索架构一般会经历这么几个阶段: (1)原始阶段-LIKE (2)初级阶段-全文索引 (3)中级阶段-开源外置索引 (4)高级阶段-自研搜索引擎 你的搜索架构到了哪一个阶段?数据量、并发量、好的经验欢迎分享? 欢迎留言,有问必答。 如果有收获,欢迎帮转。

四、下章预告 实时搜索引擎核心技术,站长发布1个新网页,Google如何做到15分钟后检索出来。 ==【(中)完】==

百度如何能实时检索到15分钟前新生成的网页?
一、缘起 《深入浅出搜索架构(上篇)》详细介绍了前三章: (1)全网搜索引擎架构与流程 (2)站内搜索引擎架构与流程 (3)搜索原理与核心数据结构 《深入浅出搜索架构(中篇)》介绍了: (4)流量数据量由小到大,常见搜索方案与架构变迁 (5)数据量、并发量、扩展性架构方案 本篇将讨论: (6)百度为何能实时检索出15分钟之前新出的新闻?58同城为何能实时检索出1秒钟之前发布的帖子?搜索引擎的实时性架构,是本文将要讨论的问题。

二、实时搜索引擎架构     大数据量、高并发量情况下的搜索引擎为了保证实时性,架构设计上的两个要点:     (1)索引分级     (2)dump&merge
  • 索引分级
    《深入浅出搜索架构(上篇)》介绍了搜索引擎的底层原理, 在数据量非常大的情况下,为了保证倒排索引的高效检索效率,任何对数据的更新,并不会实时修改索引,一旦产生碎片,会大大降低检索效率。     既然索引数据不能实时修改,如何保证最新的网页能够被索引到呢?     索引分为全量库、日增量库、小时增量库。 如下图所述: (1)300亿数据在全量索引库中 (2)1000万1天内修改过的数据在天库中 (3)50万1小时内修改过的数据在小时库中
当有修改请求发生时,只会操作最低级别的索引,例如小时库。
当有查询请求发生时, 会同时查询各个级别的索引,将结果合并,得到最新的数据: (1) 全量库是紧密存储的索引,无碎片,速度快 (2) 天库是紧密存储,速度快 (3) 小时库数据量小,速度也快 数据的写入和读取都是实时的,所以58同城能够检索到1秒钟之前发布的帖子,即使全量库有300亿的数据。
    新的问题来了:小时库数据何时反映到天库中,天库中的数据何时反映到全量库中呢?      dump&merge
    这是由两个异步的工具完成的:         dumper:将在线的数据导出         merger:将离线的数据合并到高一级别的索引中去      小时库,一小时一次,合并到天库中去;     天库,一天一次,合并到全量库中去;     这样就保证了小时库和天库的数据量都不会特别大;     如果数据量和并发量更大,还能增加星期库,月库来缓冲。

三、总结     超大数据量,超高并发量,实时搜索引擎的两个架构要点: (1)索引分级 (2)dump&merge 如《深入浅出搜索架构(上篇)》中所述,全网搜索引擎分为Spider, Search&Index, Rank三个部分。本文描述的是Search&Index如何实时修改和检索, Spider子系统如何能实时找到全网新生成的网页,又是另外一个问题,未来撰文讲述。 希望大家有收获,帮转哟。 ==【完】==

百度咋做长文本去重(一分钟系列)

缘起:     (1)原创不易,互联网抄袭成风,很多原创内容在网上被抄来抄去,改来改去     (2)百度的网页库非常大,爬虫如何判断一个新网页是否与网页库中已有的网页重复呢?     这是本文要讨论的问题(尽量用大家都能立刻明白的语言和示例表述)。
一、传统签名算法与文本完整性判断     问题抛出:     (1)运维上线一个bin文件,将文件分发到4台线上机器上,如何判断bin文件全部是一致的?     (2)用户A将消息msg发送给用户B,用户B如何判断收到的msg_t就是用户A发送的msg?     思路:     一个字节一个字节的比对两个大文件或者大网页效率低,我们可以用一个签名值(例如md5值)代表一个大文件,签名值相同则认为大文件相同(先不考虑冲突率)     回答:     (1)将bin文件取md5,将4台线上机器上的bin文件也取md5,如果5个md5值相同,说明一致     (2)用户A将msg以及消息的md5同时发送给用户B,用户B收到msg_t后也取md5,得到的值与用户A发送过来的md5值如果相同,则说明msg_t与msg相同     结论:         md5是一种签名算法,常用来判断数据的完整性与一致性      md5设计原则:         两个文本哪怕只有1个bit不同,其md5签名值差别也会非常大,故它只适用于“完整性”check,不适用于“相似性”check。
    新问题抛出:          有没有一种签名算法,如果文本非常相似,签名值也非常相似呢?

二、文本相似性的签名算法      上文提出的问题,可以用局部敏感哈希LSH(Locality Sensitive Hash)解决,局部敏感哈希是一类文本越相似,哈希值越相似的hash算法,有兴趣的同学自行百度,这里分享一下minHash的思路。
    问题的提出:什么是minHash?     回答:          minHash是局部敏感哈希的一种,它常用来快速判定集合的相似性,也常用于检测网页的重复性,其思路为,用相同的规则抽取集合中的少部分元素代表整个集合,如果少部分元素的重合度很高,非常可能整个集合的重复度也很高。     举例:待判定的集合为A{1, 7, 5, 9, 3, 11, 15, 13}         已有的集合为:             B{10, 8, 2, 4, 6, 0, 1, 16},             C{100, 700, 500, 900, 300, 1100, 1500,1300},             D{1, 3, 2, 4, 6, 5, 8, 7}     假设使用部分元素代替全体集合的规则为:集合内元素进行排序,取值最小的4个(这个过程有信息损失,我们可以认为是一个hash过程)     处理结果为:         A{1, 3, 5, 7}         B{0, 1, 2, 4} => A与B有1个元素相同         C{100, 300, 500, 700} => A与C有0个元素相同         D{1, 2, 3, 4} => A与D有2个元素相同     判断结论:我们认为集合A与集合D是最相似的     这个例子有点2,但基本能说明整体思路,实际在执行的过程中:         (1) 我们可以使用更多的元素来代表集合,以提高准确性(例如,将上例中的4个元素代表集合升级为8个元素代表集合)         (2) 我们可以使用更多的hash函数来代表集合,以提高准确性(例如,上例除了“排序后取值最小的4个元素代表集合”,还可以增加一个哈希函数“排序后取值最大的4个元素代表集合”)         (3) minHash可以量化评判相似度,亦可以评判网页是否重复(一个分类问题),设定相似度阈值,高于阈值为重复,低于阈值为不重复         (4) 实际排重过程中,网页库中的哈希值都可以提前计算,只有待判定的集合或者网页的哈希值需要临时计算

三、minHash与长文本重复度检测有什么关系     目前看来没什么关系, 但如果我们能将每一个长文本用一个集合来表示,就能将长文本的相似度用minHash来解决了。     问题的提出:如何将长文本转化为集合?     回答:我去,分词不是就可以么     举例:待判定的长文本为A{我是58沈剑,我来自58到家}。已有网页库集合为:         B{我是一只来自58的狼}         C{58到家,服务到家}         D{这事和我没关系,我是凑数的}     使用分词将上述文本集合化:         A{我,58,沈剑,来自,到家}         B{我,58,来自,狼}             C{58,服务,到家}         D{事,我,凑数,关系}     判断结论:当当当当,转化为集合后,可以快速判断A与B的相似度最高, 当然实际执行过程中,除了分词还得考虑词频,用这种方法对长文本进行相似度检测,准确率非常高(文本越长越准)

四、还有没有更有效的方法     使用上述方法进行文本相似度检测,需要进行中文分词,词频统计,哈希值计算,相似度计算,计算量微大。     然而, 抄袭成风,一字不改的风气,让技术有了更广阔的优化空间,赞! 怎么优化呢?      不再进行分词,而是进行“分句”,用标点符号把长文按照句子分开,使用N个句子集合(例如一篇文章中5条最长的句子作为签名,注意,长句子比短句子更具有区分性)作为文章的签名,在抄袭成风的互联网环境下,此法判断网页的重复度能大大降低工程复杂度,并且准确度也异常的高。

五、结论     在抄袭成风的互联网环境下,采用“分句”的方式,用5条最长的网页内容作为网页的签名,能够极大的降低排重系统复杂度,提高排重准确率,不失为一种好的选择。


如何快速实现高并发短文检索
一、需求缘起 某并发量很大,数据量适中的业务线需要实现一个“标题检索”的功能:     (1)并发量较大,每秒20w次     (2)数据量适中,大概200w数据     (3)是否需要分词:是     (4)数据是否实时更新:否

二、常见潜在解决方案及优劣 (1)数据库搜索法         具体方法:将标题数据存放在数据库中,使用like来检索         优点:方案简单         缺点:不能实现分词,并发量扛不住 (2)数据库全文检索法         具体方法:将标题数据存放在数据库中,建立全文索引来检索         优点:方案简单         缺点:并发量扛不住 (3)使用开源方案将索引外置         具体方法:搭建lucene,solr,ES等开源外置索引方案         优点:性能比上面两种好         缺点:并发量可能有风险,系统比较重,为一个简单的业务搭建一套这样的系统成本较高

三、58龙哥的建议     问1:龙哥,58同城第一届编程大赛的题目好像是“黄反词过滤”,你是冠军,当时是用DAT来实现的么?     龙哥:是的     画外音:什么是DAT?     普及: DAT是double array trie的缩写,是trie树的一个变体优化数据结构,它在保证trie树检索效率的前提下,能大大减少内存的使用,经常用来解决检索,信息过滤等问题。(具体大伙百度一下“DAT”)
    问2:上面的业务场景可以使用DAT来实现么?     龙哥: DAT更新数据比较麻烦,不能增量
    问3:那直接使用trie树可以么?     龙哥:trie树比较占内存     画外音:什么是trie树?     普及: trie树,又称单词查找树,是一种树形结构,是一种哈希树的变种。典型应用是用于统计,保存大量的字符串(但不仅限于字符串),所以经常被搜索引擎系统用于文本词频统计。它的优点是:利用字符串的公共前缀来减少查询时间,最大限度地减少无谓的字符串比较,查询效率比哈希树高。(来源:百度百科)
    例如:上面的trie树就能够表示{and, as, at, cn, com}这样5个标题的集合。
    问4:如果要支持分词,多个分词遍历trie树,还需要合并对吧?     龙哥:没错, 每个分词遍历一次trie树,可以得到doc_id的list,多个分词得到的list合并,就是最终的结果
    问5:龙哥,还有什么更好,更轻量级的方案么?     龙哥: 用trie树,数据会膨胀文档数*标题长度这么多,标题越长,文档数越多,内存占用越大。有个一个方案,内存量很小,和标题长度无关,非常帅气。
    问6:有相关文章么,推荐一篇?     龙哥:可能网上没有,我简单说一下吧,核心思想就是“内存hash + ID list”     索引初始化步骤为:对所有标题进行分词,以词的hash为key,doc_id的集合为value     查询的步骤为:对查询词进行分词,对分词进行hash,直接查询hash表格,获取doc_id的list,然后多个词进行合并
=====例子===== 例如: doc1 : 我爱北京 doc2 : 我爱到家 doc3 : 到家美好 先标题进行分词: doc1 : 我爱北京 -> 我,爱,北京 doc2 : 我爱到家 -> 我,爱,到家 doc3 : 到家美好 -> 到家,美好 对分词进行hash,建立hash + ID list: hash(我) -> {doc1, doc2} hash(爱) -> {doc1, doc2} hash(北京) -> {doc1} hash(到家) -> {doc2, doc3} hash(美好) -> {doc3} 这样,所有标题的初始化就完毕了,你会发现,数据量和标题的长度没有关系。 用户输入“我爱”,分词后变为{我,爱},对各个分词的hash进行内存检索 hash(我)->{doc1, doc2} hash(爱)->{doc1, doc2} 然后进行合并,得到最后的查找结果是doc1+doc2。 =====例子END=====
    问7:这个方法有什么优点呢?
    龙哥: 内存操作,能满足很大的并发,时延也很低,占用内存也不大,实现非常简单快速
    问8:有什么不足呢?和传统搜索有什么区别咧?     龙哥: 这是一个快速过度方案,因为索引本身没有落地,还是需要在数据库中存储固化的标题数据,如果不做高可用,数据恢复起来会比较慢。当然做高可用也是很容易的,建立两份一样的hash索引即可。另外,没有做水平切分,但数据量非常非常非常大时,还是要做水平切分改进的。
    真实用户反馈:“龙哥指点一二,受益终身”







本文标签: 之路深入浅出搜索引擎系列架构师