※ 引述《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)