Google: um mecanismo de busca hipertextual de larga escala

A anatomia de um mecanismo de busca hipertextual de
grande escala na Web
Sergey Brin e Lawrence Page
{sergey, page}@cs.stanford.edu
Departamento de Ciência da Computação, Stanford University, Stanford, CA 94305
Resumo
Neste artigo, apresentamos o Google, um protótipo de um mecanismo de busca em
larga escala que faz uso intenso da estrutura presente no hipertexto. O Google foi projetado
para rastrear e indexar a Web de maneira eficiente e produzir resultados de busca muito mais
satisfatórios do que os sistemas existentes. O protótipo com um completo banco de dados de
texto e hiperlinks de pelo menos 24 milhões de páginas está disponível em
http://google.stanford.edu/
Desenvolver um mecanismo de busca é uma tarefa desafiadora. Os mecanismos de
busca indexam dezenas a centenas de milhões de páginas da Web, envolvendo um número
comparável de termos distintos. Eles respondem a dezenas de milhões de consultas todos os
dias. Apesar da importância dos mecanismos de busca em larga escala na web, muito pouca
pesquisa acadêmica tem sido feita sobre eles. Além disso, devido ao rápido avanço na
tecnologia e proliferação da web, a criação de um mecanismo de busca na web hoje é muito
diferente de três anos atrás. Este artigo fornece uma descrição detalhada do nosso mecanismo
de busca em grande escala (a primeira descrição pública detalhada até hoje existente).
Além dos problemas de dimensionamento de técnicas tradicionais de busca para dados
dessa magnitude, há novos desafios técnicos envolvidos no uso das informações adicionais
presentes no hipertexto para produzir melhores resultados de busca. Este artigo aborda essa
questão de como construir um sistema prático de larga escala que pode explorar as
informações adicionais presentes no hipertexto. Também analisamos o problema de como
lidar efetivamente com coleções de hipertexto sem controle, onde qualquer pessoa pode
publicar o que quiser.
Palavras-chave: World Wide Web, Mecanismos de Busca, Recuperação de
Informação, PageRank, Google

Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br
Tradução para fins acadêmicos, exclusivamente. Uso não-comercial.
2A anatomia de um mecanismo de busca hipertextual de grande escala na Web
1. Introdução
(Observação: existem duas versões deste artigo; uma versão completa mais longa e
uma versão impressa mais curta. A versão completa está disponível na Web e no CD-ROM da
conferência.)
A Web cria novos desafios para a recuperação de informações. A quantidade de
informação na Web está crescendo rapidamente, bem como o número de novos usuários
inexperientes na arte da busca na Web. É provável que as pessoas naveguem usando o graph
de links da Web, geralmente começando com índices de alta qualidade construídos por
humanos como o Yahoo! ou com mecanismos de busca. As listas mantidas por humanos
cobrem os tópicos populares de forma eficaz, mas são subjetivas, caras para construir e manter,
lentas para melhorar e não podem cobrir todos os tópicos esotéricos. Os mecanismos de busca
automatizados que dependem da correspondência de palavras-chave geralmente retornam
muitas correspondências de baixa qualidade. Para piorar, alguns anunciantes tentam chamar a
atenção das pessoas tomando medidas para enganar os mecanismos de busca automatizados.
Nós construímos um mecanismo de busca em larga escala que resolve muitos dos problemas
dos sistemas existentes. Ele, especialmente, faz uso intenso da estrutura adicional presente no
hipertexto para fornecer resultados de busca de qualidade muito superior. Escolhemos o nome
do nosso sistema, Google, porque é uma grafia comum do googol, ou 10100
, e se encaixa bem
com o nosso objetivo de construir mecanismos de busca de larga escala.
1.1 Mecanismos de busca da Web: 1994 - 2000
A tecnologia dos mecanismos de busca teve que escalar drasticamente para
acompanhar o crescimento da Web. Em 1994, um dos primeiros mecanismos de busca da
Web, o World Wide Web Worm (WWWW) [McBryan 94], tinha um índice de 110.000
páginas e documentos acessíveis pela web.
A partir de novembro de 1997, os principais mecanismos de busca afirmam indexar de
2 milhões (WebCrawler) a 100 milhões de documentos da web (Search Engine Watch). É
previsível que até o ano 2000, um índice abrangente da Web contenha mais de um bilhão de
documentos. Ao mesmo tempo, o número de consultas com as quais os mecanismos de busca
têm de lidar também cresceu incrivelmente.
Em março e abril de 1994, o World Wide Web Worm recebeu uma média de cerca de
1500 consultas por dia. Em novembro de 1997, o Altavista divulgou ter lidado com cerca de
20 milhões de consultas por dia. Com o crescente número de usuários na Web e sistemas
automatizados que consultam mecanismos de busca, é provável que os principais mecanismos
de busca lidem com centenas de milhões de consultas por dia até o ano 2000.
O objetivo do nosso sistema é abordar muitos dos problemas, tanto em qualidade
quanto em escalabilidade, introduzidos pelo escalonamento da tecnologia de mecanismos de
busca a números tão extraordinários.
1.2. Google: escalando com a Web
Criar um mecanismo de busca que se adapte à Web de hoje apresenta muitos desafios.
A tecnologia de rastreamento rápido é necessária para reunir os documentos da Web e mantê-
los atualizados. O espaço de armazenamento deve ser usado eficientemente para armazenar

índices e, opcionalmente, os próprios documentos. O sistema de indexação deve processar
centenas de gigabytes de dados de maneira eficiente. As consultas devem ser tratadas
rapidamente, a uma taxa de centenas a milhares por segundo.
Essas tarefas estão se tornando cada vez mais difíceis à medida que a Web cresce. No
entanto, o desempenho e o custo do hardware melhoraram drasticamente para compensar
parcialmente as dificuldades. Há, no entanto, várias exceções notáveis a esse progresso, como
tempo de busca de disco e robustez do sistema operacional. Ao projetar o Google,
consideramos a taxa de crescimento da Web e as mudanças tecnológicas. O Google foi
projetado para ser bem dimensionado para conjuntos de dados extremamente grandes. Faz uso
eficiente do espaço de armazenamento para armazenar o índice. Suas estruturas de dados são
otimizadas para acesso rápido e eficiente (ver seção 4.2). Além disso, esperamos que o custo
para indexar e armazenar texto ou HTML acabe diminuindo em relação ao valor que estará
disponível (consulte o Apêndice B). Isso resultará em propriedades de escalabilidade
favoráveis para sistemas centralizados como o Google.
1.3 Metas de Design
1.3.1 Qualidade de pesquisa aprimorada
Nosso principal objetivo é melhorar a qualidade dos mecanismos de busca na web.
Em 1994, algumas pessoas acreditavam que um índice de pesquisa completo tornaria
possível encontrar qualquer coisa facilmente. De acordo com o Best of the Web 1994 -
Navigators, "o melhor serviço de navegação deve ser aquele que facilita a localização de quase
qualquer coisa na Web (uma vez que todos os dados sejam inseridos)". No entanto, a Web de
1997 é bem diferente. Qualquer pessoa que tenha recentemente usado um mecanismo de busca
pode comprovar, prontamente, que a integridade do índice não é o único fator na qualidade
dos resultados de busca.
Os "junk results" muitas vezes eliminam quaisquer resultados nos quais um usuário
está interessado. De fato, a partir de novembro de 1997, apenas um dos quatro principais
mecanismos de busca comerciais é capaz de encontrar a si mesmo (retornar, nos 10 primeiros
resultados, sua própria página de pesquisa em resposta ao seu nome). Uma das principais
causas desse problema é que o número de documentos nos índices tem aumentado em muitas
ordens de magnitude, mas a capacidade do usuário de examinar os documentos não aumentou.
As pessoas ainda estão dispostas apenas a olhar para os primeiros 10 resultados.
Por causa disso, à medida que o tamanho da coleção cresce, precisamos de ferramentas
que tenham alta precisão (número de documentos relevantes retornados, digamos, nos 10
primeiros resultados mais importantes). De fato, queremos que nossa noção de "relevante"
inclua apenas os melhores documentos, pois pode haver dezenas de milhares de documentos
ligeiramente relevantes. Essa precisão muito alta é importante mesmo em detrimento do recall
(o número total de documentos relevantes que o sistema é capaz de retornar).
Há um certo otimismo recente de que o uso de mais informações hipertextuais pode
ajudar a melhorar a pesquisa e outras aplicações [Marchiori 97] [Spertus 97] [Weiss 96]
[Kleinberg 98]. Em particular, a estrutura de links [Page, 98] e o texto dos links fornecem
muitas informações para fazermos julgamentos de relevância e filtragem de qualidade. O
Google utiliza a estrutura de links e o texto-âncora (consulte as seções 2.1 e 2.2).

