TG Acg PDF

Motores de busca: Uma nova
alternativa para o Aranha
Trabalho apresentado na
Universidade Federal do Paraná para obtenção
do grau de Bacharel em Ciência da Computação

Sumário
1 Introdução 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 páginas 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 Alterações realizadas . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Testes realizados com o Nutch . . . . . . . . . . . . . . . . . . 24
3.3.1 Testes realizados na máquina ]1 . . . . . . . . . . . . . 24
1
4 Novo modelo para o aranha: O Crab 30

4.1 Protocolo de comunicação Crab . . . . . . . . . . . . . . . . . 32
4.1.1 Formato da mensagem de requisição . . . . . . . . . . 33
4.1.2 Formato da mensagem de resposta . . . . . . . . . . . 35
5 Implementação e Resultados Experimentais 38

5.1 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.1 Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.2 Plataforma de execução . . . . . . . . . . . . . . . . . 40
5.2 Resultados Experimentais . . . . . . . . . . . . . . . . . . . . 41
5.2.1 Desempenho do Nutch . . . . . . . . . . . . . . . . . . 41
5.2.2 Desempenho do Crab . . . . . . . . . . . . . . . . . . . 41
5.3 Comparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6 Conclusão 45
A Alterações realizadas no Nutch 47
2
Capı́tulo 1
Introdução
A quantidade de informação contida na web vem sofrendo um crescimento

exponencial desde o seu inı́cio. Cada vez mais páginas web, documentos,
imagens, arquivos de audio, entre outros são disponibilizados na Internet. Se
por um lado a quantidade de informação na rede aumenta, a dificuldade de
encontrar uma informação relevante ao assunto desejado também.
A partir da necessidade de pesquisar uma informação na Internet, sur-
gem os motores de busca web (Search Engines), programas que objetivam
principalmente a recuperação de informação 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
máquina local, já seria um tanto quanto lenta, na web é fácil imaginar que
essa pesquisa seria completamente inviável. Atualmente, os motores de busca
são responsáveis por indexar centenas de milhares de páginas web e prover
resultados de forma eficiente.
Os motores de busca web atuais geralmente são compostos por quatro
3
partes distintas: o aranha (spider/crawler) que acessa e percorre os sites
seguindo os links encontrados nas páginas, o indexador (indexer) que processa
as páginas obtidas pelo aranha, o banco de dados (database) que armazena as
páginas processadas pelo indexador e a interface de pesquisa (result engine)
que estabelece o canal de comunicação entre o usuário e o motor de busca.
Este trabalho tem como objetivo oferecer uma nova alternativa para im-
plementação do aranha. Dado que o funcionamento do aranha é bastante
custoso pois necessita percorrer página por página na web, a nova alternativa,
chamada Crab, propõe que o aranha seja distribuı́do pela web e permaneça
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 não 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 introdução 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 comparações 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 são programas que visam a recuperação da in-

formação 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 satisfatória, um motor de busca
necessita desempenhar diversas funções que geralmente são divididas em qua-
tro partes: o aranha, o indexador, o banco de dados e a interface de pesquisa.
Todas as partes serão 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́ responsável por acessar as páginas web e analisá-las a procura

de links. Seu funcionamento pode ser descrito como um processo cı́clico que
inicia-se com uma coleção inicial de URLs (Uniform Resource Locator) a
serem acessadas, resgatando o conteúdo das mesmas e armazenando os links
encontrados em uma lista, que será a base para as novas direções que o aranha
irá seguir. Ao começar a execução o aranha encontra-se na profundidade
zero, ao recomeçar 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 árvore, no qual as URLs
representam os vértices e os links contidos na página web e que são acessados
representam as arestas, como mostra a figura 2.1.
É importante ressaltar que na prática é inviável que o aranha percorra

todas as URLs presentes na lista, percorrendo assim toda a web. Se o ara-
nha baixasse uma página por segundo (considerando a requisição HTTP) e
analisasse-a, seriam vasculhadas 86400 páginas por dia. Em um ano seriam
31.536.000 páginas. Como atualmente estima-se que exista 20 bilhões de
páginas [4], levarı́amos algumas centenas de anos para varrer toda a web.
Portanto é necessário que o aranha priorize as páginas mais relevantes
para serem acessadas, o que requer uma métrica de importância. A im-
portância de uma página é uma função de sua qualidade e de sua populari-
dade em termos de links ou visitas.
6
Figura 2.1: Representação do funcionamento do aranha
O aranha é capaz de analisar diferentes formatos de arquivos (HTML,

PDF, TXT, DOC,...). Quando for acessar uma página, o aranha pode fazer
uma requisição HTTP HEAD [5] para descobrir o formato do arquivo antes
de requisitar a página com uma requisição GET. Desta maneira não há tempo
desperdiçado obtendo arquivos da web que não desejam ser indexados. Uma
estratégia similar compara a extensões das URLs com uma lista de tipos de
páginas web conhecidas (html, asp, aspx, php, jsp, etc).
Alguns aranhas pretendem obter o máximo possı́vel de páginas 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 endereços que normalmente não podem ser encontrados
pelo processo anterior.
Grande quantidade de páginas web somente são acessadas submetendo

