Compressão de Índices

653 visualizações

Publicada em

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

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

Nenhuma nota no slide

Compressão de Índices

  1. 1. Centro de Informática – Universidade Federal da Paraíba Ordenação e Recuperação de Dados Aula 5: Compressão de Índices Prof. Alexandre Duarte - http://alexandre.ci.ufpb.br 1
  2. 2. Agenda❶ Revisão❷ Compressão❸ Compressão de dicionários❺ Compressão de postings 2
  3. 3. Agenda❶ Revisão❷ Compressão❸ Compressão de dicionários❺ Compressão de postings 3
  4. 4. Índices baseados em ordenação de blocos 4
  5. 5. Indexação em memória com passo único  Abreviação: SPIMI  Ideia chave 1: Gerar dicionários separados para cada bloco – desnecessário manter uma mapeamento de termo-termoID entre blocos.  Ideia chave 2: Não ordene. Acumule os postings nas listas de postings na medidade em que ocorrem.  Com essas ideias é possível gerar um índice invertido completo para cada bloco.  Estes índices separados podem depois ser combinados para gerar um índice único. 5
  6. 6. SPIMI-Invert 6
  7. 7. MapReduce para construção de índices 7
  8. 8. Indexação dinâmica: abordagem maissimples  Manter um grande índice principal no disco  Novos documentos utilizam pequenos índices auxiliares em memória.  Pesquise em ambos, combine os resultados  Combine periodicamente os índices auxiliares com o índice principal 8
  9. 9. Aula de hoje  Motivação para uso de compressão em sistemas de recuperação de informação  Como comprimir o dicionário em um índice invertido?  Como comprimir as listas de postings em um índice invertido? 9
  10. 10. Agenda❶ Revisão❷ Compressão❸ Compressão de dicionários❺ Compressão de postings 10
  11. 11. Por que realizar compressão? (em geral)  Usar menos espaço em disco (economizar dinheiro)  Manter mais informação na memória (aumento de velocidade)  Aumentar a velocidade na transferência de dados do disco para a memória (novamente, aumento de velocidade)  [ler dados comprimidos e depois descomprimi-los em memória é mais rápido que ler os dados não comprimidos  Premissa: Algoritmos de descompressão são rápidos.  Isto é verdade para os algoritmos que estudaremos. 11
  12. 12. Por que realizar compressão em sistemas derecuperação da informação ?  Primeiro, consideraremos o espaço utilizado para o dicionário  Motivação principal: tornar o dicionário pequeno o suficiente para mantê-lo em memória principal  Em seguida, o arquivo com as listas de postings  Motivação: reduzir o espaço necessário para armazêna-lo e diminuir o tempo necessário para fazer a leitura do disco  Nota: Grandes mecanismos de busca mantém uma parte significante de suas listas de postings em memória principal  Veremos vários esquemas de compressão para dicionários e postings. 12
  13. 13. Compressão com e sem perdas  Compressão com perdas: Descarta parte da informação  mp3, por exemplo  Várias das etapas de pré-processamento podem ser vistas como compressão com perdas:  Tratamento de maiúsculas/minúsculas, palavras de separação, números, datas  Compressão sem perdas: Toda a informação é preservada  zip, por exemplo  É a forma mais utilizada para compressão de índices 13
  14. 14. Agenda❶ Revisão❷ Compressão❸ Compressão de dicionários❺ Compressão de postings 14
  15. 15. Coleção modeloSímbolo Estatística valorN Documentos 800.000L # médio de tokens por documento 200M Termos 400.000 # médio de bytes por token (incl. espaços/punt.) 6 # médio de bytes por token (sem espaços/punt.) 4,5 # médio de bytes por termo 7,5T postings não posicionais 100.000.000 15
  16. 16. Compressão de dicionários  O dicionário é pequeno em comparação ao tamanho das listas de postsings.  Mas queremos mantê-lo na memória principal.  Questões importantes: competição com outras aplicações, telefones celulares, computadores embarcados  Portanto, comprimir o dicionário é importante. 16
  17. 17. Relembrando: O Dicionário como um array deestruturas de tamanho fixo Espaco necessário: 20 bytes 4 bytes 4 bytes Para Reuters: (20+4+4)*400,000 = 11,2 MB 17
  18. 18. Estruturas de tamanho fixo não são boa idéia  A maioria dos bytes na coluna de termos são desperdiçados.  Alocamos 20 bytes mesmo para termos de tamanho 1.  Não podemos lidar com termos como HYDROCHLOROFLUOROCARBONS e SUPERCALIFRAGILISTICEXPIALIDOCIOUS  Tamanho médio de um termo em inglês: 8 caracteres  Como podemos utilizar em média 8 caracteres por termo? 18
  19. 19. Dicionário como uma string única 19
  20. 20. Espaço para o dicionário como uma string  4 bytes por termo para frequência  4 bytes por termo para o apontador da lista de postings  8 bytes (média) para cada termo na string  3 bytes por apontador para a string (precisamos de log2 8 · 400000 < 24 bits para endereçar 8 · 400,000 posições)  Espaço: 400.000 × (4 + 4 + 8 + 3) = 7,6MB (comparados aos 11,2 MB para o array de estruturas de tamanho fixo) 20
  21. 21. Dicionário como um string de blocos 21
  22. 22. Espaço para o dicionário como uma string deblocos  Tamanho do bloco de k = 4  Onde usávamos 4 × 3 bytes para apontadores de termos sem bloco . . .  . . . usamos agora 3 bytes para um ponteiro para o bloco e mais 4 bytes para indicar o tamanho de cada termo no bloco.  Economizamos 12 − (3 + 4) = 5 bytes por bloco.  Economia total: 400,000/4 ∗ 5 = 0,5 MB  Isto reduz o dicionário de 7,6 MB para 7,1 MB. 22
  23. 23. Localização de termo sem bloco 23
  24. 24. Localização de termo com bloco (mais lenta) 24
  25. 25. Codificação de prefixo Um bloco na string com blocos (k = 4) . . . 8 a u t o m a t a 8 a u t o m a t e 9 a u t o m a t i c 10 a u t o m a t i o n ⇓ . . . reduzida com compressão de prefixo. 8automat∗a1⋄e2⋄ic3⋄ion 25
  26. 26. Compressão de dicionário para a Reuters -Sumário Estrutura de dados Tamanho em MB dicionário, tamanho fixo 11,2 dicionário, string única com apontadores 7,6 “, com blocos, k = 4 7,1 ” e codificação de prefixo 5,9 26
  27. 27. Agenda❶ Revisão❷ Compressão❸ Compressão de dicionários❺ Compressão de postings 27
  28. 28. Compressão de postings  O arquivo com as listas de postings é pelo menos 10 vezes maior que o dicionário.  Consideramos um posting como sendo um docID.  Para a coleção da Reuters (800,000 documentos), devemos utilizar 32 bits por docID (inteiros de 4 bytes).  Alternativamente, poderíamos utilizar log2 800,000 ≈ 19.6 < 20 bits por docID.  Nosso objetivo: utilizar muito menos que 20 bits por docID. 28
  29. 29. Ideia chave: Armazenar diferenças ao invésdos docIDs As listas de postings são ordenadas por docID. Exemplo de lista de postings: COMPUTER: 283154, 283159, 283202, . . . Basta armazenar as diferenças: 283159-283154=5, 283202- 283159=43 Exemplo de lista de postings com diferenças : COMPUTER: 283154, 5, 43, . . . As diferenças para termos frequentes são pequenas. Portanto, podemos utilizar menos que 20 bits para codificar as diferenças. 29
  30. 30. Codificando as diferenças 30
  31. 31. Codifição de tamanho variável  Objetivo:  Para ARACHNOCENTRIC e outros termos pouco frequentes, teremos que utilizar cerca de 20 bits por diferença (= posting).  Para THE e outros temos muito frequentes, utilizaremos apenas uns poucos bits por diferença (= posting).  Para poder implementar esse esquema, precisamos criar alguma forma de codificação de tamanho variável  Codificação de tamanho variável utiliza poucos bits para diferenças pequenas e muitos bits para diferenças maiores. 31
  32. 32. Código de tamanho variável  Usado em muitos sistemas comerciais  Dedicar um 1 bit para ser o bit de continuação c.  Se o valor da diferença couber em 7 bits, codificar dentro dos 7 bits disponíveis e fazer c = 1.  Senão: codificar os 7 bits mais significativos e utilizar bytes adicionais para codificar o restante do número utilizando o mesmo algoritmo.  No final, o bit de continuação do último byte será 1 (c = 1) e dos outros bytes será 0 (c = 0). 32
  33. 33. Exemplos de códigos de comprimentovariáveldocIDs 824 829 215406gaps 5 214577VB code 00000110 10111000 10000101 00001101 00001100 10110001 33
  34. 34. Compressão da coleção da Reuters Estrutura de dados Tamanho em MB dicionário, estrutura fixa 11.2 dictionário, ponteiroes para string 7.6 ∼, com blocos, k = 4 7.1 ∼, com blocos & codificação de prefixo 5.9 coleção (texto, xml etc) 3600.0 coleção (texto) 960.0 matriz de incidência T/D 40,000.0 postings, sem compressão (32-bits) 400.0 postings, sem compressão (20 bits) 250.0 postings, codificação de tamanho variável 116.0 34
  35. 35. Sumário  Podemos agora criar um índice muito eficiente em relação ao espaço para consultas booleanas.  O índice terá entre 10 e 15% do tamanho do texto na coleção.  No entanto, ignoramos frequência e informação posicional.  Portanto, na prática a economia de espaço é menor. 35

×