1.3.2 Pesquisa acadêmica dos Mecanismos de Busca
Além do enorme crescimento, a Web também se tornou cada vez mais comercial ao
longo do tempo. Em 1993, 1,5% dos servidores da Web estavam em domínios .com.
Esse número cresceu para mais de 60% em 1997. Ao mesmo tempo, os mecanismos
de busca migraram do domínio acadêmico para o comercial. Até agora, a maior parte do
desenvolvimento de mecanismos de busca foi implementado em empresas e com pouca
publicação de detalhes técnicos. Isso faz com que a tecnologia dos mecanismos de busca
permaneça uma “arte negra” e seja orientada para a publicidade (consulte o Apêndice A). Com
o Google, temos um forte objetivo de promover mais desenvolvimento e compreensão no
mundo acadêmico.
Outro objetivo importante do projeto foi criar sistemas que um número razoável de
pessoas pudesse realmente usar. O uso foi importante para nós, porque achamos que algumas
das pesquisas mais interessantes envolverão a utilização da vasta quantidade de dados de uso
que está disponível nos sistemas web modernos. Por exemplo, existem muitas dezenas de
milhões de pesquisas realizadas todos os dias. No entanto, é muito difícil obter esses dados,
principalmente porque é considerado comercialmente valioso.
Nosso objetivo final de projeto foi construir uma arquitetura que pudesse apoiar novas
atividades de pesquisa em dados da Web em larga escala. Para apoiar novos usos de pesquisa,
o Google armazena todos os documentos reais que ele rastreia em formato compactado. Um
dos nossos principais objetivos ao projetar o Google foi criar um ambiente em que outros
pesquisadores pudessem entrar rapidamente, processar grandes partes da Web e produzir
resultados interessantes que, de outra forma, teriam sido muito difíceis de produzir.
No curto espaço de tempo em que o sistema tem estado em atividade, já houve diversos
artigos usando bancos de dados gerados pelo Google, e muitos outros estão em andamento.
Outro objetivo que temos é criar um ambiente semelhante ao do Spacelab, no qual
pesquisadores (ou até estudantes) possam propor e fazer experimentos interessantes em nossos
dados da Web em larga escala.
2. Recursos do Sistema
O mecanismo de busca do Google tem dois recursos importantes que ajudam a produzir
resultados de alta precisão.
Primeiro, ele faz uso da estrutura de links da Web para calcular uma classificação de
qualidade para cada página da Web. Essa classificação é chamada de PageRank e é descrita
em detalhes em [Page 98: Lawrence Page, Sergey Brin, Rajeev Motwani, Terry Winograd.
The PageRank Citation Ranking: Bringing Order to the Web].
Em segundo lugar, o Google utiliza links para melhorar os resultados da busca.
2.1 PageRank: Levando ordem para a Web
O graph de citação (link) da web é um recurso importante que, em grande parte, não
tem sido utilizado nos mecanismos de busca existentes na web. Criamos mapas contendo até
518 milhões desses hiperlinks, uma amostra significativa do total. Esses mapas permitem o

cálculo rápido do “PageRank” de uma página da Web, uma medida objetiva de sua
importância de citação que corresponde bem à ideia subjetiva de importância das pessoas.
Devido a essa correspondência, o PageRank é uma excelente maneira de priorizar os
resultados das buscas de palavras-chave da Web. Para os assuntos mais populares, uma busca
de correspondência de texto simples restrita a títulos de páginas da Web tem um desempenho
admirável quando o PageRank prioriza os resultados (demonstração disponível em
google.stanford.edu). Para o tipo de pesquisa de texto completo no sistema principal do
Google, o PageRank também ajuda bastante.
2.1.1 Descrição do cálculo do PageRank
Literatura de citação acadêmica tem sido aplicada à web, em grande parte, contando
citações ou backlinks para uma determinada página. Isto dá alguma aproximação da
importância ou qualidade de uma página. O PageRank estende essa ideia não contando links
de todas as páginas igualmente, e normalizando pelo número de links em uma página.
O PageRank é definido da seguinte maneira:
Assumimos que a página A tem páginas T1 ... Tn que apontam para ela (ou
seja, são citações). O parâmetro d é um fator de amortecimento que pode
ser ajustado entre 0 e 1. Geralmente, ajustamos d para 0,85. Há mais
detalhes sobre d na próxima seção. Também C(A) é definido como o número
de links saindo da página A. O PageRank de uma página A é dado da
seguinte forma:
PR(A) = (1-d) + d (PR(T1) / C(T1) + ... + PR(Tn) / C(Tn))
Observe que os PageRanks formam uma distribuição de probabilidade
sobre páginas da Web, portanto, a soma dos PageRanks de todas as páginas
da Web será um.
O PageRank ou PR(A) pode ser calculado usando um algoritmo iterativo simples e
corresponde ao principal autovetor da matriz de enlace normalizado da web.
Além disso, um PageRank para 26 milhões de páginas da web pode ser computado em
poucas horas em uma estação de trabalho de tamanho médio. Há muitos outros detalhes que
estão além do escopo deste artigo.
2.1.2 Justificação intuitiva
O PageRank pode ser considerado um modelo de comportamento do usuário.
Assumimos que existe um "surfista web aleatório" ao qual é apresentada uma página da web
aleatoriamente e ele continua clicando nos links, nunca clicando no botão "de volta" do
navegador, mas que, eventualmente, fica entediado e começa em outra página aleatória.
A probabilidade de que este "surfista web aleatório" visite uma página é o PageRank
da página. E o fator de amortecimento é a probabilidade em cada página de o "surfista web
aleatório" ficar entediado e solicitar outra página aleatória.
Uma variação importante é adicionar apenas o fator de amortecimento "d" a uma única
página ou a um grupo de páginas. Isso permite personalização e pode tornar quase impossível

enganar deliberadamente o sistema para obter uma classificação mais alta. Temos várias outras
extensões para o PageRank [ver mais uma vez Page 98].
Outra justificativa intuitiva é que uma página pode ter um PageRank alto se houver
muitas páginas que apontem para ela, ou se houver algumas páginas que apontem para ela e
tenham um PageRank alto. Intuitivamente, as páginas que são bem citadas em muitos lugares
da Web merecem ser vistas. Além disso, páginas que talvez tenham apenas uma citação a
partir de uma página como a homepage do Yahoo! geralmente também vale a pena ser vista.
Se uma página não fosse de alta qualidade, ou fosse um link quebrado, é bem provável que a
página inicial do Yahoo! não tivesse um link para ela. O PageRank manipula esses dois casos
e tudo o mais, propagando recursivamente os pesos através da estrutura de links da Web.
2.2 Texto-âncora
O texto dos links é tratado de maneira especial em nosso mecanismo de busca.
A maioria dos mecanismos de busca associa o texto de um link à página em que o link
está. Ademais, nós o associamos à página para a qual o link aponta. Isso tem várias vantagens.
Primeiro, as âncoras geralmente fornecem descrições mais precisas de páginas da Web do que
as próprias páginas. Em segundo lugar, âncoras podem existir para documentos que não podem
ser indexados por um mecanismo de busca baseado em texto, como imagens, programas e
bancos de dados. Isso possibilita o retorno de páginas da Web que não foram realmente
rastreadas.
Observe que as páginas que não foram rastreadas podem causar problemas, pois nunca
são verificadas quanto à validade antes de serem apresentadas ao usuário. Nesse caso, o
mecanismo de busca pode até apresentar uma página que nunca existiu, mas tinha hiperlinks
apontando para ela. No entanto, é possível classificar os resultados para que esse problema
específico raramente aconteça.
Essa ideia de propagar o texto-âncora para a página a que ele se refere foi
implementada no World Wide Web Worm [McBryan 94], especialmente porque ajuda a
buscar informações não-textuais e expande a cobertura de busca com menos documentos
baixados. Usamos a propagação de âncoras principalmente porque o texto-âncora pode ajudar
a fornecer resultados de melhor qualidade.
Usar o texto-âncora com eficiência é tecnicamente difícil devido às grandes
quantidades de dados que devem ser processados. Em nosso rastreamento atual de 24 milhões
de páginas, tivemos mais de 259 milhões de âncoras que indexamos.
2.3 Outras funcionalidades
Além do PageRank e do uso do texto-âncora, o Google tem vários outros recursos.
Primeiro, ele tem informações de localização para todos os hits e, por isso, faz uso
extensivo da proximidade na pesquisa.
Em segundo lugar, o Google acompanha alguns detalhes da apresentação visual, como
o tamanho da fonte das palavras. Palavras em uma fonte maior ou negrito têm mais peso que
outras palavras.