consultas a banco de dados ou através da submissão de informação ao servidor
7
web pelo método POST [5]. São chamadas de páginas dinâmicas e escritas
em linguagens de programação como: PHP, Java, ASP, etc. Torna-se então
necessário alguns aranhas especializados para acessar e processar tais páginas
web, visto que os aranhas comuns não são hábeis para essa tarefa pois pode
não haver links apontando para elas.
2.2 Indexador
O indexador recebe e processa as páginas obtidas pelo aranha. Sua função

é destacar cada palavra do site, descartando as mais comuns (por exemplo:
’e’, ’isto’, ’a’, ...). O código HTML também é examinado e faz com que
ajude o site a ser mais facilmente encontrado em uma futura recuperação.
Palavras em negrito, itálico ou tags de cabeçalhos recebem ênfase maior, ou
seja, momento no qual é analisada as meta-informações inseridas no código
HTML do site (palavras chaves e tags de descrição).
Entre os principais tipos de indexadores, o mais utilizado é o ı́ndice inver-
tido (Inverted index). Este é amplamente utilizado por permitir uma rápida
recuperação 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 contém o termo.
Adicionalmente, para cada termo distinto, pode ser armazenado a posição
a qual o termo se encontra (palavra, frase, parágrafo, etc) e um valor que
representa a relevância do mesmo na página web.
Para a construção do ı́ndice invertido é utilizado o algoritmo 1. Conforme
indica o algoritmo, são 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 questão pertence a lista de termos distintos, se
sim, então não há a necessidade de adiciona-lo novamente na lista, portanto
adiciona-se somente a URL na lista de URLs do termo. Caso contrário é
necessário criar um novo campo nas respectivas listas para adicionar o novo
termo e a nova URL.
1 para cada url U encontrada faça

2 para cada termo T na url U faça
3 se T já está armazenado na lista de termos distintos então
4 adiciona U na lista de urls;
5 senão
6 adiciona T na lista de termos distintos;
7 adiciona U na lista de urls;
8 fim
9 fim
10 fim
Algoritmo 1: Algoritmo do ı́ndice invertido
Após processar todas as páginas web, o ı́ndice invertido é armazenado

em mı́dia permanente. Fica evidente, então, que a sua construção custa caro
em termos de requisitos computacionais, mas uma vez construı́do, é possı́vel
extrair resultados de forma eficiente.
A recuperação de informação sobre um ı́ndice invertido se dá através
da intersecção 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 interseção 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́ implementações que armazenam também o conteúdo
da página 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 milhões de documentos, e também assumindo que o tamanho médio 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 comunicação entre o usuário e o motor

de busca. É através da interface que são efetuadas as buscas e obtém-se os
resultados, sendo considerada uma das partes mais importantes de um motor
de busca e foco dos maiores esforços para otimização.
As páginas web resultantes de um motor de busca, (Search Engine Results
Page, SERP) retornadas em resposta a uma pesquisa, normalmente incluem
uma lista de páginas web com seus respectivos tı́tulos, um link para a página,
e uma curta descrição mostrando onde as palavras chaves “casaram”com o
conteúdo dentro da página. Uma SERP pode referir-se à uma simples página
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
freqüentes e exibem o conteúdo em cache ao invés 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 páginas e
possivelmente para alterar o ranking das páginas na SERP. As atualizações
das SERPs podem levar muitos dias ou semanas o que pode causar uma im-
precisão 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, definições, ou refinamentos de sugestões de busca. A maioria
dos sistemas de busca também 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 também pode ser responsável pelo ranqueamento
das páginas. Ela determina as melhoras páginas que “casam”com a busca
feita pelo usuário 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 páginas web
Em uma rede como a Internet, na qual o ambiente é completamente hete-

