Motores de busca: Uma nova alternativa para o Aranha · uma lista de documentos nos quais as palavras chaves foram encontradas. ... S~ao chamadas de p aginas din^amicas e escritas

Motores de busca: Uma nova

alternativa para o Aranha

Trabalho apresentado na

Universidade Federal do Parana para obtencao

do grau de Bacharel em Ciencia da Computacao

Sumario

1 Introducao 3

2 Motores de busca web 5

2.1 Aranha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Indexador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Interface de pesquisa . . . . . . . . . . . . . . . . . . . . . . . 11

2.5 Ranqueamento de paginas web . . . . . . . . . . . . . . . . . . 12

2.6 Motores de busca distribuıdos . . . . . . . . . . . . . . . . . . 13

2.6.1 Peer-to-peer . . . . . . . . . . . . . . . . . . . . . . . . 15

3 O Nutch 16

3.1 Arquitetura do Nutch . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1 Banco de dados . . . . . . . . . . . . . . . . . . . . . . 19

3.1.2 Aranha . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Alteracoes realizadas . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Testes realizados com o Nutch . . . . . . . . . . . . . . . . . . 24

3.3.1 Testes realizados na maquina ]1 . . . . . . . . . . . . . 24

1



4 Novo modelo para o aranha: O Crab 30

4.1 Protocolo de comunicacao Crab . . . . . . . . . . . . . . . . . 32

4.1.1 Formato da mensagem de requisicao . . . . . . . . . . 33

4.1.2 Formato da mensagem de resposta . . . . . . . . . . . 35

5 Implementacao e Resultados Experimentais 38

5.1 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.1 Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.2 Plataforma de execucao . . . . . . . . . . . . . . . . . 40

5.2 Resultados Experimentais . . . . . . . . . . . . . . . . . . . . 41

5.2.1 Desempenho do Nutch . . . . . . . . . . . . . . . . . . 41

5.2.2 Desempenho do Crab . . . . . . . . . . . . . . . . . . . 41

5.3 Comparacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6 Conclusao 45

A Alteracoes realizadas no Nutch 47

2

Capıtulo 1

Introducao

A quantidade de informacao contida na web vem sofrendo um crescimento

exponencial desde o seu inıcio. Cada vez mais paginas web, documentos,

imagens, arquivos de audio, entre outros sao disponibilizados na Internet. Se

por um lado a quantidade de informacao na rede aumenta, a dificuldade de

encontrar uma informacao relevante ao assunto desejado tambem.

A partir da necessidade de pesquisar uma informacao na Internet, sur-

gem os motores de busca web (Search Engines), programas que objetivam

principalmente a recuperacao de informacao contida na web

Em 2002, estimava-se que o tamanho da web estivesse entre 66800 e 91800

TB [2]. Se uma pesquisa realizada sobre esta quantidade de dados, em uma

maquina local, ja seria um tanto quanto lenta, na web e facil imaginar que

essa pesquisa seria completamente inviavel. Atualmente, os motores de busca

sao responsaveis por indexar centenas de milhares de paginas web e prover

resultados de forma eficiente.

Os motores de busca web atuais geralmente sao compostos por quatro

3

partes distintas: o aranha (spider/crawler) que acessa e percorre os sites

seguindo os links encontrados nas paginas, o indexador (indexer) que processa

as paginas obtidas pelo aranha, o banco de dados (database) que armazena as

paginas processadas pelo indexador e a interface de pesquisa (result engine)

que estabelece o canal de comunicacao entre o usuario e o motor de busca.

Este trabalho tem como objetivo oferecer uma nova alternativa para im-

plementacao do aranha. Dado que o funcionamento do aranha e bastante

custoso pois necessita percorrer pagina por pagina na web, a nova alternativa,

chamada Crab, propoe que o aranha seja distribuıdo pela web e permaneca

localizado junto aos servidores web, tirando proveito do acesso a disco e pro-

cessamento local e eliminando assim o alto custo dos aranhas tradicionais.

O Crab nao percorre links. Sua tarefa e analisar e compactar toda a base do

servidor web e aguardar para transferi-la quando o for solicitado.

O restante do trabalho esta organizado da seguinte maneira: o capıtulo 2

faz uma breve introducao a arquitetura dos motores de busca web, o capıtulo

3 apresenta o Nutch [13], um motor de busca web open source, o capıtulo

4 apresenta o Crab, o capıtulo 5 apresenta testes e comparacoes realizados

entre o Crab e o aranha do Nutch e finalmente o capıtulo 6 conclui este

trabalho.

4

Capıtulo 2

Motores de busca web

Os motores de busca web sao programas que visam a recuperacao da in-

formacao contida na web de forma eficiente. Basicamente, sua principal

tarefa e receber como entrada palavras chaves especıficas e gerar como saıda

uma lista de documentos nos quais as palavras chaves foram encontradas.

Para que esta tarefa seja efetuada de forma satisfatoria, um motor de busca

necessita desempenhar diversas funcoes que geralmente sao divididas em qua-

tro partes: o aranha, o indexador, o banco de dados e a interface de pesquisa.

Todas as partes serao detalhadas mais adiante.

A medida que a web foi se tornando cada vez mais complexa e consequen-

temente novos desafios sendo gerados, os motores de busca foram agregando

diversas caracterısticas a sua estrutura, fazendo com que evoluissem cada vez

mais desde o surgimento do Wandex [3], o primeiro motor de busca.

5

2.1 Aranha

O aranha e responsavel por acessar as paginas web e analisa-las a procura

de links. Seu funcionamento pode ser descrito como um processo cıclico que

inicia-se com uma colecao inicial de URLs (Uniform Resource Locator) a

serem acessadas, resgatando o conteudo das mesmas e armazenando os links

encontrados em uma lista, que sera a base para as novas direcoes que o aranha

ira seguir. Ao comecar a execucao o aranha encontra-se na profundidade

zero, ao recomecar um novo ciclo, a profundidade e incrementada e passa

a valer um e assim sucessivamente. Desta maneira, e possıvel estabelecer

uma analogia do funcionamento do aranha com uma arvore, no qual as URLs

representam os vertices e os links contidos na pagina web e que sao acessados

representam as arestas, como mostra a figura 2.1.

E importante ressaltar que na pratica e inviavel que o aranha percorra

todas as URLs presentes na lista, percorrendo assim toda a web. Se o ara-

nha baixasse uma pagina por segundo (considerando a requisicao HTTP) e

analisasse-a, seriam vasculhadas 86400 paginas por dia. Em um ano seriam

31.536.000 paginas. Como atualmente estima-se que exista 20 bilhoes de

paginas [4], levarıamos algumas centenas de anos para varrer toda a web.

Portanto e necessario que o aranha priorize as paginas mais relevantes