Em terceiro lugar, o HTML bruto completo das páginas está disponível em um
repositório.
3. Trabalhos Relacionados
A pesquisa sobre busca na Web tem um histórico curto e conciso.
O World Wide Web Worm (WWWW) [McBryan 94] foi um dos primeiros
mecanismos de busca da Web. Posteriormente, foi seguido por vários outros mecanismos de
busca acadêmicos, muitos dos quais agora são empresas públicas.
Em comparação com o crescimento da Web e a importância dos mecanismos de busca,
há poucos artigos atuais e relevantes sobre os mecanismos de busca recentes [Pinkerton 94].
De acordo com Michael Mauldin (cientista-chefe, Lycos Inc) [Mauldin], "os vários serviços
(incluindo o Lycos) guardam os detalhes desses bancos de dados".
No entanto, tem havido uma quantidade razoável de trabalho sobre as características
específicas dos mecanismos de busca. Especialmente representativo é o trabalho que pode
obter resultados por pós-processamento dos resultados dos mecanismos de busca comerciais
existentes, ou produzir mecanismos de busca "individualizados" em pequena escala.
Finalmente, tem havido muita pesquisa sobre sistemas de recuperação de informação,
especialmente em coleções bem controladas. Nas próximas duas seções, discutiremos algumas
áreas em que essa pesquisa precisa ser estendida para funcionar melhor na Web.
3.1 Recuperação de Informações
O trabalho em sistemas de recuperação de informação remonta há muitos anos e está
bem desenvolvido [Witten 94].
No entanto, a maioria das pesquisas sobre sistemas de recuperação de informação é
sobre pequenas coleções bem controladas e homogêneas, como coleções de artigos científicos
ou notícias sobre um tópico relacionado. De fato, a principal referência para a recuperação de
informações, a Conferência de Recuperação de Texto [TREC 96], usa uma coleção
razoavelmente pequena e bem controlada para seus benchmarks.
O benchmark "Very Large Corpus" é de apenas 20GB comparado aos 147GB do nosso
rastreamento de 24 milhões de páginas da Web. As coisas que funcionam bem no TREC
geralmente não produzem bons resultados na Web. Por exemplo, o modelo de espaço vetorial
padrão tenta retornar o documento que mais se aproxima da consulta, uma vez que tanto a
consulta quanto o documento são vetores definidos por sua ocorrência de palavras.
Na Web, essa estratégia geralmente retorna documentos muito curtos, que são a
consulta e algumas palavras. Por exemplo, vimos um grande mecanismo de busca retornar
uma página contendo apenas "Bill Clinton sucks" e uma foto para uma consulta "Bill Clinton".
Alguns argumentam que, na Web, os usuários devem especificar com mais precisão o que
querem e adicionar mais palavras à consulta.
Discordamos veementemente dessa posição. Se um usuário fizer uma consulta como
"Bill Clinton", ele deverá obter resultados razoáveis, pois há uma enorme quantidade de
informações de alta qualidade disponíveis sobre esse tópico.

Diante de exemplos como esses, acreditamos que o trabalho padrão de recuperação de
informações precisa ser estendido para lidar efetivamente com a Web.
3.2 Diferenças entre a Web e coleções bem controladas
A Web é uma vasta coleção de documentos heterogêneos completamente sem controle.
Os documentos na Web têm uma extrema variação interna nos documentos e também nas
meta-informações externas que podem estar disponíveis.
Por exemplo, os documentos diferem internamente em seu idioma (tanto humano,
quanto de programação), vocabulário (endereços de e-mail, links, CEP’s, números de telefone,
números de produtos), tipo ou formato (texto, HTML, PDF, imagens, áudio) e mesmo quanto
a ser gerado por máquina (arquivos de log ou de saída de um banco de dados).
Por outro lado, definimos meta-informações externas como aquelas informações que
podem ser inferidas sobre um documento, mas que não estão contidas nele. Exemplos de meta-
informações externas incluem coisas como reputação da fonte, frequência de atualização,
qualidade, popularidade ou uso e citações. Não apenas as possíveis fontes de meta-informação
externas são variadas, mas as coisas que estão sendo medidas também variam em muitas
ordens de grandeza.
Por exemplo, compare as informações de uso de uma página principal, como o Yahoo!
(que atualmente recebe milhões de visualizações de página todos os dias) com um obscuro
artigo histórico que pode receber uma visualização a cada dez anos. Obviamente, esses dois
itens devem ser tratados de maneira muito diferente por um mecanismo de busca.
Outra grande diferença entre a Web e as coleções tradicionais bem controladas é que
praticamente não há controle sobre o que as pessoas podem colocar na Web. Associe essa
flexibilidade de publicar qualquer coisa com a enorme influência dos mecanismos de busca
para direcionar o tráfego e temos o sério problema de empresas que deliberadamente
manipulam os mecanismos de busca para obter lucros. Este problema não tem sido abordado
em sistemas tradicionais de recuperação de informação fechada.
Além disso, é interessante observar que os esforços de metadados têm falhado em
grande parte com os mecanismos de busca da Web, porque qualquer texto na página que não
seja representado diretamente para o usuário é mal usado para manipular os mecanismos de
busca. Existem ainda inúmeras empresas especializadas em manipular os mecanismos de
busca para obter lucro.
4. Anatomia do sistema
Primeiro, forneceremos uma discussão de alto nível sobre a arquitetura. Em seguida,
há algumas descrições detalhadas de estruturas de dados importantes. Finalmente, os
principais aplicativos: rastreamento, indexação e busca serão examinados em profundidade.
4.1 Visão geral da arquitetura do Google
Nesta seção, apresentaremos uma visão geral de alto nível de como todo o sistema
funciona como ilustrado na Figura 1. Outras seções discutirão as aplicações e estruturas de

dados não mencionadas nesta seção. A maior parte do Google é implementada em C ou C++
para eficiência e pode ser executada no Solaris ou no Linux.
Figura 1. Arquitetura de alto nível do Google
No Google, o rastreamento da Web (download de páginas da Web) é feito por vários
rastreadores distribuídos. Existe um servidor de URL’s que envia listas de URL’s a serem
buscadas pelos rastreadores. As páginas da web que são buscadas são enviadas para o servidor
de armazenamento. O servidor de armazenamento, então, compacta e armazena as páginas da
web em um repositório. Cada página da web tem um número de ID associado chamado docID,
que é atribuído sempre que um novo URL é analisado em uma página da Web. A função de
indexação é executada pelo indexador e pelo classificador. O indexador executa várias
funções. Ele lê o repositório, descompacta os documentos e os analisa. Cada documento é
convertido em um conjunto de ocorrências de palavras denominados “hits”. Os hits registram
a palavra, a posição no documento, uma aproximação do tamanho da fonte e a capitalização
(maiusculização). O indexador distribui esses hits em um conjunto de "barris", criando um
índice de encaminhamento parcialmente classificado.
O indexador executa outra função importante. Ele analisa todos os links em todas as
páginas da Web e armazena informações importantes sobre eles em um arquivo de âncoras.
Esse arquivo contém informações suficientes para determinar de onde (e para onde) cada link
aponta e o texto do link.
O URLresolver lê o arquivo de âncoras e converte URL’s relativos em URL’s
absolutos e, por sua vez, em docIDs. Ele coloca o texto-âncora no índice de encaminhamento,
associado ao docID para o qual a âncora aponta. Também gera um banco de dados de links