rogêneo, a qualidade e a relevância da informação contida na mesma pode va-
riar absurdamente. A partir dessa diversidade torna-se necessário a criação de
um meio que tenha por função filtrar automaticamente os resultados busca-
dos, retornando assim documentos web que estejam o mais próximo possı́vel
dentro do escopo da pesquisa. Tem-se inı́cio então o ranking de documentos
web, ou seja, uma pré-avaliação e posterior qualificação do documento.
Dentre os métodos mais famosos de ranqueamento está o PageRank [7]
da Google, que entre outros fatores é um dos responsáveis por tornar o motor
de busca da mesma o mais utilizado da web.
Ao contrário de simplesmente usar o conceito da popularidade do link, o
qual vários tipos de ranqueamento o fazem, o PageRank utiliza um conceito
mais democrático, sendo a classificação dos documentos web efetuada pela
própria Internet e não por usuários. A classificação se faz através do número
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 também considera que quanto mais alto for a colocação do
documento web no Ranking, maior o valor do seu voto.
Outros exemplos de otimização de motor de busca são aqueles especi-
alizados em pesquisa de imagens, em pesquisa local (evolução das páginas
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 implementação de motores de busca. O conceito de distribuido em
questão não 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 implementação.
Existem várias implementações disponibilizadas na Internet tais como
YaCy [18], Minerva [19], OpenSearch [20], entre outros. Cada qual com suas
particularidades e vantagens. No entanto, não há nenhuma implementação
que consiga erradicar todos os desafios que um motor de busca necessite
enfrentar. Entre os principais desafios encontrados atualmente estão: au-
mentar a relevância do conteúdo buscado, diminuir a grande latência na
atualização das páginas web já indexadas, indexar completamente a web e
indexar páginas web dinâmicas.
No motor de busca distribuı́do, as tarefas básicas executadas (acessar,
indexar e recuperar páginas web) são 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 são:
No aranha: Acessar e processar as páginas web eficientemente no cenário

dinâmico da web, visando minimizar a taxa de requisições GET aos
servidores web e encontrar peers confiáveis na rede para executarem a
função 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 número possı́vel de partições para fornecer o maior número
de documentos relevantes. É necessário também definir uma estratégia
para balancear a carga de buscas, redirecionando-as para diferentes
peers.
Na interface de busca: Lidar com problemas de roteamento (geralmente

são utilizadas DHTs [21] como tabelas de roteamento). Em particular,
com o roteamento de consultas. É importante também saber manipular
falhas, como por exemplo: quando um peer encontra-se desconectado.
Para tal são usadas técnicas de replicação, as quais aumentam a dispo-
nibilidade de informação na rede.
Para estabelecer a comunicação entre esses peers é utilizada a arquitetura

das redes peer-to-peer[9].
14
2.6.1 Peer-to-peer
Freqüentemente chamada de P2P, consiste em um tipo de rede a qual

cada estação de trabalho tem capacidades e responsabilidades equivalen-
tes (eqüipotência entre os nodos), fazendo com que os peers tenham uma
interação direta. Podemos caracterizar peer-to-peer como uma classe de
aplicações que tomam vantagens de diversos recursos como armazenamento
e conteúdo, disponı́veis nas mais diversas bordas da Internet. Isto difere das
arquiteturas cliente-servidor, nas quais alguns computadores (servidores) são
dedicados a servir outros (clientes).
As redes P2P são sistemas distribı́dos tipicamente usados para interligar
uma grande quantidade de nodos (através de conexões ad hoc) capazes de
se auto-organizar dentro da topologia da rede com o intuito de compartilhar
recursos tais como conteúdo, capacidade de armazenamento, ciclos de CPU
e largura de banda. É importante ressaltar que elas formam um tipo de rede
virtual (overlay) com suas próprias regras de roteamento, onde são capazes
de se adaptar a falhas e a populações transitórias de nodos enquanto mantem
uma aceitável conectividade e desempenho, sem o requerimento de intermédio
ou suporte de um servidor ou autoridade global.
15
Capı́tulo 3
O Nutch
Nutch é o inı́cio de um esforço para implementar um sistema de loca-

lização na web com código-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:
transparência na pesquisa web, suporte a alto tráfego de rede e escalabilidade
para bilhões de páginas.
O Nutch é uma alternativa transparente aos sistemas comerciais de loca-
lização na web. Somente os resultados gerados por sistemas de localização
feitos com código-fonte aberto podem ser inteiramente confiáveis quanto a
não serem direcionados (ou, ao menos, sua orientação é pública). Todos os
principais sistemas de localização existentes têm fórmulas de ranking próprias
e não vão explicar porque foi dado um ranking a um determinado resultado.
Além disso, alguns sistemas de localização determinam em que locais posi-
16
cionar os resultados baseados mais em pagamentos do que nos méritos 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 páginas e as converte em um ı́ndice invertido,
que o buscador usa para responder as consultas realizadas pelos usuários. 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 sumários e fornecer acesso ao cache das páginas.
O ponto principal deste modelo é que os sistemas do aranha e do buscador
podem ser implantados em plataformas separadas. Por exemplo uma página
de busca com um alto tráfego 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 conteúdo das páginas são guardadas,
bem como as listas de busca. A cada atualização dos conteúdos as listas de
buscas também são atualizadas. Estes conteúdos são utilizados pelos inde-
xadores que irão gerar os ı́ndices invertidos das páginas. Os pesquisadaroes
são elementos que irão realizar as consultas dentro dos ı́ndices e irão devolver
para o motor de busca o resultado da pesquisa, que na figura em questão 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 próprio que é dividido nas seguintes

partes:
• Banco de dados do Aranha: Contém informações 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: Contém os indexes no formato estabe-

lecido pelo Lucene.
• Segmentos: Um conjunto de subdiretórios cada qual contendo URLs

que são 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 mantém 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 não realiza nenhum outro papel durante a busca.
19
A webDB armazena dois tipos de entidades: páginas e links. Uma página
representa uma página na web, e é indexada por sua URL e o hash MD5
de seu conteúdo. Outras informações pertinentes também são armazenadas,
são elas: o número de links na página (também chamados de outlinks); in-
formações de busca (tal como quando a página deve ser buscada novamente);
e o score da página, que é uma medida de quanto a página é importante (por
exemplo, uma medida de importância pontua com alto score páginas que são
ligadas de muitas outras páginas). Um link representa uma ligação de uma
página web (a fonte) para outra (o destino). No grafo da webDB, os nodos
são páginas e as arestas são links.
Um segmento é uma coleção de páginas buscadas e indexadas pelo aranha
em uma simples execução. 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 páginas 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 páginas
são buscadas novamente dentro de um intervalo de tempo. O intervalo de
tempo padrão para refazer uma busca é de 30 dias, portanto os segmentos
mais antigos do que isto devem ser apagados, particularmente porque eles
ocupam muito espaço em disco. Os segmentos são nomeados pela data e
hora em que eles foram criados, por isso é fácil ver o quanto eles são antigos.
O ı́ndice é o ı́ndice invertido de todas as páginas 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 indexação, portanto todas as
ferramentas e APIs (Application Programming Interfaces) estão 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

coleção de listas de buscas a partir da webDB, uma coleção de buscadores
resgata os conteúdos das páginas web, o aranha atualiza a webDB com novos
links que foram encontrados e então gera um novo conjunto de listas de
busca para os links que não foram capturados ainda em um dado perı́odo,
incluindo os novos links encontrados no ciclo anterior e o ciclo se repete.
Este ciclo é freqüentemente referido como ciclo gerar/buscar/atualizar e roda
periodicamente tanto quanto se deseje manter o ı́ndice de busca atualizado.
URLs com o mesmo host são sempre associados à mesma lista de busca.
Isto é feito por razões de clareza, portanto um site da Internet não é sobrecar-
regado com requisições vindas de multiplos buscadores em rápidas sucessões.
O Nutch observa o protocolo de exclusão de robôs (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 aplicações que rea-
lizam tarefas mais especı́ficas, portanto é possı́vel conseguir os mesmos re-
sultados rodando estas em uma seqüência particular. Abaixo segue uma
discriminação do que o aranha faz, juntamente com a suas aplicações em
baixo nı́vel entre parênteses:
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 conteúdos das URLs nas listas de busca (fetch).
5. Atualizar a webDB com os links das páginas buscadas (updatedb).
6. Repetir os passos 3-5 até que a profundidade desejada seja alcançada.
7. Atualizar os segmentos com os scores e links da webDB (updatesegs).
8. Indexar as páginas buscadas (index ).
9. Eliminar conteúdo duplicado (e URLs duplicadas) dos ı́ndices (dedup).
10. Mesclar os ı́ndices em um único ı́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 páginas duplicadas (isto é, páginas com
URLs diferentes mas com o mesmo conteúdo) sejam removidas (passo 9).
Finalmente os ı́ndices individuais são combinados em um único ı́ndice (passo
10).
A ferramenta dedup pode remover as URLs duplicadas dos ı́ndices dos
segmentos. Isto não é para remover múltiplas buscas da mesma URL por ela
ter sido duplicada na webDB - este fato não pode acontecer pois a webDB
não permite entradas de URLs duplicadas. Ao invés disso, duplicatas podem
surgir se uma URL é buscada e o antigo segmento para a busca prévia ainda
22
coexistir (visto que ainda não foi apagada). Esta situação não pode aparecer
durante uma simples execução do aranha, mas sim durante a repetição 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, porém será
necessário utilizar as ferramentas de baixo nı́vel para repetir buscas e outros
tipos de manutenção nas estruturas de dados construı́das durante a varredura
inicial.
3.2 Alterações realizadas
Foram adicionados alguns pontos de controle em alguns pontos no Nutch,

onde registramos o tamanho das requisições e das respostas do servidor.
Para capturar o tamanho das respostas foi alterado algumas linhas da classe
“Fetcher”, onde colocamos o tamanho das páginas baixadas juntamente com
o tamanho dos cabeçalhos (Figura A.1 do apêndice A).
Para capturar o tamanho das requisicoes, modificamos a classe HttpRes-
ponse do plugin httpclient que é responsável por obter as páginas da web e
que se encontra dentro do pacote protocol-httpclient (Figura A.2 do apêndice
A).
Este plugin foi habilitado no arquivo ”nutch-defaults.xml” na seção ”plu-
gin.includes” (Figura A.3 do apêndice A).
Criamos um script para automatização das tarefas que foram realizadas.

Este script invoca a classe “Crawl”definindo, por parâmetros, o diretório
23
onde se encontra as URLs para injetar nas listas de busca da base, o número
de threads e o valor para o número de links por nı́vel de profundidade. O
valor padrão para profundidade foi fixado em 10 para a realização dos testes.
Após o término das tarefas do Nutch, através de algumas funções, o script
calcula algumas estatı́sticas, como o total de páginas obtidas, total de páginas
indexadas, total de download, total de upload, tempo de processo, tempo de
indexação, entre outros.
3.3 Testes realizados com o Nutch
Para efeitos de estudo, realizamos alguns testes de execução com o Nutch

em três máquinas diferentes. Escolhemos um conjunto de páginas aleatório,
retirado do arquivo com diretórios de links do projeto Dmoz [17].
3.3.1 Testes realizados na máquina ]1
O hardware da máquina ]1 é o seguinte:
• AMD Opteron(tm) Processor 242
• Clock 1593.901 MHz
• RAM 4090852KB
Para este conjunto de testes variamos o número de threads entre 50 e