para serem acessadas, o que requer uma metrica de importancia. A im-

portancia de uma pagina e uma funcao de sua qualidade e de sua populari-

dade em termos de links ou visitas.

6

Figura 2.1: Representacao do funcionamento do aranha

O aranha e capaz de analisar diferentes formatos de arquivos (HTML,

PDF, TXT, DOC,...). Quando for acessar uma pagina, o aranha pode fazer

uma requisicao HTTP HEAD [5] para descobrir o formato do arquivo antes

de requisitar a pagina com uma requisicao GET. Desta maneira nao ha tempo

desperdicado obtendo arquivos da web que nao desejam ser indexados. Uma

estrategia similar compara a extensoes das URLs com uma lista de tipos de

paginas web conhecidas (html, asp, aspx, php, jsp, etc).

Alguns aranhas pretendem obter o maximo possıvel de paginas de um

determinado web site. Este incremento no funcionamento do aranha acessa

todos os caminhos em cada URL que o aranha pretende processar. Por exem-

plo, para a URL http://llama.org/hamster/monkey/page.html, sera proces-

sado o /hamster/monkey/, /hamster/ e /. Este incremento e interessante

pois pode encontrar enderecos que normalmente nao podem ser encontrados

pelo processo anterior.

Grande quantidade de paginas web somente sao acessadas submetendo

consultas a banco de dados ou atraves da submissao de informacao ao servidor

7

web pelo metodo POST [5]. Sao chamadas de paginas dinamicas e escritas

em linguagens de programacao como: PHP, Java, ASP, etc. Torna-se entao

necessario alguns aranhas especializados para acessar e processar tais paginas

web, visto que os aranhas comuns nao sao habeis para essa tarefa pois pode

nao haver links apontando para elas.

2.2 Indexador

O indexador recebe e processa as paginas obtidas pelo aranha. Sua funcao

e destacar cada palavra do site, descartando as mais comuns (por exemplo:

’e’, ’isto’, ’a’, ...). O codigo HTML tambem e examinado e faz com que

ajude o site a ser mais facilmente encontrado em uma futura recuperacao.

Palavras em negrito, italico ou tags de cabecalhos recebem enfase maior, ou

seja, momento no qual e analisada as meta-informacoes inseridas no codigo

HTML do site (palavras chaves e tags de descricao).

Entre os principais tipos de indexadores, o mais utilizado e o ındice inver-

tido (Inverted index). Este e amplamente utilizado por permitir uma rapida

recuperacao dos termos ja indexados. Possui uma estrutura simples com

dois componentes principais: uma lista de termos distintos (term dictionary)

e uma lista de URLs (posting list) que contem o termo.

Adicionalmente, para cada termo distinto, pode ser armazenado a posicao

a qual o termo se encontra (palavra, frase, paragrafo, etc) e um valor que

representa a relevancia do mesmo na pagina web.

Para a construcao do ındice invertido e utilizado o algoritmo 1. Conforme

indica o algoritmo, sao separados todos os termos de cada URL (linha 2),

8

e isso e feito para todas as URLs encontradas (linha 1). As linhas 3 a 7

verificam se o termo em questao pertence a lista de termos distintos, se

sim, entao nao ha a necessidade de adiciona-lo novamente na lista, portanto

adiciona-se somente a URL na lista de URLs do termo. Caso contrario e

necessario criar um novo campo nas respectivas listas para adicionar o novo

termo e a nova URL.

para cada url U encontrada faca1

para cada termo T na url U faca2

se T ja esta armazenado na lista de termos distintos entao3

adiciona U na lista de urls;4

senao5

adiciona T na lista de termos distintos;6

adiciona U na lista de urls;7

fim8

fim9

fim10

Algoritmo 1: Algoritmo do ındice invertido

Apos processar todas as paginas web, o ındice invertido e armazenado

em mıdia permanente. Fica evidente, entao, que a sua construcao custa caro

em termos de requisitos computacionais, mas uma vez construıdo, e possıvel

extrair resultados de forma eficiente.

A recuperacao de informacao sobre um ındice invertido se da atraves

da interseccao entre a lista de URLs dos ındices armazenados e que foram

atingidos pelos termos de pesquisa. Por exemplo: temos os seguintes termos:

index, search, engine, inverted e as seguintes URLs: X, Y, Z, W, K.

Suponha que ao montar o ındice invertido ficamos com a tabela da figura

2.2:

9

termos / lista de

urls

index X Y

search W Z K

engine W Z

inverted X Y Z

Figura 2.2: Tabela do indice invertido

Portanto ao efetuarmos uma busca pelos termos “inverted”e “index”,

teremos as URLs X, Y e Z, referente ao termo “inverted”e as URLs X e Y,

referente ao termo “index”. Fazendo a intersecao destas listas obteremos as

URLs X e Y.

2.3 Banco de dados

E armazenado no banco de dados as palavras consideradas importantes

pelo indexador. Ha implementacoes que armazenam tambem o conteudo

da pagina com o intuito de manter um cache dos sites. O banco de dados

dos motores de busca requerem uma quantidade enorme de capacidade de

armazenamento. Se supormos que um motor de busca possui algo em torno

de 3 milhoes de documentos, e tambem assumindo que o tamanho medio de

cada documento em torno de algumas dezenas de kilobytes, isto facilmente

ultrapassa muitos terabytes de dados. O Google[6], por exemplo, possui

aproximadamente 850 TB de dados [8].

10

2.4 Interface de pesquisa

A interface de pesquisa e o meio de comunicacao entre o usuario e o motor

de busca. E atraves da interface que sao efetuadas as buscas e obtem-se os

resultados, sendo considerada uma das partes mais importantes de um motor

de busca e foco dos maiores esforcos para otimizacao.

As paginas web resultantes de um motor de busca, (Search Engine Results

Page, SERP) retornadas em resposta a uma pesquisa, normalmente incluem

uma lista de paginas web com seus respectivos tıtulos, um link para a pagina,

e uma curta descricao mostrando onde as palavras chaves “casaram”com o

conteudo dentro da pagina. Uma SERP pode referir-se a uma simples pagina

web contendo links, ou a um conjunto de todos os links retornados por uma

busca.

Alguns motores de busca fazem cache de SERPs para as buscas mais

frequentes e exibem o conteudo em cache ao inves de refazer a busca nova-

mente, aumentando assim o desempenho do motor de busca. O motor de

busca atualiza as SERPs periodicamente para contagem das novas paginas e

possivelmente para alterar o ranking das paginas na SERP. As atualizacoes

das SERPs podem levar muitos dias ou semanas o que pode causar uma im-

precisao nos resultados, pois estes podem estar desatualizados e os sites mais

novos estarem completamente ausentes.