que são pares de docIDs. O banco de dados de links é usado para calcular os PageRanks de
todos os documentos.
O classificador pega os barris, que são classificados por docID (isso é uma
simplificação, veja a Seção 4.2.5), e recorre a eles através do wordID para gerar o índice
invertido. Isso é feito in-place para que pouco espaço temporário seja necessário para essa
operação. O classificador também produz uma lista de wordIDs e offsets no índice invertido.
Um programa chamado DumpLexicon pega essa lista junto com o léxico produzido pelo
indexador e gera um novo léxico para ser usado pelo pesquisador. O pesquisador é executado
por um servidor da Web e usa o léxico criado pelo DumpLexicon junto com o índice invertido
e os PageRanks para responder a consultas.
4.2 Principais estruturas de dados
As estruturas de dados do Google são otimizadas para que uma grande coleção de
documentos possa ser rastreada, indexada e buscada com pouco custo.
Embora as CPU’s e as taxas de input/output em massa tenham melhorado
drasticamente ao longo dos anos, uma busca em disco ainda requer cerca de 10 ms para ser
concluída. O Google foi projetado para evitar buscas em disco sempre que possível, e isso teve
uma influência considerável no design das estruturas de dados.
4.2.1 BigFiles
BigFiles são arquivos virtuais que abrangem vários sistemas de arquivos e são
endereçáveis por inteiros de 64 bits. A alocação entre vários sistemas de arquivos é tratada
automaticamente.
O pacote BigFiles também lida com alocação e desalocação de descritores de arquivos,
uma vez que os sistemas operacionais não fornecem o suficiente para as nossas necessidades.
Os BigFiles também suportam opções de compactação rudimentares.
4.2.2 Repositório
O repositório contém os códigos HTML completos de todas as páginas Web. Cada
página é compactada usando zlib (consulte RFC1950). A escolha da técnica de compressão
considerou a velocidade e taxa de compressão. Escolhemos a velocidade do zlib em relação a
uma melhoria significativa na compactação oferecida pelo bzip. A taxa de compactação do
bzip foi de aproximadamente 4 para 1 no repositório, em comparação com a compactação de
3 para 1 do zlib.
No repositório, os documentos são armazenados um após o outro e são prefixados por
docID, comprimento e URL, como pode ser visto na Figura 2. O repositório não requer outras
estruturas de dados a serem usadas para acessá-lo. Isso ajuda na consistência dos dados e
facilita muito o desenvolvimento; podemos reconstruir todas as outras estruturas de dados
apenas a partir do repositório e um arquivo que lista os erros do rastreador.

Figura 2. Estrutura de dados do Repositório
4.2.3 Índice do documento
O índice do documento mantém informações sobre cada documento. É um índice
ISAM (Index Sequential Access Mode) de largura fixa, ordenado por docID. As informações
armazenadas em cada entrada incluem o status atual do documento, um ponteiro para o
repositório, uma soma de verificação do documento e várias estatísticas. Se o documento foi
rastreado, ele também contém um ponteiro em um arquivo de largura variável chamado
docinfo que contém seu URL e título. Caso contrário, o ponteiro aponta para a lista de URLlist
que contém apenas o URL. Essa opção de design foi motivada pelo desejo de ter uma estrutura
de dados razoavelmente compacta e a capacidade de alcançar um registro em uma busca de
disco durante uma pesquisa
Além disso, existe um arquivo que é usado para converter URL’s em docIDs. É uma
lista de somas de verificação de URL com seus docIDs correspondentes e é classificada por
soma de verificação. Para localizar o docID de um URL específico, a soma de verificação do
URL é calculada e uma pesquisa binária é executada no arquivo de somas de verificação para
localizar seu docID. URL’s podem ser convertidos em docIDs em lote, fazendo uma
mesclagem com esse arquivo. Essa é a técnica usada pelo URLresolver para transformar
URL’s em docIDs. Esse modo de atualização em lote é crucial, porque, caso contrário,
devemos executar uma busca para cada link, o que pressupõe que um disco levaria mais de
um mês para nosso conjunto de dados de 322 milhões de links.
4.2.4 Léxico
O léxico tem várias formas diferentes. Uma mudança importante dos sistemas
anteriores é que o léxico pode caber na memória por um preço razoável. Na implementação
atual, podemos manter o léxico na memória em uma máquina com 256 MB de memória
principal. O léxico atual contém 14 milhões de palavras (embora algumas palavras raras não
tenham sido adicionadas ao léxico). Ele é implementado em duas partes: uma lista das palavras
(concatenadas, mas separadas por nulls) e uma tabela de hash de ponteiros. Para várias
funções, a lista de palavras tem alguma informação auxiliar cuja explicação completa está
além do escopo deste artigo.
4.2.5 Listas de Hits
Uma lista de hits corresponde a uma lista de ocorrências de uma determinada palavra
em um determinado documento, incluindo informações de posição, fonte e capitalização. As
listas de ocorrências respondem pela maior parte do espaço usado nos índices direto e
invertido. Por isso, é importante representá-los da forma mais eficiente possível.

Consideramos várias alternativas para codificar posição, fonte e capitalização: codificação
simples (uma tripla de inteiros), uma codificação compacta (uma alocação otimizada à mão
de bits) e codificação de Huffman. No final, escolhemos uma codificação compacta otimizada
manualmente, pois ela requeria muito menos espaço do que a codificação simples e muito
menos manipulação de bits do que a codificação Huffman. Os detalhes dos hits são mostrados
na Figura 3.
Figura 3. Índices avançados e inversos e o Léxico
Nossa codificação compacta usa dois bytes para cada hit. Existem dois tipos de hits:
hits invulgares e hits simples. Os hits invulgares incluem hits que ocorrem em um URL, título,
texto-âncora ou meta-tag. Hits simples incluem todo o resto. Um hit simples consiste em um
bit de capitalização, tamanho da fonte e 12 bits de posição da palavra em um documento (todas
as posições superiores a 4095 são rotuladas como 4096). O tamanho da fonte é representado
em relação ao resto do documento usando três bits (apenas 7 valores são realmente usados
porque 111 é o sinalizador que sinaliza um hit invulgar). Um hit invulgar consiste em um bit
de capitalização, o tamanho da fonte definido como 7 para indicar que é um hit invulgar, 4 bits
para codificar o tipo de hit invulgar e 8 bits de posição. Para hits de âncora, os 8 bits de posição
são divididos em 4 bits para posição na âncora e 4 bits para um hash do docID em que a âncora
ocorre. Isso nos dá uma busca de frase limitada, desde que não há muitas âncoras para uma
palavra particular. Esperamos atualizar a maneira como os hits de âncora são armazenados
para permitir maior resolução na posição e campos docIDhash. Usamos o tamanho da fonte
em relação ao restante do documento porque, ao buscar, você não deseja classificar
documentos idênticos de outra forma apenas porque um dos documentos está em uma fonte
maior.
O tamanho de uma lista de hits é armazenado antes dos próprios hits. Para economizar
espaço, o tamanho da lista de hits é combinado com o wordID no índice de encaminhamento
e o docID no índice invertido. Isso limita a 8 e 5 bits, respectivamente (existem alguns truques

que permitem que 8 bits sejam emprestados da wordID). Se o comprimento for maior do que
caberia em muitos bits, um código de escape será usado nesses bits e os próximos dois bytes
conterão o tamanho real.
4.2.6 Forward Index (índice de encaminhamento)
O índice de encaminhamento já está parcialmente ordenado. É armazenado em vários
barris (usamos 64). Cada barril contém um intervalo de wordIDs. Se um documento contiver
palavras que caiam em um determinado barril, o docID é registrado no barril, seguido por uma
lista de wordID com listas de hits que correspondem a essas palavras. Esse esquema requer
um pouco mais de armazenamento devido a docIDs duplicados, mas a diferença é muito
pequena para um número razoável de buckets e economiza tempo considerável e
complexidade de codificação na fase final de indexação feita pelo classificador. Além disso,
em vez de armazenar wordID's reais, armazenamos cada wordID como uma diferença relativa
do mínimo de wordID que cai no barril em que o wordID está. Dessa forma, podemos usar
apenas 24 bits para o wordID nos barris não-classificados, deixando 8 bits para o tamanho da
lista de hits.
4.2.7 Índice Invertido
O índice invertido consiste nos mesmos barris que o índice de encaminhamento, exceto
pelo fato de terem sido processados pelo classificador. Para cada wordID válida, o léxico
contém um ponteiro para o barril em que o wordID se encaixa. Aponta para uma doclist de
docIDs juntamente com suas listas de ocorrências hits. Esta lista de documentos representa
todas as ocorrências dessa palavra em todos os documentos.
Uma questão importante é em que ordem os docIDs devem aparecer na doclist. Uma
solução simples é armazená-los classificados por docID. Isso permite a rápida mesclagem de
diferentes doclist para consultas de várias palavras. Outra opção é armazená-los classificados
por uma classificação da ocorrência da palavra em cada documento. Isso faz com que
responder a uma consulta de uma palavra seja trivial e torna provável que as respostas para
consultas de várias palavras estejam próximas do início. No entanto, a fusão é muito mais
difícil. Além disso, isso torna o desenvolvimento muito mais difícil, pois uma alteração na
função de classificação exige uma reconstrução do índice. Escolhemos uma harmonização
entre essas opções, mantendo dois conjuntos de barris invertidos: um conjunto para lista de
hits que incluem hits de título ou âncora e outro conjunto para todas as listas de hits. Desta
forma, nós verificamos o primeiro conjunto de barris primeiro e se não houver
correspondências suficientes dentro desses barris, nós verificamos os maiores.
4.3 Rastreando a Web
A execução de um rastreador da Web é uma tarefa desafiadora. Há problemas
complicados de desempenho e confiabilidade e, ainda mais importante, há questões sociais. O
rastreamento é o aplicativo mais frágil, pois envolve a interação com centenas de milhares de
servidores da Web e vários servidores de nomes, que estão além do controle do sistema.
A fim de escalar para centenas de milhões de páginas da Web, o Google tem um
sistema de rastreamento rápido distribuído. Um único servidor de URL’s serve listas de URL’s
para vários rastreadores (normalmente, cerca de 3). O servidor de URL’s e os rastreadores são
implementados em Python. Cada rastreador mantém cerca de 300 conexões abertas ao mesmo