200. Como resultado dos testes obtivemos os dados que estão representados
na tabela da Figura 3.2. Pode-se constatar que mesmo aumentando em 50 o
número de threads o tempo diminui em uma média de 15 minutos. O gráfico
representado na figura 3.3 demonstra essa variação.
24
Figura 3.2: Testes realizados na máquina ]1 para 2541 páginas
Figura 3.3: Grafico Threads X Tempo para dados coletados na máquina ]1
• Intel(R) Xeon(TM)
25
• RAM 4151660KB
Para este conjunto de testes variamos o número de threads entre 400 e

700. Como resultado dos testes obtivemos os dados que estão representados
na tabela da Figura 3.4. Neste teste o número de threads foi variado em 100,
e o tempo diminuiu em média 8 minutos para cada variação. Analogamente
ao teste anterior (Figuras 3.2 e 3.3) houve um ganho muito pequeno no tempo
real da execução, assim como mostra a figura 3.5.
26
Figura 3.5: Gráfico Threads X Tempo para dados coletados na máquina ]2
• Intel(R) Xeon(R) CPU E5345
27
• RAM 12460760KB
Para este conjunto de testes utilizamos valores entre 800 e 1100 para o
número de threads. Os resultados estão representados na tabela da figura 3.6.
Novamente o número de threads foi variado em 100, porém foram utilizados
valores maiores para que o tempo diminuı́sse de forma considerável. O tempo
neste caso diminuiu em média 7 minutos, e novamente uma variação muito
pequena no tempo foi constatada, assim como mostra o gráfico da figura 3.7.
28
Figura 3.7: Gráfico Threads X Tempo para dados coletados na máquina ]3
29
Capı́tulo 4
Novo modelo para o aranha: O