As SERPs da maioria dos motores de busca, como Google e Yahoo!, po-

dem incluir diferentes tipos de listagem como: listagens patrocinadas, ima-

gens, mapas, definicoes, ou refinamentos de sugestoes de busca. A maioria

dos sistemas de busca tambem oferecem diversos tipos de busca, tal como

11

de imagens, notıcias e blogs. As SERPs para estas buscas especializadas

oferecem resultados especıficos.

A interface de pesquisa tambem pode ser responsavel pelo ranqueamento

das paginas. Ela determina as melhoras paginas que “casam”com a busca

feita pelo usuario e em que ordem elas devem ser listadas. Isto sera realizado

de acordo com o algoritmo de ranqueamento que o motor de busca utiliza.

2.5 Ranqueamento de paginas web

Em uma rede como a Internet, na qual o ambiente e completamente hete-

rogeneo, a qualidade e a relevancia da informacao contida na mesma pode va-

riar absurdamente. A partir dessa diversidade torna-se necessario a criacao de

um meio que tenha por funcao filtrar automaticamente os resultados busca-

dos, retornando assim documentos web que estejam o mais proximo possıvel

dentro do escopo da pesquisa. Tem-se inıcio entao o ranking de documentos

web, ou seja, uma pre-avaliacao e posterior qualificacao do documento.

Dentre os metodos mais famosos de ranqueamento esta o PageRank [7]

da Google, que entre outros fatores e um dos responsaveis por tornar o motor

de busca da mesma o mais utilizado da web.

Ao contrario de simplesmente usar o conceito da popularidade do link, o

qual varios tipos de ranqueamento o fazem, o PageRank utiliza um conceito

mais democratico, sendo a classificacao dos documentos web efetuada pela

propria Internet e nao por usuarios. A classificacao se faz atraves do numero

de votos. Um voto nada mais e do que um link, localizado em qualquer lugar

documento web, que aponte diretamente para o determinado documento web.

12

O PageRank tambem considera que quanto mais alto for a colocacao do

documento web no Ranking, maior o valor do seu voto.

Outros exemplos de otimizacao de motor de busca sao aqueles especi-

alizados em pesquisa de imagens, em pesquisa local (evolucao das paginas

amarelas para a Internet) e pesquisa vertical (motores de busca focalizados

em determinado assunto).

2.6 Motores de busca distribuıdos

Os motores de busca distribuıdos surgem como uma diferente alternativa

para implementacao de motores de busca. O conceito de distribuido em

questao nao necessariamente engloba todo o funcionamento do motor de

busca mas pode abranger somente algumas partes do mesmo, ou seja, pode-

se distribuir apenas o aranha ou o indexador e o banco de dados e assim por

diante. Este conceito pode variar de acordo com cada implementacao.

Existem varias implementacoes disponibilizadas na Internet tais como

YaCy [18], Minerva [19], OpenSearch [20], entre outros. Cada qual com suas

particularidades e vantagens. No entanto, nao ha nenhuma implementacao

que consiga erradicar todos os desafios que um motor de busca necessite

enfrentar. Entre os principais desafios encontrados atualmente estao: au-

mentar a relevancia do conteudo buscado, diminuir a grande latencia na

atualizacao das paginas web ja indexadas, indexar completamente a web e

indexar paginas web dinamicas.

No motor de busca distribuıdo, as tarefas basicas executadas (acessar,

indexar e recuperar paginas web) sao divididas por computadores que podem

13

estar localizados em qualquer lugar da Internet (peers). Isso gera novas

dificuldades que afetam diretamente o desempenho do motor de busca. As

principais dificuldades encontradas sao:

No aranha: Acessar e processar as paginas web eficientemente no cenario

dinamico da web, visando minimizar a taxa de requisicoes GET aos

servidores web e encontrar peers confiaveis na rede para executarem a

funcao do aranha.

No indexador e no banco de dados: Definir uma maneira efetiva de par-

ticionar o banco de dados de modo que futuras buscas necessitem utili-

zar o menor numero possıvel de particoes para fornecer o maior numero

de documentos relevantes. E necessario tambem definir uma estrategia

para balancear a carga de buscas, redirecionando-as para diferentes

peers.

Na interface de busca: Lidar com problemas de roteamento (geralmente

sao utilizadas DHTs [21] como tabelas de roteamento). Em particular,

com o roteamento de consultas. E importante tambem saber manipular

falhas, como por exemplo: quando um peer encontra-se desconectado.

Para tal sao usadas tecnicas de replicacao, as quais aumentam a dispo-

nibilidade de informacao na rede.

Para estabelecer a comunicacao entre esses peers e utilizada a arquitetura

das redes peer-to-peer[9].

14

2.6.1 Peer-to-peer

Frequentemente chamada de P2P, consiste em um tipo de rede a qual

cada estacao de trabalho tem capacidades e responsabilidades equivalen-

tes (equipotencia entre os nodos), fazendo com que os peers tenham uma

interacao direta. Podemos caracterizar peer-to-peer como uma classe de

aplicacoes que tomam vantagens de diversos recursos como armazenamento

e conteudo, disponıveis nas mais diversas bordas da Internet. Isto difere das

arquiteturas cliente-servidor, nas quais alguns computadores (servidores) sao

dedicados a servir outros (clientes).

As redes P2P sao sistemas distribıdos tipicamente usados para interligar

uma grande quantidade de nodos (atraves de conexoes ad hoc) capazes de

se auto-organizar dentro da topologia da rede com o intuito de compartilhar

recursos tais como conteudo, capacidade de armazenamento, ciclos de CPU

e largura de banda. E importante ressaltar que elas formam um tipo de rede

virtual (overlay) com suas proprias regras de roteamento, onde sao capazes

de se adaptar a falhas e a populacoes transitorias de nodos enquanto mantem

uma aceitavel conectividade e desempenho, sem o requerimento de intermedio

ou suporte de um servidor ou autoridade global.

15

Capıtulo 3

O Nutch

Nutch e o inıcio de um esforco para implementar um sistema de loca-

lizacao na web com codigo-fonte aberto desenvolvido pela Apache Software

Foundation. Construıdo no topo do Lucene [11], o Nutch aborda todas as

ferramentas que um motor de busca possui, podendo ser utilizado tanto na

Internet quanto em uma Intranet ou ainda no sistema de arquivos local de

um computador. Dentre as suas principais caracterısticas, o Nutch oferece:

transparencia na pesquisa web, suporte a alto trafego de rede e escalabilidade

para bilhoes de paginas.

O Nutch e uma alternativa transparente aos sistemas comerciais de loca-

lizacao na web. Somente os resultados gerados por sistemas de localizacao

feitos com codigo-fonte aberto podem ser inteiramente confiaveis quanto a

nao serem direcionados (ou, ao menos, sua orientacao e publica). Todos os