tempo. Isso é necessário para recuperar páginas da web com rapidez suficiente. Em
velocidades de pico, o sistema pode rastrear mais de 100 páginas da Web por segundo usando
quatro rastreadores. Isso equivale a cerca de 600K de dados por segundo. Um grande estresse
de desempenho é a pesquisa de DNS. Cada rastreador mantém um cache DNS próprio,
portanto, não precisa fazer uma pesquisa de DNS antes de rastrear cada documento. Cada uma
das centenas de conexões pode estar em vários estados diferentes: procurando o DNS,
conectando-se ao host, enviando solicitação e recebendo resposta. Esses fatores tornam o
rastreador um componente complexo do sistema. Ele usa E/S assíncrona para gerenciar
eventos e várias filas para mover as buscas de página de estado para estado.
Acontece que a execução de um rastreador que se conecta a mais de meio milhão de
servidores e gera dezenas de milhões de entradas de log gera uma boa quantidade de emails e
telefonemas. Devido ao grande número de pessoas que entram na fila, há sempre aqueles que
não sabem o que é um rastreador, porque este é o primeiro que viram. Quase diariamente,
recebemos um e-mail do tipo: "Uau, você viu muitas páginas do meu site. Você gostou?" Há
também algumas pessoas que não conhecem o protocolo de exclusão de robôs e simplesmente
acham que suas páginas devem ser protegidas da indexação por uma declaração como "Esta
página é protegida por direitos autorais e não deve ser indexada", o que é desnecessário dizer
que é difícil para rastreadores da Web entender.
Além disso, devido à enorme quantidade de dados envolvidos, coisas inesperadas
acontecerão. Por exemplo, nosso sistema tentou rastrear um jogo online. Isso resultou em
muitas mensagens-lixo no meio do jogo deles. Acontece que este foi um problema fácil de
corrigir. Mas esse problema não surgiu até termos baixado dezenas de milhões de páginas.
Devido à imensa variação em páginas e servidores da Web, é virtualmente impossível testar
um rastreador sem executá-lo em grande parte da Internet. Invariavelmente, existem centenas
de problemas obscuros que podem ocorrer apenas em uma página de toda a Web e fazer com
que o rastreador falhe, ou pior, causar comportamento imprevisível ou incorreto.
Sistemas que acessam grandes partes da Internet precisam ser projetados para serem
muito robustos e cuidadosamente testados. Já que grandes sistemas complexos, tais como os
rastreadores, invariavelmente causam problemas, é necessário que haja recursos significativos
dedicados à leitura de emails e à solução desses problemas à medida que surgem.
4.4 Indexando a Web
Análise - Qualquer analisador que é projetado para ser executado na Web inteira deve
manipular uma grande variedade de possíveis erros. Eles variam de erros de digitação em tags
HTML a kilobytes de zeros no meio de uma tag, caracteres não-ASCII, tags HTML aninhadas
profundamente e uma grande variedade de outros erros que desafiam a imaginação de qualquer
pessoa para lidar com criações semelhantes. Para a velocidade máxima, em vez de usar o
YACC para gerar um analisador CFG, usamos o flex para gerar um analisador léxico que nós
equipamos com sua própria pilha. Desenvolver esse analisador que funciona a uma velocidade
razoável e é muito robusto envolveu uma boa quantidade de trabalho.
Indexando documentos em barris - Depois que cada documento é analisado, ele é
codificado em vários barris. Cada palavra é convertida em um wordID usando uma tabela de
hash na memória - o léxico. Novas adições à tabela de hash do léxico são registradas em um
arquivo. Depois que as palavras são convertidas em wordIDs, suas ocorrências no documento

atual são convertidas em listas de hits e são gravadas nos barris avançados. A principal
dificuldade da paralelização da fase de indexação é que o léxico precisa ser compartilhado.
Em vez de compartilhar o léxico, adotamos a abordagem de escrever um log de todas as
palavras extras que não estavam em um léxico de base, que fixamos em 14 milhões de
palavras. Dessa forma, vários indexadores podem ser executados em paralelo e, em seguida,
o pequeno arquivo de log de palavras extras pode ser processado por um indexador final.
Classificação - Para gerar o índice invertido, o classificador pega cada um dos barris
dianteiros e classifica-os por wordID para produzir um barril invertido para hits de títulos e
âncora e um barril invertido de texto completo. Este processo acontece um barril de cada vez,
exigindo assim pouco armazenamento temporário. Além disso, paralelizamos a fase de
classificação para usar tantas máquinas quantas as que temos simplesmente executando vários
separadores, que podem processar diferentes buckets ao mesmo tempo. Como os barris não se
encaixam na memória principal, o classificador os subdivide em cestas que se encaixam na
memória com base na wordID e docID. Em seguida, o classificador, carrega cada cesta na
memória, classifica-a e grava seu conteúdo no barril invertido pequeno e no barril invertido
completo.
4.5 Buscando
O objetivo da busca é fornecer resultados de busca de qualidade com eficiência. Muitos
dos grandes mecanismos de busca comerciais ao que parece têm feito grandes progressos em
termos de eficiência. Por isso, nos concentramos mais na qualidade da busca em nossa
pesquisa, embora acreditemos que nossas soluções sejam escaláveis para volumes comerciais
com um pouco mais de esforço.
O processo de avaliação de consultas do Google é mostrado na Figura 4.
Figura 4. Avaliação de consultas do Google
Para limitar o tempo de resposta, quando um determinado número de documentos
correspondentes (atualmente 40.000) é encontrado, o pesquisador automaticamente passa para
a etapa 8 na Figura 4. Isso significa que é possível que resultados abaixo do ideal sejam
apresentados. No momento, estamos investigando outras maneiras de resolver esse problema.

No passado, classificamos os resultados de acordo com o PageRank, o que pareceu melhorar
a situação.
4.5.1 O sistema de classificação
O Google mantém muito mais informações sobre documentos da Web do que os
mecanismos de busca comuns. Cada hitlist inclui informações de posição, fonte e
capitalização. Além disso, consideramos os hits do texto-âncora e do PageRank do documento.
Combinar todas essas informações em uma classificação é difícil. Projetamos nossa função de
classificação para que nenhum fator em particular possa ter muita influência. Primeiro,
considere o caso mais simples: uma consulta de uma única palavra. Para classificar um
documento com uma única consulta de palavra, o Google analisa a lista de hits desse
documento para essa palavra. O Google considera cada hit como um dos vários tipos diferentes
(título, âncora, URL, fonte grande de texto simples, fonte pequena de texto simples, ...), cada
um com seu próprio peso-tipo. Os pesos-tipo compõem um vetor indexado por tipo. O Google
conta o número de acessos de cada tipo na lista de hits. Então, cada contagem é convertida em
um peso-de-contagem. Os pesos-de-contagem aumentam linearmente com as contagens no
início, mas diminuem rapidamente para que mais do que uma determinada contagem não
ajude. Tomamos o dot-product de ponto do vetor de peso-de-contagem com o vetor de pesos-
tipos para calcular uma pontuação de IR para o documento. Finalmente, a pontuação de IR é
combinada com o PageRank para dar uma classificação final ao documento.
Para uma busca com várias palavras, a situação é mais complicada. Agora, várias listas
de hits devem ser verificadas ao mesmo tempo, de modo que as ocorrências próximas em um
documento sejam ponderadas mais do que as ocorrências muito distantes. Os hits das várias
listas de hits são correspondidos para que os hits próximos sejam associados. Para cada
conjunto combinado de hits, uma proximidade é calculada. A proximidade é baseada em quão
distantes estão os hits no documento (ou âncora), mas é classificados em 10 diferentes valores,
variando de uma correspondência de frase a "nem mesmo chega perto". As contagens são
calculadas não apenas para cada tipo de hit, mas para todos os tipos e proximidades. Cada tipo
e par de proximidade tem um peso-tipo-aproximado. As contagens são convertidas em pesos-
de-contagem e utilizamos o dot-product dos pesos-de-contagem e pesos-tipo para calcular
uma pontuação de IR. Todos esses números e matrizes podem ser exibidos com os resultados
da busca usando um modo de depuração especial. Essas exibições foram muito úteis no
desenvolvimento do sistema de classificação.
4.5.2 Feedback
A função de classificação tem muitos parâmetros como os pesos-tipo e os pesos-tipo-
aproximado. Descobrir os valores certos para esses parâmetros é uma espécie de arte negra.
Para fazer isso, temos um mecanismo de feedback do usuário no mecanismo de busca. Um
usuário confiável pode, opcionalmente, avaliar todos os resultados apresentados. Então, este
feedback é salvo. Então, quando modificamos a função de classificação, podemos ver o
impacto dessa alteração em todas as pesquisas anteriores que foram classificadas (ranqueadas).
Embora longe de ser perfeito, isso nos dá uma ideia de como uma mudança na função de
classificação afeta os resultados da busca.