Crab
Um motor de busca, geralmente, procura indexar o máximo possı́vel de

páginas web em sua base. Os aranhas dos motores de busca são os res-
ponsáveis pela obtenção das páginas 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 conteúdo de páginas web contidas no servidor web.
Esse servidor fornece todas as páginas do servidor web diretamente para o
cliente Crab. Diferentemente do aranha tradicional, neste modelo, o cliente
não faz requisições HTTP para cada página, 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 situações: 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 páginas disponı́veis pelo servidor web. No segundo
caso, receberá apenas as páginas que foram atualizadas desde o último con-
tato.
Visando a diminuição do tamanho das páginas web a serem transferidas, o
Crab pode tirar proveito do processamento local e compactar toda a base do
servidor web, otimizando assim, a transferência das páginas web ao motor de
busca. Estatistı́camente, ao ser compactado, um arquivo de texto é reduzido
em até 80% [22]. Esta redução do tamanho dos arquivos reduz a taxa de
tranferência e faz com que o tempo também diminua.
A figura 4.1 ilustra um modelo da arquitetura do Crab. Nesta figura estão
representados o motor de busca, o servidor web e os tipos de mensagens de
requisição e respostas existente entre eles.
31
Figura 4.1: Arquitetura do Crab.
Discutiremos nas próximas seções a respeito dos detalhes do protocolo

proposto, bem como detalhes do funcionamento.
4.1 Protocolo de comunicação Crab
O Crab é um servidor do conteúdo das páginas web contidas dentro de

um servidor web. Seu objetivo é fornecer de uma só vez todas as páginas
web que o servidor tem em sua base. É utilizado o modelo cliente-servidor,
como maioria dos protocolos de rede, funcionando através de requisições
e respostas. As mensagens de requisições são realizadas pelo cliente Crab
(motor de busca). As mensagens de respostas são enviadas pelo servidor
Crab (servidor web). Estes dois tipos de mensagens são baseados em um
32
formato genérico definido na RFC 822 [14], que é um padrão para formato
de mensagens de texto e que era o protocolo utilizado para e-mails (antes de
2001) e também é um dos protocolos utilizados pelo HTTP.
4.1.1 Formato da mensagem de requisição
As mensagens consistem de um cabeçalho e opcionalmente um corpo. O

