Construção de Índices

1.047 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.047
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
43
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Construção de Índices

  1. 1. Centro de Informática – Universidade Federal da Paraíba Ordenação e Recuperação de Dados Aula 4: Construção de Índices Prof. Alexandre Duarte - http://alexandre.ci.ufpb.br 1
  2. 2. Agenda❶ Revisão❷ Introdução❸ Algoritmo BSBI❹ Algoritmo SPIMI❺ Indexação Distribuída❻ Indexação Dinâmica 2
  3. 3. Agenda❶ Revisão❷ Introdução❸ Algoritmo BSBI❹ Algoritmo SPIMI❺ Indexação Distribuída❻ Indexação Dinâmica 3
  4. 4. Dicionário como um array de estruturas detamanho fixoEspaço necessário: 20 bytes 4 bytes 4 bytes 4
  5. 5. Árvore B para localizar entradas em umíndice 5
  6. 6. Distância de Levenshtein para correçãoortográfica 6
  7. 7. Aula de hoje Dois algoritmos para a construção de índices: BSBI (simples) e SPIMI (mais realista) Contrução distribuída de índices: MapReduce Construção dinâmica de índices: como manter o índice atualizado quando a coleção de documentos muda 7
  8. 8. Agenda❶ Revisão❷ Introdução❸ Algoritmo BSBI❹ Algoritmo SPIMI❺ Indexação Distribuída❻ Indexação Dinâmica 8
  9. 9. Hardware  Muitas decisões de projeto em sistemas de recuperação da informação se devem a restrições do hardware.  Vamos agora revisar os aspectos do hardware que são importantes para este curso. 9
  10. 10. Hardware  Acesso aos dados em memória é mais rápido que acesso aos dados no disco (grosseiramente por um fator de 10)  Tempo de busca no disco é desperdício: Nenhum dado é transferido enquanto a cabeça de leitura do disco está sendo posicionada.  Para otimizar a transferência de dados do disco para a memória é melhor transferir um pedaço grande do que vários pedaços menores.  Sistema de entrada/saída de disco é baseado em blocos: Leitura e escrita de blocos inteiros. Tamanho do bloco varia de 8KB a 256 KB  Os servidores utilizados em sistemas de recuperação da informação geralmente tem vários GB de memória principal e TBs de espaço em disco.  Tolerar falhas é caro: É melhor utilizar várias máquinas convencionais do que uma máquina tolerante a falhas. 10
  11. 11. Coleção RCV1  A coleção com as obras de Shakespeare não é grande o suficiente para demonstrar muitos dos pontos deste curso.  Como exemplo para aplicar técnicas de construção de índices utilizaremos a coleção RCV1 da Reuters.  Conjunto de artigos de notícias escritos em ingles entre 1995 e 1996 (um ano). 11
  12. 12. Um documento da coleção RCV1 12
  13. 13. Estatísticas da RCV1N documentos 800,000L tokens por documento 200M termos 400,000 bytes por token (incl. espaços/pontuação) 6 bytes por token (sem espaços/pontuação) 4.5 bytes por termo 7.5T postings não posicionais 100,000,000Exercícios:• Qual a frequência média de um termo (quantos tokens) ?• 4.5 bytes por token vs. 7.5 bytes por termo: por que essa diferença?• Quantos postings posicionais? 13
  14. 14. Agenda❶ Revisão❷ Introdução❸ Algoritmo BSBI❹ Algoritmo SPIMI❺ Indexação Distribuída❻ Indexação Dinâmica 14
  15. 15. Objetivo: construir o índice invertido dicionário postings 15
  16. 16. Construção de índiceOrdenação dos postings em memória 16
  17. 17. Construção de índices baseada emordenação  Enquanto construímos o índice, analisamos os documentos um de cada vez.  As listas de postings para cada termo estão incompletas até o final do processamento.  Podemos manter todos os postings na memória e ordenar tudo ao fim do processamento?  Não para grandes coleções de documentos  Utilizando 10–12 bytes por posting, precisamos de muito espaço para grandes coleções.  T = 100,000,000 para a RCV1: podemos ordenar isso em memória utilizando uma máquina convencional.  Porém, construções de índices em memória principal não tem escala para grandes coleções de documentos.  Portanto: precisamos armazenar resultados intermediários em disco. 17
  18. 18. Podemos utilizar o mesmo algoritmo?  Podemos utilizar o mesmo algoritmo de construção de índices para coleções maiores, apenas utilizando o disco ao invés da memória principal?  Não: Ordenar T = 100,000,000 registros no disco é muito lento – muito tempo desperdiçado com o posicionamento da cabeça de leitura.  Precisamos de um algoritmo de ordenação externa. 18
  19. 19. Algoritmo de ordenação externa(movimentando menos a cabeça de leitura)  Precisamos ordenar T = 100,000,000 postings não posicionais.  Cada posting tem 12 bytes (4+4+4: termID, docID, frequencia).  Definir um bloco com 10.000.000 desses postings  Podemos armazenar facilmente um bloco desses na memória principal.  Para o RCV1 teremos 10 desses blocos.  Ideia básica do algoritmo:  Para cada bloco: (i) armazene os postings, (ii) ordene em memória, (iii) grave no disco  Mais tarde, faça o merge dos blocos formando uma grande lista ordenada. 19
  20. 20. Fazendo o merge de dois blocos 20
  21. 21. Indexação baseada em blocos ordenados (BlockedSort-Based Indexing – BSBI)  Decisão chave: Qual o tamanho do bloco? 21
  22. 22. Agenda❶ Revisão❷ Introdução❸ Algoritmo BSBI❹ Algoritmo SPIMI❺ Indexação Distribuída❻ Indexação Dinâmica 22
  23. 23. Problema com os algoritmos baseados emordenação  Supomos que poderíamos manter o dicionário na memória principal.  Precisamos do dicionário (que cresce dinamicamente) para poder implementar um mapeamento entre termo e termID.  Na verdade, poderíamos trabalhar com postings do tipo termo,docID ao invés de postings do tipo termID,docID . . .  . . . mas assim os arquivos intermediários ficariam muito grandes. 23
  24. 24. Indexação em memória com passo único(Single-pass in-memory indexing)  Abreviação: SPIMI  Ideia chave 1: Gerar dicionários separados para cada bloco – não é necessário manter uma correspondência termo-termID entre blocos.  Ideia chave 2: Não ordene. Acumule os postings nas listas à medida em que ocorrem.  Com essas duas ideias é possível gerar um índice invertido completo para cada bloco.  Esses índices separados podem então ser combinados em um grande índice. 24
  25. 25. SPIMI-Invert 25
  26. 26. SPIMI: Compressão  Compressão torna o SPIMI ainda mais eficiente.  Compressão de termos  Compressão de postings  Veremos mais na próxima aula 26
  27. 27. Agenda❶ Revisão❷ Introdução❸ Algoritmo BSBI❹ Algoritmo SPIMI❺ Indexação Distribuída❻ Indexação Dinâmica 27
  28. 28. Indexação Distribuída  Indexação na escala da web: necessário utilizar um cluster de computação distribuída  Máquinas individuais são sujeitas a falhas.  Podem ficar muito lentas ou falhar de forma imprevisível.  Como explorar um conjunto muito grande dessas máquinas sujeitas a falhas? 28
  29. 29. Data Centers do Google (estimativas de 2007)  Os data centers do Google são formados principalmente por máquinas comuns.  São distribuídos ao redor do mundo.  1 milhão de servidores, 3 milhões de processadores/núcleos  O Google instala 100.000 servidores por semestre.  Gastos entre 200 e 260 milhões de dólares por ano  Representa 10% da capacidade computacional mundial!  Se um sistema que não tolera falhas é formado por 1000 nós, cada nó com um uptime de 99.9%, qual é o uptime do sistema inteiro (assumindo que ele não tolera falhas)?  Resposta: 63%  Suponha que um servidor falhará a cada 3 anos. Qual o intervalo entre a falha de duas máquinas em uma instalação com 1 milhão de servidores?  Resposta: menos de dois minutos 29
  30. 30. Indexação Distribuída  Mantenha uma máquina mestre controlando o trabalho de indexação  Quebre o processo de indexação em conjuntos de tarefas paralelas independentes  A máquina mestre distribui a execução das tarefas em uma coleção de máquinas. 30
  31. 31. Tarefas paralelas  Definiremos dois conjuntos de tarefas paralelas e dois tipos de máquinas para executá-las:  Pré-processadores (parsers)  Indexadores (Inverters)  Quebre a coleção de documentos de entrada em sub-coleções (correspondentes aos blocos no BSBI/SPIMI) 31
  32. 32. Pré-processadores (Parsers)  O mestre atribui uma sub-coleção a uma máquina desocupada.  O pré-processador lê os documentos e gera os pares (termo,docID).  Os pré-processadores gravam os pares em n partições de termos.  Cada partição representa uma faixa alfabética  E.g., a-f, g-p, q-z (com: n = 3) 32
  33. 33. Indexadores  Um indexador coleta pares (termo,docID), que são os postings para uma determinada partição.  Ordena a lista em seguida grava o resultado 33
  34. 34. Fluxo de dados 34
  35. 35. MapReduce  O algoritmo de indexação que acabamos de ver é uma instância do MapReduce.  MapReduce é um framework robusto e conceitualmente simples para computação distribuída . . .  . . .que não exige a codificação para a parte da distribuição das tarefas.  O processo de indexação do Google consistia (em 2002) de um número de fases, cada uma delas implementadas utilizando o MapReduce.  Construção do índice invertido era uma das fases. 35
  36. 36. Agenda❶ Revisão❷ Introdução❸ Algoritmo BSBI❹ Algoritmo SPIMI❺ Indexação Distribuída❻ Indexação Dinâmica 36
  37. 37. Indexação dinâmica  Até agora assumimos que as coleções de documentos são estáticas.  Elas raramente são: documentos são inseridos, removidos e modificados  Isto significa que os dicionários e listas de postings precisam ser dinamicamente modificados 37
  38. 38. Indexação dinâmica: a abordagem maissimples  Manter um índice principal no disco  Novos documentos são inseridos em pequenos índices auxiliares em memória principal.  Fazer a pesquisa em ambos e combinar os resultados  Periodicamente os índices auxiliares são combinados com o índice principal  Remoções  Vetor de bits de validade para os documentos removidos  Filtrar os documentos retornados utilizando os bits desse vetor 38
  39. 39. Problemas com o uso de índice principal eauxiliares  Merges frequentes  Fraco desempenho em pesquisas realizadas durante um merge  Na verdade:  Combinar os índices auxiliares com o índice principal não leva tanto tempo se cada lista de postings é armazenada em um arquivo separado.  Nesse caso, o merge é simplesmente uma concatenação.  Porém, isso requer um número muito grande de arquivos, o que reduz a eficiência do sistema.  Suposição para o restante do curso: o índice é um grande arquivo único  Na prática: usa-se um esquema intermediário (e.g., quebrar listas de postings muito grandes em vários arquivos, combinar listas menores em um único arquivo, etc.) 39
  40. 40. Indexação dinâmica em grandes motores debusca  Geralmente uma combinação  Modificações incrementais frequentes  Rotação de grandes partes do índice que podem então ser trazidas para a memória principal  Reconstrução completa ocasional (fica mais difícil com o aumento do tamanho – não é certo se o Google conseguiria reconstruir totalmente o seu índice) 40
  41. 41. Construindo índices posicionais  Basicamente o mesmo problema com a exceção de que as estruturas de dados intermediárias são maiores. 41

×