principais sistemas de localizacao existentes tem formulas de ranking proprias

e nao vao explicar porque foi dado um ranking a um determinado resultado.

Alem disso, alguns sistemas de localizacao determinam em que locais posi-

16

cionar os resultados baseados mais em pagamentos do que nos meritos deles

mesmos.

3.1 Arquitetura do Nutch

O Nutch divide-se em duas partes: o aranha (crawler) e o buscador (se-

archer). O aranha captura as paginas e as converte em um ındice invertido,

que o buscador usa para responder as consultas realizadas pelos usuarios. A

interface existente entre essas duas partes e o ındice (index ). O buscador

precisa acessar os segmentos descritos abaixo com a finalidade de produzir

os sumarios e fornecer acesso ao cache das paginas.

O ponto principal deste modelo e que os sistemas do aranha e do buscador

podem ser implantados em plataformas separadas. Por exemplo uma pagina

de busca com um alto trafego que fornece pesquisa para um modesto conjunto

de sites pode necessitar apenas de um modesto investimento correspondente

na infraestrutura do aranha, enquanto necessitara mais recursos substanciais

para o buscador.

Como mostra a Figura 3.1, o Nutch utiliza um meio persistente de arma-

zenamento, chamado de webDB, onde o conteudo das paginas sao guardadas,

bem como as listas de busca. A cada atualizacao dos conteudos as listas de

buscas tambem sao atualizadas. Estes conteudos sao utilizados pelos inde-

xadores que irao gerar os ındices invertidos das paginas. Os pesquisadaroes

sao elementos que irao realizar as consultas dentro dos ındices e irao devolver

para o motor de busca o resultado da pesquisa, que na figura em questao esta

representado como o servidor web.

17

Figura 3.1: Arquitetura do Nutch

18

3.1.1 Banco de dados

O Nutch usa um banco de dados proprio que e dividido nas seguintes

partes:

• Banco de dados do Aranha: Contem informacoes sobre as URLs

conhecidas pelo Nutch.

• Banco de dados de links: Armazena a lista de links conhecidos para

cada URL.

• Banco de dados de indexes: Contem os indexes no formato estabe-

lecido pelo Lucene.

• Segmentos: Um conjunto de subdiretorios cada qual contendo URLs

que sao coletadas como uma unidade, de acordo com um determinado

fator.

3.1.2 Aranha

O sistema do aranha e gerenciado pela ferramenta do Nutch crawl, e uma

famılia de ferramentas relacionadas para construir e manter muitos tipos

de estruturas de dados, incluindo a base de dados web, um conjunto de

segmentos, e o ındice.

A base de dados web, ou webDB, e uma estrutura de dados persistente

especializada para fazer o espelhamento da estrutura e propriedades da web

sendo percorrida. Ela mantem a base enquanto a web esta sendo varrida, (e

varrida novamente), o que pode levar meses ou anos. A base de dados web e

usada apenas pelo aranha e nao realiza nenhum outro papel durante a busca.

19

A webDB armazena dois tipos de entidades: paginas e links. Uma pagina

representa uma pagina na web, e e indexada por sua URL e o hash MD5

de seu conteudo. Outras informacoes pertinentes tambem sao armazenadas,

sao elas: o numero de links na pagina (tambem chamados de outlinks); in-

formacoes de busca (tal como quando a pagina deve ser buscada novamente);

e o score da pagina, que e uma medida de quanto a pagina e importante (por

exemplo, uma medida de importancia pontua com alto score paginas que sao

ligadas de muitas outras paginas). Um link representa uma ligacao de uma

pagina web (a fonte) para outra (o destino). No grafo da webDB, os nodos

sao paginas e as arestas sao links.

Um segmento e uma colecao de paginas buscadas e indexadas pelo aranha

em uma simples execucao. A lista de busca para um segmento e uma lista

de URLs para o aranha buscar, e e gerada a partir da webDB. A saıda do

buscador e o dado recuperado a partir das paginas na lista de busca. A saıda

do buscador para o segmento e indexado e o ındice e armazenado no seg-

mento. Qualquer segmento tem um ciclo de vida limitado, pois suas paginas

sao buscadas novamente dentro de um intervalo de tempo. O intervalo de

tempo padrao para refazer uma busca e de 30 dias, portanto os segmentos

mais antigos do que isto devem ser apagados, particularmente porque eles

ocupam muito espaco em disco. Os segmentos sao nomeados pela data e

hora em que eles foram criados, por isso e facil ver o quanto eles sao antigos.

O ındice e o ındice invertido de todas as paginas que o sistema recuperou

e e criado pela mesclagem de todos os ındices dos segmentos individualmente.

O Nutch usa o lucene[11] em seu sistema de indexacao, portanto todas as

ferramentas e APIs (Application Programming Interfaces) estao disponıveis

20

para interagir com o ındice gerado.

Funcionamento do Aranha

A varredura realizada pelo aranha e um processo cıclico: e gerada uma

colecao de listas de buscas a partir da webDB, uma colecao de buscadores

resgata os conteudos das paginas web, o aranha atualiza a webDB com novos

links que foram encontrados e entao gera um novo conjunto de listas de

busca para os links que nao foram capturados ainda em um dado perıodo,

incluindo os novos links encontrados no ciclo anterior e o ciclo se repete.

Este ciclo e frequentemente referido como ciclo gerar/buscar/atualizar e roda

periodicamente tanto quanto se deseje manter o ındice de busca atualizado.

URLs com o mesmo host sao sempre associados a mesma lista de busca.

Isto e feito por razoes de clareza, portanto um site da Internet nao e sobrecar-

regado com requisicoes vindas de multiplos buscadores em rapidas sucessoes.

O Nutch observa o protocolo de exclusao de robos (Robots Exclusion Proto-

col [16]), o que permite que mantenedores controlem quais partes do seu site

podem ser varridas.

A ferramenta do aranha e um front end para outras aplicacoes que rea-

lizam tarefas mais especıficas, portanto e possıvel conseguir os mesmos re-

sultados rodando estas em uma sequencia particular. Abaixo segue uma

discriminacao do que o aranha faz, juntamente com a suas aplicacoes em

baixo nıvel entre parenteses:

1. Criar uma nova webDB (admin db -create).

2. Injetar URLs dentro da webDB (inject).

21

3. Gerar uma lista de busca a partir da webDB em um novo segmento

(generate).

4. Buscar os conteudos das URLs nas listas de busca (fetch).

5. Atualizar a webDB com os links das paginas buscadas (updatedb).

6. Repetir os passos 3-5 ate que a profundidade desejada seja alcancada.

7. Atualizar os segmentos com os scores e links da webDB (updatesegs).

8. Indexar as paginas buscadas (index ).