cabeçalho é formado por simples sequência de linhas contendo caracteres
ASCII. Cada linha é finalizada pela sequência dos caracteres CRLF (\r\n).
O cabeçalho é separado do corpo através de uma linha nula, isto é, sem
precedente à sequência CRLF
O corpo, pode ser formado por sequência de caracteres ASCII ou por
uma sequência binária (quando as páginas forem compactadas para a trans-
ferência).
O cabeçalho da mensagem de requisição 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: Identificação 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 páginas web serão transmitidas em formato
de texto puro (TEXTO) ou se serão transmitidas compactadas (ZIP).
data ultimo contato: Especifica a data do último contato estabelecido
pelo cliente com o servidor crab. Esta linha é opcional.
Ao enviar uma mensagem de requisição, o cliente Crab encontra-se em
uma das seguintes situações:
• Primeira tentativa de comunicação com o servidor web.
• Atualização da base de dados.
Na primeira situação, o cliente não tem conhecimento das páginas web

que o servidor web possui. Neste primeiro contato, é desejável que o cliente
obtenha todas as páginas disponı́veis neste servidor. Neste caso, o cabeçalho
da mensagem de requisição 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 sequência de \r\n) indica que
acabou de transmitir o cabeçalho, e neste caso, como se trata de um primeiro
contato, significa que terminou de transmitir e agora espera a resposta do
servidor.
Na segunda situação, o cliente já possui conhecimento das páginas web
que encontram-se no servidor. Buscando otimizar, o cliente pode passar ao
servidor algumas informações das páginas que já estão armazenadas em sua
34
base de dados. Passando o nome, a data e a hora em que a página foi obtida,
o cliente receberá somente as páginas que possuem atualização 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 sequência de \r\n) indica

que acabou de transmitir o cabeçalho. Neste caso, o cabeçalho indica que
esta é uma mensagem de atualização. Neste tipo de mensagem o cliente deve
enviar o corpo da mensagem. Este conterá uma lista das páginas 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 requisição: A de primeiro

contato e a de atualização de conteúdo. 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 então deve transmitir ao cliente todos os sites
que possui no momento, com exceção das páginas identificadas nos arquivos
robots.txt de cada site.
Na mensagem atualização de conteúdo, o cliente se identifica, avisa que
quer atualizar a sua base, especifica o formato do corpo da resposta e passa
uma lista das páginas conhecidas junto com a data e a hora em que recebeu
cada arquivo. O Crab então deve transmitir ao cliente apenas as páginas
que tiverem data de atualização mais recente do que a data passada pelo
cliente e as páginas com data de criação mais recente do que a da última
comunicação.
O formato do cabeçalho 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 páginas web para

o cliente. Para cada página a ser transferida deve ser especificado o host,
a referência (dentro do host) e o tamanho do conteúdo da página. Logo
em seguida é transferido o conteúdo da página web. Este deve seguir a
especificação de formato que o cliente informou (texto puro ou zip).
O formato do corpo da mensagem então 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 página até acabar as
páginas}
\r\n
Ao enviar uma linha nula, que esteja fora do conteúdo das páginas, o
servidor Crab indica que acabou de transmitir. O cliente saberá quando isso
vai ocorrer, pois lhe foi informado no cabeçalho da resposta o total de sites,
páginas e o total de bytes. Ao finalizar o corpo da mensagem a conexão é
encerrada.
37
Capı́tulo 5
Implementação 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
implementação, a elaboração dos testes e os resultados obtidos.
5.1 Implementação
Para o funcionamento do Crab é necessário que tanto um servidor web

quando um motor de busca, implementem o protoclo de comunicação do
Crab.
Para o servidor web, desenvolvemos um módulo 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 módulos.
38
Sendo um módulo do Apache, o módulo Crab possui acesso as confi-
gurações locais e livre navegação pelos diretórios onde estão contidas as
páginas web do servidor Apache. Com isso, o módulo Crab tem a informação
necessária para a montar o protocolo de comunicação. É importante salien-
tar que o módulo Crab, ao menos nesta primeira implementação, somente
transfere as páginas web estáticas.
Para o motor de busca, desenvolvemos um módulo para o Nutch que
implementa o protocolo de comunicação do Crab. Este módulo é executado
de maneira similar ao aranha do Nutch, porém deve-se especificar o endereço
de um servidor web, ao invés de uma lista de URLs.
5.1.1 Ambiente
No ambiente para a execução dos testes, um servidor apache foi prepa-

