“搜索”的原理,架构,实现,实践,面试不用再怕了(值得收藏)!!!(2)
分词后倒排索引:
由检索词item快速找到包含这个查询词的网页Map>就是倒排索引。 画外音:明白了吧,词到url的过程,是倒排索引。 正排索引和倒排索引是spider和build_index系统提前建立好的数据结构,为什么要使用这两种数据结构,是因为它能够快速的实现“用户网页检索”需求。 画外音,业务需求决定架构实现,查询起来都很快。 检索的过程是什么样的? 假设搜索词是“我爱”:
画外音:检索的过程也很简单:分词,查倒排索引,求结果集交集。 就结束了吗?其实不然,分词和倒排查询时间复杂度都是O(1),整个搜索的时间复杂度取决于“求list的交集”,问题转化为了求两个集合交集。 字符型的url不利于存储与计算,一般来说每个url会有一个数值型的url_id来标识,后文为了方便描述,list统一用list替代。 list1和list2,求交集怎么求? (1) 方案一:for * for,土办法,时间复杂度O(n*n) 每个搜索词命中的网页是很多的,O(n*n)的复杂度是明显不能接受的。倒排索引是在创建之初可以进行排序预处理,问题转化成两个有序的list求交集,就方便多了。 画外音:比较笨的方法。 (2) 方案二:有序list求交集,拉链法
两个指针指向首元素,比较元素的大小:
这种方法的好处是:
这个方法就像一条拉链的两边齿轮,一一比对就像拉链,故称为拉链法; 画外音:倒排索引是提前初始化的,可以利用“有序”这个特性。 (3) 方案三:分桶并行优化 数据量大时,url_id分桶水平切分+并行运算是一种常见的优化方法,如果能将list1和list2分成若干个桶区间,每个区间利用多线程并行求交集,各个线程结果集的并集,作为最终的结果集,能够大大的减少执行时间。 举例:
求交集,先进行分桶拆分:
于是: 集合1就拆分成
集合2就拆分成
每个桶内的数据量大大降低了,并且每个桶内没有重复元素,可以利用多线程并行计算:
最终,集合1和集合2的交集,是x与y与z的并集,即集合{3,5,7,30,50,70}。 画外音:多线程、水平切分都是常见的优化手段。 (4)方案四: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需要大量连续空间,占用内存较大。 画外音:bitmap能够表示集合,用它求集合交集速度非常快。 (5)方案五:跳表skiplist (编辑:ASP站长网) |