请问
- 智能排序的posting list是document-base posting list还是term-base posting list? 我理解是如果是硬盘智能排序term-base posting list, 如果是内存智能排序document-base posting list
- 如果内存中用的是document-base posting list, 那是不是意味我搜一个关键词比如说“汉堡”，在缓存Miss的情况下，需要查询所有节点才能返回结果？
- 如果我的内存里面没找到， 上课说回去找硬盘上term-based posting list, 请问这个是通过什么机制找到的？我理解是通过一个big table query?
- 上课提到数据posting list是由map-reduce生成的， 我理解是map-reduce生成后会存big table, 那内存中的document-base posting list是什么时候加载上去的呢？
- 上课提到过硬盘索引的更新， 那请问内存索引是如何更新的呢？
logic
2
- 智能排序只存一部分比较重要的数据，所以可以偏向内存来做存储，document partition。
- 是需要访问所有节点
- 这里内存找不到是因为用户往后翻了页，开始读取不常读的信息。这时候去硬盘上找对应 的 posting list，直接根据 term 来 lookup 就可以了（不一定需要使用特定的技术），然后做交集或者并集。需要自己实现一下交并集。
- MapReduce Job 数据生成以后更新到缓存中去。
- Linked list of fixed size array 是很灵活的数据结构，因为没有读取时只允许一次 disk seek 的限制，写的时候就实时更新就可以了，每隔一定时间 compact 一下数据，避免内存碎片过于严重。
- 我有点疑惑，如果以现在google这种体量 需要访问所有节点然后再返回
我感觉有点难以想象 那会不会超级慢 比如我搜索 "无脊椎动物语言学"冷门词汇 但我去翻google很后面的页面一共就13页 我并没有感觉但慢呀 请问这是为什么
- 我理解的硬盘的term lookup是个o(log(n))的操作, 类似一个binary search? 还是有什么reference 可以发一下？谢谢
- 那硬盘和内存数据是不是有一定程度的重复. 最后结果还要去的重什么的
logic
4
- 如果是 document-based 只能这样，考虑到使用的是内存，即使 Fanout，返回速度还是更快的。缓存的每个节点也会有多台存储一样的信息，这样仍然可以 Scale up。
-
用 B Tree 做 Index 的话是 O(lgn) 没错，也可以选用 Hash，那么就是 O(1)。除了读 Index 花的时间以外，还得考虑 disk seek 的时间。
- 需要去重的
1 个赞