Índices e Rastejamento na Web

429 views
371 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
429
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
37
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Índices e Rastejamento na Web

  1. 1. Ordenação e Recuperação de Dados Aula 13: Índices e rastejamento (crawling) web Alexandre Duarte alexandre@di.ufpb.br 1 1
  2. 2. Revisão da última aula Pesquisa na Web Spam Tamanho da Web Deteção de duplicatas  Usar o Coeficiente de Jaccard para calcular a similaridade entre dois documentos 2
  3. 3. Aula de Hoje Rastejamento 3
  4. 4. Sec. 20.2Operação básica de um crawler Começar com um conjunto conhecidos de URLs (“raiz”) Recuperar e fazer parsing  Extrair as URLs referenciadas  Colocar as URLs em uma fila Recuperar cada URL da fila e repetir 4
  5. 5. Sec. 20.2Retrado do crawling URLs recuperadas e processadas Web desconhecida Páginas URLs na Fronteira raízWeb 5
  6. 6. Sec. 20.1.1Algumas complicações desse retrato Crawling na web não pode ser feito com uma única máquina  Todos os passos descritos são distribuídos Páginas maliciosas  Spam  Armadilhas– incluído páginas geradas dinamicamente Mesmo páginas não maliciosas podem ser desafiadoras  Latência/largura de banda de servidores remotos varia  Profundidade  Quão “profundo” deve-se ir numa hierarquia de URLs?  Espelhos e duplicatas de sites  Educação – não borbardear um servidor muito frequentemente 6
  7. 7. Sec. 20.1.1O que todo crawler precisa fazer Ser Educado: Respeitar considerações implícitas e explicitas  Só processar páginas permitidas  Respeitar o robots.txt (mais sobre isso jajá) Ser Robusto: Ser imune a armadilhas e comportamento malicioso de servidores web 7
  8. 8. Sec. 20.1.1O que todo crawler deve fazer Se capaz de operar de forma distribuída: projetado para rodar em várias máquinas distribuídas Ser escalável: projetado para aumentar a taxa de processamento com a adição de mais máquinas Desempenho/eficiência: permitir uso total dos recursos de processamento e rede disponíveis 8
  9. 9. Sec. 20.1.1O que todo crawler deve fazer Recuperar as páginas de “maior qualidade” primeiro Operação Contínua: Continuar a recuperar cópias atualizadas de páginas previamente recuperadas Extensibilidade: Adaptação a novos formatos de dados, protocolos, etc 9
  10. 10. Sec. 20.1.1 Retrato do crawling atualizado URLs recuperadas e processadas Web desconhecida Páginas Raiz URLs na FronteiraCrawling thread 10
  11. 11. Sec. 20.2URLs na fronteira Podem incluir várias páginas de um mesmo servidor Precisa evitar tentar recuperar todas elas ao mesmo tempo Precisa tentar manter todos os crawling threads ocupados 11
  12. 12. Sec. 20.2Educação Explicita e Implícita Educação explicita: especificações dos webmasters sobre que porções do site podem ser recuperadas  robots.txt Educação implícita: mesmo sem especificação, evitar visitar um site muito frequentemente 12
  13. 13. Sec. 20.2.1Robots.txt Protocolo criado em 1994 para dar aos crawlers (“robôs”) acesso limitado a um website  www.robotstxt.org/wc/norobots.html Website anunciam seus requisitos sobre o que pode e não pode ser recuperado Para um servidor, criar um arquivo /robots.txt  Este arquivo especifica as restrições de acesso 13
  14. 14. Sec. 20.2.1Exemplo de Robots.txt Nenhum robô deve visitar URLs começando com "/yoursite/temp/", exceto o robô chamado “searchengine":User-agent: *Disallow: /yoursite/temp/User-agent: searchengineDisallow: 14
  15. 15. Sec. 20.2.1Etapas de processamento durante ocrawling Escolher uma URL da fronteira Qual? Recuperar o documento correspondente Fazer parse do documento  Extrair links para outros documentos (URLs) Checar se a URL tem conteúdo já visto  Se não, adicionar ao índices Ex., só processar .edu, Para cada URL extraída obedecer robots.txt, etc.  Garantir que ela passa em alguns filtros de teste para URLs  Checar se ela já está na fronteira (eliminação de URLs duplicadas) 15
  16. 16. Sec. 20.2.1Arquitetura básica DNS Doc robots URL FP’s filters setWWW Parse Fetch Dup Content URL seen? URL filter elim URL Frontier 16
  17. 17. Sec. 20.2.2DNS (Domain Name Server) Um serviço de consulta na Web  Dada uma URL, recuperar seu endereço IP  Serviço oferecido por um conjunto distribuído de servidores, portanto, latências de consulta podem ser altas (mesmo de segundos) Implementações comuns de consultas a DNS nos Sistemas Operacionais são bloqueantes: apenas uma consulta aberta por vez Soluções  Cache de DNS  Batch DNS resolver – coleta as requisições e envia as consultas de uma só vez 17
  18. 18. Sec. 20.2.1 Parsing: normalização de URL Quando um documento recuperado é processado, alguns dos links são URLs relativas Ex., http://en.wikipedia.org/wiki/Main_Page tem um link relativo para /wiki/Wikipedia:General_disclaimer que aponta para a URL absoluta http://en.wikipedia.org/wiki/Wikipedia:General_disclaimer Durante o parsing é preciso normalizar (expandir) URLs relativas 18
  19. 19. Sec. 20.2.1Conteúdo já visto? Duplicação está em todo lugar na web Se a página recuperada já está no índice, deve ser ignorada Isso é verificado utilizando assinaturas de documentos 19
  20. 20. Sec. 20.2.1Filtros e robots.txt  Filtros – expressões regulares para URLs a serem (ou não) recuperadas  Uma vez que o arquivo robots.txt de um site é recuperado, ele não precisa ser recuperado repetivas vezes  Fazer isso consume largura de banda e afeta os servidores web  Fazer cache dos arquivos robots.txt 20
  21. 21. Sec. 20.2.1Eliminação de URL duplicadas Para uma recuperação não-contínua, testar para ver se a URL extraída+filtrada já está na fronteira Para uma recuperação contínua, ver detalhes sobre a implementação da fronteira 21
  22. 22. Sec. 20.2.1Distribuíndo o crawler Executar vários threads do crawler, dentro de diferentes processos, potencialmente em diferentes nós  Nós distribuídos geograficamente Particionar os servidores sendo processados entre os nós  Partição baseada em hash Como esses nós se comunicam e compartilham URLs? 22
  23. 23. Sec. 20.2.1Comunicação entre os nós  Saída do filtro de URLs em cada nó é enviada para um Eliminador de URLs Duplicadas do nó apropriado DNS Para Doc robots outros URL FP’s filters nós setWWW Parse Host Fetch splitter Dup Content URL seen? URL filter elim De outros nós URL Frontier 23
  24. 24. Sec. 20.2.3URLs na fronteira: duas principaisconsiderações Educação: não visitar um servidor web muito frequentemente Atualização: recuperar algumas páginas mais frequentemente que outras  Ex., páginas (como sites de notícias) cujos conteúdos mudam frequentementeEstes objetivos estão em conflitos.(Ex., Filas de prioridade não são suficientes – muitos dos links de uma página vão para o mesmo servidor, criando uma rajada de acessos a este servidor.) 24
  25. 25. Sec. 20.2.3Educação – desafios Mesmo que restrinjamos a um único thread por host, ele ainda poderá ser visitado repetidas vezes Heurística comum: inserir um intervalo entre duas consultas sucessivas a um mesmo servidor que seja >> que o tempo necessário para recuperar o documento da última vez 25
  26. 26. Sec. 20.2.3URL na fronteira: Esquema deMercator URLs Prioritizer K front queues Biased front queue selector Back queue router B back queues Single host on each Back queue selector Crawl thread requesting URL 26
  27. 27. Sec. 20.2.3Fronteira de URLs de Mercator As URLs fluem do topo até a fronteira As filas da frente gerenciam a priorização As filas de trás garantem educação Cada fila é FIFO 27
  28. 28. Sec. 20.2.3Filas da Frente Prioritizer 1 K Biased front queue selector Back queue router 28
  29. 29. Sec. 20.2.3Filas da Frente Prioritizer atribui uma prioridade de 1 a K para cada URL  Adiciona a URL à fila correspondente Heurística para atribuição de prioridade  Taxa de atualização observada nas recuperações anteriores  Específica da Aplicação (ex., “checar sites de notícias mais frequentemente”) 29
  30. 30. Sec. 20.2.3Biased front queue selector Quando uma fila de trás solicita uma URL: escolhe uma fila da frente de onde remover a URL Esta escolha pode ser feita utilizando round robin ou utilizando alguma variante mais sofisticada  Também pode ser aleatória 30
  31. 31. Sec. 20.2.3Filas de trás Biased front queue selector Back queue router 1 B Back queue selector Heap 31
  32. 32. Sec. 20.2.3Filas de trás Cada fila é mantida não-vazia enquanto o processamento é realizado Cada fila contém URLs de um único servidor  Manter uma tabela mapeando servidores em filas Host name Back queue … 3 1 B 32
  33. 33. Heap das filas de trás Uma entrada para cada fila de trás A entrada é o menor tempo te no qual o servidor correspondente pode ser visitado novamente O menor tempo é determinado a partir do  Último acesso ao servidor  Alguma outra heurística desejada 33
  34. 34. Sec. 20.2.3Processamento das filas de trás  Um crawler thread a procura de uma URL para recuperar:  Extrair a raiz do heap  Recuperar a URL na cabeça da fila correspondente q (olhar a tabela)  Checar se a fila q esta vazia – em caso afirmativo obter uma URL v das filas da frente  se já existe uma fila de trás para o servidor de v, adicionar v à esta fila e pegar outra URL das filas da frente, repetir  Caso contrário, adicionar v a q  Quando q é não-vazia, criar uma entrada no heap para q 34
  35. 35. Sec. 20.2.3Número de filas de trás B Manter todos os threads ocupados mas mantendo a educação Recomendação de Mercator: ter três vezes mais filas que crawler threads 35

×