【转贴】为什么Google不直接使用一套bigtable来存放网页的倒排索引_浮云随风_新浪博客
【转贴】为什么Google不直接使用一套bigtable来存放网页的倒排索引
(2011-03-20 22:12:02)
转载▼
标签：
bigtable
杂谈
分类： 技术
来源：http://nosql-wiki.org/wiki/bin/view/Main/ArchRandomThoughts
我们知道，google的big table是一套很牛的存储系统，甚至可以说是一套完备的存储系统。但是为什么好像没有听说google使用它来存储倒排索引呢？ 可以设想一下如何用bigtalbe来存倒排拉链：rowkey是关键字，document id是其中一个column，这个column里面有很多的值，每个id对应了一个网页， 每个对应的网页中出现了该关键字。按照这种存储模式，一个关键字的拉链肯定存放在一个tablet上。对于网页搜索而言，存在两个特征：
关键字对应的倒排拉链很长；
查询的结果不完全需要全局最优
设想一次查询中出现了两个关键词，foo, bar。查询的处理过程是：
查出foo对应的倒排拉链
查出bar的倒排拉链(可以和第一步并发进行)
进行merge和rank排序
返回查询结果
在倒排拉链很长的情况下，前面3步都会花很长的时间。如果使用一套bigtable来存储，单次查询的响应时间将会很长。
实际的搜索引擎是如何处理的呢？可以通过并发来降低单次查询的latency。设想所有的关键词分布在n个bigtable集群上， 那么每个bigtable集群只有1/n的倒排拉链长度。每个bigtale集群上进行上述的查询过程，每个集群只返回m个最优结果， 然后由merge模块来对这n*m个结果进行排序。按照这样的处理方式，前3步的并行度为n。这样可以大大的减少单次查询的 处理时间。
这里的每个bigtable集群对应了百度搜索架构中的BS(basic search engine)，而merge模块对应了百度搜索架构中的 AS(advanced search engine)。
那么实际实现中，这些数据是如何进行划分的呢？基于上述原因，肯定不能基于关键词划分，在百度的实现中，数据划分是通过网页url的hash值进行划分，这样保证每个BS集群的数据规模比较均匀。