5. Resultados e desempenho
A medida mais importante de um mecanismo de busca é a qualidade de seus resultados
de busca. Embora uma avaliação completa do usuário esteja além do escopo deste documento,
nossa própria experiência com o Google mostrou que ele produz melhores resultados do que
os principais mecanismos de busca comerciais (para a maioria das buscas).
Como um exemplo que ilustra o uso do PageRank, texto-âncora e proximidade, a
Figura 4 (abaixo) mostra os resultados do Google para uma pesquisa sobre "Bill Clinton".
Esses resultados demonstram alguns dos recursos do Google. Os resultados são agrupados por
servidor. Isso ajuda consideravelmente ao filtrarmos os conjuntos de resultados. Vários
resultados são do domínio whitehouse.gov, que é o que razoavelmente se pode esperar de tal
busca. Atualmente, a maioria dos principais mecanismos comerciais de busca não retorna
nenhum resultado para whitehouse.gov, muito menos resultados corretos. Observe que não há
título para o primeiro resultado. Isso é porque não foi rastreado. Em vez disso, o Google
baseou-se no texto-âncora para determinar se essa era uma boa resposta para a consulta. Da
mesma forma, o quinto resultado é um endereço de email que, obviamente, não é rastreável.
Também é um resultado do texto-âncora.

Todos os resultados são de qualidade razoavelmente alta e, na última verificação,
nenhum era link quebrado. Isto se deve, em grande parte, porque todos eles têm alto PageRank.
Os PageRanks são as porcentagens em vermelho junto com os gráficos de barras.
Finalmente, não há resultados sobre um outro Bill senão Clinton, ou sobre um Clinton
diferente de Bill. Isso porque atribuímos grande importância à proximidade das ocorrências
de palavras. É claro que um verdadeiro teste da qualidade de um mecanismo de busca
envolveria um extenso estudo dos usuários ou análise de resultados (infelizmente não temos
espaço para isso aqui). Em vez disso, convidamos o leitor a experimentar o Google por conta
própria em http://google.stanford.edu.
5.1 Requisitos de armazenamento
Além da qualidade de busca, o Google foi projetado para escalar de maneira econômica
o tamanho da Web à medida que cresce. Um aspecto disso é usar o armazenamento de forma
eficiente.
A Tabela 1 apresenta alguns detalhes de estatísticas e requisitos de armazenamento do
Google. Devido à compactação, o tamanho total do repositório é de cerca de 53 GB (pouco
mais de um terço do total de dados que ele armazena). Com os preços atuais dos discos, isso
torna o repositório uma fonte relativamente barata de dados úteis. E mais importante: o total
de todos os dados usados pelo mecanismo de busca requer uma quantidade comparável de
armazenamento, cerca de 55 GB. Além disso, a maioria das consultas pode ser respondida
usando apenas o pequeno índice invertido. Com uma melhor codificação e compactação do
índice de documentos, um mecanismo de busca da Web de alta qualidade pode caber em um
disco de 7 GB de um PC novo.

5.2 Desempenho do sistema
É importante que um mecanismo de busca rastreie e indexe com eficiência. Dessa
forma, as informações podem ser mantidas atualizadas e as principais alterações no sistema
podem ser testadas com relativa rapidez.
Para o Google, as principais operações são: Rastreamento, Indexação e Classificação.
É difícil medir quanto tempo o rastreio demorou em geral porque os discos foram
preenchidos, os servidores de nomes falharam ou vários outros problemas ocorreram que
pararam o sistema. No total, demorou cerca de 9 dias para baixar os 26 milhões de páginas
(incluindo erros). No entanto, uma vez que o sistema estava perfeitamente funcionando, ele
rodou muito mais rápido, baixando as últimas 11 milhões de páginas em apenas 63 horas, com
uma média de pouco mais de 4 milhões de páginas por dia ou 48,5 páginas por segundo.
Executamos o indexador e o rastreador simultaneamente. O indexador foi executado
com mais rapidez do que os rastreadores. Isso ocorreu principalmente porque gastamos tempo
suficiente otimizando o indexador para que não fosse um gargalo. Essas otimizações incluíram
atualizações em massa no índice de documentos e no posicionamento de estruturas de dados
críticas no disco local. O indexador executou em aproximadamente 54 páginas por segundo.
Os classificadores podem ser executados completamente em paralelo; usando quatro
máquinas, todo o processo de classificação leva cerca de 24 horas.

5.3 Desempenho da busca
Melhorar o desempenho da busca não foi o foco principal de nosso trabalho de
pesquisa, até este ponto. A versão atual do Google responde à maioria das consultas entre 1 e
10 segundos. Esse tempo é predominantemente dominado pelo disco IO sobre o NFS (já que
os discos estão espalhados em várias máquinas).
Além disso, o Google não possui otimizações, como cache de consulta, sub-índices em
termos comuns e outras otimizações comuns. Temos a intenção de acelerar consideravelmente
o Google por meio de melhorias na distribuição e hardware, software e aprimoramentos
algorítmicos. Nosso objetivo é ser capaz de lidar com várias centenas de consultas por
segundo.
A Tabela 2 apresenta alguns exemplos de tempos de consulta da versão atual do
Google. Esses exemplos são repetidos para mostrar as acelerações resultantes do IO em cache.
6. Conclusões
O Google foi projetado para ser um mecanismo de busca escalável. O objetivo
principal é fornecer resultados de busca de alta qualidade em uma rede mundial em rápido
crescimento. O Google emprega várias técnicas para melhorar a qualidade da busca, incluindo
classificação de página, texto-âncora e informações de proximidade. Além disso, o Google é
uma arquitetura completa para reunir páginas da Web, indexá-las e realizar consultas de busca
sobre elas.
6.1 Desenvolvimentos futuros
Um mecanismo de busca em grande escala na Web é um sistema complexo e ainda há
muito a ser feito.
Nossos objetivos imediatos são melhorar a eficiência da busca e dimensionar para
aproximadamente 100 milhões de páginas da Web. Algumas melhorias simples para a
eficiência incluem o cache de consulta, a alocação de disco inteligente e os sub-índices.

