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