[架构师之路] 深入浅出搜索引擎 系列

http://zhuanlan.51cto.com/art/201702/531315.htm 深入浅出搜索架构引擎、方案与细节（上）

http://zhuanlan.51cto.com/art/201702/532287.htm 就是这么迅猛的实现搜索需求

http://zhuanlan.51cto.com/art/201703/533480.htm 百度如何能实时检索到15分钟前新生成的网页

http://zhuanlan.51cto.com/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索引即可。另外，没有做水平切分，但数据量非常非常非常大时，还是要做水平切分改进的。

    真实用户反馈：“龙哥指点一二，受益终身”