Outra área que requer muita pesquisa são as atualizações. Precisamos ter algoritmos
inteligentes para decidir quais páginas antigas devem ser rastreadas novamente e quais novas
páginas devem ser rastreadas. O trabalho em direção a esse objetivo foi feito por [Cho 98].
Uma área promissora de pesquisa é usar caches de proxy para criar bancos de dados
de busca, já que eles são orientados pela demanda. Estamos planejando adicionar recursos
simples suportados por mecanismos de busca comerciais, como operadores booleanos,
negação e stemming. No entanto, outros recursos estão apenas começando a ser explorados,
como o feedback de relevância e o clustering (atualmente, o Google suporta um simples
hostname baseado em clustering).
Também planejamos oferecer suporte ao contexto do usuário (como a localização do
usuário) e a sumarização de resultados. Também estamos trabalhando para ampliar o uso da
estrutura de links e do texto do link. Experiências simples indicam que o PageRank pode ser
personalizado aumentando o peso da página inicial ou favoritos de um usuário. Quanto ao
texto do link, estamos experimentando texto circunvizinho aos links, além do próprio texto do
link.
Um mecanismo de busca da Web é um ambiente muito rico para ideias de pesquisa.
Temos muitos para listar aqui, portanto, não consideramos que essa seção de
Desenvolvimentos Futuros venha a se tornar mais curta em um futuro próximo.
6.2 Busca de alta qualidade
Atualmente, o maior problema enfrentado pelos usuários dos mecanismos de busca da
Web é a qualidade dos resultados que recebem. Embora os resultados muitas vezes sejam
divertidos e ampliem os horizontes dos usuários, eles geralmente são frustrantes e consomem
tempo precioso.
Por exemplo, o principal resultado de uma busca por "Bill Clinton" (em um dos
mecanismos de busca comerciais mais populares) foi o Bill Clinton Joke of the Day: 14 de
abril de 1997.
O Google foi projetado para fornecer pesquisa de maior qualidade, enquanto a Web
continua a crescer rapidamente, a informação pode ser encontrada facilmente. Para conseguir
isso, o Google faz uso intenso de informações hipertextuais que consistem em estrutura de
links e texto de link (âncora). O Google também usa informações de proximidade e fonte.
Embora a avaliação de um mecanismo de busca seja difícil, descobrimos
subjetivamente que o Google retorna resultados de busca de melhor qualidade do que os
mecanismos de busca comerciais atuais. A análise da estrutura de links via PageRank permite
que o Google avalie a qualidade das páginas da Web. O uso do texto do link como uma
descrição para o quê o link aponta ajuda o mecanismo de busca a apresentar resultados
relevantes (e até certo ponto de alta qualidade). Por fim, o uso de informações de proximidade
ajuda a aumentar a relevância em muitas consultas.
6.3 Arquitetura escalável
Além da qualidade da busca, o Google é projetado para escalar. Deve ser eficiente no
espaço e no tempo, e os fatores constantes são muito importantes quando se lida com toda

Web. Na implementação do Google, vimos gargalos na CPU, acesso à memória, capacidade
de memória, busca de disco, taxa de transferência de disco, capacidade de disco e IO de rede.
O Google evoluiu para superar vários desses gargalos durante várias operações. As principais
estruturas de dados do Google fazem uso eficiente do espaço de armazenamento disponível.
Além disso, as operações de rastreamento, indexação e classificação são eficientes o suficiente
para criar um índice de uma parte substancial da Web (24 milhões de páginas), em menos de
uma semana. Esperamos poder criar um índice de 100 milhões de páginas em menos de um
mês.
6.4 Uma ferramenta de pesquisa
Além de ser um mecanismo de busca de alta qualidade, o Google é uma ferramenta de
pesquisa.
Os dados coletados pelo Google já resultaram em muitos outros artigos submetidos a
conferências e muitos outros estão a caminho. Pesquisas recentes [como Abiteboul 97]
mostraram uma série de limitações a consultas sobre a Web que podem ser respondidas sem
que a Web esteja disponível localmente. Isso significa que o Google (ou um sistema
semelhante) não é apenas uma ferramenta de pesquisa valiosa, mas necessária para uma ampla
gama de aplicações.
Esperamos que o Google seja um recurso para usuários de busca e pesquisadores em
todo o mundo e que acenda à próxima geração de tecnologia dos mecanismos de busca.
7. Agradecimentos
Scott Hassan e Alan Steremberg foram fundamentais para o desenvolvimento do
Google. Suas talentosas contribuições são insubstituíveis e os autores lhes devem muita
gratidão. Gostaríamos também de agradecer a Hector Garcia-Molina, a Rajeev Motwani, a
Jeff Ullman, a Terry Winograd e a todo o grupo do WebBase pelo seu apoio e discussões
perspicazes. Finalmente, gostaríamos de reconhecer o generoso apoio de nossos doadores de
equipamentos IBM, Intel, Sun e nossos financiadores. A pesquisa descrita aqui foi conduzida
como parte do Projeto da Biblioteca Digital Integrada de Stanford, apoiada pela National
Science Foundation sob o Acordo Cooperativo IRI-9411306. O financiamento para este
acordo cooperativo também é fornecido pela DARPA e NASA, e pela Interval Research e
pelos parceiros industriais do Projeto de Bibliotecas Digitais de Stanford.
Referências
Best of the Web 1994 - Navigators http://botw.org/1994/awards/navigators.html
Bill Clinton Joke of the Day: April 14, 1997.
http://www.io.com/~cjburke/clinton/970414.html.
Bzip2 Homepage http://www.muraroa.demon.co.uk/
Google Search Engine http://google.stanford.edu/
Harvest http://harvest.transarc.com/

Mauldin, Michael L. Lycos Design Choices in an Internet Search Service, IEEE
Expert Interview http://www.computer.org/pubs/expert/1997/trends/x1008/mauldin.htm
The Effect of Cellular Phone Use Upon Driver Attention
http://www.webfirst.com/aaa/text/cell/cell0toc.htm
Search Engine Watch http://www.searchenginewatch.com/
RFC 1950 (zlib) ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html
Robots Exclusion Protocol:
http://info.webcrawler.com/mak/projects/robots/exclusion.htm
Web Growth Summary: http://www.mit.edu/people/mkgray/net/web-growth-
summary.html
Yahoo! http://www.yahoo.com/
[Abiteboul 97] Serge Abiteboul and Victor Vianu, Queries and Computation on the
Web. Proceedings of the International Conference on Database Theory. Delphi, Greece
1997.
[Bagdikian 97] Ben H. Bagdikian. The Media Monopoly. 5th Edition. Publisher:
Beacon, ISBN: 0807061557
[Chakrabarti 98] S. Chakrabarti, B. Dom, D. Gibson, J. Kleinberg, P. Raghavan and
S. Rajagopalan. Automatic Resource Compilation by Analyzing Hyperlink Structure and
Associated Text. Seventh International Web Conference (WWW 98). Brisbane, Australia,
April 14-18, 1998.
[Cho 98] Junghoo Cho, Hector Garcia-Molina, Lawrence Page. Efficient Crawling
Through URL Ordering. Seventh International Web Conference (WWW 98). Brisbane,
Australia, April 14-18, 1998.
[Gravano 94] Luis Gravano, Hector Garcia-Molina, and A. Tomasic. The
Effectiveness of GlOSS for the Text-Database Discovery Problem. Proc. of the 1994 ACM
SIGMOD International Conference On Management Of Data, 1994.
[Kleinberg 98] Jon Kleinberg, Authoritative Sources in a Hyperlinked Environment,
Proc. ACM-SIAM Symposium on Discrete Algorithms, 1998.
[Marchiori 97] Massimo Marchiori. The Quest for Correct Information on the Web:
Hyper Search Engines. The Sixth International WWW Conference (WWW 97). Santa Clara,
USA, April 7-11, 1997.
[McBryan 94] Oliver A. McBryan. GENVL and WWWW: Tools for Taming the Web.
First International Conference on the World Wide Web. CERN, Geneva (Switzerland), May
25-26-27 1994. http://www.cs.colorado.edu/home/mcbryan/mypapers/www94.ps
[Page 98] Lawrence Page, Sergey Brin, Rajeev Motwani, Terry Winograd. The
PageRank Citation Ranking: Bringing Order to the Web. Manuscript in progress.
http://google.stanford.edu/~backrub/pageranksub.ps

[Pinkerton 94] Brian Pinkerton, Finding What People Want: Experiences with the
WebCrawler. The Second International WWW Conference Chicago, USA, October 17-20,
1994. http://info.webcrawler.com/bp/WWW94.html
[Spertus 97] Ellen Spertus. ParaSite: Mining Structural Information on the Web. The
Sixth International WWW Conference (WWW 97). Santa Clara, USA, April 7-11, 1997.
[TREC 96] Proceedings of the fifth Text REtrieval Conference (TREC-5).
Gaithersburg, Maryland, November 20-22, 1996. Publisher: Department of Commerce,
National Institute of Standards and Technology. Editors: D. K. Harman and E. M. Voorhees.
Full text at: http://trec.nist.gov/
[Witten 94] Ian H Witten, Alistair Moffat, and Timothy C. Bell. Managing Gigabytes:
Compressing and Indexing Documents and Images. New York: Van Nostrand Reinhold,
1994.
[Weiss 96] Ron Weiss, Bienvenido Velez, Mark A. Sheldon, Chanathip Manprempre,
Peter Szilagyi, Andrzej Duda, and David K. Gifford. HyPursuit: A Hierarchical Network
Search Engine that Exploits Content-Link Hypertext Clustering. Proceedings of the 7th ACM
Conference on Hypertext. New York, 1996.
Os autores
Sergey Brin recebeu seu Bacharelado em Matemática e Ciências da
Computação pela Universidade de Maryland em College Park em
1993. Atualmente, ele é candidato a Ph.D. em ciência da computação
na Universidade de Stanford, onde recebeu seu M.S. em 1995. Ele é
bolsista de pós-graduação da National Science Foundation. Seus
interesses de pesquisa incluem mecanismos de busca, extração de
informações de fontes não estruturadas e data mining de grandes
coleções de textos e dados científicos.
Lawrence Page nasceu em East Lansing, Michigan, e recebeu um
B.S.E. em Engenharia de Computação na Universidade de Michigan
Ann Arbor, em 1995. Ele é atualmente é candidato a Ph.D. em Ciência
da Computação na Universidade de Stanford. Alguns de seus interesses
de pesquisa incluem a estrutura de links da Web, interação homens-
computadores, mecanismos de busca, escalabilidade de interfaces de
acesso à informação e personal data mining.
8. Apêndice A: Publicidade e motivos
Atualmente, o modelo de negócios predominante para os mecanismos de busca
comerciais é a publicidade.
Os objetivos do modelo de negócios de publicidade nem sempre correspondem ao
fornecimento de resultados de busca de qualidade aos usuários. Por exemplo, em nosso

