Download - Compressão de Índices
Ordenação e Recuperação de Dados
Prof. Alexandre Duarte - http://alexandre.ci.ufpb.br
Centro de Informática – Universidade Federal da Paraíba
Aula 5: Compressão de Índices
1
Agenda
❶ Revisão
❷ Compressão
❸ Compressão de dicionários
❺ Compressão de postings
2
Agenda
❶ Revisão
❷ Compressão
❸ Compressão de dicionários
❺ Compressão de postings
3
4
Índices baseados em ordenação de blocos
4
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
SPIMI-Invert
6
7
MapReduce para construção de índices
7
8
Indexação dinâmica: abordagem mais simples
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
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
Agenda
❶ Revisão
❷ Compressão
❸ Compressão de dicionários
❺ Compressão de postings
10
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
Por que realizar compressão em sistemas de recuperaçã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
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
Agenda
❶ Revisão
❷ Compressão
❸ Compressão de dicionários
❺ Compressão de postings
14
15
Coleção modelo
15
Símbolo Estatística valor
NL M
T
Documentos# médio de tokens por documentoTermos# médio de bytes por token (incl. espaços/punt.)# médio de bytes por token (sem espaços/punt.)# médio de bytes por termo postings não posicionais
800.000200400.00064,57,5100.000.000
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
Relembrando: O Dicionário como um array de estruturas de tamanho fixo
Espaco necessário: 20 bytes 4 bytes 4 bytes
Para Reuters: (20+4+4)*400,000 = 11,2 MB
17
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
Dicionário como uma string única
19
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
Dicionário como um string de blocos
21
22
Espaço para o dicionário como uma string de blocos
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
Localização de termo sem bloco
23
24
Localização de termo com bloco (mais lenta)
24
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.
8 a u t o m a t ∗ a 1 ⋄ e 2 ⋄ i c 3 ⋄ i o n
25
26
Compressão de dicionário para a Reuters -Sumário
26
Estrutura de dados Tamanho em MB
dicionário, tamanho fixo
dicionário, string única com apontadores
“, com blocos, k = 4
” e codificação de prefixo
11,2
7,6
7,1
5,9
Agenda
❶ Revisão
❷ Compressão
❸ Compressão de dicionários
❺ Compressão de postings
27
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
Ideia chave: Armazenar diferenças ao invés dos 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
Codificando as diferenças
30
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
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
Exemplos de códigos de comprimento variável
33
docIDsgapsVB code
824
00000110 10111000
829510000101
21540621457700001101 00001100 10110001
34
Compressão da coleção da Reuters
34
Estrutura de dados Tamanho em MB
dicionário, estrutura fixadictionário, ponteiroes para string∼, com blocos, k = 4∼, com blocos & codificação de prefixocoleção (texto, xml etc)coleção (texto)matriz de incidência T/D postings, sem compressão (32-bits)postings, sem compressão (20 bits)postings, codificação de tamanho variável
11.27.67.15.9
3600.0960.0
40,000.0400.0250.0116.0
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