※ 引述《gmoz ( This can't do that. )》之铭言： : 其实10月初就有了，刚刚才发现@@ : http://0rz.tw/ztXgh : 用来应付索引资料内即时更新的资料 : 正在看XD 之前看完了，稍微PO一下大意好了XD 里面提出一个增量处理的系统 Percolator 用Percoliator为主的搜索引擎就是咖啡因 简单的大意就是，原本的Google是用MapReduce来分析整理爬下来的网页，制作出索引库 如果现在有一批新资料(更新过的网页)出现时， 没办法即时地只对这些资料做MapReduce整理就加进索引库 因为索引库内的资料彼此之间都是有关连的 例：由A算出B、由B算出C，你不能只更新一小部份的A或B或C 你只能全部重做Mapreduce 一般的资料库又没办法容纳下GOOGLE的资料量，也缺乏伸缩性 所以Google提出Percolator，可以增量的处理新资料的玩意 主要有两个重点：transaction 和 observer 符合ACID(利用时间戳达成ACID)的transaction用来读写资料 又因为他的ACID特性可以避免冲突 而触发与运行transcation的便是observer 一个observer会再触发(trigger)他下游的observer (ob之间的关系开发者自定义) 一系列的observer就构成了Percolator的主要架构 原本的GOOGLE SEARCH要做100次左右的Mapreduce 现在GOOGLE只需要10个observer就可以做完 另外Percolator是建构在改良过的Bigtable上 (这里用的是GFS2) Percolator发送RPC给Bigtable server， 这个server再发送RPC给chunk server做实体修改 一个对bigtable的新增 (改良成多row，并且有时间戳，类似版本概念) 会登记在他的notify列，等待observer来处理他 系统流程直接引述PAPER里面的一段话 Percolator applications are structured as a series of observers; each observer completes a task and creates more work for “downstream” observers by writing to the table. In our indexing system, a MapReduce loads crawled documents into Percolator by running loader transactions, which trigger the document processor transaction to index the document (parse, extract links, etc.). The document processor transaction triggers further transactions like clustering. The clustering transaction, in turn, triggers transactions to export changed document clusters to the serving system. 原文里面还有很多细节 例如observer是以怎样的方式去搜索notify亮起来的bigtable行列 observer在运作时候避免冲突的流程细节，transaction的程式细节和锁的运作 如何减少RPC和效能的分析等等 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 111.243.224.126 ※ 编辑: gmoz 来自: 111.243.224.126 (12/05 15:03)