protótipo de mecanismo de busca, um dos principais resultados para “telefone celular” é "The
Effect of Cellular Phone Use Upon Driver Attention” (O efeito do uso do telefone celular na
atenção do motorista), um estudo que explica detalhadamente as distrações e os riscos
associados a uma conversa ao celular durante a direção de um automóvel.
Este resultado de busca apareceu em primeiro devido à sua alta importância, conforme
julgado pelo algoritmo PageRank, uma aproximação da importância de citação na Web [Page,
98]. É claro que um mecanismo de busca que estivesse recebendo dinheiro para exibir
anúncios de celular teria dificuldade em justificar aos anunciantes a página que nosso sistema
apresentou. Por essa razão e pela experiência histórica com outras mídias [Bagdikian 83], a
expectativa é que os mecanismos de busca financiados por publicidade estejam inerentemente
comprometidos com os anunciantes e dissociados das necessidades dos consumidores.
Como é muito difícil para os especialistas avaliarem os mecanismos de busca, o viés
do mecanismo de busca é particularmente insidioso. Um bom exemplo foi a OpenText, que é
tida como vendendo a empresas o direito de serem listadas no topo dos resultados de busca
para consultas particulares [Marchiori 97]. Esse tipo de dissociação é muito mais insidioso do
que a publicidade, porque não está claro quem "merece" estar lá, e quem está disposto a pagar
para ser listado.
Esse modelo de negócios resultou em um alvoroço e a OpenText deixou de ser um
mecanismo de busca viável. Mas, um viés menos flagrante provavelmente será tolerado pelo
mercado. Por exemplo, um mecanismo de busca pode adicionar um pequeno fator aos
resultados de busca de empresas "amigáveis" e subtrair um fator dos resultados dos
concorrentes. Esse tipo de viés é muito difícil de detectar, mas ainda pode ter um efeito
significativo no mercado. Além disso, a receita de publicidade geralmente fornece um
incentivo para fornecer resultados de busca de baixa qualidade.
Por exemplo, notamos que um grande mecanismo de busca não apresenta a página
inicial de uma grande companhia aérea quando o nome da empresa aérea foi fornecido como
uma consulta. Acontece que a companhia aérea colocou um anúncio caro, ligado à consulta (o
seu nome). Um mecanismo de busca melhor não exigiria esse anúncio e possivelmente
resultaria na perda da receita da empresa aérea para o mecanismo de busca. Em geral, pode-
se argumentar, do ponto de vista do consumidor, que quanto melhor o mecanismo de busca,
menos anúncios serão necessários para que o consumidor encontre o que deseja. Isso, é claro,
corrói o modelo de negócios com suporte em publicidade dos mecanismos de busca existentes.
No entanto, sempre haverá dinheiro de anunciantes que desejam que um cliente troque de
produto ou tenha algo realmente novo. Mas acreditamos que a questão da publicidade provoca
incentivos mistos suficientes para que seja crucial ter um mecanismo de busca competitivo
que seja transparente e no meio acadêmico.
9. Apêndice B: Escalabilidade
9.1 Escalabilidade do Google
Projetamos o Google para ser dimensionável no curto prazo para uma meta de 100
milhões de páginas da web. Acabamos de receber disco e máquinas para lidar com essa
quantidade. Todas as partes que consomem tempo do sistema são paralelas e,

aproximadamente, de tempo linear. Isso inclui coisas como rastreadores, indexadores e
separadores. Também achamos que a maioria das estruturas de dados lidará de maneira
adequada com a expansão. No entanto, em 100 milhões de páginas da Web, estaremos muito
próximos de todos os tipos de limites de sistema operacional em sistemas operacionais comuns
(atualmente executamos no Solaris e no Linux). Isso inclui coisas como memória endereçável,
número de descritores de arquivos abertos, soquetes de rede e largura de banda e muitos outros.
Acreditamos que expandir para mais de 100 milhões de páginas aumentaria muito a
complexidade do nosso sistema.
9.2 Escalabilidade de arquiteturas de indexação centralizadas
À medida que as capacidades dos computadores aumentam, torna-se possível indexar
uma quantidade muito grande de texto por um custo razoável.
É claro que outras mídias mais intensivas em largura de banda, como vídeos,
provavelmente se tornarão mais difundidas. Mas, como o custo de produção de texto é baixo
em comparação com a mídia como o vídeo, é provável que o texto permaneça muito difundido.
Além disso, é provável que em breve teremos reconhecimento de fala que faça um trabalho
razoável convertendo fala em texto, expandindo a quantidade de texto disponível.
Tudo isso oferece possibilidades incríveis de indexação centralizada. Aqui está um
exemplo ilustrativo. Assumamos que queremos indexar tudo o que todas as pessoas nos EUA
escreveram durante um ano. Presumamos que existem 250 milhões de pessoas nos EUA e elas
escrevem uma média de 10k por dia. Isso resulta em cerca de 850 terabytes. Suponhamos
também que a indexação de um terabyte pode ser feita agora por um custo razoável. Também
assumamos que os métodos de indexação usados ao longo do texto são lineares ou quase
lineares em sua complexidade.
Dadas todas essas suposições, podemos calcular quanto tempo levaria até que
pudéssemos indexar nossos 850 terabytes por um custo razoável, assumindo certos fatores de
crescimento. A Lei de Moore foi definida em 1965 como uma duplicação, a cada 18 meses,
no poder de processamento. Ela se mostrou extremamente verdadeira, não apenas para
processadores, mas também para outros parâmetros importantes do sistema, como discos.
Se assumirmos que a lei de Moore vale para o futuro, precisamos de apenas mais 10
dobras (ou 15 anos) para atingir nossa meta de indexar tudo o que todas as pessoas nos EUA
escreveram por um ano por um preço que uma pequena empresa poderia arcar.
É claro que os especialistas em hardware estão de certa forma preocupados com a Lei
de Moore, que pode não continuar se sustentando pelos próximos 15 anos, mas certamente há
muitas aplicações centralizadas interessantes, mesmo que só obtenhamos parte do nosso
exemplo hipotético.
É claro que sistemas distribuídos como o Gloss [Gravano 94] ou o Harvest serão
muitas vezes a solução técnica mais eficiente para a indexação, mas parece difícil convencer
o mundo a usar esses sistemas por causa dos altos custos de administração para configurar um
grande número de instalações. Naturalmente, é bastante provável que reduzir drasticamente o
custo de administração seja possível. Se isso acontecer, e todos começarem a executar um
sistema de indexação distribuído, a pesquisa certamente melhorará drasticamente.

Como os humanos só podem digitar ou falar uma quantidade finita, e à medida que os
computadores continuem melhorando, a indexação de texto aumentará ainda mais do que
agora. É claro que pode haver uma quantidade infinita de conteúdo gerado por máquina, mas
apenas indexar grandes quantidades de conteúdo gerado por humanos parece ser
tremendamente útil. Por isso, estamos otimistas de que nossa arquitetura centralizada de
mecanismos de busca na Web melhorará em sua capacidade de cobrir as informações de texto
pertinentes ao longo do tempo e que haja um futuro brilhante para a busca.

Google: um mecanismo de busca hipertextual de larga escala

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Google: um mecanismo de busca hipertextual de larga escala

Semelhante a Google: um mecanismo de busca hipertextual de larga escala (20)

Google: um mecanismo de busca hipertextual de larga escala