9. Eliminar conteudo duplicado (e URLs duplicadas) dos ındices (dedup).

10. Mesclar os ındices em um unico ındice para busca (merge).

Depois de criar uma nova webDB (passo 1), o ciclo gerar/buscar/atualizar

(passos 3-6) e inicializado pelo carregamento da webDB com algumas URLs

sementes (passo 2). Quando este ciclo se completa, o aranha ira criar um

ındice de todos os segmentos (passos 7-10). Cada segmento e indexado inde-

pendentemente (passo 8), antes que paginas duplicadas (isto e, paginas com

URLs diferentes mas com o mesmo conteudo) sejam removidas (passo 9).

Finalmente os ındices individuais sao combinados em um unico ındice (passo

10).

A ferramenta dedup pode remover as URLs duplicadas dos ındices dos

segmentos. Isto nao e para remover multiplas buscas da mesma URL por ela

ter sido duplicada na webDB - este fato nao pode acontecer pois a webDB

nao permite entradas de URLs duplicadas. Ao inves disso, duplicatas podem

surgir se uma URL e buscada e o antigo segmento para a busca previa ainda

22

coexistir (visto que ainda nao foi apagada). Esta situacao nao pode aparecer

durante uma simples execucao do aranha, mas sim durante a repeticao de

buscas, por isso a ferramenta dedup garante que URLs duplicadas sejam

removidas.

O aranha e um meio de iniciar a varredura de sites na web, porem sera

necessario utilizar as ferramentas de baixo nıvel para repetir buscas e outros

tipos de manutencao nas estruturas de dados construıdas durante a varredura

inicial.

3.2 Alteracoes realizadas

Foram adicionados alguns pontos de controle em alguns pontos no Nutch,

onde registramos o tamanho das requisicoes e das respostas do servidor.

Para capturar o tamanho das respostas foi alterado algumas linhas da classe

“Fetcher”, onde colocamos o tamanho das paginas baixadas juntamente com

o tamanho dos cabecalhos (Figura A.1 do apendice A).

Para capturar o tamanho das requisicoes, modificamos a classe HttpRes-

ponse do plugin httpclient que e responsavel por obter as paginas da web e

que se encontra dentro do pacote protocol-httpclient (Figura A.2 do apendice

A).

Este plugin foi habilitado no arquivo ”nutch-defaults.xml” na secao ”plu-

gin.includes” (Figura A.3 do apendice A).

Criamos um script para automatizacao das tarefas que foram realizadas.

Este script invoca a classe “Crawl”definindo, por parametros, o diretorio

23

onde se encontra as URLs para injetar nas listas de busca da base, o numero

de threads e o valor para o numero de links por nıvel de profundidade. O

valor padrao para profundidade foi fixado em 10 para a realizacao dos testes.

Apos o termino das tarefas do Nutch, atraves de algumas funcoes, o script

calcula algumas estatısticas, como o total de paginas obtidas, total de paginas

indexadas, total de download, total de upload, tempo de processo, tempo de

indexacao, entre outros.

3.3 Testes realizados com o Nutch

Para efeitos de estudo, realizamos alguns testes de execucao com o Nutch

em tres maquinas diferentes. Escolhemos um conjunto de paginas aleatorio,

retirado do arquivo com diretorios de links do projeto Dmoz [17].

3.3.1 Testes realizados na maquina ]1

O hardware da maquina ]1 e o seguinte:

• AMD Opteron(tm) Processor 242

• Clock 1593.901 MHz

• RAM 4090852KB

Para este conjunto de testes variamos o numero de threads entre 50 e

200. Como resultado dos testes obtivemos os dados que estao representados

na tabela da Figura 3.2. Pode-se constatar que mesmo aumentando em 50 o

numero de threads o tempo diminui em uma media de 15 minutos. O grafico

representado na figura 3.3 demonstra essa variacao.

24

Figura 3.2: Testes realizados na maquina ]1 para 2541 paginas

Figura 3.3: Grafico Threads X Tempo para dados coletados na maquina ]1



• Intel(R) Xeon(TM)

25


• RAM 4151660KB

Para este conjunto de testes variamos o numero de threads entre 400 e

700. Como resultado dos testes obtivemos os dados que estao representados

na tabela da Figura 3.4. Neste teste o numero de threads foi variado em 100,

e o tempo diminuiu em media 8 minutos para cada variacao. Analogamente

ao teste anterior (Figuras 3.2 e 3.3) houve um ganho muito pequeno no tempo

real da execucao, assim como mostra a figura 3.5.

26





• Intel(R) Xeon(R) CPU E5345

27


• RAM 12460760KB

Para este conjunto de testes utilizamos valores entre 800 e 1100 para o

numero de threads. Os resultados estao representados na tabela da figura 3.6.

Novamente o numero de threads foi variado em 100, porem foram utilizados

valores maiores para que o tempo diminuısse de forma consideravel. O tempo

neste caso diminuiu em media 7 minutos, e novamente uma variacao muito

pequena no tempo foi constatada, assim como mostra o grafico da figura 3.7.

28



29

Capıtulo 4

Novo modelo para o aranha: O

Crab

Um motor de busca, geralmente, procura indexar o maximo possıvel de

paginas web em sua base. Os aranhas dos motores de busca sao os res-

ponsaveis pela obtencao das paginas web. Como visto nos capıtulos anterio-

res, esta e uma tarefa que demanda muito tempo. Neste capıtulo propomos

um novo modelo de aranha: O Crab.

O Crab consiste numa arquitetura cliente-servidor, onde o cliente Crab

e um motor de busca e um servidor Crab e um servidor web. O servidor

Crab e um servidor de conteudo de paginas web contidas no servidor web.

Esse servidor fornece todas as paginas do servidor web diretamente para o

cliente Crab. Diferentemente do aranha tradicional, neste modelo, o cliente

nao faz requisicoes HTTP para cada pagina, nem percorre os links contidos

na mesma.

Ao estabelecer contato com um servidor web, o motor de busca encontra-

30

se em uma das seguinte situacoes: ou e o primeiro contato que ele estabelece

com o servidor web, ou ja conhece o mesmo. No primeiro caso, o motor de

busca recebera todas as paginas disponıveis pelo servidor web. No segundo

caso, recebera apenas as paginas que foram atualizadas desde o ultimo con-

tato.

Visando a diminuicao do tamanho das paginas web a serem transferidas, o

Crab pode tirar proveito do processamento local e compactar toda a base do

servidor web, otimizando assim, a transferencia das paginas web ao motor de

busca. Estatistıcamente, ao ser compactado, um arquivo de texto e reduzido

em ate 80% [22]. Esta reducao do tamanho dos arquivos reduz a taxa de

tranferencia e faz com que o tempo tambem diminua.