rado e configurado com o módulo Crab. Para criar uma base de páginas a
serem indexadas, foi desenvolvido o programa GERPA. Este gera páginas
HTML com base num dicionário de palavras (arquivo de palavras do Open
Office - português-Brasil). O GERPA gera um site com base nos seguintes
parâmetros:
• Número de links por página
• Profundidade a partir da primeira página
• Número de bytes mı́nimo para uma página
• Número de bytes máximo para uma página
39
Sites f2a10 f3a7 f3a8 f4a6 f5a5 f6a5
NoL̇inks 2 3 3 4 5 6
Altura 10 7 8 6 5 5
Mı́nimo 4kb 4kb 4kb 4kb 4kb 4kb
Máximo 30kb 30kb 30kb 30kb 30kb 30kb
Total 2047 3280 9841 5461 3906 9331
páginas.
Total de páginas no servidor Apache: 33866
Tamanho total das páginas: 589MB
Figura 5.1: Sites gerados pelo programa GERPA
O GERPA cria uma árvore com base nos 2 primeiros parâmetros. O

número de links por página é o número de filhos por nó da árvore, e a
profundidade é a altura desta. Para cada nó nesta árvore é gerado uma
página com tamanho entre os dois últimos parâmetros. A ligação existente
entre os nós das árvores é convertida entre ligações entre as páginas web.
Para o ambiente de execução foram criados 6 sites com parâmetros 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 páginas criadas através do GERPA, permitem que
o Crawl do Nutch consiga encontrar todas as páginas pertencentes a cada
site.
5.1.2 Plataforma de execução
Os clientes Nutch e o servidor Crab foram executados em máquinas dentro

de uma Intranet, com link dedicado a 100Mb/s.
Configuração da máquina do servidor:
• AMD AthlonXP 2400
40
• 512 MB RAM
• HD SEAGATE 5400RPM
Configuração da máquina 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 (opção do java para

melhor utilização dos recursos computacionas em processos de longa execução),
100 threads, profundidade máxima 10 e limite de nı́vel 10000. A tabela 5.2
mostra os resultados obtidos na execução do Nutch. Na execução 1 o timeout
(tempo de espera por uma página) do Crawl foi de 10 segundos. Na execução
2, o tempo de timeout foi de 300 segundos (o mesmo tempo de timeout do
Apache). A diferença dos ajustes dos valores do timeout tinha o objetivo de
fazer com que o aranha do Nutch buscasse todas as páginas 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 páginas em formato texto e outra obtendo as páginas compactadas. Para
41
Execução 1 2
Tempo Real 19:27.96 40:05.46
Tempo Usuário 1003.41 s 2309.44 s
Tempo Sistema 192.76 s 430.07 s
Tempo Processo 1167.96 s 2405.46 s
Porcentagem de CPU 102% 113%
Total Download 562MB 620MB
Total indexadas 32842 32842
Total páginas 32842 36264
Tempo para buscar 642 seg 1283 seg
Tempo para indexar 488 seg 1042 seg
Tempo para dedup 8 seg 11 seg
Tempo 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 páginas em formato texto. A tabela 5.4 mostra
os resultados obtidos obtendo as páginas compactadas.
5.3 Comparação
Com base nos testes realizados podemos observar a vantagem do Crab

em relação ao aranha tradicional. Nas execuções do aranha, observamos
que o mesmo não conseguiu obter o mesmo número de páginas web que o
Crab, embora os sites gerados através do GERPA fossem adequados aos
seus parâmetros de execução. Houve uma grande diferença de execução ao
aumentarmos o tempo de time out para o mesmo valor do time out do Apa-
che. Aumentamos esse valor com o intuito de forçar o aranha tradicional a
conseguir obter o mesmo número de páginas web que o Crab.
42
Execução 1 2 3
Tempo Real 6:05.70 6:08.02 5:32.36
Tempo Usuário 111.38 s 111.41 s 111.45 s
Tempo Sistema 24.47 s 24.84 s 25.25 s
Troca de Contexto Invo- 33299 48389 34550
luntária
Troca de Contexto Vo- 50410 49487 49678
luntária
Tempo Processo 365.70 s 368.02 s 332.36 s
Porcentagem de CPU 37% 37% 41%
Total Download 567,98MB 567,98MB 567,98MB
Total Páginas 33866 33866 33866
Figura 5.3: Resultados obtidos. Crab com transferência em formato TEXTO.
Execução 1 2 3
Tempo Real 8:04.30 7:34.87 7:34.55
Tempo Usuário 47.82 s 79.74 s 78.98 s
Tempo Sistema 22.16 s 19.63 s 19.02 s
Troca de Contexto Invo- 24382 9065 16222
luntária
Troca de Contexto Vo- 49473 90657 90424
luntária
Tempo Processo 484.76 s 454.87 s 454.55 s
Porcentagem de CPU 8% 21% 21%
Total Download 229,75MB 229,75MB 229,75MB
Total Páginas 33866 33866 33866
Figura 5.4: Resultados obtidos. Crab com transferência em formato ZIP.
43
No melhor caso de teste obtido com o aranha tradicional, o tempo de
usuário 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 compressão das páginas.
Podemos observar ainda que, utilizando o Crab com compressão, conse-
guimos reduzir ainda mais os tempos de usuário e de sistema e a quantidade
de bytes transferidos foi reduzida em 60%.
44
Capı́tulo 6
Conclusão
Vimos neste trabalho que os motores de busca web são de extrema im-
portância atualmente, pois sem eles, dificilmente encontrarı́amos alguma in-
formação relevante na web. Vimos também que apesar dos motores de busca
prover a recuperação da informação eficientemente, há vários desafios a serem
enfrentados.
O aranha, que é uma parte do motor de busca, tem a função de percorrer
página por página contida na web, afim de acessa-las a procura de links e
obter seu conteúdo. 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 serão acessadas, utilizando
métricas como qualidade e populariedade em termos de visitas para as URLs.
Foi proposto então 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 são os servidores web e os clientes, os motores de busca. Possui
protocolo de comunicação próprio e, na implementação realizada ficou limi-
tado a transferir somente as páginas web estáticas. Páginas dinâmicas, pdf,
arquivos de audio e video ainda não são suportados. Além de suportar estes
formatos, como um trabalho futuro, podemos sugerir que o o Crab classifi-
que as páginas do servidor Web pelo número de visitas que recebe, auxiliando
assim o ranqueamento de páginas.
Foram executados testes em ambiente fechado que mostraram a eficiência
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 diminuição da quantidade de bytes transferidos. O Crab
com transferência 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 indexação de mais sites, redução de carga nos servidores web e consequen-
temente redução na transferência de bytes.
46
Apêndice A
Alterações realizadas no Nutch
Figura A.1: Alterações do arquivo Fetcher.java
47
Figura A.2: Alterações realizadas no arquivo HttpResponse.java do plugin
HttpClient
48
Figura A.3: Alterações no arquivo de configurações do Nutch.
49
Referências Bibliográficas
[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] Análise de tráfego P2P no Backbone da RNP, Simpósio brasileiro de

