o problema
O índice da web é uma função de um repositório de documentos. Cada página rastreada precisa ser transformada — parseada, deduplicada, ligada às outras, pontuada — e o resultado dessa transformação é o que a busca consulta. Até 2010, o Google fazia isso do jeito que a década anterior tinha ensinado a fazer: em lote. Rastreia-se um monte de páginas, roda-se a pipeline inteira sobre o repositório inteiro, publica-se o índice novo. Repete.
Esse desenho tem um custo embutido que nenhuma otimização de lote remove: a idade do índice. Um documento rastreado logo depois do início de uma rodada espera a rodada inteira terminar para existir na busca. E não havia para onde correr. Banco de dados não aguentava os requisitos — o sistema de indexação guardava dezenas de petabytes e processava bilhões de atualizações por dia em milhares de máquinas. MapReduce e os outros sistemas de lote aguentavam a escala, mas pela razão errada: a eficiência deles vem justamente de agrupar trabalho em lotes grandes, então processar uma atualização pequena sozinha é o que eles não sabem fazer. A tarefa caía num vão entre as duas categorias de infraestrutura existentes.
a ideia
Peng e Dabek atacam a granularidade, não a vazão. Se o problema é que a menor unidade de trabalho é “o repositório inteiro”, a saída é fazer a menor unidade de trabalho ser “um documento”. Isso exige duas coisas que o mundo do lote não precisava ter.
A primeira é transação. Quando mutações pequenas mexem em estado compartilhado — a tabela de duplicatas, o grafo de links — e milhares de máquinas fazem isso ao mesmo tempo, você precisa de garantias sobre o que acontece quando duas delas se cruzam. Lote não precisa disso: cada rodada vê um retrato parado do mundo. Incremental precisa, e em escala de petabytes isso quer dizer transação distribuída.
A segunda é notificação. Transação diz o que é seguro escrever; não diz o que rodar em seguida. Num sistema incremental, o trabalho é encadeado por mudança: alguém escreveu neste documento, então aquele outro processamento precisa acordar. É essa metade que transforma um armazenamento transacional numa pipeline. O sistema que sai das duas se chama Percolator, e o Google o colocou em produção para construir o índice de busca da web.
o que isso custou
O número que o próprio resumo publica já diz onde está o limite. Depois da troca, o sistema processava a mesma quantidade de documentos por dia. O ganho todo foi de latência: metade da idade média dos documentos nos resultados. Nada indica que ficou mais barato ou que passou a dar conta de mais coisa — e isso é coerente com a premissa do trabalho, que reconhece que o lote é eficiente exatamente por ser lote. Abandonar o lote é trocar eficiência por atualidade, e a troca só se paga quando a atualidade vale muito, como vale para busca.
O resumo não abre a conta de recursos, o desenho interno nem as limitações que os autores declaram no corpo do paper — este verbete foi escrito a partir do resumo e não afirma nada sobre isso. Vale ler o original justamente por essa parte: o preço em máquinas e em complexidade operacional de rodar transações distribuídas em cima de um repositório desse tamanho é o assunto que um resumo nunca conta.
onde isso aparece hoje
O Percolator é o ponto em que a Google admite, em produção e por escrito, que MapReduce não é a resposta para tudo. Ele não substitui o modelo de lote; ele marca a fronteira dele, e a fronteira é a latência. A linha que continua daí desemboca no modelo Dataflow, que cinco anos depois trata lote e processamento contínuo como casos do mesmo desenho em vez de duas infraestruturas separadas.
A outra herança é a normalização da transação distribuída como peça de infraestrutura em escala planetária, e não como luxo de banco relacional. Dois anos depois do Percolator, a mesma casa publica o Spanner. Fora do Google, “processamento incremental” virou categoria: a ideia de manter uma derivação grande atualizada por mutação, em vez de recomputá-la, é a que sustenta boa parte do que hoje se chama de pipeline streaming ou de materialização incremental.