[搜索] 索引那节课的几个问题

[dawnleave]

趁着视频过期前复习一遍，还是问题不少……

1. 老师说index builder很适合map reduce，虽然streaming processing和custom code也可以做但是很快，但这里不适用。不太明白streaming processing为啥这里可以用于build index （其实我不太明白streaming processing的一般应用场景是什么）
2. 如果那些可以做而且快，只是比较贵，是不是可以再hybrid一下。对于热门的网站产生的file用streaming processing/custom code，其他用map reduce半天或者一天搞定
3. 标准化的时候，vehicle和car会当成同义词，那他俩是共用一个posting list吗？因为即使同义，我搜索vehicle的时候还是希望vehicle的结果多一点。我觉得有两种处理方法：
   a) 共用一个posting list，然后返回结果之后排序的时候给vehicle比较高的rank;
   b) 分别有各自的posting list， 然后在index的keyword字段加上可能的同义词然后搜索的时候一起搜，赋予不同的权重
4. 不太明白什么是document partitioned index。我们build posting list不就是term based的吗？
   keyword: [document1, offset1-> document1, offset2->document2, offset3]
   如果我是document partitioned index还要把这个posting list再拆成一段一段的吗？

[logic]

1. Streaming Processing 指的是在 HTML 爬下来之后立刻就根据这个 HTML 去把文件拆解成逆向索引，再添加进整个索引中。不同于收集完大量 HTML 一起做批处理 (MapReduce)。之后会有专题来讲 Streaming Processing。
2. 确实可以。还是看需求要不要求那么快。MapReduce 可以每半小时跑一遍。
3. 我的意思就是同义词共用一个 Posting List。这道题的 Scope 不包括排序，如果要求排序的话，那么情况会复杂很多，牵涉到 PageRank。相对而言，我认为方案a更可行，“检索”这个一步不区分同义词，“排序”时作区分。
4. 就是把 Posting List 拆成一段一段。