百度如何能实时检索到15分钟前新生成的网页(下)?

  

  编辑手记:

  百度为何能实时检索出15分钟之前新出的新闻?58同城为何能实时检索出1秒钟之前发布的帖子?我们拣选架构师之路中的一个系列文章,体系化的聊聊搜索引擎,从宏观到细节,详解实时检索的原理。只要业务有检索需求,本文一定对你有帮助。

  前文回顾:百度如何能实时检索到15分钟前新生成的网页(上)

  本文重点介绍:

  一、流量数据量由小到大,常见搜索方案与架构变迁

  二、数据量、并发量、扩展性方案

  三、搜索引擎的实时性架构

  1

  检索需求的满足与架构演进

  任何互联网需求,或多或少有检索需求,还是以58同城的帖子业务场景为例。

  帖子的标题,帖子的内容有很强的用户检索需求,在业务、流量、并发量逐步递增的各个阶段,应该如何实现检索需求呢?

  那么为了满足搜索业务的需求,随着数据量和并发量的增长,搜索架构一般会经历这么几个阶段:

  (1)原始阶段-LIKE

  (2)初级阶段-全文索引

  (3)中级阶段-开源外置索引

  (4)高级阶段-自研搜索引擎

  原始阶段-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)

  使用matchagainst实现索引字段上的查询需求。

  全文索引能够快速实现业务上分词的需求,并且快速提升性能(分词后倒排,至少不要全表扫描了),但也存在一些问题

  (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万吞吐;业务个性也逐步增加的时候,就需要自研搜索引擎了,定制化实现搜索内核了。

  2

  数据量、并发量、扩展性方案

  到了定制化自研搜索引擎的阶段,超大数据量、超高并发量为设计重点,为了达到“无限容量、无限并发”的需求,架构设计需要重点考虑“扩展性”,力争做到:增加机器就能扩容(数据量+并发量)。

  58同城的自研搜索引擎E-search初步架构图如下:

  

  (1)上层proxy(粉色)是接入集群:

  为对外门户,接受搜索请求,其无状态性能够保证增加机器就能扩充proxy集群性能

  2)中层merger(浅蓝色)是逻辑集群

  主要用于实现搜索合并,以及打分排序,业务相关的rank就在这一层实现,其无状态性也能够保证增加机器就能扩充merger集群性能

  3)底层searcher(暗红色大框)是检索集群:

  服务和索引数据部署在同一台机器上,服务启动时可以加载索引数据到内存,请求访问时从内存中load数据,访问速度很快

  ①为了满足数据容量的扩展性,索引数据进行了水平切分,增加切分份数,就能够无限扩展性能,如上图searcher分为了4组

  ②为了满足一份数据的性能扩展性,同一份数据进行了冗余,理论上做到增加机器就无限扩展性能,如上图每组searcher又冗余了2份

  如此设计,真正做到做:

  增加机器就能承载更多的数据量,响应更高的并发量

  3

  实时搜索引擎架构

  大数据量、高并发量情况下的搜索引擎为了保证实时性,架构设计上的两个要点:

  1)索引分级

  2dump&merge;

  索引分级

  深入浅出搜索架构(上篇)介绍了搜索引擎的底层原理,在数据量非常大的情况下,为了保证倒排索引的高效检索效率,任何对数据的更新,并不会实时修改索引,一旦产生碎片,会大大降低检索效率。

  既然索引数据不能实时修改,如何保证最新的网页能够被索引到呢?

  索引分为全量库、日增量库、小时增量库

  如下图所述:

  (1)300亿数据在全量索引库中

  (2)1000万1天内修改过的数据在天库中

  (3)50万1小时内修改过的数据在小时库中

  

  当有修改请求发生时,只会操作最低级别的索引,例如小时库。

  

  当有查询请求发生时,会同时查询各个级别的索引,将结果合并得到最新的数据

  1)全量库是紧密存储的索引,无碎片,速度快

  2)天库是紧密存储,速度快

  3)小时库数据量小,速度也快

  数据的写入和读取都是实时的,所以58同城能够检索到1秒钟之前发布的帖子,即使全量库有300亿的数据。

  新的问题来了:小时库数据何时反映到天库中,天库中的数据何时反映到全量库中呢?

  dump&merge;

  这是由两个异步的工具完成的:

  

  dumper将在线的数据导出

  merger将离线的数据合并到高一级别的索引中去

  小时库,一小时一次,合并到天库中去;

  天库,一天一次,合并到全量库中去;

  这样就保证了小时库和天库的数据量都不会特别大;

  如果数据量和并发量更大,还能增加星期库,月库来缓冲。

  4

  总结

  超大数据量,超高并发量,实时搜索引擎的两个架构要点:

  (1)索引分级

  (2)dump&merge;

声明:本文由入驻搜狐公众平台的作者撰写,除搜狐官方账号外,观点仅代表作者本人,不代表搜狐立场。
推荐阅读