500W数据,20Wqps分词检索,架构如何设计?

精选
开发 架构
本文通过一个典型的,短文本分词搜索的问题,简单聊聊自己的经验。

作者 | KG沈剑

​有水友提问:

沈哥,我们有个业务,类似于“标题分词检索”,并发量非常大,大概20W次每秒,数据量不是很大,大概500W级别,而且数据不会频繁更新,平均每天更新一次,请问有什么好的方案么?

这是一个典型的,短文本分词搜索的问题,简单聊聊自己的经验。

常见的文本检索方案有哪些?

(1) 数据库LIKE法​

将标题数据存放在数据库中,使用like来查询,方案非常简单,能支持简单的模糊搜索,但不支持分词。

画外音:显然不适用于本例。

(2) 数据库全文检索法​

将标题数据存放在数据库中,建立全文索引来检索,方案依然简单,利用了数据库的能力,不用额外开发,但性能较低。

画外音:本例的并发肯定扛不住。​

(3) 开源方案索引外置法

搭建lucene,solr,ES等开源搜索工具,建立索引,支持分词,支持数据量和吞吐量的水平扩展。

该方案能够很好的满足本例的需求。但是,杀鸡焉用牛刀,本例有一些业务特性:文本短,更新不频繁,如果利用好这两个特点,能有更巧妙的方案。

画外音:任何脱离业务的架构设计,都是耍流氓。​

针对“更新不频繁”的特性,可以使用“分词+DAT”方案。

画外音:分词就不多说了。

什么是DAT?​

DAT是double array trie的缩写,是trie树的一个变体优化数据结构,它在保证trie树检索效率的前提下,能大大减少内存的使用,经常用来解决检索,信息过滤等问题。

画外音:更具体的,可以Google一下“DAT”,DAT的缺点是,需要提前建立索引,索引不能实时更新。

为什么用trie树的变种DAT,是否可以直接使用trie树呢?​

trie树的优点是,索引可以实时更新;不足是,占用内存非常大。

本例索引无需实时更新,无法利用trie树的优点。但是,如果300W短文本建立好trie树内存能装下,则可以使用trie树,否则只能使用DAT。

普及,什么是trie树?​

trie树,又称单词查找树,经常用于搜索引擎词频统计,短文本检索,输入法输入提示等。

画外音:什么数据结构适合什么业务场景,一定要烂熟于胸。

它的特点是,能利用字符串的公共前缀来减少查询时间,最大限度地减少无谓的字符串比较,其查询时间复杂度只与树的高度有关,与查询数据量级无关,因此查询效率非常高。

画外音:“时间复杂度与查询数量级无关”这个太屌了。

图片

例如:上面的trie树就能够表示{and, as, at, cn, com}这样5个标题的集合,可以用来做这5个字符串的词频统计,或者检索。

画外音:检索时,节点存储命中该item的doc_list<doc_id>。

分词之后,是不是需要多次扫描trie树? 

是的。

分词之后,每个item都要扫描一次trie树,得到的doc_list<doc_id>的交集,就是最终命中每个item的检索结果。

针对“短文本”“500W数据”“不频繁更新”这些特性,还能使用“分词+内存hash”方案。

这个方案需要先对索引进行初始化:对所有短文本进行分词,以词的hash为key,doc_id的集合为value。

查询的过程也很简单:​对查询字符串进行分词,对每个分词进行hash,直接查询hash表格得到doc_list<doc_id>,再对每个分词的检索结果进行交集。

举个栗子进行说明。

例如:

  • doc1 : 我爱北京
  • doc2 : 我爱到家
  • doc3 : 到家美好

先对短文本进行分词:

  • doc1 : 我爱北京 -> 我,爱,北京
  • doc2 : 我爱到家 -> 我,爱,到家
  • doc3 : 到家美好 -> 到家,美好

对分词进行hash,建立hash表:

  • hash(我) -> {doc1, doc2}
  • hash(爱) -> {doc1, doc2}
  • hash(北京) -> {doc1}
  • hash(到家) -> {doc2, doc3}
  • hash(美好) -> {doc3}

这样,所有短文本初始化完毕,与trie树类似,查询时间复杂度与文本数据量也没有关系。

画外音:只与被分词后有多少数据量,即hash桶个数有关。

查询的过程是这样的:

假如用户输入“我爱”,分词后变为{我,爱},对各个分词的hash进行内存检索:

  • hash(我)->{doc1, doc2}
  • hash(爱)->{doc1, doc2}

然后进行合并,得到最后的查找结果是{doc1, doc2}。

这个方法的优点是,纯内存操作,能满足很大的并发,时延也很低,占用内存也不大,实现非常简单快速,而且冗余索引很容易水平扩展。

画外音:做索引高可用也不难,建立两份一样的hash索引即可。

它的缺点也很明显,索引全内存,没有落地,还是需要在数据库中存储固化的短文本数据,如果内存数据全丢失,数据恢复起来会比较慢。

总结​

短文本,高并发,支持分词,不用实时更新的检索场景,可以使用:

  • ES,杀鸡用牛刀;
  • 分词+DAT(trie);
  • 分词+内存hash;

等几种方式解决。

思路比结论重要,希望大家有收获。​

责任编辑:赵宁宁 来源: 架构师之路
相关推荐

2024-10-05 00:00:20

Element开源项目

2023-06-30 07:19:25

电源供电显卡

2011-04-28 09:36:22

海量数据存储

2011-11-01 11:01:47

优派投影机

2011-08-09 20:16:43

投影机评测

2015-07-20 16:55:58

2011-06-02 14:51:00

SQL Server

2021-05-11 07:39:58

跳槽谈薪工作

2022-11-09 10:15:26

2020-07-29 09:54:35

帖子中心数据架构

2011-11-25 13:45:42

优派投影机

2023-06-29 07:22:11

功率12V电脑

2023-08-08 14:49:12

2011-10-18 22:07:46

优派投影仪

2021-07-09 05:52:36

架构开发缓存

2021-12-30 09:50:35

数据泄露漏洞信息安全

2019-10-25 15:50:06

MySQL数据库命令

2009-09-07 17:32:14

LINQ检索数据

2013-03-20 13:35:12

数据库数据库设计

2019-02-27 09:46:05

数据库架构并发
点赞
收藏

51CTO技术栈公众号