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

心已赠人 2022-05-13 03:42 255阅读 0赞

## 本文重点介绍： ##

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

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

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

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

任何互联网需求，或多或少有检索需求，还是以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)

使用match和against实现索引字段上的查询需求。

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

（1）由于全文索引利用的是数据库特性，搜索需求和普通CURD需求耦合在数据库中：检索需求并发大时，可能影响CURD的请求；CURD并发大时，检索会非常的慢；

（2）数据量达到百万级别，性能还是会显著降低，查询返回时间很长，业务难以接受

（3）比较难水平扩展

## **中级阶段-开源外置索引** ##

为了解决全文索引的局限性，当数据量增加到大几百万，千万级别时，就要考虑外置索引了。

**外置索引的核心思路**：索引数据与原始数据分离，前者满足搜索需求，后者满足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初步架构图如下：

![762dc2890ae74d2dbcb511155bbd6620_th.jpg][]

（1）上层**proxy（粉色）是接入集群：**

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

（2）中层**merger（浅蓝色）是逻辑集群****：**

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

（3）底层**searcher（暗红色大框）是检索集群：**

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

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

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

如此设计，真正做到做：

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

实时搜索引擎架构

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

（1）索引分级

（2）dump&merge;

**索引分级**

在数据量非常大的情况下，为了保证倒排索引的高效检索效率，任何对数据的更新，并不会实时修改索引，一旦产生碎片，会大大降低检索效率。

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

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

如下图所述：

（1）300亿数据在全量索引库中

（2）1000万1天内修改过的数据在天库中

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

![188f5034b6f64f4b828f5c0f0cef0619.jpg][]

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

![03df3b8abcaf448cab29496a19cd27ef.jpg][]

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

（1）全量库是紧密存储的索引，无碎片，速度快

（2）天库是紧密存储，速度快

（3）小时库数据量小，速度也快

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

新的问题来了：小时库数据何时反映到天库中，天库中的数据何时反映到全量库中呢？

**dump&merge;**

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

![8f78e0236d654f47bbfff8f75d88f6b8.jpg][]

**dumper**：将在线的数据导出

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

小时库，一小时一次，合并到天库中去；

天库，一天一次，合并到全量库中去；

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

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

[http://www.sohu.com/a/163507640\_505827][http_www.sohu.com_a_163507640_505827]

[762dc2890ae74d2dbcb511155bbd6620_th.jpg]: /images/20220513/93fb2e697bbd446d96102e4f34ce8237.png
[188f5034b6f64f4b828f5c0f0cef0619.jpg]: /images/20220513/539c26104867400dbcf8f94242415124.png
[03df3b8abcaf448cab29496a19cd27ef.jpg]: /images/20220513/a16cf4e741724076933e160e863d02a6.png
[8f78e0236d654f47bbfff8f75d88f6b8.jpg]: /images/20220513/1f3e857039f74539b905f9670fdc6396.png
[http_www.sohu.com_a_163507640_505827]: http://www.sohu.com/a/163507640_505827