A figura 4.1 ilustra um modelo da arquitetura do Crab. Nesta figura estao

representados o motor de busca, o servidor web e os tipos de mensagens de

requisicao e respostas existente entre eles.

31

Figura 4.1: Arquitetura do Crab.

Discutiremos nas proximas secoes a respeito dos detalhes do protocolo

proposto, bem como detalhes do funcionamento.

4.1 Protocolo de comunicacao Crab

O Crab e um servidor do conteudo das paginas web contidas dentro de

um servidor web. Seu objetivo e fornecer de uma so vez todas as paginas

web que o servidor tem em sua base. E utilizado o modelo cliente-servidor,

como maioria dos protocolos de rede, funcionando atraves de requisicoes

e respostas. As mensagens de requisicoes sao realizadas pelo cliente Crab

(motor de busca). As mensagens de respostas sao enviadas pelo servidor

Crab (servidor web). Estes dois tipos de mensagens sao baseados em um

32

formato generico definido na RFC 822 [14], que e um padrao para formato

de mensagens de texto e que era o protocolo utilizado para e-mails (antes de

2001) e tambem e um dos protocolos utilizados pelo HTTP.

4.1.1 Formato da mensagem de requisicao

As mensagens consistem de um cabecalho e opcionalmente um corpo. O

cabecalho e formado por simples sequencia de linhas contendo caracteres

ASCII. Cada linha e finalizada pela sequencia dos caracteres CRLF (\r\n).

O cabecalho e separado do corpo atraves de uma linha nula, isto e, sem

precedente a sequencia CRLF

O corpo, pode ser formado por sequencia de caracteres ASCII ou por

uma sequencia binaria (quando as paginas forem compactadas para a trans-

ferencia).

O cabecalho da mensagem de requisicao tem o seguinte formato:

CLIENTE cliente_crab\r\n

CONTATO tipo_de_contato\r\n

FORMATO tipo_formato\r\n

[DATA data_ultimo_contato]\r\n

\r\n

cliente crab: Identificacao do cliente Crab (motor de busca).

tipo de contato: Especifica o tipo de contato que o cliente esta estabele-

cendo com o Crab. O cliente pode estar estabelecendo o primeiro contato com

o servidor (PRIMEIRO) ou estar fazendo um novo contato para atualizar a

sua base (ATUALIZACAO).

33

tipo formato: Especifica se as paginas web serao transmitidas em formato

de texto puro (TEXTO) ou se serao transmitidas compactadas (ZIP).

data ultimo contato: Especifica a data do ultimo contato estabelecido

pelo cliente com o servidor crab. Esta linha e opcional.

Ao enviar uma mensagem de requisicao, o cliente Crab encontra-se em

uma das seguintes situacoes:

• Primeira tentativa de comunicacao com o servidor web.

• Atualizacao da base de dados.

Na primeira situacao, o cliente nao tem conhecimento das paginas web

que o servidor web possui. Neste primeiro contato, e desejavel que o cliente

obtenha todas as paginas disponıveis neste servidor. Neste caso, o cabecalho

da mensagem de requisicao poderia ser da seguinte forma:

CLIENTE nutch\r\n

CONTATO PRIMEIRO\r\n

FORMATO TEXTO

\r\n

O cliente, ao enviar uma linha nula (dupla sequencia de \r\n) indica que

acabou de transmitir o cabecalho, e neste caso, como se trata de um primeiro

contato, significa que terminou de transmitir e agora espera a resposta do

servidor.

Na segunda situacao, o cliente ja possui conhecimento das paginas web

que encontram-se no servidor. Buscando otimizar, o cliente pode passar ao

servidor algumas informacoes das paginas que ja estao armazenadas em sua

34

base de dados. Passando o nome, a data e a hora em que a pagina foi obtida,

o cliente recebera somente as paginas que possuem atualizacao mais recente

que a data passada. Neste caso o a mensagem poderia ser da seguinte forma:

CLIENTE nutch\r\n

CONTATO ATUALIZACAO\r\n

FORMATO ZIP\r\n

DATA <2008/03/10>

\r\n

www.youse.com.br <2008/03/03><13:10>\r\n

www.youse.com.br/contatos.html <2008/03/05><15:57>\r\n

www.youse.com.br/empresa.html <2008/03/04><17:21>\r\n

.*

\r\n

O cliente, ao enviar a primeira linha nula (dupla sequencia de \r\n) indica

que acabou de transmitir o cabecalho. Neste caso, o cabecalho indica que

esta e uma mensagem de atualizacao. Neste tipo de mensagem o cliente deve

enviar o corpo da mensagem. Este contera uma lista das paginas ja obtidas

pelo cliente junto ao servidor Crab. Ao enviar uma linha nula no corpo

da mensagem, o cliente indica que terminou de transmitir e agora espera a

resposta do servidor.

4.1.2 Formato da mensagem de resposta

O Crab pode receber dois tipos de mensagens de requisicao: A de primeiro

contato e a de atualizacao de conteudo. Na mensagem de primeiro contato,

35

o cliente se identifica, avisa que e o primeiro contato e especifica o formato

do corpo da resposta. O Crab entao deve transmitir ao cliente todos os sites

que possui no momento, com excecao das paginas identificadas nos arquivos

robots.txt de cada site.

Na mensagem atualizacao de conteudo, o cliente se identifica, avisa que

quer atualizar a sua base, especifica o formato do corpo da resposta e passa

uma lista das paginas conhecidas junto com a data e a hora em que recebeu

cada arquivo. O Crab entao deve transmitir ao cliente apenas as paginas

que tiverem data de atualizacao mais recente do que a data passada pelo

cliente e as paginas com data de criacao mais recente do que a da ultima

comunicacao.

O formato do cabecalho da resposta e igual para os dois tipos de mensa-

gens de resposta.

HI cliente_crab\r\n

SITES total_sites\r\n

PAGINAS total_paginas\r\n

TAMANHO total_bytes\r\n

\r\n

No corpo da mensagem o servidor Crab transmitira as paginas web para

o cliente. Para cada pagina a ser transferida deve ser especificado o host,

a referencia (dentro do host) e o tamanho do conteudo da pagina. Logo

em seguida e transferido o conteudo da pagina web. Este deve seguir a

especificacao de formato que o cliente informou (texto puro ou zip).

O formato do corpo da mensagem entao e:

36

HOST endereco_host\r\n

HREF: pagina_html\r\n

TAMANHO: tamanho_pagina\r\n

conteudo_da_pagina_no_formato_escolhido\r\n

{repete a estrutura de transmiss~ao da pagina ate acabar as

paginas}

\r\n

Ao enviar uma linha nula, que esteja fora do conteudo das paginas, o

servidor Crab indica que acabou de transmitir. O cliente sabera quando isso

