标签：索引 tar 包含 bsp SM 外置 Lucene com 架构设计
1. 深入浅出搜索架构引擎、方案与细节（上）
文字很多，有宏观，有细节，对于大部分不是专门研究搜索引擎的同学，记住以下几点即可：
1）. 全网搜索引擎系统由spider， search&index， rank三个子系统构成
2）. 站内搜索引擎与全网搜索引擎的差异在于，少了一个spider子系统
3）. spider和search&index系统是两个工程系统，rank系统的优化却需要长时间的调优和积累
4）正排索引（forward index）是由网页url_id快速找到分词后网页内容list<item>的过程
5）倒排索引（inverted index）是由分词item快速寻找包含这个分词的网页list<url_id>的过程
6）用户检索的过程，是先分词，再找到每个item对应的list<url_id>，最后进行集合求交集的过程
7）有序集合求交集的方法有
a）二重for循环法，时间复杂度O(n*n)
b）拉链法，时间复杂度O(n)
c）水平分桶，多线程并行
d）bitmap，大大提高运算并行度，时间复杂度O(n)
e）跳表，时间复杂度为O(log(n))
2. 就是这么迅猛的实现搜索需求
为了满足搜索业务的需求，随着数据量和并发量的增长，搜索架构一般会经历这么几个阶段：
1）原始阶段-LIKE
2）初级阶段-全文索引
3）中级阶段-开源外置索引
楼主强烈推荐ES（ElasticSearch），原因是Lucene虽好，但始终有一些不足。ES完全能满足10亿数据量，5k吞吐量的常见搜索业务需求，强烈推荐。
4）高级阶段-自研搜索引擎
3. 百度如何能实时检索到15分钟前新生成的网页？
实时搜索引擎架构
大数据量、高并发量情况下的搜索引擎为了保证实时性，架构设计上的两个要点：
1）索引分级
《深入浅出搜索架构（上篇）》介绍了搜索引擎的底层原理，在数据量非常大的情况下，为了保证倒排索引的高效检索效率，任何对数据的更新，并不会实时修改索引，一旦产生碎片，会大大降低检索效率。
既然索引数据不能实时修改，如何保证最新的网页能够被索引到呢？
索引分为全量库、日增量库、小时增量库。
如下图所述：
a. 300亿数据在全量索引库中
b. 1000万1天内修改过的数据在天库中
c. 50万1小时内修改过的数据在小时库中
当有修改请求发生时，只会操作最低级别的索引，例如小时库。
当有查询请求发生时，会同时查询各个级别的索引，将结果合并，得到最新的数据：
a. 全量库是紧密存储的索引，无碎片，速度快
b. 天库是紧密存储，速度快
c. 小时库数据量小，速度也快
数据的写入和读取都是实时的，所以58同城能够检索到1秒钟之前发布的帖子，即使全量库有300亿的数据。
新的问题来了：小时库数据何时反映到天库中，天库中的数据何时反映到全量库中呢？
2）dump&merge
dumper：将在线的数据导出
merger：将离线的数据合并到高一级别的索引中去
小时库，一小时一次，合并到天库中去；
天库，一天一次，合并到全量库中去；
这样就保证了小时库和天库的数据量都不会特别大；
如果数据量和并发量更大，还能增加星期库，月库来缓冲。
标签：索引 tar 包含 bsp SM 外置 Lucene com 架构设计
原文地址：https://www.cnblogs.com/Jtianlin/p/8908598.html