redes, Stênio F. L. Fernandes, Guthemberg S. Silvestre, Kelvin L. Dias,
João 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 recuperação de informação 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

TG Acg PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TG Acg PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Motores de busca: Uma nova

alternativa para o Aranha

Universidade Federal do Paraná para obtenção

do grau de Bacharel em Ciência da Computação

2 Motores de busca web 5

4 Novo modelo para o aranha: O Crab 30

5 Implementação e Resultados Experimentais 38

A Alterações realizadas no Nutch 47

A quantidade de informação contida na web vem sofrendo um crescimento

Motores de busca web

Os motores de busca web são programas que visam a recuperação da in-

O aranha é responsável por acessar as páginas web e analisá-las a procura

É importante ressaltar que na prática é inviável que o aranha percorra

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

Alguns aranhas pretendem obter o máximo possı́vel de páginas de um

Grande quantidade de páginas web somente são acessadas submetendo

O indexador recebe e processa as páginas obtidas pelo aranha. Sua função

1 para cada url U encontrada faça

Após processar todas as páginas web, o ı́ndice invertido é armazenado

Figura 2.2: Tabela do indice invertido

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

2.3 Banco de dados

É armazenado no banco de dados as palavras consideradas importantes

A interface de pesquisa é o meio de comunicação entre o usuário e o motor

2.5 Ranqueamento de páginas web

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

2.6 Motores de busca distribuı́dos

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

No aranha: Acessar e processar as páginas web eficientemente no cenário

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

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

Para estabelecer a comunicação entre esses peers é utilizada a arquitetura

Freqüentemente chamada de P2P, consiste em um tipo de rede a qual

Nutch é o inı́cio de um esforço para implementar um sistema de loca-

3.1 Arquitetura do Nutch

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

O Nutch usa um banco de dados próprio que é dividido nas seguintes

• Banco de dados do Aranha: Contém informações sobre as URLs

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

• Banco de dados de indexes: Contém os indexes no formato estabe-

• Segmentos: Um conjunto de subdiretórios cada qual contendo URLs

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

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

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

2. Injetar URLs dentro da webDB (inject).

4. Buscar os conteúdos das URLs nas listas de busca (fetch).

5. Atualizar a webDB com os links das páginas buscadas (updatedb).

6. Repetir os passos 3-5 até que a profundidade desejada seja alcançada.

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

8. Indexar as páginas buscadas (index ).

9. Eliminar conteúdo duplicado (e URLs duplicadas) dos ı́ndices (dedup).

10. Mesclar os ı́ndices em um único ı́ndice para busca (merge).

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

3.2 Alterações realizadas

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

Criamos um script para automatização das tarefas que foram realizadas.

3.3 Testes realizados com o Nutch

Para efeitos de estudo, realizamos alguns testes de execução com o Nutch

3.3.1 Testes realizados na máquina ]1

O hardware da máquina ]1 é o seguinte:

• AMD Opteron(tm) Processor 242

• Clock 1593.901 MHz

Para este conjunto de testes variamos o número de threads entre 50 e