vai ocorrer, pois lhe foi informado no cabecalho da resposta o total de sites,

paginas e o total de bytes. Ao finalizar o corpo da mensagem a conexao e

encerrada.

37

Capıtulo 5

Implementacao e Resultados

Experimentais

Neste capıtulo comparamos um motor de busca tradicional (que utiliza o

aranha) com um motor de busca utilizando o Crab. Descrevemos como foi a

implementacao, a elaboracao dos testes e os resultados obtidos.

5.1 Implementacao

Para o funcionamento do Crab e necessario que tanto um servidor web

quando um motor de busca, implementem o protoclo de comunicacao do

Crab.

Para o servidor web, desenvolvemos um modulo para o Apache que im-

plemente este protocolo. O Apache foi o escolhido por ser um servidor web

open source, robusto, popular e principalmente por sua extensibilidade dada

pelo desenvolvimento de modulos.

38

Sendo um modulo do Apache, o modulo Crab possui acesso as confi-

guracoes locais e livre navegacao pelos diretorios onde estao contidas as

paginas web do servidor Apache. Com isso, o modulo Crab tem a informacao

necessaria para a montar o protocolo de comunicacao. E importante salien-

tar que o modulo Crab, ao menos nesta primeira implementacao, somente

transfere as paginas web estaticas.

Para o motor de busca, desenvolvemos um modulo para o Nutch que

implementa o protocolo de comunicacao do Crab. Este modulo e executado

de maneira similar ao aranha do Nutch, porem deve-se especificar o endereco

de um servidor web, ao inves de uma lista de URLs.

5.1.1 Ambiente

No ambiente para a execucao dos testes, um servidor apache foi prepa-

rado e configurado com o modulo Crab. Para criar uma base de paginas a

serem indexadas, foi desenvolvido o programa GERPA. Este gera paginas

HTML com base num dicionario de palavras (arquivo de palavras do Open

Office - portugues-Brasil). O GERPA gera um site com base nos seguintes

parametros:

• Numero de links por pagina

• Profundidade a partir da primeira pagina

• Numero de bytes mınimo para uma pagina

• Numero de bytes maximo para uma pagina

39

Sites f2a10 f3a7 f3a8 f4a6 f5a5 f6a5

NoLinks 2 3 3 4 5 6Altura 10 7 8 6 5 5Mınimo 4kb 4kb 4kb 4kb 4kb 4kbMaximo 30kb 30kb 30kb 30kb 30kb 30kbTotalpaginas.

2047 3280 9841 5461 3906 9331

Total de paginas no servidor Apache: 33866Tamanho total das paginas: 589MB

Figura 5.1: Sites gerados pelo programa GERPA

O GERPA cria uma arvore com base nos 2 primeiros parametros. O

numero de links por pagina e o numero de filhos por no da arvore, e a

profundidade e a altura desta. Para cada no nesta arvore e gerado uma

pagina com tamanho entre os dois ultimos parametros. A ligacao existente

entre os nos das arvores e convertida entre ligacoes entre as paginas web.

Para o ambiente de execucao foram criados 6 sites com parametros con-

forme a tabela 5.1.1.

Cada site criado foi configurado como um host virtual dentro do Apache.

A estrutura dos sites e das paginas criadas atraves do GERPA, permitem que

o Crawl do Nutch consiga encontrar todas as paginas pertencentes a cada

site.

5.1.2 Plataforma de execucao

Os clientes Nutch e o servidor Crab foram executados em maquinas dentro

de uma Intranet, com link dedicado a 100Mb/s.

Configuracao da maquina do servidor:

• AMD AthlonXP 2400

40

• 512 MB RAM

• HD SEAGATE 5400RPM

Configuracao da maquina do Nutch:

• Intel Centrino Core 2 Duo

• 2 GB RAM

• HD 5400RPM

5.2 Resultados Experimentais

5.2.1 Desempenho do Nutch

O Crawl do Nutch foi executado com AggressiveHeap (opcao do java para

melhor utilizacao dos recursos computacionas em processos de longa execucao),

100 threads, profundidade maxima 10 e limite de nıvel 10000. A tabela 5.2

mostra os resultados obtidos na execucao do Nutch. Na execucao 1 o timeout

(tempo de espera por uma pagina) do Crawl foi de 10 segundos. Na execucao

2, o tempo de timeout foi de 300 segundos (o mesmo tempo de timeout do

Apache). A diferenca dos ajustes dos valores do timeout tinha o objetivo de

fazer com que o aranha do Nutch buscasse todas as paginas disponıveis no

servidor. So que isto custou mais do que o dobro dos tempos medidos.

5.2.2 Desempenho do Crab

O Crab integrado ao Nutch foi executado de duas maneiras: uma obtendo

as paginas em formato texto e outra obtendo as paginas compactadas. Para

41

Execucao 1 2Tempo Real 19:27.96 40:05.46Tempo Usuario 1003.41 s 2309.44 sTempo Sistema 192.76 s 430.07 sTempo Processo 1167.96 s 2405.46 sPorcentagem de CPU 102% 113%Total Download 562MB 620MBTotal indexadas 32842 32842Total paginas 32842 36264

Tempo para buscar 642 seg 1283 segTempo para indexar 488 seg 1042 segTempo para dedup 8 seg 11 segTempo para merge 15 seg 30 seg

*Medidas em tempo real.

Figura 5.2: Resultados obtidos. Nutch com 100 threads.

cada uma delas, realizamos 3 processos de testes. A tabela 5.3 mostra os

resultados obtidos obtendo as paginas em formato texto. A tabela 5.4 mostra

os resultados obtidos obtendo as paginas compactadas.

5.3 Comparacao

Com base nos testes realizados podemos observar a vantagem do Crab

em relacao ao aranha tradicional. Nas execucoes do aranha, observamos

que o mesmo nao conseguiu obter o mesmo numero de paginas web que o

Crab, embora os sites gerados atraves do GERPA fossem adequados aos

seus parametros de execucao. Houve uma grande diferenca de execucao ao

aumentarmos o tempo de time out para o mesmo valor do time out do Apa-

che. Aumentamos esse valor com o intuito de forcar o aranha tradicional a

conseguir obter o mesmo numero de paginas web que o Crab.

42

Execucao 1 2 3Tempo Real 6:05.70 6:08.02 5:32.36Tempo Usuario 111.38 s 111.41 s 111.45 sTempo Sistema 24.47 s 24.84 s 25.25 sTroca de Contexto Invo-luntaria

33299 48389 34550

Troca de Contexto Vo-luntaria

50410 49487 49678

Tempo Processo 365.70 s 368.02 s 332.36 sPorcentagem de CPU 37% 37% 41%Total Download 567,98MB 567,98MB 567,98MBTotal Paginas 33866 33866 33866

