O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

A anatomia de um mecanismo de busca hipertextual de grande escala na web

185 visualizações

Publicada em

Tradução (fins acadêmicos, não-comercial), para o idioma português, do artigo "The anatomy of a large scale hyper textual web search engine", de Sergey Brin e Larry Page, Tradução: Fernando Gallas.

Publicada em: Internet
  • Seja o primeiro a comentar

A anatomia de um mecanismo de busca hipertextual de grande escala na web

  1. 1. 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
  2. 2. 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
  3. 3. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 3A anatomia de um mecanismo de busca hipertextual de grande escala na Web í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).
  4. 4. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 4A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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
  5. 5. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 5A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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
  6. 6. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 6A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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.
  7. 7. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 7A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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.
  8. 8. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 8A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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
  9. 9. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 9A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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
  10. 10. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 10A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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.
  11. 11. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 11A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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.
  12. 12. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 12A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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
  13. 13. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 13A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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
  14. 14. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 14A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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
  15. 15. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 15A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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.
  16. 16. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 16A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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.
  17. 17. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 17A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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.
  18. 18. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 18A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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.
  19. 19. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 19A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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.
  20. 20. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 20A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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.
  21. 21. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 21A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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
  22. 22. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 22A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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/
  23. 23. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 23A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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
  24. 24. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 24A anatomia de um mecanismo de busca hipertextual de grande escala na Web [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
  25. 25. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 25A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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,
  26. 26. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 26A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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.
  27. 27. Tradutor: Fernando Gallas. 2016 | www.seo.salvador.br Tradução para fins acadêmicos, exclusivamente. Uso não-comercial. 27A anatomia de um mecanismo de busca hipertextual de grande escala na Web 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.

×