Figura 5.3: Resultados obtidos. Crab com transferencia em formato TEXTO.

Execucao 1 2 3Tempo Real 8:04.30 7:34.87 7:34.55Tempo Usuario 47.82 s 79.74 s 78.98 sTempo Sistema 22.16 s 19.63 s 19.02 sTroca de Contexto Invo-luntaria

24382 9065 16222

Troca de Contexto Vo-luntaria

49473 90657 90424

Tempo Processo 484.76 s 454.87 s 454.55 sPorcentagem de CPU 8% 21% 21%Total Download 229,75MB 229,75MB 229,75MBTotal Paginas 33866 33866 33866

Figura 5.4: Resultados obtidos. Crab com transferencia em formato ZIP.

43

No melhor caso de teste obtido com o aranha tradicional, o tempo de

usuario foi 9 vezes e o tempo de sistema foi 7,87 vezes maior se comparado

ao pior caso de teste obtido com o Crab sem compressao das paginas.

Podemos observar ainda que, utilizando o Crab com compressao, conse-

guimos reduzir ainda mais os tempos de usuario e de sistema e a quantidade

de bytes transferidos foi reduzida em 60%.

44

Capıtulo 6

Conclusao

Vimos neste trabalho que os motores de busca web sao de extrema im-

portancia atualmente, pois sem eles, dificilmente encontrarıamos alguma in-

formacao relevante na web. Vimos tambem que apesar dos motores de busca

prover a recuperacao da informacao eficientemente, ha varios desafios a serem

enfrentados.

O aranha, que e uma parte do motor de busca, tem a funcao de percorrer

pagina por pagina contida na web, afim de acessa-las a procura de links e

obter seu conteudo. Vimos que esse processo e bastante custoso, pois para

o aranha conseguir percorrer toda a web, levaria algumas centenas de anos.

Por isso o aranha precisa priorizar as URLs que serao acessadas, utilizando

metricas como qualidade e populariedade em termos de visitas para as URLs.

Foi proposto entao o Crab, sugerindo uma nova alternativa para o aranha.

O Crab tem a proposta de funcionamento completamente diferente dos

aranhas comuns. Este descentraliza o trabalho do aranha, dividindo-o entre

o motor de busca e o servidor web. Sua arquitetura e cliente-servidor, onde

45

o servidor sao os servidores web e os clientes, os motores de busca. Possui

protocolo de comunicacao proprio e, na implementacao realizada ficou limi-

tado a transferir somente as paginas web estaticas. Paginas dinamicas, pdf,

arquivos de audio e video ainda nao sao suportados. Alem de suportar estes

formatos, como um trabalho futuro, podemos sugerir que o o Crab classifi-

que as paginas do servidor Web pelo numero de visitas que recebe, auxiliando

assim o ranqueamento de paginas.

Foram executados testes em ambiente fechado que mostraram a eficiencia

do Crab perante aos aranhas tradicionais. Em alguns casos o Crab chegou

a ser 9 vezes mais eficiente que um motor de busca tradicional. Outro dife-

rencial e a possıvel diminuicao da quantidade de bytes transferidos. O Crab

com transferencia em modo ZIP, reduziu em 60% a quantidade de bytes

transferidos.

Embora nos motores de buscas modernos, os aranhas sejam extrema-

mente otimizados e executados em clusters cada vez maiores, acreditamos

que o modelo do Crab proporcionaria vantagens aos motores de buscas, como

a indexacao de mais sites, reducao de carga nos servidores web e consequen-

temente reducao na transferencia de bytes.

46

Apendice A

Alteracoes realizadas no Nutch

Figura A.1: Alteracoes do arquivo Fetcher.java

47

Figura A.2: Alteracoes realizadas no arquivo HttpResponse.java do plugin

HttpClient

48

Figura A.3: Alteracoes no arquivo de configuracoes do Nutch.

49

Referencias Bibliograficas

[1] Ian Foster and Carl Kesselman (eds), The Grid: Blueprint for a New

Computing Infrastructure, Morgan Kaufmann, July 1998. ISBN 1-55860-

475-8.

[2] SIMS, 2003, http://www2.sims.berkeley.edu/research/projects/how-

much-info-2003/internet.htm

[3] SELF SEO, 2006, http://www.selfseo.com/story-18951.php

[4] IEEE Computer society, 2006, http://www.computer.org/portal/site/

computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&p

Name=computer level1 article&TheCat=1055&path=computer/homep

age/0606&file=thingswork.xml&xsl=article.xsl&;jsessionid=GxXRG9L

BQ30yFn36Pq73g9NT2F2JbWj2psKYXHK2rDQZy3gW6C15!1483256709

[5] HTTP/1.1 Method definitions, http://www.w3.org/Protocols/rfc2616/rfc2

616-sec9.html

[6] How much data does Google store?, www.google.com

[7] Google PageRank, http://pr.efactory.de/

50

[8] How much data does Google store?,

http://googlesystem.blogspot.com/2006/09/how-much-data-does-

google-store.html

[9] A Survey of Peer-To-Peer Content Distribution Technologies, 2004,

STEPHANOS ANDROUTSELLIS-THEOTOKIS AND DIOMIDIS SPI-

NELLIS, Athens University of Economics and Business

[10] Analise de trafego P2P no Backbone da RNP, Simposio brasileiro de

redes, Stenio F. L. Fernandes, Guthemberg S. Silvestre, Kelvin L. Dias,

Joao B. Rocha Jr., Djamel Sadok, Carlos Kamienski1

[11] Apache - Lucene http://lucene.apache.org/

[12] http://today.java.net/pub/a/today/2006/01/10/introduction-to-nutch-

1.html

[13] http://lucene.apache.org/nutch/

[14] Standard for ARPA Internet Text Messages -

http://tools.ietf.org/html/rfc822

[15] Desafios a recuperacao de informacao dis-

tribuıda http://www.dcc.uchile.cl/ ccas-

till/papers/baeza 2007 challenges distributed information retrieval.pdf

[16] Robots Exclusion Protocol

http://www.robotstxt.org/wc/exclusion.html

[17] ODP - Open Directory Project http://www.dmoz.org/

51

[18] YaCy http://yacy.net/

[19] The Minerva Project

http://www.mpi-inf.mpg.de/departments/d5/software/minerva/index.html

[20] Open Search http://www.opensearch.org/Home

[21] Distributed Hash Tables http://www.linuxjournal.com/article/6797

[22] HTTP Compression

http://www.websiteoptimization.com/speed/tweak/compress/

52

Documents

Motores de busca: Uma nova alternativa para o Aranha · uma lista de documentos nos quais as palavras chaves foram encontradas. ... S~ao chamadas de p aginas din^amicas e escritas