Oscar Gomes de Miranda. VIF - Uma Estrutura de Índice Invertido em Blocos Baseada em uma B + -Tree

Transcrição

1 Oscar Gomes de Miranda VIF - Uma Estrutura de Índice Invertido em Blocos Baseada em uma B + -Tree Recife, PE - Brasil Agosto de 2003

2 Oscar Gomes de Miranda VIF - Uma Estrutura de Índice Invertido em Blocos Baseada em uma B + -Tree Dissertação apresentada à Coordenação do curso de Mestrado em Ciência da Computação da Universidade Federal de Pernambuco para a obtenção do título de Mestre em Ciência da Computação. Orientadora: Profa. Dra. Ana Carolina Salgado Universidade Federal de Pernambuco Centro de Informática Recife, PE - Brasil Agosto de 2003

3 i Dissertação de Mestrado sob o título VIF - Uma Estrutura de Índice Invertido em Blocos Baseada em uma B + -Tree, defendida por Oscar Gomes de Miranda e aprovada em 8 de Setembro de 2003, em Recife, Pernambuco, pela banca examinadora constituída pelos doutores: Profa. Dra. Ana Carolina Salgado Orientadora Profa. Dra. Kátia Silva Guimarães Universidade Federal de Pernambuco Prof. Dr. Jones Oliveira de Albuquerque Universidade Federal Rural de Pernambuco

4 ii À minha mãe.

5 iii Agradecimentos Dedico meus sinceros agradecimentos: Aos meus pais e toda minha família pelo apoio; À Profa. Ana Carolina Salgado por ter me orientado e me apoiado no desenvolvimento deste trabalho; A meus amigos por terem me apoiado e me ajudado diretamente, Thiago Santos, Luciano Barbosa, Fernando Trinta, Mariano Cravo, Rodrigo Teixeira; À empresa Mobile e ao antigo Grupo Radix por terem oferecido os recursos necessários para a conclusão deste trabalho; A todos os amigos do Grupo Radix, Mobile e CIn-UFPE que tive o prazer de conhecer por terem participado no desenvolvimento deste trabalho, mesmo que de forma indireta, ou por terem me apoiado; À Deus sobretudo.

6 iv Só se encontra o que se busca, o que nos é indiferente foge-nos. Sócrates

7 v Resumo A explosão de uso da World Wide Web (Web) e seu crescimento exponencial são fatos reais hoje em dia. A grande quantidade de dados em formato textual disponível de forma dispersa na Web tornou o uso de sistemas de busca bastante popular. Pesquisas mostram que cerca de 57% de usuários da internet fazem uma consulta a cada dia. Esta necessidade de uso tem sido a alavanca da popularidade dos sistemas de busca que, mesmo tendo evoluído de forma signicativa nos últimos anos, precisam manter-se atualizados com estruturas capazes de indexar toda essa informação para atender esta demanda de crescimento da Web. Esta dissertação apresenta um levantamento de técnicas no estado-da-arte sobre estruturas de índices para sistemas de Recuperação de Informação (RI) apresentando as estruturas: Arquivo invertido, que é o foco principal deste trabalho; Array de suxos. que, mesmo oferecendo facilidades na busca em consultas por proximidade, tem um custo de espaço de armazenamento muito alto; e Arquivo de assinaturas, que foi amplamente utilizada em sistemas de RI na década de 80, porém foi superada pelas técnicas modernas aplicadas a estruturas de arquivo invertido. Dentre estas técnicas cita-se a compressão do índice através do uso de codicação Elias e Golomb os quais, além de trazer economia de espaço, melhoram o desempenho tanto no processo de consulta quanto no processo de construção do índice. Além disso, são descritos em detalhes métodos ecientes de acesso e de construção e manipulação do índice. Como resultado do trabalho é proposto o VIF - Vertical Inverted File - implementado na prática a partir de experiência pessoal adquirida durante o trabalho realizado no engenho de busca Radix. O VIF é uma estrutura de índice invertido organizada em blocos baseada em uma estrutura de dados dinâmica B -Tree que possibilita a inserção eciente de pequenas quantidades de documentos HTML + e, também, oferece uma forma nativa de otimização no processamento de consultas através de salto de blocos. No Radix foram feitos testes sobre estrutura onde obteve-se ganhos de cerca de 78% de espaço utilizado comparado com a estrutura utilizada anteriormente. Outros testes mostraram melhoria média de 26.5% no tempo de processamento consultas usando salto em blocos comparado com processamento sem otimização, considerando o tempo no processamento das consultas mais realizadas pelos usuários do sistema. Palavras-chave: Recuperação de Informação, Web, Estrutura de Dados, Arquivo Invertido, B-Tree.

8 vi Abstract The explosion of the use of the World Wide Web (Web) and its exponential growth are true facts nowadays. The huge amount of data in textual format available widespread over the Web have made the use of search systems very popular. Statistics show that about 57% of the internet users do a query to a search engine everyday. This need of information turned out to be the reason that drives the Web search engines popularity. Even thought the Web search engines have had signicant evolution in the last years, they still need to keep up-to-date their data structures in order to reect the constantly changing Web. This master thesis presents a research describing state-of-the-art techniques about indexing structures for Information Retrieval (IR) systems such as: Inverted File, which is the main focus of this work; Sux arrays that, even oering facilities in searching of proximity queries, need a high quantity of storage space; and Signature les, although this approach is no longer in use since it was overtaken by the modern techniques applied to inverted le structures, the Signature les were widely used in IR systems in the 80's. Between those techniques are the index compression methods using, for instance, Elias and Golomb coding. Such methods decrease the space needed to store the index data while increase the performance of the index in query and construction processing time. Moreover, ecient methods for access, construction and updating of the inverted index are described. As result of the work we present the VIF - Vertical Inverted File - actually implemented based on the personal experience working on the Radix search engine. The VIF is an inverted le structure organized in blocks based on a dynamic data structure B - Tree which made possible the ecient insertion of small quantity of HTML documents. + It also oers a native optimization for faster query processing using blocks-jumps. In the tests performed on the structure, the index achieved savings of about 78% of the storage space used compared with the space spent by the previous data structure used in the Radix search engine. Other tests show savings in query processing time of approximately 26.5% using the optimization of block-jumps compared with the classic approach considering only the most requested queries of the system. Keywords: Information Retrieval, Web, Data Structure, Inverted File, B-Tree.

9 vii Sumário Lista de Figuras xi Lista de Tabelas 1 Introdução Motivação Trabalho Proposto Organização do Documento Sistemas de Indexação e Busca para Web Recuperação de Informação Denições Iniciais Visão Lógica dos Documentos Processo de Recuperação de Informação Modelos de Recuperação de Informação Modelo Booleano Modelo Vetorial Modelo Booleano Estendido Modelo Probabilístico Considerações Sobre Os Modelos Sistemas de Recuperação de Informação para Web Modelo do Grafo da Web O Dinamismo da Web xiii

10 viii Desaos da Web Arquitetura Centralizada Consulta Considerações Finais Sumário 3 Índices e Técnicas para Sistemas de Recuperação de Informação Índices para Sistemas de RI Arquivo de Assinaturas Array de Suxos e Árvore de Suxos Arquivos Invertidos Granularidade do Índice Índice Baseado em Endereçamento de Blocos Considerações Sobre As Estruturas Apresentadas Estrutura de Índice Dinâmico B + -Tree Busca na B + -Tree Inserção na B + -Tree Remoção na B + -Tree Compressão Métodos de Compressão de Índices Codicação com Quantidade Variável de Bytes Codicação Elias Codicação Golomb Construção do Índice Construção Linear Baseada em Partições Multi-way In-place Merge Construção em Pipeline Atualização

11 ix Atualização Incremental sobre B-Tree Atualização em Tempo de Consulta Processamento de Consultas Processamento de Consultas Booleanas Processamento Rápido de Consultas Considerações nais Sumário 4 Especicação do VIF Descrição do Problema e Objetivo Arquitetura do Radix Módulo de Busca Função de Termos e de Urls Módulo de Indexação Atualização de Base Estrutura IF Estrutura PL Atualização dos Índices IF e PL Processamento de Consultas no IF e PL Especicação VIF Estrutura VIF Organização blocos VIF Processamento de Consulta no VIF Processamento com Fila de Prioridade Salto de Blocos Construção e Atualização do VIF Projeto e Implementação do VIF Ambiente de Desenvolvimento

12 x Linguagem de Implementação e de Modelagem Plataforma Operacional Arquitetura VIF Modelo Acesso e Manipulação do Índice VIF Servidor de Indexação Processador de Consultas Árvore de Processamento de Consultas Processo de Release no VIF Testes e Resultados Metodologia Ambiente do Experimento Resultados Considerações Finais Sumário 5 Conclusões Principais Contribuições Diculdades Encontradas Limitações e Trabalhos Futuros Referências Bibliográcas 91 Anexo A -- Algoritmo de Counting-Sort 96 Anexo B -- Fila de Prioridades 97 Anexo C -- Tabelas do Teste de Processamento de Consultas 99 Anexo D -- Grácos do Teste de Carga 101

13 xi Lista de Figuras 1 Processo de recuperação de informação Modelo Vetorial baseado na função de cosseno do ângulo A web vista como uma gravata borboleta Arquitetura centralizada Exemplo de uma consulta booleana Suxos de exemplo Árvore de suxos do exemplo Array de suxos do exemplo Exemplo arquivo invertido Estrutura do nó da árvore B + -Tree de grau Inserção simples em B + -Tree Inserção em B + -Tree com nó cheio Inserção em B + -Tree com nó interno cheio e aumento da profundidade Compressão de texto usando modelo Procedimento de inversão em memória Procedimento de inversão linear Procedimento de inversão via multi-way in-place merge Processamento de consulta booleana Arquitetura Básica do Engenho de Busca Radix Componentes do módulo de busca do Radix Estrutura IF Estrutura PL

14 xii 23 Estrutura básica índice VIF Organização dos blocos no VIF Atualização localizada no VIF Componentes modicados para usar o VIF Diagrama de Classes dos componentes de acesso e manipulação do índice VIF Diagrama de seqüência do Servidor de Indexação do Radix Diagrama de Classes do Processador de Consultas Diagrama de Seqüência do Processador de Consultas Diagrama de Classes dos Nós de Processamento da Busca Diagrama de Colaboração para Árvore de Processamento Diagrama de Colaboração para o Passo 1 do Release do VIF Diagrama de Atividades da Atualização em Blocos no Índice VIF Pseudo-código do algoritmo de divisão dos blocos VIF Pseudo-código do algoritmo de counting sort Código-fonte em Linguagem Java para a Fila de Prioridades Tempo de resposta com carga de 1000 ms Tempo de resposta com carga de 500 ms Tempo de resposta com carga de 250 ms Tempo de resposta com carga de 125 ms Fluxo de consultas com carga de 1000 ms Fluxo de consultas com carga de 500 ms Fluxo de consultas com carga de 250 ms Lista de Figuras

15 xiii Lista de Tabelas 1 Comparação entre recuperação de dados e recuperação de informação Repositório Exemplo Vocabulário e lista invertida completa do texto exemplo Documento codicado em um Arquivo de assinaturas Texto exemplo dividido em blocos de 20 palavras Vocabulário exemplo com índice de endereçamento de blocos Exemplo de codicação para números usando as codicações unário, Eliasγ, Elias-δ e Golomb (b=3) Componentes de busca e suas características Atributos de uma entrada VIF Detalhe dos corpus de testes Espaço utilizado pelo VIF para a BASE Teste de carga para índice VIF e índice IF mais PL Desempenho do índice com a variação do tamanho do bloco Comparação Tempo de Busca usando Otimização de salto em blocos Percentual de consultas por quantidade de termos Tempo de Processamento da cache estática com otimização de salto em blocos Tempo de Processamento da cache estática sem otimização Tempo de processamento da cache estática com salto de blocos para consultas com mais de um termo Tempo de processamento da cache estática sem otimização para consultas com mais de um termo

16 1 1 Introdução Sistemas de recuperação de informação automatizados foram originalmente desenvolvidos para ajudar no gerenciamento da grande quantidade de informação literária em universidades e bibliotecas públicas [1]. Hoje em dia a grande número de documentos disponíveisnainternetéumdesaoparaaáreaderecuperaçãodeinformaçãonosentidode manter estruturas capazes de armazenar, recuperar e gerenciar essa quantidade de dados. Em fevereiro de 1999, a estimativa do tamanho da Web era de 800 milhões de páginas [2], o que representava mais que o dobro do tamanho estimado em dezembro de 1997 (320 milhões). Estimativas mais recentes, em julho de 2000, indicavam que o tamanho da Web era de 2.1 bilhões de páginas únicas e que a sua taxa de crescimento era de 7.3 milhões de páginas adicionais por dia [3]. Estes fatos mostram um crescimento exponencial da Web, Levene [4] mostra um modelo estocástico para identicar o expoente de crescimento da Web. Atualmente, a Web tem, por baixo, mais de 3.3 bilhões de páginas [5]. 1.1 Motivação A explosão de uso da Web e seu crescimento exponencial são fatos reais hoje em dia. A grande quantidade de dados em formato textual disponível de forma dispersa na Web tornou o uso de sistemas de busca bastante popular. Pesquisas mostram que cerca de 57% de usuários da internet fazem uma consulta a cada dia1. Esta necessidade de uso tem sido a alavanca da popularidade dos sistemas de busca que, mesmo tendo evoluído de forma signicativa nos últimos anos, precisam manter-se atualizados com estruturas capazes de indexar toda essa informação, pois a Web continua crescendo com taxas semelhantes. Mesmo diante de das diculdades econômicas observadas no mundo e no Brasil neste primeiro semestre de 2003, o uso da internet continua crescendo em níveis elevados quando foi registrado um aumento de 27% do número de usuários da internet brasileira2. Este 1The Search Engine Index: 2IBOPE e-ratings:

17 1.1 Motivação 2 crescimento, que vem sendo notado nos últimos anos, indica um potencial para a continuação no crescimento tanto do uso diário de engenhos de busca quanto do tamanho da Web. Outro ponto importante é a característica dinâmica do conteúdo da internet. Um estudo sobre a freqüência de modicação das páginas da Web [6] feito no ano 2000indicou que 23%daspáginassãomodicadastodososdiasequeotempodemeia-vidadaspáginas é de onze dias, isto é, em 11 dias metade das páginas deixam de existir. Este fato deve ser considerado quando se busca uma estrutura capaz de indexar a Web. O Trabalho realizado nesta dissertação também reete a experiência pessoal adquirida durante o desenvolvimento do engenho de busca Radix [7]. Além dos problemas atrelados de forma intrínseca à Web, existem os problemas práticos que foram notados no projeto, onde, por exemplo, o uso de diferentes abordagens de armazenamento quando, no começo do projeto BRight!3 foi utilizado uma estrutura de arquivo invertido armazenando em um sistema baseado em modelo relacional usando um sistema de banco de dados genérico (SGBD) que se apresentou não escalável. Isto acontecia porque a atualização do índice era feita em tempo de indexação atualizando diretamente cada lista invertida na base de dados fazendo com que o tempo de adição de cada documento novo aumentasse a medida que a base crescia. O protótipo chegou a armazenar uma quantidade de páginas da ordem de (dez mil) apenas. Este foi um dos motivos de migração inicial do protótipo do BRight! para que fosse utilizada uma estrutura de índice especíca, no caso foi utilizada uma abordagem simples de arquivo invertido descrita na Seção Outras mudanças relacionadas à escalabilidade da estrutura utilizada foram efetuadas durante a evolução do protótipo do BRight! para o Radix. Outro conceito inserido no desenvolvimento do sistema foi a atualização de base (release) que, inicialmente, era feita deformadiretaon-lineefoiatualizadaparaserfeitaem batch. Oíndicedebuscaeracriado de forma separada do que era coletado na fase de indexação, fazendo com que pudesse ser utilizado um procedimento mais eciente durante o release que era semelhante ao descrito na Seção Indo mais além, houve uma evolução deste procedimento para um chamado de atualização incremental que na realidade se assemelhava a uma construção baseada em várias uniões de pequenas quantidades de documentos, conforme descrito na Seção sem considerar o uso de compressão do índice e de atualização direta (inplace). Mesmo tendo evoluído signicativamente o engenho apresentava vários problemas de gerenciamento das estruturas causados principalmente pelo espaço utilizado pelas estru- 3BRight! foi o projeto de pesquisa [8] que deu origem ao engenho de busca Radix.

18 1.2 Trabalho Proposto 3 turas. Problema que se tornou mais grave com a utilização de uma estrutura extra para armazenar lista de posições das palavras nos documentos criada para possibilitar consultas por proximidade (Seção 2.4). Esta estrutura, descrita na Seção 4.2.6, juntamente com o índice invertido simples gerava uma sobrecarga de espaço alta. Por exemplo, uma das bases do Radix com 11 milhões de páginas precisava de um total de 35.1GB para armazenar somente estas duas estruturas (Tabela 11). Este custo era muito elevado sendo que necessitava de muito esforço para gerenciar as duas estruturas, pois eram necessários 7 (sete) dias para a realização do release Trabalho Proposto Esta dissertação tem como objetivo principal expor o projeto da estrutura de índice invertido VIF - Vertical Inverted File - implementada para incorporar o engenho de busca Radix. Abaixo segue a lista de objetivos relacionados ao projeto: Realizar o levantamento de técnicas no estado-da-arte sobre estruturas de índices para sistemas de Recuperação de Informação (RI). Foram consideradas as estruturas: Arquivo invertido, que é o foco principal deste trabalho; Array de suxos, que, mesmo oferecendo facilidades na busca em consultas por proximidade, tem um custo de espaço de armazenamento muito alto; e Arquivo de assinaturas, que foi amplamente utilizada em sistemas de RI na década de 80, porém foi superada pelas técnicas modernas aplicadas a estruturas de arquivo invertido. Dentre estas técnicas cita-se a compressão do índice através do uso de codicação Elias e Golomb, os quais, além de trazer economia de espaço, melhoram o desempenho tanto no processo de consulta quanto no processo de construção do índice; Expor a arquitetura utilizada no engenho Radix onde se encaixa todo o projeto apresentado nesta dissertação descrevendo a estrutura utilizada anteriormente, os índices IF e PL detalhados na Seção 4.2; Descrever os detalhes da estrutura VIF que, basicamente, é uma estrutura de índice invertido organizada em blocos baseada em uma estrutura de dados dinâmica B + - Tree que possibilita a inserção eciente de pequenas quantidades de documentos HTML e, também, oferece uma forma nativa de otimização no processamento de consultas através de salto de blocos; 4Este era o tempo total para criação do novo índice e para atualização das máquinas de busca

19 1.3 Organização do Documento 4 Apresentar todos os passos do projeto realizado para a implementação do VIF desde a especicação ao projeto; Fazer a comparação do índice VIF implementado em relação à estrutura anterior utilizada e fazer os testes de vericação do desempenho da estrutura considerando como medidas o espaço utilizado, tempo de construção e processamento de consultas. 1.3 Organização do Documento Este documento está organizado nos seguintes capítulos: Capítulo 2 - Sistemas de Indexação e Busca para Web São descritos conceitos básicos sobre o assunto Recuperação de Informação (RI) onde são descritos os modelos clássicos para sistemas de RI sendo abordada a aplicação de sistemas de RI na Web. Capítulo 3 - Índices e Técnicas para Sistemas de Recuperação de Informação Este capítulo descreve as principais estruturas de dados para índices de sistemas de RI e, também, descreve a estrutura de dados B + -Tree que é utilizada no projeto do VIF. Este capítulo também aborda de forma detalhada técnicas em estado-da-arte aplicadas a índices de arquivo invertido onde são descritas técnicas de compressão de índices, métodos ecientes de construção e atualização do índice e métodos de processamento de consultas em índices invertidos. Capítulo 4 - Especicação do VIF Apresenta a estrutura de índice VIF resultado da proposta descrita neste documento. Inicialmente é descrita a arquitetura do engenho de busca Radix e a estrutura utilizada previamente no engenho. Em seguida é descrita a especicação do VIF para depois serem expostos os detalhes do projeto de implementação do índice VIF. Por m, são apresentados os resultados dos testes aplicados à estrutura implementada. Capítulo 5 - Conclusão Expõe as conclusões nais do trabalho apresentado neste documento mostrando as principais contribuições alcançadas, as diculdades encontradas durante o trabalho e possíveis trabalhos futuros que possam ser usados para dar continuidade ao que foi realizado neste trabalho.

20 5 2 Sistemas de Indexação e Busca para Web Este capítulo trata de sistemas de recuperação de informação para Web e conceitos fundamentais que servem de embasamento para a compreensão do trabalho proposto nesta dissertação. A Seção 2.1 dene Recuperação de informação e terminologias gerais; a Seção 2.2 descreve os modelos de sistemas de recuperação de informação; a Seção 2.3 descreve um modelo de arquitetura e modelagem genérica para de Sistemas de RI para Web e aspectos relacionados; a Seção 2.4 descreve basicamente como é denida uma consulta no sistema. E, por m, a Seção 2.5 cita algumas considerações nais do conteúdo tratado neste capítulo. 2.1 Recuperação de Informação Recuperação de Informação(RI) é a área que trata da representação, armazenamento, organização e acesso a itens de informação. Um Sistema de RI tem como objetivo básico responder ao seu usuário com uma representação e organização de itens de informação de modo que satisfaça os interesses desse usuário [9]. Um Sistema de RI não informa o usuário com conhecimento sobre o assunto de sua investigação, mas ele informa a existência e o local onde se encontram documentos relacionados com sua requisição [10]. Existem outras várias denições para Recuperação de Informação que vêm sofrendo alterações durante os anos devido à evolução dos problemas tratados pela área. A falta de uma denição formal é algo que já foi discutido por Raghavan [11] onde o autor encoraja uma discussão mais pontual sobre uma denição que identique de forma satisfatória o termo RI. O autor aconselha como ponto de partida o texto de Heaps [12] que resume RI da seguinte forma:...informação é comumente recuperada por meio de dados que repre-

21 2.1 Recuperação de Informação 6 sentam documentos. É a ênfase dada na informação relevante a uma requisição que caracteriza recuperação de informação moderna ao invés de ser apenas um ponteiro direto a um documento. As denições modernas de RI sempre tentam destacar as diferenças em relação a Recuperação de Dados (RD) visando esclarecer melhor o que realmente é RI. A Tabela 1 resume essas diferenças. Primeiramente, RD consiste em determinar quais documentos de uma coleção contêm o casamento exato das palavras chaves de uma consulta de usuário enquanto RI recupera informações sobre algum assunto que satisfazem à consulta tentando descobrir os documentos que interessem ao usuário, i.e., RI visa resolver a necessidade de informação do usuário. RD retorna todos os documentos usando consultas que satisfazem claramente condições que estão bem denidas em sua estrutura e em sua semântica, inverso de RI que trata de informações textuais em linguagem natural onde as consultas não são bem denidas estruturalmente e muitas vezes também não estão bem denidas na sua semântica. Outra diferença é que em RI um erro em milhares de respostas é aceitável enquanto em RD um erro qualquer implica em falha total. Para Sistemas de RI serem mais efetivos eles fazem uma interpretação sintática e semântica no conteúdo dos documentos com o objetivo de classicá-los de alguma forma relativa a alguma função de relevância (Seção 2.2) enquanto em RD os itens de resposta normalmente não são classicados, a não ser que o usuário especique na sua consulta a classicação que deve ser usada. Recuperação de Dados Recuperação de Informação Casamento Exato Parcial, melhor casamento Inferência Dedução Indução Modelo Determinístico Probabilístico Linguagem de Consulta Articial Natural Especicação da Consulta Completa Incompleta Itens Desejáveis Matching Relevantes Tabela 1: Comparação entre recuperação de dados e recuperação de informação- adaptada de [13] Denições Iniciais Os elementos básicos tratados em um sistema de Recuperação de Informação são: Palavra-chave ou termo: É uma seqüência de caracteres (string) que formam uma palavra;

22 2.1 Recuperação de Informação 7 Documento Texto 1 Caranguejo não é peixe, Caranguejo peixe é; 2 Caranguejo só é peixe na enchente da maré. 3 Ora, palma, palma, palma! Ora, pé, pé, pé! 4 Ora, roda, roda, roda, Caranguejo peixe é! 5 Cai, Cai, balão! Cai, Cai, Balão! Aqui na minha mão. 6 Não cai, não! Não cai, não! Não cai, não! Cai no meio do salão! Tabela 2: Repositório Exemplo: Um documento por linha com seu texto na segunda coluna. Página ou Documento: Uma página é uma seqüência de palavras identicada por um endereço. Um documento é a tupla (E, W*) onde E é o endereço da página e W* é a seqüência de nenhum termo ou vários termos representando o conteúdo do documento1; Corpus ou Repositório ou Coleção: É o conjunto de documentos armazenados no sistema. A Tabela 2 apresenta um corpus exemplo com 6 (seis) documentos; Vocabulário: É o conjunto de todos os termos distintos encontrados no corpus. No campo palavra-chave da Tabela 3 estão listados todos os termos que formam o vocabulário do corpus exemplo (Tabela 2); Endereço de uma Página ou simplesmente endereço: É o identicador único no corpus de um documento. O endereço de uma página é considerado como sendo uma URL2, a partir da qual pode-se recuperar o documento; Lista invertida: É a lista de documentos em que um termo da coleção ocorre; Posição do termo ou Posição: Indica a posição relativa do termo a partir do início do documento em quantidade de termos. Por exemplo, posição 1 (um) para o primeiro termo, posição 2 (dois) para o segundo e assim por diante; Lista de Posições: Para um termo t qualquer do vocabulário e um documento d qualquer pertencente ao corpus. A lista de posições pl t,d é a lista com todos os valores de posição do termo t no documento d. 1Alguns sistemas não armazenam o documento original, mas apenas o texto interno deixando de lado, por exemplo, informações de formatação do documento e caracteres de pontuação, já que a partir do endereço pode-se recuperar o documento original. 2Apesar de identicar unicamente um documento na coleção, várias URLs podem apontar para o mesmo documento. Até porque não existe uma forma canônica de representação de uma URL, por exemplo as URLs ou ou ou apontam para o mesmo documento físico.

23 2.1 Recuperação de Informação 8 Código Palavra-Chave Documentos Total de Ocorrências (Documento: posições) 1 aqui 1 (5:7) 2 balão 1 2 (5:3,6) 3 cai 2 8 (5:1,2,4,5)(6:2,5,8,10) 4 caranguejo 3 4 (1:1,5)(2:1)(4:5) 5 da (2:7) 6 do (6:13) 7 enchente (2:6) 8 maré (2:8) 9 meio (6:12) 10 minha (5:9) 11 mão 1 1 (5:10) 12 na 2 2 (2:5)(5:8) 13 no 1 1 (6:11) 14 não 7 (1:2)(6:1,3,4,6,7,9) 15 ora 2 (3:1,5)(4:1) 16 palma 1 3 (3:2,3,4) 17 peixe 3 4 (1:4,6)(2:4)(4:6) 18 pé (3:6,7,8) 19 roda 3 (4:2,3,4) 20 salão (6:14) 21 só 1 1 (2:2) 22 é 3 4 (1:3,7)(2:3)(4:7) Tabela 3: Vocabulário e lista invertida completa do texto exemplo Além destas denições, os valores numéricos bastante utilizados são: Tamanho do corpus (N): É o número total de documentos da coleção. Usado como parâmetro indicador do tamanho da coleção; Tamanho total do texto (B): É a soma do tamanho do texto original de cada documento presente no corpus; Tamanho do Vocabulário (n): É a quantidade de termos distintos que ocorrem na coleção. Usado como parâmetro indicador do tamanho da coleção. Textos escritos em linguagem natural têm a tendência de seguirem a distribuição de Zipf [14]. Desta forma, o valor de n tende a ser muito menor que o tamanho do corpus, por exemplo, uma coleção com 10 Megabytes de texto tem um vocabulário menor que 1% do tamanho do texto; Freqüência em documentos (df): O df de um termo é um valor indicando a quantidade distinta de páginas em que o termo aparece. Para cada termo t ocorrendo

24 2.1 Recuperação de Informação 9 no corpus o valor de df limita-se em 1 df t n. O campo Documentos da Tabela 3 equivale ao df do termo; Identicador de página (docid) e Identicador de termo (termid): Estes identicadores são valores internos em um sistema de recuperação de informação que representam unicamente cada documento(identicador de página) e cada termo (identicador de termo). Para cada termo e para cada documento é atribuído um valor numérico que será usado no sistema para tornar o processamento interno mais eciente. Para o usuário nal estes códigos não são visíveis. Estes identicadores são utilizados nos índices para evitar o armazenamento das strings dos termos ou dos endereços das páginas. Os valores limitam-se em 1 docid N e 1 termid n; Número de entradas (f): É a quantidade de pares (termid, docid) existentes no corpus. Podendo ser calculado a partir dos valores de df, onde f = n t=1 t. df Visão Lógica dos Documentos Um documento, basicamente, é modelado por um conjunto de palavras chaves ou termos (como descrito na seção anterior) retirados diretamente do documento original ou, também, podem ser adicionados por meio externo, como por exemplo, através de adição de informação extra ao documento via interação humana. O sistema de recuperação de informação deve ser responsável pela extração da informação textual do documento. Além disso, o sistema pode extrair outros dados que representem a estrutura sintática ou semântica do documento. A estrutura sintática equivale a estrutura organizacional formada por elementos que denem a formatação do documento, enquanto a estrutura semântica equivale ao signicado do conteúdo descrito no documento. Por exemplo, um documento pode ser indexado usando conceitos no lugar de palavras-chaves, estes conceitos identicam o signicado da palavra e, dessa forma, é possível recuperar um documento mesmo sem especicar exatamente as palavras-chaves presentes no documento. Isto é possível fazendo uma busca por por conceitos que estejam descritos no documento. A extração dos elementos do texto pode identicar informação relevante que pode ser usada para classicar de forma mais efetiva a relevância do documento em relação à consulta do usuário ou até mesmo extrair dados úteis ou ltros como, por exemplo, a língua do texto, localização geográca, assunto do documento. Além disso, o sistema também pode fazer outros tratamentos antes de gerar a representação interna nal do documento, neste tratamento pode-se usar técnicas de operações

25 2.1 Recuperação de Informação 10 sobre o texto, tais como: extração de stopwords, stemming, case folding e thesaurus [1]. Extração de Stopwords: Stopwords são palavras com elevada freqüência de ocorrência nos textos. Normalmente são elementos da gramática das línguas utilizadas nos textos que não denem nenhum conceito e não são úteis para identicação de assuntos especícos. Por exemplo, artigos, conjunções, advérbios são considerados stopwords e são adicionados na chamada lista de stopwords ou simplesmente stoplist. Todasaspalavraspertencentesaestalistasãoremovidasdotextoenãofazemparte do índice; Case folding: técnica que visa unicar palavras com diferentes capitalizações, por exemplo, as palavras chaves Página e página e PÄGINA e qualquer outra combinação seriam tratadas todas como página; Stemming: técnica utilizada para extrair os radicais de cada palavra do texto; Thesaurus: Esta técnica visa encontrar sinônimos das palavras do texto, deste modo pode-se usar apenas uma denição para os mesmos sinônimos economizando espaço. Witten, Moat e Bell [1] citam que o principal efeito causado pelo uso destas técnicas é a diminuição do tamanho do índice, principalmente quando aplicado a índices invertidos (Capítulo 3). Existem dois motivos para esta redução: o primeiro é que com o uso de stemming e case folding, o número de termos diminui consideravelmente; segundo, a freqüência média de termos no documento tende a aumentar de modo que o número de entradas total(f) do índice diminua. Os autores citam que o efeito destas duas técnicas na coleção TREC3 com 741 mil documentos reduz o número de entradas(f) em 16% e o número de termos distintos(n) em 40%, fazendo com que o tamanho do índice seja reduzidopara 30%doseutamanhooriginal. Elestambémcitamoefeitodousodatécnica de remoção de stopwords que proporciona um ganho signicativo ao tamanho nal do índice, pois estes termos praticamente aparecem em todos os documentos na coleção. Por exemplo, na mesma coleção TREC com um vocabulário com 535 mil termos distintos existem 33 termos que aparecem em mais de 38.2% dos documentos. Uma pequena fração do vocabulário que ocupa cerca de 11% do total de entradas do índice(f). Além disso a eliminação das stopwords afeta o tempo de processamento onde não é mais necessário 3A coleção TREC, um acrônimo para Text REtrieval Conference, é uma coleção disponibilizada na internet para ser usada por grupos de pesquisa com objetivo de fornecer uma base para comparação entre experimentos na área de recuperção de informação.

26 2.1 Recuperação de Informação 11 processar consultas com termos de stoplist diminuindo o tempo de processamento destas consultas Processo de Recuperação de Informação A Figura 1 ilustra os componentes básicos de uma arquitetura genérica para sistemas de recuperação de informação. Inicialmente existe o corpus do sistema que contém os documentos com toda a informação textual usada pelo sistema. A estrutura textual de cada documento do corpus é analisada e são retirados os elementos do texto para formar a visão lógica do documento. Sobre esta visão lógica é gerado o índice do sistema usado para responder as consultas dos usuários. A estrutura mais popular utilizada neste índice é o arquivo invertido mas podem ser usadas outras estruturas como as descritas na Seção 3.1. Figura 1: Processo de recuperação de informação Com o índice pronto, o usuário pode consultar o sistema. Para isto, o usuário utiliza uma interface de consulta onde ele especica sua necessidade de informação. Esta necessidade de informação é tratada e interpretada pelo sistema para depois ser feita a busca no índice onde são gerados os documentos recuperados que são classicados pelo

27 2.2 Modelos de Recuperação de Informação 12 sistema e listados para o usuário em ordem de relevância julgada pelo sistema relativa à necessidade de informação do usuário. Além disso o usuário pode interagir com o sistema examinando a resposta que lhe é mostrada e indicando ao sistema alguns destes documentos que realmente são relevantes e os que não são relevantes. O sistema pode usar esta informação para reformular a consulta e retornar outro conjunto de respostas mais aprimorado. 2.2 Modelos de Recuperação de Informação Modelos de recuperação de informação são formas sistemáticas que denem como um sistema faz o cálculo da relevância dos documentos, ou seja, basicamente tais modelos denem uma função de ordenamento e um framework de como é feita a representação dos documentos, das consultas e a relação entre eles. Um dos principais problemas de sistemas de recuperação de informação é predizer quais documentos são relevantes e quais não são. Esta decisão depende do algoritmo de cálculo de relevância utilizado, considerado como o núcleo do sistema, onde é denida a função de ordenamento do sistema. Esta função é uma relação que associa um número real a uma consulta e a um item de resposta. Tal função dene uma ordem entre os itens de resposta de modo que os itens que estejam no topo sejam os considerados mais relevantes. Na literatura surgiram vários modelos para este problema. Os modelos clássicos de RI são descritos nas próximas seções Modelo Booleano O modelo booleano [9] é um modelo de recuperação de informação simples baseado em teoria de conjuntos e algebra booleana. Por usar o conceito de conjuntos que é bem intuitivo, sistemas de RI baseados neste modelo tem uma interface de consultas fácil de ser utilizada por um usuário comum. Além disto, as consultas no modelo booleano são descritas como expressões booleanas tendo uma semântica precisa. Por estes motivos o modelo booleano foi adotado por vários sistemas de recuperação no passado. Entretanto, este modelo peca em usar uma estratégia de ordenamento baseado em decisão binária (um documento ou é relevante ou não) onde o sistema não consegue distinguir o grau de relevância dos itens de resposta de uma consulta. Outra desvantagem do modelo booleano é diculdade de fazer a tradução de uma necessidade de informação de usuário em uma

28 2.2 Modelos de Recuperação de Informação 13 expressão booleana Modelo Vetorial O Modelo Vetorial [15, 9] faz uso de modelagem em espaço vetorial possibilitando o uso de pesos como critério de ordenamento entre itens de resposta de uma consulta, e também, possibilita a recuperação por casamento parcial. Neste modelo os documentos e as consultas são tratados como vetores de um espaço n-dimensional onde cada dimensão é relativa a um termo distinto na coleção. O valor da função de ordenamento é calculado a partir de uma função de similaridade que opera sobre dois argumentos: a consulta e o documento; esta função é usada para denir o grau de correlação entre cada documento e a consulta. Uma medida simples que pode ser usada é a função do cosseno do ângulo formado entre os vetores da consulta e do documento como ilustrado na Figura 2. Existem várias outras funções de similaridade [16] sendo que esta função de cosseno é a mais utilizada. Figura 2: Modelo Vetorial baseado na função de cosseno do ângulo Os pesos usados nos vetores dos termos na função de similaridade podem ser calculados de várias formas. O esquema mais conhecido para estes pesos é o tf-idf que é baseado nas medidasde(i) tf i,j queéafreqüênciadotermo inodocumento j, ouseja, aquantidadede vezes que o termo i aparece no documento j; e (ii) df i que é a quantidade de documentos em que o termo i aparece. Estas duas medidas têm suas utilidades no cálculo da função de ordenamento. Para o tf, quanto maior a freqüência de um termo maior será o seu peso de ordenamento. O df é útil para indicar no valor da função de ordenamento os termos que ocorrem em muitas páginas. Estes tipos de termos são considerados pouco úteis pois

29 2.2 Modelos de Recuperação de Informação 14 não servem para distinguir se um documento é relevante ou não Modelo Booleano Estendido O modelo booleano Estendido [15] é basicamente a união do modelo clássico booleano com o cálculo de relevância usado no modelo vetorial evitando o problema de decisão binária de relevância. No modelo booleano estendido a consulta continua sendo representada por uma expressão booleana. Além disso, este modelo utiliza os critérios do modelo vetorial para classicar os itens de resposta que integram o espaço vetorial dos termos da consulta e satisfazem a expressão booleana da consulta Modelo Probabilístico O Modelo probabilístico tem como objetivo encontrar o conjunto de resposta que contenha todos os documentos relevantes e nenhum outro além destes. Este conjunto é denido como o conjunto ideal de respostas. Para encontrar este conjunto ideal o modelo probabilístico calcula a probabilidade de relevância de cada documento. Para gerar estas probabilidades o modelo assume que, para uma certa consulta q e um documento d, esta probabilidade depende de q e d apenas. As probabilidades de relevância de cada documento são calculadas a partir do índice de termos dos documentos classicados como relevantes Considerações Sobre Os Modelos Existe uma diculdade na escolha do melhor modelo a ser usado em um sistema de RI, principalmente porque não se sabe de que forma os modelos afetam o usuário. Além dos modelos clássicos citados nesta seção, existem vários outros denidos na literatura que podem ser considerados[9] e, dentre estes modelos, vários fatores podem ser considerados durante a escolha do modelo, não apenas o aspectos relacionados ao próprio corpus mas também os aspectos relacionados aos usuários do sistema. Observa-se que um sistema de RI para a Web possui características peculiares (Seção 2.3.3) e além disso os usuários as vezes nem sabem sequer o que procuram ou não sabem como formular uma consulta. Esta dissertação se baseia no modelo de Booleano Estendido por usar uma interface de consulta simples baseado em teoria dos conjuntos(seção 2.4) e por possibilitar uma forma de cálculo de relevância baseado em denições de documentos e palavras-chaves como as descritas na Seção

30 2.3 Sistemas de Recuperação de Informação para Web Sistemas de Recuperação de Informação para Web Sistemas de recuperação de informação automatizados foram originalmente desenvolvidos para ajudar no gerenciamento da grande quantidade de informação literária em universidades e bibliotecas públicas. Hoje em dia a grande quantidade de documentos disponíveis na Internet é um desao para a área de Recuperação de Informação no sentido de manter estruturas capazes de armazenar, recuperar e gerenciar essa quantidade de dados. São mais de três bilhões de páginas Web indexadas [5] em 40 milhões de sites e sendo acessadas por 605 milhões de usuários. E até mesmo hoje em dia este número cresce continuamente de forma exponencial [17]. Sistemas de recuperação de informação para Web, os conhecidos engenhos de busca, são bastante populares nos dias atuais chegando a obter alto nível de delidade entre os usuários onde cerca de 75% dos usuários da Web usam engenhos de busca para navegar pela rede 4. Sem dúvida o mais popular engenho de busca no momento é o google [5] que vem se mantendo líder entre os maiores engenhos de busca da atualidade por ser um dos mais ecientes no tratamento dos principais fatores críticos em um engenho de busca. Entre os fatores estão relevância, tamanho do índice, índice recente, desempenho e facilidade de uso 5. Nestes últimos anos, essa popularidade dos engenhos de busca chamou a atenção tanto da comunidade cientíca quanto do mercado nanceiro quando houve vários investimentos na área e a criação de sistemas de busca pelo mundo. Um deles foi o Radix6 que surgiu do projeto de pesquisa BRight [8] desenvolvido no Centro de Informática da Universidade Federal de Pernambuco, que era um sistema de busca especializado em indexar a Web brasileira onde foi desenvolvido todo o trabalho desta dissertação Modelo do Grafo da Web A Web podeservista comoumagrandebibliotecavirtual, ealémdosaspectoscitados nos itens anteriores, a Web tem características únicas que vêm sendo modeladas pela comunidade cientíca. Um dos modelos que é bem difundido atualmente é o modelo da Gravata Borboleta [18] que dene o grafo de hyperlinks dos documentos existentes na Web da seguinte forma. Nele existem três classes básicas de páginas como ilustrado na Figura 3 que são: 4http:// 5http://searchenginewatch.com/searchday/article.php/ www.radix.com.br

31 2.3 Sistemas de Recuperação de Informação para Web 16 Figura 3: A web vista como uma gravata borboleta Núcleo: é composto dos documentos com links entre si, ou seja, é um componente fortemente conexo; IN: é a classe das páginas que existe um caminho dela para o núcleo, mas não existe caminho inverso. Também chamada de classe da web invisível; OUT: são as páginas que podem ser alcançadas a partir do núcleo, mas não têm caminho de volta. São os pontos nais, sem saída; Dendritos: são as páginas restantes que não têm ligações para o núcleo e nem ligações do núcleo para elas. O grafo da Web é útil para se compreender a disposição dos documentos pela rede.estudos têm utilizado a estrutura de links para tentar identicar o comportamento da Web. Estes estudos visam identicar melhorias em sistemas de RI como, por exemplo, formas mais ecientes de crawling [19] e formas de ordenamento de páginas como algoritmo de Page- Rank[20] utilizado no google ou o algoritmo de HITS [21, 22] onde ambos utilizam o grafo de links da Web para fazer o cálculo de relevância dos documentos.

32 2.3 Sistemas de Recuperação de Informação para Web O Dinamismo da Web Além de estudos que modelem o Grafo de links da Web existem os que analisam o comportamento das páginas. O estudo do comportamento do dinamismo das páginas é útil porque ele pode ser usado como base para otimizações de estruturas ou de outros processos de modo geral. Em 2000 foi realizado um estudo sobre a freqüência de modicação das páginas da Web onde foram observadas meio milhão de páginas durante quatro meses [6]. Este estudo indicou que 23% das páginas são modicadas todos os dias e que o tempo de meia-vida das páginas foi de onze dias, isto é, em 11 dias metade das páginas deixam de existir. Estudo semelhante sobre a Web brasileira em 2002 [23] deniu uma metodologia usando técnicas de IA para classicação de grupos de páginas de acordo com a freqüência de atualização das páginas Web para diminuir o desperdício de recursos de rede gastos durante o crawling Desaos da Web Baeza-Yates e Ribeiro-Neto [24] descrevem os principais problemas associados aos dados da Web. Entre eles: Dados distribuídos: Em virtude da natureza intrínseca da Web, os dados estão espalhados em vários computadores em várias plataformas diferentes conectados com links de diferentes largura de banda; Alto percentual de dados voláteis: Grande parte dos dados na Web mudam bastante como descrito na Seção 2.3.2; Grande quantidade de dados: O crescimento exponencial da Web acarreta uma grande diculdade na manipulação de tamanha quantidade de dados; Dados não estruturados e redundantes: Grande parte dos documentos na Web não são bem estruturados e, além disso, a maioria dos documentos são repetidos (sites espelhos ou cópias simples) onde cerca de 30% das páginas da Web são cópias ou copias aproximadas (near duplicates) [25, 26]; Qualidade dos dados: Grande parte da informação textual presente na Web é feita com uma escrita pobre e muitos documentos contêm vários erros. São erros de graa, erros gramaticais e outros. Além disso, a informação pode ser falsa;

33 2.3 Sistemas de Recuperação de Informação para Web 18 Dados heterogêneos: O conteúdo da Web pode estar disponível em vários tipos de arquivos (vídeo, texto, imagem, som) e também em vários tipos de formatos (gif, jpg, png,...). Além disto, os documentos são escritos em várias línguas, escritas e dialetos Arquitetura Centralizada A maior parte dos engenhos de busca utiliza uma arquitetura centralizada de Indexação. Esta arquitetura se baseia no uso de crawlers que são programas que percorrem a Web coletando as páginas atualizadas e enviando-as para um servidor de indexação que mantém o índice do engenho. Os crawlers também são processos locais, normalmente executando na mesma máquina ou numa máquina na rede local. Eles recuperam os dados das páginas da Web via requisições HTTP. O Servidor de indexação mantém o índice atualizado e envia ao servidor de links os links que foram coletados para novas páginas. O servidor de links por sua vez alimenta os crawlers com novos endereços. Este processo é contínuo, e é deste modo que o sistema se auto-alimenta como ilustrado na Figura 4. Figura 4: Arquitetura centralizada Este tipo de arquitetura ainda oferece alguns problemas. O primeiro é que esta arquitetura gera um tráfego intenso de dados nas proximidades do engenho de busca saturando a rede usando os recursos de rede da Web de forma dispendiosa. Outro problema está

34 2.4 Consulta 19 associado com o tamanho da Web que torna impraticável o custo da capacidade de processamento e armazenamento para manter uma arquitetura central que suporte toda a Web Consulta Uma consulta é a forma de uma usuário exprimir sua necessidade de informação. Os engenhos de busca utilizam consultas baseadas em palavras chaves indicando que o usuário procura por documentos que contenham os termos especicados na consulta [9]. Os tipos básicos de consultas são: Consulta por uma única palavra: é uma consulta onde é especicado apenas um termo e onde são retornados os documentos que contêm este termo; Consulta por vários palavras: é uma consulta onde são especicados vários termos e são retornados documentos que contêm todas as palavras da consulta; Consulta por frase: é uma consulta formada por uma lista de palavras-chave que compõem uma frase e são retornados apenas os documentos que contêm esta frase, i.e., os documentos que contêm os termos na mesma seqüência que foram denidos pelo usuário; Consulta por proximidade: é uma consulta formada por palavras e frases e um parâmetro indicando a maior distância permitida entre elas. São retornados os documentos que contêm estas palavras ou frases não necessariamente na mesma ordem denida na consulta contanto que obedeça o limite da distância entre eles; Consulta booleana: é uma consulta formada por uma expressão lógica com palavras-chave e conectivos E, OU e NÃO, onde são retornados documentos que satisfazem a expressão formada pela consulta, cada conectivo equivale a uma operação lógica. A operação a E b recupera os documentos que contêm a e b, a operação a OU b recupera os documentos que contêm a ou b e a operação a NÃO b recupera os documentos que contêm a mas não contêm b8. Por exemplo, a Figura 5 ilustra a árvore sintática da consulta booleana (índice OU arquivo) 7Para se ter uma idéia, o google com um índice de 3 bilhões de páginas usa mais de servidores em um cluster linux ( 8A operação lógica clássica unária NÃO a indica que são retornados todos os documentos menos os que contêm a o que retornaria bastante documentos que provavelmente não seria o que o usuário gostaria. Por este motivo se usa a versão binária mais restrita.

35 2.5 Considerações Finais 20 E invertido que representa uma consulta por documentos que contêm as palavras arquivo ou índice e também contêm a palavra invertido. Figura 5: Exemplo da consulta booleana (índice OU arquivo) E invertido 2.5 Considerações Finais Este capítulo descreve um breve resumo do que é um Sistema de Recuperação de Informação para a Web com intuito de esclarecer os desaos acerca da implementação do sistema, listando as denições e conceitos básicos associados a um sistema de RI. A Seção 2.2 descreve os modelos para sistemas de RI onde é destacado o modelo Booleano Estendido, que é utilizado como base do conteúdo tratado nos próximos capítulos. Além disso, este capítulo descreve também, uma arquitetura genérica de um engenho de busca para a Web que é utilizada como molde para o sistema Radix descrito no Capítulo 4.

36 21 3 Índices e Técnicas para Sistemas de Recuperação de Informação Neste capítulo são descritas estruturas de dados utilizadas em índices para sistemas de Recuperação de Informação e técnicas para gerenciar estes índices de forma eciente com foco na estrutura de arquivo invertido. Inicialmente são descritas três estruturas de índices: Arquivo de Assinaturas, Array de Suxos e Arquivo Invertido. A Seção 3.1 descreve estas estruturas e faz uma comparação entre elas. A Seção 3.2 descreve a estrutura de dados B + -Tree que é utilizada na elaboração do índice VIF descrito no próximo capítulo. A Seção 3.3 aborda técnicas de compressão de índices. A Seção 3.4 descreve métodos ecientes para construção de índices invertidos. Na Seção 3.5 são abordadas técnicas para atualização do índice. A Seção 3.6 descreve como é realizado o processamento de consulta usando o índice invertido. Por m, a Seção 3.7 segue com algumas considerações nais sobre este capítulo. 3.1 Índices para Sistemas de RI Esta seção cita as estruturas de dados mais utilizadas para índices em sistemas de recuperação de informação na Web, dentre eles: arquivo invertido, array de suxo e arquivo de assinaturas Arquivo de Assinaturas ArquivodeAssinaturas[27]éaestruturadeíndicequesebaseianousodeassinaturas hash. Nas estruturas de índices de arquivos de assinatura existe uma função de hash que é usada para gerar as assinaturas das palavras. Além da assinatura das palavras existem as assinaturas dos documentos que são formadas pela união das assinaturas dos termos que ocorrem no documento usando a operação OR bit a bit ilustrada na Tabela 4. Para descobrir as páginas onde um termo qualquer aparece deve-se fazer uma operação AND

37 3.1 Índices para Sistemas de RI 22 de bits entre a assinatura do termo e a assinatura da página. Deste modo, se todos os bits da assinatura do termo estiverem presentes na assinatura da página, esta página é qualicada como possível resposta. Para saber se a página foi uma resposta real ou apenas um casamento incorreto, um false match, isso deve ser conrmado recuperando o documento. Por exemplo, uma consulta pelo termo inadequado cuja assinatura é quando for comparado com a assinatura do documento da Tabela 4 acontece um false match que será apenas vericado quando o documento for recuperado e for comprovado que o termo inadequado foi um engano. Quando não houver um casamento das assinaturas, então a página é classicada como não tendo o termo, sendo descartada de imediato. Além de uma busca simples, a estrutura é capaz de processar consultas com expressões booleanas. Para isto, basta realizar um processamento lógico em cima da assinatura de cada página. Essas estruturas têm custo de armazenamento baixo, cerca de 10% a 20% do texto, entretanto tem custo alto de processamento de consultas pois é necessária uma busca seqüencial no índice. Termo Assinatura exemplo arquivo assinatura Assinatura do documento Tabela 4: Documento codicado em um Arquivo de assinaturas Array de Suxos e Árvore de Suxos Árvores de suxos1 são estruturas capazes de armazenar suxos do texto dos documentos possibilitando não somente recuperar palavras-chave, mas também encontrar facilmente textos com partes de palavras ou frases exatas. A estrutura de árvores de suxos foi descrita pela primeira vez por Morrison, em 1968 [28], tendo Weiner [29] apresentado uma versão mais completa em Várias abordagens foram criadas visando melhorar o desempenho da estrutura, sendo que em 1976, McCreight expôs um algoritmo para a construção da árvore de suxos em tempo de execução linear [30]. Mais recentemente, em 1995, Ukkonen [31] apresentou um algoritmo on-line para a construção desta estrutura. 1Adotaremos esta terminologia para estruturas em Árvore de suxo(sux tree) e Array de suxo(sux array) também conhecidas como PAT tree e PAT array, respectivamente.

38 3.1 Índices para Sistemas de RI 23 Figura 6: Suxos de exemplo Figura 7: Árvore de suxos do exemplo Numa árvore de suxo cada posição do texto é um suxo diferente. Não necessariamente todas as posições estão presentes na árvore, são escolhidas preferencialmente as posições iniciais de palavras. A Figura 6 demonstra alguns suxos retirados do texto de exemplo. A árvore de suxo é semelhante a uma estrutura Trie de strings mas de forma compactada em uma Patricia Tree. Nas árvores de suxo os nós folhas contêm a posição inicial do suxo no texto e os nós internos direcionam a busca até os nós folhas baseados nos caracteres do suxo. Cada nó interno possui ligações para sub-árvores e cada ligação é nomeada por uma cadeia de caracteres especicando o prexo do suxo da sub-árvore. A Figura 7 ilustra a árvore de suxos resultante do texto exemplo. Entretanto, árvores de suxos não são utilizadas na prática para textos muito grandes por causa do alto custo de armazenamento onde é necessário alocar espaço para todos os nós e links da árvore.

39 3.1 Índices para Sistemas de RI 24 Array de suxos [32, 33] é uma implementação de Árvore de suxos com uso eciente de espaço em disco. Um array de suxos pode ser visto como uma forma compactada da árvore de suxos onde é usada apenas uma parte da árvore. O array de suxos contem apenas os nós folhas armazenados em um array na ordem presente na árvore de suxos. A Figura 8 ilustra o array de suxos do texto exemplo. Sobre o array de suxos pode ser utilizada uma estrutura auxiliar chamada de supra-index [9], ela é útil para indexar diretamente palavras do texto limitando o espaço da busca binária por padrões na estrutura. Este supra-index armazena para cada palavra chave do texto um ponteiro indicando o início da lista de suxos para esta palavra no array de suxos. Figura 8: Array de suxos do exemplo Em uma árvore de suxos a busca por um padrão qualquer de m caracteres pode ser encontrada em tempo O(m) com uma busca simples na árvore. Esta busca pode ser uma busca por uma palavra-chave, assim como o uso de arquivos invertidos, ou uma busca por uma frase exata ou até uma busca por parte de uma palavra. Nos arrays de suxos o tempo de busca é equivalente a uma busca binária no array em tempo O(log n) onde n é o número total de suxos. Uso do supra-index e de otimizações na busca binária utilizada podem diminuir este custo a algo em torno de 40% a 60% no tempo de processamento Arquivos Invertidos Arquivo invertido [15, 34] é um mecanismo para indexar coleções textuais ao nível de palavras. Arquivos invertidos são as estruturas mais utilizadas em sistemas de RI por serem a forma mais intuitiva de modelar e estruturar o acesso aos dados. A função principal de um arquivo invertido é retornar a lista de documentos onde ocorre um termo tendo como idéia básica o armazenamento do mapeamento inverso de termos para documentos. A estrutura de arquivo invertido é composta por dois elementos: o vocabulário e a lista invertida como ilustrado na Figura 9. O vocabulário contém o conjunto de todas as palavras distintas que aparecem no corpus, o vocabulário é muito menor quando

40 3.1 Índices para Sistemas de RI 25 comparado com a lista invertida e, dependendo do tamanho do texto original, pode ser gerenciado por completo em memória principal por uma estrutura Trie ou uma hashtable ou uma B + -Tree (Seção 3.2). Para o caso do texto não caber em memória, é necessário usar uma estrutura secundária normalmente uma B + -Tree ou um hashtable em arquivo. No vocabulário comumente são armazenados o número de documentos que o termo ocorre (df) e o ponteiro para a sua lista invertida. Figura 9: Exemplo arquivo invertido A lista invertida contém a relação de documentos onde cada palavra aparece. A informação presente em cada lista invertida são apontadores para os documentos que a palavra chave ocorre e, geralmente, são adicionadas outras informações que podem ser úteis durante o processamento de consultas como, por exemplo, a lista de posições de cada palavra que é adicionada para que seja possível processar consultas por frases exatas ou consultas por proximidade. Os índices de arquivos invertidos normalmente são criados a partir de um processo em batch, deste modo sempre que se deseja atualizar a base é necessário inverter2 a base por completo. Existe um procedimento com tempo de execução proporcional ao tamanho do corpus para esta inversão [13]. Entretanto, este procedimento é útil apenas para bases pequenas ou que sejam estáticas ou semi-estáticas, isto é, que modiquem pouco e poucas vezes, mas para a Web este processo não é eciente o suciente. Outros trabalhos denem estruturas de índices invertidos otimizadas para operações de acréscimo de páginas, isto é, apenas com adição de novas páginas, e o resultado experimental foi um procedimento com tempo de execução proporcional ao tamanho do texto a ser adicionado [35, 36]. Mais detalhes sobre a estrutura de arquivo invertido serão tratados no próximo capítulo. 2usamos o termo inverter ou inversão para indicar o processo de gerar o arquivo invertido

41 3.1 Índices para Sistemas de RI Granularidade do Índice Granularidade de um índice [1] é o nível de precisão de um índice em localizar uma palavra. Existem três níveis básicos de granularidade de índices que são: (a) no nível de palavras, presente no índice chamado índice invertido completo e (b) no nível de documento, o mais popular, presente no índice chamado arquivo invertido ou índice invertido e (c) no nível de blocos, presente no índice baseado no endereçamento de blocos. Em (a) cada palavra é armazenada com a informação de localização completa da palavra no documento, neste caso, o índice armazena todas as posições de palavras existentes, este tipo de índice serve de apoio para poder processar consultas por frases. Mas no nível de documentos (b) todas as entradas de uma mesma palavra em um documento são colapsadas em uma entrada única. Dependendo da granularidade, o índice pode precisar de menos espaço de armazenamento. Entretanto a quantidade de casamentos inválidos (false matches) durante o processamento pode aumentar gerando a necessidade de leitura do texto original com impacto direto no tempo de processamento. E, por m, existe a granularidade no nível de blocos (c) que é ainda mais esparso que no nível de documentos, onde o repositório é dividido em blocos sendo que cada bloco pode conter parte de páginas ou até várias páginas pequenas. Este nível de granularidade é utilizado no índice de endereçamento de blocos descrito na próxima seção. Bloco Texto 1 Caranguejo não é peixe, Caranguejo peixe é; Caranguejo só é peixe Na enchente da maré Ora, palma, palma, palma! Ora 2 pé, pé, pé! Ora, roda, roda, roda, Caranguejo peixe é! Cai, Cai, balão! Cai, Cai, Balão! Aqui na minha mão. 3 Não cai, não! Não cai, não! Não cai, não! Cai no meio do salão! Tabela 5: Texto exemplo dividido em blocos de 20 palavras Índice Baseado em Endereçamento de Blocos O índice baseado em endereçamento de blocos [9] é fundamentado no agrupamento de páginas em blocos sobre um índice invertido. Neste índice, cada bloco contém parte do texto de uma página ou vários textos de várias páginas pequenas. Quando uma palavrachave ocorre várias vezes no mesmo bloco esta entrada é armazenada apenas uma única vez no índice. Deste modo, o índice se torna mais compacto que um índice invertido que aponta para todas as ocorrências, os chamados índices invertidos completos. Esta

42 3.1 Índices para Sistemas de RI 27 técnica, além de colapsar todas as entradas de uma mesma palavra-chave dentro de um bloco fazendo com que haja menos ponteiros, também utiliza ponteiros menores pois há menos blocos do que entradas. Usando esta técnica o índice chega a 5% do texto. A Tabela 6 mostra o vocabulário e a lista de blocos do corpus exemplo dividido em blocos de 20 (vinte) palavras (Tabela 5) onde a lista de blocos é claramente menor que a lista de documentos e posições completa mostrada na Tabela 3. Mesmo ocupando pouco espaço, comparado com o índice invertido completo, com este índice não é possível processar consultas sem apoio ou do texto ou de outra estrutura. Ele serve de apoio à busca diminuindo a quantidade de páginas que serão vericadas. Código Palavra-Chave Blocos Lista de Blocos 1 aqui 2 balão cai 2,3 4 caranguejo 2 1,2 5 da 1 6 do 3 7 enchente 8 maré 1 9 meio 3 10 minha 11 mão na 2 1,2 13 no não 1,3 15 ora 2 1,2 16 palma peixe 2 1,2 18 pé 19 roda 2 20 salão 3 21 só é 2 1,2 Tabela 6: Vocabulário exemplo com índice de endereçamento de blocos Considerações Sobre As Estruturas Apresentadas As estruturas apresentadas nos itens anteriores têm suas vantagens e desvantagens. Esta seção faz uma comparação supercial destas estruturas utilizando como base o artigo de Zobel [37] que mostra a comparação entre índices de arquivo invertido e arquivo de assinaturas. No artigo são considerados os seguintes aspectos: espaço utilizado pela

43 3.1 Índices para Sistemas de RI 28 estrutura, memória extra necessária durante o processamento, tempo de criação do índice, tempo de atualização, escalabilidade, aspectos em relação a função de ordenamento e extensibilidade da estrutura. Estes aspectos são considerados a seguir com um breve resumo comparativo entre as estruturas, conforme seguem: Espaço: Em 1981, Haskin estimou que o espaço ocupado pelo arquivo invertido seria cerca de 50% a 300% do tamanho do texto indexado [38] mas com uso de técnicas atuais de compressão (Seção 3.3) o índice chega a ocupar aproximadamente de 6% a 10% do espaço do texto indexado pelo índice [39]. O tamanho de índice de arquivo de assinaturas chega a ocupar de 25% a 40% do espaço do texto indexado pelo arquivo de assinaturas [40, 41]. Para o índice de árvore de suxos o aspecto de espaço utilizado é o que tem maior peso onde o tamanho do índice chega a ocupar de 120% a 240% do tamanho do texto [9]. Este aspecto torna inviável o uso desta estrutura, Entretanto, o uso de array de suxos não é tão dispendioso, necessita cerca de 40% do tamanho do texto; Memória: Um índice invertido utiliza memória extra para armazenar o vocabulário que não necessariamente precisa estar em memória por ocupar pouco espaço, entretanto, normalmente o vocabulário é mantido em memória para evitar uma operação de leitura à disco extra a cada acesso às listas invertidas. O mesmo acontece para a estrutura de array de suxos, caso seja utilizada a estrutura auxiliar supra-index para armazenar o início das palavras indexadas no array de suxos. De forma análoga, comparado com arquivo invertido, o supra-index funciona como o vocabulário e pode ser armazenado em memória para evitar uma operação de acesso a disco a mais. Já arquivo de assinaturas não necessitam de memória extra; Tempo de Criação: Basicamente o tempo de criação em índices de arquivo invertido e arquivo de assinaturas são equivalentes, os procedimentos para construção dos dois índices são semelhantes, ambos baseados em leitura e divisão do arquivo de entrada como o procedimento descrito na Seção Entretanto, nos experimentos realizados por Zobel [37], o tempo de construção do arquivo invertido foi de 40 minutos, muito menor que os 86 minutos necessários para gerar o arquivo de assinaturas para uma mesma base textual. Isto acontece basicamente por dois motivos. Primeiro o arquivo invertido tem a vantagem de precisar de menos espaço e com isso a quantidade de dados processadas é menor. E, segundo, arquivo de assinaturas tem a desvantagem de precisar gerar várias vezes valores de hash durante a criação que precisa de mais processamento comparado com operações de lookup em tabelas

44 3.1 Índices para Sistemas de RI 29 realizadas na construção do arquivo invertido. Em relação ao array de suxos, o tempo de criação chega a ser de 5 a 10 vezes maior que o tempo necessário para criar o arquivo invertido para mesma base [9]; Atualização: Atualização de índices invertidos é uma operação complexa, dependendo do nível de atualização que se procura, pode-ser utilizar um estrutura dinâmica para manipular o índice como uma B + -Tree(Seção 3.2). Entretanto, usando uma estrutura como esta geram novos overheads de espaço extra, pois, a propria estrutura utiliza cerca de 67% espaço extra e gera também um tempo maior de leitura. Para a atualização de um arquivo de assinaturas e array de suxos seria necessário também uma estrutura de B + -Tree. Mesmo assim, métodos de atualização do índice podem ser mais ecientes quando são usados atualizações em batches como, por exemplo, usando técnicas descritas nas Seções 3.4 e 3.5; Escalabilidade: Para uma consulta qualquer, o número de acessos ao disco nos índices de arquivo invertido quanto e arquivo de assinaturas são independentes de escala, isto é, o custo assintótico de processamento do índice é a quantidade de dados a ser transferida do índice. Entretanto, para arquivos de assinaturas, o custo de processamento é linear em relação ao tamanho do corpus sem levar em consideração a consulta realizada. Em contrapartida, no arquivo invertido, o tamanho médio das listas invertidas é sublinear em relação ao tamanho do corpus, já que a medida que novos termos aparecem são criadas novas listas vazias para estes termos. De forma análoga um array de suxos os blocos que armazenam as entradas do array tem crescimento sublinear. Conseqüentemente, os índices de arquivo invertido e array de suxos têm melhor escalabilidade que o arquivo de assinaturas; Ordenamento: Para uma consulta qualquer, é utilizada uma função de ordenamentoparagerarumvalorderelevânciaemcadadocumentodocorpusemrelaçãoa consulta. Então, os documento são ordenados em relação a este valor e são retornados os melhores para o usuário. Neste aspecto, o índice invertido possui a vantagem da simplicidade, principalmente considerando a função de ordenamento baseada no cálculo de tdf (Seção 2.2). Neste aspecto, o array de suxos têm vantagem de oferecer de forma inata informações necessárias para processamentos de consultas por frase exatas e consultas por proximidades (Seção 2.4). Além disso, um array de su- xos pode ser utilizado para realizar consultas por casamento aproximado diferente de arquivo invertido que precisa fazer um pré-processamento sobre o vocabulário para resolver este tipo de consulta[9];

45 3.2 Estrutura de Índice Dinâmico B + -Tree 30 Extensibilidade: Basicamente, o arquivo de assinaturas pode ser visto como uma estrutura binária indicando que propriedades estão presentes ou não. Deste modo, este tipo de índice pode ser considerado menos extensível do que o arquivo invertido e um array de suxos. No arquivo invertido, pode-se adicionar propriedades extras à estruturas agregadas a cada entrada na estrutura, como, por exemplo, a lista de posições (como mostrado na Seção 4.2.6) possibilitando processamento de consultas por frases exatas ou por proximidade (Seção 2.4). De forma semelhante, podese adicionar informações extras às entradas no array de suxos. Pode-se colocar, por exemplo, informações de como cada palavra está formatada no texto original (tamanho da fonte, se esta em negrito, itálico, etc). Fundamentado nos aspectos evidenciados acima, a partir desta seção o arquivo invertido será usado como índice a ser estudado onde são descritas técnicas de construção, atualização e processamento de consultas sobre este índice. Esta escolha se baseia, principalmente, pelos fatores de espaço ocupado com uso de técnicas de compressão descritas na Seção 3.3, e também por sua simplicidade. Além disso, a estrutura de índice VIF descrita no próximo capítulo que utiliza como base outros dois índices sendo um deles uma estrutura de arquivo invertido simples. Mais além, a estrutura do índice VIF se baseia em uma B + -Tree(descrita na próxima seção) fundamentalmente por ser uma estrutura dinâmica com o objetivo de oferecer atualização do índice de forma mais eciente. 3.2 Estrutura de Índice Dinâmico B + -Tree B -Tree [42, 43, 44] é uma estrutura dinâmica para índices baseada em árvore de busca + criada com intuito de gerenciar dados armazenados em memória secundária. A estrutura da B -Tree se baseia numa árvore balanceada onde os nós internos direcionam a busca e os nós + folhas armazenam as entradas de dados. Cada nó contém no máximo D entradas, onde este parâmetro D é chamado de grau da árvore ou a ordem da B -Tree. O número de entradas + M de cada nó varia entre D M D para todos os nós exceto a 2 raiz que pode armazenar 1 M D quando a árvore está vazia ou com poucos dados. Essa condição faz com que a ocupação mínima de 50% seja garantida. Cada nó interno da B -Tree inclui chaves de busca e ponteiros para outros nós, sendo que cada nó armazena + M valores de chaves de busca (K 1, K 2,..., K M ) e M + 1 ponteiros (P 1, P 2,..., P M+1 ). As chaves de busca dos nós internos servem apenas para guiar a busca pelaárvoreeosponteirosindicamoendereçofísicoemdiscoondeselocalizaopróximonó.

46 3.2 Estrutura de Índice Dinâmico B + -Tree 31 Nos nós folhas são armazenadas M chaves de busca e para cada chave K i é armazenado um valor D i do dado associado a esta chave. Além disto, nos nós folhas existem ponteiros P P apontando para o próximo nó folha fazendo com que todos os nós folhas formem uma estrutura de lista encadeada facilitando a listagem seqüencial3. Estruturalmente os nós internos e nós folhas são iguais como mostrado na Figura 10 apesar de um armazenar ponteiros e outro armazenar dados. Na gura são mostradas as estruturas do nó interno e folha para uma B + -Tree de grau 2. Figura 10: Estrutura do nó da árvore B + -Tree de grau Busca na B + -Tree As operações de busca oferecidas pela B + -Tree são: Busca por um elemento: Onde dada uma chave K deve-se encontrar o nó onde a chave se encontra e recuperar a entrada de dados associada à chave; Busca por todos os elementos: Recupera uma listagem completa e ordenada de todos os elementos contidos no índice. Esta operação é executada fazendo uma busca pelo primeiro nó folha existente, i.e., o nó onde não existe nenhuma outra chave menor que a menor chave deste nó. Então, a partir deste nó, é feita uma leitura seqüencial na lista de todos os nós folhas usando os ponteiros de encadeamento entre folhas; Busca por um intervalo de elementos: Nesta operação são passados dois argumentos necessários A e B que são chaves especicando a fronteira da lista que será recuperada. Ao nal serão retornados de forma ordenada todos os elementos onde a chave de busca do elemento esteja no intervalo [A, B] onde A B. Para isto faz-se uma busca na árvore pelo nó folha que contenha o primeiro elemento da lista, isto é, o nó que contenha o menor elemento L existente no intervalo que satisfaça a condição 3algumas implementações adicionam um ponteiro para o nó folha anterior criando uma lista duplamente encadeada

47 3.2 Estrutura de Índice Dinâmico B -Tree 32 + L [A, B] e i [A, B] L i. a partir deste elemento se faz uma busca seqüencial na lista encadeada dos nós folhas de forma ordenada retornando todos os elementos E enquanto a condição esteja satisfeita(e [A, B]). Esta operação pode ser vista como uma generalização das duas buscas anteriores onde a primeira operação pode ser modelada como uma busca onde A = B = K e a segunda operação uma busca onde A = e B = +. Estas operações de busca podem ser divididas em duas etapas: (a) uma busca nos nós internos da árvore até encontrar o nó folha desejado e (b) uma busca seqüencial na lista encadeada dos nós folha (menos para o caso de recuperar apenas um elemento). Na busca pelo nó folha o procedimento recursivo da busca por um elemento de chave K tendo início no nó raiz é denido como: Caso Base: Se o nó atual for um nó folha a busca termina. Indução: Se o nó atual for um nó interno com M chaves K 1, K 2,..., K M com M + 1 ponteiros P 1, P 2,..., P M+1 deve-se encontrar o primeiro ponteiro para P j tal que K < K j, caso K seja maior que K M então se deve usar o ponteiro de P M+1 e continuar o procedimento recursivamente no nó lho de ponteiro escolhido. Desta forma, as chaves presentes nos nós internos servem como guias para encontrar as folhas. No exemplo da Figura 10 existe apenas um nó interno que é a própria raíz. Neste nó existe uma chave apenas com o valor E. Esta chave indica que existem dois nós lhos da raíz. Um nó cujo valores são menores que E e outro nó cujo valores são maiores ou igual a E com localização indicada pelos primeiro e segundo ponteiros da raíz, respectivamente P 1 e P Inserção na B + -Tree A inserção de um elemento visa adicionar o elemento na estrutura de modo que se mantenham as características de uma árvore balanceada. Uma inserção é feita em dois passos, o primeiro é encontrar f, o nó folha da árvore onde o elemento deve ser inserido. Para isto basta fazer uma busca como descrito na seção anterior. Com o nó em mãos, o dado deve ser inserido no nó. Quando o nó não está cheio então é feita uma inserção simples, basta adicionar o novo elemento na árvore no nó f, como ilustrado na Figura 11. Caso ocorra um overow, isto é, o nó esteja no limite de sua capacidade, então será necessário realizar uma operação de divisão do nó, que consiste em criar um novo nó vazio

48 3.2 Estrutura de Índice Dinâmico B + -Tree 33 Figura 11: Inserção simples em B + -Tree v e distribuir igualmente as entradas do nó f mais a nova entrada que está sendo inserida entre os nós f e v. Em seguida, deve ser inserido o ponteiro de v no nó pai de f com a chave do primeiro elemento de v. Na Figura 12 a adição do elemento (D, 5) gera overow em f, o ponteiro de v é inserido na raíz que é o pai de f. Além disso, o ponteiro do próximo nó folha é atualizado em f, onde o novo nó v é inserido entre f e o nó apontado por P P de f. Figura 12: Inserção em B + -Tree com nó cheio À medida que a árvore vai crescendo pode acontecer overow nos nós internos caso os nós estejam cheios. Nesse caso, deve-se realizar uma operação de divisão no nó interno (o pai de f). Este processo pode ocorrer recursivamente duplicando e inserindo novos ponteiros no nó pai até que se encontre um nó interno que não esteja cheio. O pior caso da inserção acontece quando os nós internos e a raiz estão todos cheios, neste caso, a árvore é acrescida de um novo nível, um novo nó extra é criado e este nó passa a ser a nova raíz da árvore como mostrado na Figura 13 com a inserção do elemento (G, 6) ocorre um overow na raíz quer é dividida sendo criado um novo nó interno e uma nova raíz onde a raíz anterior passa a ser um nó interno comum Remoção na B + -Tree Remoção em B + -Tree é a operação mais complexa e, muitas vezes, é simplesmente ignorada. A complexidade desta operação está em apagar dados sem quebrar as pro-

49 3.3 Compressão 34 Figura 13: Inserção em B + -Tree com nó interno cheio e aumento da profundidade priedades de balanceamento da árvore. Por isto, na maioria das vezes, é utilizada uma abordagem mais simples onde o espaço utilizado pelos itens removidos são apenas liberados sem que seja feito o re-balanceamento da árvore a cada operação de remoção. Como este tipo de operação é pouco utilizada, o balanceamento da árvore sofre pouca modicação com o tempo. Mesmo assim é aconselhado que a árvore seja reconstruída para evitar que o desempenho da árvore degrade demasiadamente. 3.3 Compressão Mesmo com o crescente aumento na capacidade tanto de armazenamento de mídias secundárias quanto de banda de transmissão de dados, muito esforço tem sido alocado no uso de compressão de dados. O problema de compressão não é novo, métodos de compactação têm sido inventados e reinventados ao longo dos anos. Um dos primeiros e mais conhecidos métodos de compressão de texto é a codicação de Human [45] que usa idéia que lembra o código Morse. Na codicação de Human caracteres mais comuns são codi- cados usando menos bits, enquanto caracteres que aparecem raramente são codicados

50 3.3 Compressão 35 com mais bits. Este método foi publicado nos anos 50 e permaneceu por décadas como uma das melhores técnicas de compressão existentes até o aparecimento, nos anos 70, da compressão Ziv-Lempel [46] e codicação aritmética [47] com maiores taxas de compressão. Estas duas técnicas usam compactação adaptável onde o texto é compactado com um modelo que é construído dinamicamente baseado no texto que está sendo codicado (Figura 14) e durante a decodicação o modelo é reconstruído simultaneamente com o texto que está sendo descompactado. O método Ziv-Lempel é rápido e obtém boa taxa de compressão com uso moderado de memória. Apesar da codicação aritmética ter muito boa taxa de compressão o tempo de codicação e decodicação é lento [1]. Figura 14: Compressão de texto usando modelo Algoritmos de compressão modernos como block sorting, LZW, PPM [1] chegam a diminuir o espaço necessário para armazenamento de texto em até 25% do tamanho original. Apesar desta economia de espaço, o custo agregado de codicação e decodicação do texto fazia com que compressão e processamento on-line de consultas fossem utilizados de forma exclusiva. Entretanto, atualmente, técnicas de compressão especializadas têm sido fundamentais em sistemas de RI. Um fator para isto é que o aumento do poder de processamento das máquinas cresceu bastante enquanto o tempo de leitura e escrita em dispositivos de armazenamento secundário teve um crescimento inferior. Em engenhos de buscaotempogastoépredominantementeemoperaçõesemdiscoeacpuénormalmente sub-utilizada. Hoje em dia, e com o poder computacional das arquiteturas modernas, o tempo de espera para recuperar um byte em memória está entre 12 e 150 ciclos de CPU enquanto uma leitura em disco precisa de (dez milhões) ciclos de CPU. Esse poder de processamento latente pode ser usado com algoritmos de compressão. Além disso, o uso de compressão diminui a quantidade de operações necessárias na leitura em disco com impacto sensível no tempo necessário para as principais operações em engenhos de busca, entre elas busca e construção do índice. Ou seja, a compressão traz economia de espaço utilizado e também traz economia de tempo de processamento [48, 49, 50]. A compressão pode ser usada tanto para armazenar o texto original compactado

51 3.3 Compressão 36 quanto também na compressão do índice. Existem várias técnicas de compressão, mas apenas algumas se aplicam ao problema de Recuperação de Informação. Uma técnica boa é aquela que oferece características de boa velocidade de codicação e decodicação, alta taxa de compressão, possibilidade de decodicação aleatória e não seja gulosa no uso do espaço em memória. Em Sistemas de RI, por armazenarem grande quantidade de texto, a economia é bastante signicativa. Para alcançar esta melhoria no desempenho é necessário que o algoritmo de compressão escolhido seja eciente, de forma que não degrade o desempenho anulando o ganho de operações em disco. Dependendo do modelo decompressãoutilizadonãohaveráperdas, massimganhodeespaçoeganhodetempode indexação e consulta. As próximas seções descrevem técnicas de compressão de índices Métodos de Compressão de Índices Técnicas de compressão de índices têm os pré-requisitos de serem velozes e de consumirem pouco tempo de processador. Uma vantagem dos índices invertidos é o fato de serem estruturados de modo que as informações armazenadas são listas de números ordenados. Esta característica possibilita armazenar apenas as diferenças dos números. Este método é chamado de codicação por diferenças ou codicação delta( ) [1, 49]. Na função de codicação uma lista é armazenada mantendo-se o primeiro elemento original e para cada elemento seguinte de índice i (i > 0) o valor armazenado é a diferença entre o elemento i e o elemento i 1. Esta transformação das listas é importante pois os valores armazenados serão menores como mostrado logo abaixo e, juntamente com uso dos métodos que serão descritos nas próximas seções, aumenta a taxa de compressão, já que, na maioria destes métodos, quanto menor o valor do número, menos bits são necessários para armazená-lo. Lista de ocorrência: (3, 7, 15, 16, 26, 34, 67, 197, 198, 199, 299). Codicação : (3, 4, 8, 1, 10, 8, 33, 130, 1, 1, 100) Codicação com Quantidade Variável de Bytes A codicação com quantidade variável de bytes(vbc) utiliza uma quantidade variável de bytes para codicar um número qualquer x. Nesta codicação em cada byte do código gerado é reservado um bit (o primeiro bit) para indicar se o byte atual é o último byte ou não. Como cada byte armazena 7 bits são necessários (log x)/7 bytes para armazenar x. A codicação gera os bytes do código seqüencialmente, para cada byte é atribuído o

52 3.3 Compressão 37 valor 0 para o primeiro bit indicando que existem mais bytes e o último byte é atribuído o valor 1 para o primeiro bit para indicar que este é o último byte Codicação Elias Os métodos de codicação de números Elias-γ e Elias-δ propostos por Elias [51] são modelos globais e não parametrizados para codicação de números usando uma quantidade variável de bits, bastante utilizados para compressão de índices invertidos [1, 49, 50]. O código Elias-γ é denido como: para um número x qualquer, o código é dividido em duas partes, a primeira armazena o valor em unário para 1 + log x ; na segunda parte são armazenados log x bits em formato binário para o valor de x 2. A parte unária indica quantos bits são necessários para codicar log x x e a segunda parte codica x em binário. O código unário utilizado para armazenar a primeira parte necessita de um número variável de bits. Para armazenar um número qualquer y em unário são necessários exatos y bits onde para os (y 1) primeiros bits é atribuído o valor 1 e o último bit recebe o valor 0. A codicação Elias-δ é semelhante, uma forma simples de denir é baseada na denição de Elias-γ onde a primeira parte em vez de ser codicada em unário é codicada usando a própria codicação Elias-γ. A codicação Elias-δ gera códigos maiores para números pequenos se comparado com os gerados por Elias-γ, entretanto para valores grandes, por exemplo (um milhão), os códigos Elias-δ são menores. A Tabela 7 mostra os valores de 1 a 10 codicados usando codicação Elias-γ e Elias-δ com as duas partes do código gerado separadas pelo caracter.. Número Unário Elias-γ Elias-δ Golomb (b=3) Tabela 7: Exemplo de codicação para números usando as codicações unário, Elias-γ, Elias-δ e Golomb (b=3)

53 3.4 Construção do Índice Codicação Golomb A codicação de Golomb [52, 50, 1] é um modelo de codicação que consegue melhor taxa de compressão e tem melhor tempo de decodicação que o método de Elias. Este modelo é ótimo assumindo que o conjunto de documentos de um dado termo é aleatório. Os códigos gerados se adaptam à sua densidade de valores através de um parâmetro usado para determinar o código emitido para um número. Este parâmetro pode ser global para toda coleção ou local para uma lista invertida de um termo e normalmente é armazenado usando codicação Elias. Para codicar um número inteiro x (x > 0) usando o método de Golomb com um parâmetro b, primeiro é gerado o valor q + 1 em unário, onde q é o quociente com q = ; logo após a primeira parte é codicado o valor do resto x 1 b r = x qb 1 em binário, usando ou log b ou log b bits. Para decodicar o resto usa-se o valor t = 1 ((log x) + 1) b, onde (a b) é a operação de deslocamento de b bits de a para a esquerda (left-shift). Depois de recuperar log b bits do resto, r é comparado com t. Se r > t então é necessário ler mais um bit para r. A escolha do parâmetro b pode ser feita de modo a minimizar o número de bits necessários na codicação de uma lista. Para os casos onde a probabilidade de um valor particular z ser pequena, que é o que acontece para os valores de docid, então b é minimizado quando b = 0.69 media(z) [1]. Pode-se escolher uma aproximação global da média usando estatísticas do corpus, i.e. b = Neste caso o parâmetro N.n b será global, utilizado em todas as listas, entretanto f parâmetros locais têm melhor taxa de compressão. O valor de b pode ser local em cada lista invertida de termo t, neste caso a aproximação da média é b = 0.69 N df t. 3.4 Construção do Índice O processo de construção visa gerar a partir de uma coleção de páginas um índice invertido. Este processo, que recebe o nome de inversão, é realizado em batch tendo como entrada o conjunto com todos os documentos da coleção e gera como saída o índice invertido. O processo de inversão pode ser simples e eciente de forma ad-hoc gerando o índice em memória usando algoritmos e estruturas de dados simples. Este processo ad-hoc pode ser dividido em duas fases: primeiro é feito o parsing dos documentos extraindo os termos e gerando o vocabulário e a lista de incidência em memória. O vocabulário pode ser armazenado usando uma estrutura em árvore binária ou uma hashtable, enquanto a lista de ocorrências é armazenada em memória utilizando uma estrutura de lista ligada. E, por m, as listas em memória são compactadas e armazenadas em disco como ilustrado

54 3.4 Construção do Índice 39 em pseudo-código na Figura 15. Este tipo de inversão é útil apenas para coleções muito pequenas, pois é limitado em número de páginas pelo tamanho de memória disponível. Para coleções grandes é necessário um procedimento eciente para inversão de páginas como os descritos nas próximas seções. Algoritmo 1 Procedimento MemAdHocInv(C, N) Entrada: O corpus C, número de documentos no corpus N Saída: Arquivo invertido I, O Vocabulário V 1. seja V o vocabulário vazio 2. ( Fase 1: leitura e armazenamento das listas em memória ) 3. para i 1 até N 4. faça seja D C i o i-ézimo documento no corpus 5. faça o parsing dos termos de D 6. seja T o número de termos em D 7. para j 1 até T 8. faça seja t D j o j-ézimo termo do documento D 9. seja f D,t a freqüência do termo t no documento D 10. se t / V 11. então V V t 12. seja L t a lista invertida do termo t 13. adicione a entrada (D, f D,t ) a lista L 14. t ( Fase 2: compactação e geração do arquivo em disco ) 15. seja #V o número de termos no vocabulário V 16. para i 1 até #V 17. faça seja t V i o i-ézimo termo no vocabulário V 18. seja L t a lista invertida do termo t 19. compacte a lista L t e armazene em I 20. Figura 15: Procedimento de inversão em memória - [1] Construção Linear Baseada em Partições Este procedimento é um processo de inversão com tempo de processamento linear baseadonousodememória[13]. AFigura16ilustraesteprocessoquerecebecomoentrada (0. fase inicial) um arquivo com as listas de entradas de documentos e termos e executa em três passos. Primeiro é feita uma leitura completa do arquivo de entrada composto pela lista de tupla (docid, termid, freq) gerando em memória a tabela de controle e a tabela de amostras (1. preparação). O Segundo passo divide o arquivo de entrada em várias amostras. O objetivo é dividir o arquivo de entrada (2. divisão da entrada) em A partes que possam ser carregadas usando o máximo de memória disponível R. O valor de

55 3.4 Construção do Índice 40 Adepende de R, do número total deentradas docorpus f, e dotamanho de cadaentrada. Cada entrada é composta por três valores numéricos inteiros, normalmente usando 4 bytes para representar cada inteiro, A é calculado pela fórmula A =. O segundo passo gera 12f R as A amostras onde cada uma armazena a parte do arquivo de entrada contendo todas as palavras chaves de um intervalo xo distinto. Cada intervalo é denido por dois códigos de termo termid i e termid f. Estes valores são escolhidos satisfazendo as condições de memória para cada amostra. O terceiro e último passo inverte cada amostra em memória (3. inversão de cada amostra) baseado na tabela de controle usando um algoritmo de ordenação counting-sort descrito em pseudo-código no anexo A. A tabela de controle armazena os índices de cada termo pré-calculados na fase inicial a partir do df de cada termo. O resultado da ordenação de cada amostra é concatenado ao arquivo de índice invertido parcial. Ao nal do processo este arquivo será o índice invertido nal e completo. O tempo de execução de cada passo é linear em relação ao tamanho da entrada, e o processo nal também é linear em vários passos Multi-way In-place Merge Um problema da inversão linear é a necessidade de usar espaço temporário proporcional ao corpus. Outro tipo de inversão existente que não usa espaço em disco extra é o multi-way in-place merge [1]. A idéia básica do processo é a mesma idéia de uma ordenação com união (merge-sort). No caso, o arquivo de entrada é dividido em várias amostras pequenas que ou contém apenas um elemento ou poucos elementos que podem ser invertidos em memória. Estas amostras são unidas (merge) em outras maiores até que no nal reste apenas o índice completo e totalmente invertido. Um merge simples é aquele onde há a união por duas vias ou 2-way merge. Neste caso as amostras são unidas de duas em duas até que haja apenas uma onde são necessários log 2 A leituras do arquivo temporário, onde A é o número de amostras no passo inicial. A forma mais geral é o chamado merge de múltiplas vias ou multi-way merge onde cada união é realizada com M amostras. Deste modo, o número total de leituras seqüenciais no arquivo de entrada será log M A. A escolha do parâmetro M depende da limitação da máquina tanto em memória quanto em disco, i.e., o valor de M é limitado em quantos buers podem ser alocados considerando o total de memória física disponível na máquina e também é limitado na quantidade de arquivos que podem ser manipulados simultaneamente. O procedimento completo é realizado da seguinte forma, primeiro os documentos da coleção são lidos seqüencialmente e é feito o parsing em memória gerando o arquivo de

56 3.4 Construção do Índice 41 Figura 16: Procedimento de inversão linear amostras comprimido em blocos seqüenciais. Nesta fase inicial o arquivo de amostras conterá as entradas de tuplas (termid, docid, f req) dos documentos da amostra. No segundo passo é feita a ordenação de cada amostra onde cada amostra é carregada em memória e ordenada e o resultado será um pequeno índice invertido para os documentos presentes na amostra armazenado de volta no arquivo de amostras. O terceiro passo é fazer o merge dos blocos do arquivo temporário. Este merge é realizado com leitura seqüencial de cada amostra. Para isto, são mantidos em memória os buers de cada amostra com a parte que está sendo atualmente processada. Inicialmente cada buer armazena o primeiro bloco da amostra, o bloco de rótulo bloco 1 de cada amostra na Figura 17. O processamento é reali-

57 3.4 Construção do Índice 42 Figura 17: Procedimento de inversão via multi-way in-place merge zado sobre os buers que são consumidos durante o processo, a cada iteração é escolhida a menor entrada (a próxima entrada) que irá para o buer de saída. Esta entrada é escolhida ecientemente usando-se uma estrutura de la de prioridade em memória descrita no anexo B. Enquanto as amostras vão sendo processadas, os buers são consumidos e são atualizados com os próximos blocos da amostra. Neste momento, os blocos antigos não são mais utilizados e podem ser descartados. Então, o endereço do bloco inutilizável é adicionado à tabela de blocos. Quando o buer de saída é totalmente preenchido ele é descarregado em disco em um bloco físico de uma amostra que já foi descartado da tabela de blocos. A Figura 17 ilustra um momento durante o processamento mostrando a reutilização do espaço em disco, onde, no instante do processamento mostrado na gura, os blocos marcados com * do próprio arquivo de amostras são usados para armazenar o índice invertido. Ao nal do processo, quando todos os blocos de amostra forem consumidos, o espaço temporário do arquivo de amostras é o espaço ocupado pelo índice. Este procedimento de reutilização de blocos garante a característica in-place do processo. No nal do passo de merge, o arquivo de amostras contém o índice invertido. Entretanto, os blocos que formam o índice estão dispersos no arquivo. Então, por m, o último passo organiza os blocos do arquivo baseado na tabela de blocos que foi gerada em memória contendo a ordem de escrita dos blocos em disco. Este passo de merge talvez precise executar várias vezes, isto depende dos valores A e M, como dito antes serão necessários log M A merges. O valor de M já foi discutido, mas o valor de A não. Para A é preferível

58 3.5 Atualização 43 que cada amostra contenha o máximo de documentos possível fazendo com que A seja menor, então, de forma análoga ao procedimento de inversão linear A é calculado usando o máximo de memória disponível A =. 12f R Construção em Pipeline A construção em pipeline visa utilizar de forma eciente os recursos de disco, CPU e rede das máquinas diminuindo o tempo em que estes recursos cam ociosos durante a construção do índice. O método proposto por Melnik [53] divide o processo de construção em três etapas: L - carga de dados, P - processamento e E - descarga de dados. Uma construção sem uso de pipeline cria um índice a partir de varias seqüências de operações L, P e E. Como cada uma destas operações utiliza recursos distintos e independentes (considerando que os dados são carregados da rede e descarregados em disco) estas operações podem ser executadas em paralelo diminuindo o tempo de processamento nal. 3.5 Atualização A atualidade do índice é uma medida de peso de um engenho de busca. O dinamismo da Web faz com que o índice sofra alterações constantes. Existe um problema inato na atualizaçãodosíndicesparaumrepositóriocomoawebqueéaquantidadededadosoque torna o problema não trivial. Vários sistemas fazem a atualização do índice simplesmente construindo um novo e o colocando no lugar do antigo. Entretanto, esta solução pode ser muito custosa. Esta seção lista métodos para tratar do problema de atualização do índice. A Web está sujeita a alterações, entre elas, as principais são: Inserção: Quando um novo documento é adicionado. Um documento novo é inserido no corpus sendo atribuído um novo docid para este documento; Remoção: Quando um documento é removido. Neste caso o seu docid se torna inválido. Caso o sistema sofra muitas remoções com o tempo, vários valores de docid se tornarão inválidos gerando janelas de valores de docid que nunca serão preenchidas nas listas de ocorrências tendo impacto direto na compressão do índice; Atualização: Quando o conteúdo do documento é atualizado. Este tipo de operação é comumente implementada com uma operação de remoção seguida de uma inserção;

59 3.5 Atualização 44 Mudança: Quando a localização do documento é alterada e o documento é movido para outro endereço. Este tipo de operação normalmente é tratado como uma remoção seguida de uma inserção usando a nova localização. Cada operação de atualização gera várias outras alterações no índice. Cada termo presente em um documento alterado acarreta em uma das seguintes alterações no índice invertido: Adição: Esta operação insere um documento novo no nal de uma lista invertida; Inserção localizada: Equivale à adição de um documento a uma lista invertida. Esta operação acontece quando um documento é atualizado e no seu conteúdo aparecem termos que já estão no índice invertido; Atualização: Quando um termo reaparece em um documento modicado então a entrada do documento na lista invertida deve ser atualizada; Remoção: Esta operação remove uma entrada de documento de uma lista invertida. A remoção pode fazer a lista car vazia, no caso, o sistema pode ou remover a lista ou manter a lista vazia. Este tipo de operação pode acontecer quando um documentoéapagadooutambémquandoéatualizadoeumdostermosfoiremovido do documento Atualização Incremental sobre B-Tree Cutting e Pedersen [54] descrevem uma estrutura otimizada para operações de incremento usando uma B-tree. No seu trabalho eles usam uma B-Tree para armazenar o vocabulário e os ponteiros para as listas invertidas que são armazenadas em uma estrutura auxiliar chamada de posting le. Eles descrevem a técnica chamada merge-update onde citam que o uso de memória como buer ao invés de ser usada exclusivamente para cache diminui signicativamente a quantidade de operações em disco necessárias para atualização. Outra otimização é a técnica de pulsing que visa diminuir o espaço utilizado armazenando parte das entradas das listas invertidas na própria B-Tree, isto é feito usando os blocos da B-Tree para armazenar as entradas que estão para ser inseridas, sendo que é usado um parâmetro t para indicar a quantidade de entradas que são atualizadas diretamente na B-Tree, quando t é alcançado, ou seja, para uma lista invertida qualquer

60 3.5 Atualização 45 t entradas da lista estão armazenadas no bloco da B-Tree, então estas entradas são armazenadas no posting-le. Além disso, os autores ainda citam outras técnicas utilizadas visando economia de espaço que são a codicação delta e a codicação VBC. Brown [36] propõe uma técnica para gerenciamento de listas invertidas com tempo de atualização proporcional ao tamanho do texto atualizado. No seu trabalho, as listas invertidas grandes são tratadas de forma diferente das listas pequenas. Entre os motivos seguem que é vericada a distribuição de Zipf sobre as listas invertidas onde 10% das listas ocupam 90% do espaço do índice e também que estas listas têm alta probabilidade de serem recuperadas durante o processamento de consultas. A principal modicação feita na estrutura de arquivo invertido é que cada lista invertida é armazenada em uma lista de blocos de tamanho xo variando de tamanho entre 16 e 8192 bytes. Quando uma lista é criada um bloco de 16 bytes é alocado para esta lista, e quando esta lista ca cheia então um novo bloco com o dobro do tamanho é alocado, o conteúdo da lista é copiado para este novo bloco e o bloco anterior é liberado. Quando este bloco chega ao tamanho máximo (8192 bytes) então um novo bloco de tamanho máximo é alocado e é encadeado como uma lista com o bloco anterior. Além disso, há três tipos de gerenciamento de blocos. Os blocos de tamanho máximo são manipulados usando um segmento físico próprio chamado de large object pool. Os blocos de menor tamanho, blocos pequenos de 16 bytes, são armazenados em blocos físicos de 4KB de tamanho com 255 blocos em cada bloco físico onde estes blocos são armazenados em um segmento próprio chamado de small object pool. E os demais blocos são armazenados em blocos físicos de 8KB onde cada bloco físico armazena blocos de um mesmo tamanho e contém tantos blocos quantos couberem no segmento. Estes segmentos são armazenados em um segmento de disco chamado de medium object pool. Deste modo a estrutura é otimizada para operações de incremento onde novas páginas são adicionadas às listas pré-existentes deixando a maioria das listas anteriores sem serem tocadas durante o processo de atualização. Nos artigo Brown mostra que além manter a taxa de atualização constante por documento inserido, ele arma que o uso de batches grandes é mais eciente que atualizações de poucas páginas, pois o custo de leitura dos segmentos é amortizado com a união de documentos onde as entradas de um mesmo termo são acumuladas para atualização seqüencial Atualização em Tempo de Consulta As técnicas de atualização descritas na seção anterior estão focadas em sistemas com incremento de páginas onde existe apenas a operação de adição de novas páginas. En-

61 3.6 Processamento de Consultas 46 tretanto, o dinamismo da web é um desao maior, o estudo de Cho e Garcia-Molina [19] modela o comportamento de modicação das páginas baseado em experimentos onde foram coletadas informações indicando que 50% das páginas sofrem alteração em um período de uma semana. Enquanto isso várias páginas continuam sem serem modicadas, isso sem contar com as páginas que são removidas. Normalmente os engenhos de busca mantêm sua base atualizada de forma discreta, fazendo atualizações completas das páginas em períodos de tempo xos. Chiueh [55] propõe uma estrutura de índice com atualização em tempo de consulta. A idéia principal da estrutura é manter um buer em memória com as entradas que estão sendo atualizadas e fazer com que as consultas sejam processadas usando informação deste buer e do índice. O sistema deve se preocupar em controlar o acesso concorrente ao índice realizado simultaneamente pelos usuários que estão fazendo consulta ao sistema e o crawler que vive continuamente atualizando o índice. Comousodobuerasoperaçõesdeatualizaçãoemdiscosãopostergadaserealizadas de forma ordenada, amortizando o custo total. Entretanto, o uso de buer acaba se tornando o ponto crítico da performance do sistema de modo que, dependendo da carga de atualização, o sistema não consiga lidar com altas taxas de modicação de páginas. 3.6 Processamento de Consultas Até agora foram descritas apenas a estrutura e técnicas de geração e atualização de índices invertidos deixando de lado o processo da busca. Vários tipos de consultas podem ser implementados ecientemente usando índices invertidos, entre eles consultas booleanas simples, consultas booleanas estendidas, consulta por proximidade Processamento de Consultas Booleanas O processamento de consultas visa recuperar documentos que satisfazem uma consulta e classicá-los em ordem de relevância para serem mostrados ao usuário. Esses são os dois aspectos por trás do processamento de consultas. Para que uma cnnsulta seja processada usando um índice invertido, primeiramente, é feita uma busca no vocabulário para encontrar os termos presentes na consulta. Do vocabulário também são retornados o valor do df e o apontador da lista invertida de cada termo. Com estes valores em mãos é feita uma busca nas listas invertidas para resolver

62 3.6 Processamento de Consultas 47 a expressão booleana formada pela consulta. Isto pode ser feito, basicamente, de duas maneiras: (a) por ordem de termo: é quando o processamento é realizado para cada termo da consulta por vez e (b) por ordem de documento: quando a consulta é processada em ordem de documento que satisfazem a expressão booleana da consulta. Processar uma consulta por ordem de termo, pode ser até eciente dependendo da consulta, mas, na prática, não é viável e, as vezes, requer que a lista invertida de cada documento seja armazenada em memória. Mesmo fazendo otimizações no processamento, como recuperar listas invertidas com menor df primeiro, não garantem que a memória será suciente [1]. O processamento por ordem de documento (b) é realizado com a união das listas invertidas dos termos presentes na consulta que geram os documentos que satisfazem a consulta, um por vez, e o adicionam ao conjunto de documentos do resultado da consulta. O processamento da consulta, em ambos os casos, é realizado usando a árvore sintática da expressão booleana da consulta. O uxo da ordem de processamento, ou por termos ou por documentos, não interfere no resultado, apenas no tempo de processamento. A segunda etapa do processamento é classicar os documentos recuperados. Isto é feito a partir de um valor de peso atribuído a cada documento do conjunto de respostas da consulta, que é calculado durante o processamento por uma função de ordenamento. Esta função pode ser a função de cosseno do ângulo ou outra como as mostradas na Seção 2.2. Figura 18: Processamento de consulta booleana Processamento Rápido de Consultas O tempo de processamento de consultas é uma medida fundamental em um engenho de busca. Os usuários não costumam esperar pela resposta. Grande parte das consultas realizadas em um engenho de busca já cam armazenadas em cache. No trabalho de Moat [56] é descrito o conceito de skip-lists onde são adicionados ponteiros entre as entradas do índice que são usados para evitar decodicação de todas as

63 3.6 Processamento de Consultas 48 entradas. Durante o processamento de consulta quando é feito merge das listas invertidas dos termos da consulta podem acontecer casamentos incorretos e estes ponteiros são usados para identicar quando um bloco de entradas não precisa ser decodicado economizando tempo no processamento. A desvantagem do uso de skip-lists é o aumento do índice causado pela adição desses ponteiros. Entretanto, este aumento é aceitável. Outra técnica é o uso de blocos de tamanho xo [37] que possibilita a descoberta de entradas de forma mais eciente usando uma busca binária entre os blocos com o custo de adicionar espaço extra desperdiçado pelos espaços vazios no nal dos blocos. Outra técnica citada [1] é o processamento usando la de prioridade armazenando os documentos de maior peso de relevância. Esta técnica altera o algoritmo de processamento e não modica nada no índice. O algoritmo de processamento é modicado de modo a evitar gerar um conjunto com todos os documentos que satisfazem a consulta durante o processamento selecionando apenas os mais relevantes. Dependendo da consulta, o resultado pode produzir um conjunto de resposta bastante grande de modo que seja impraticável gerenciá-lo, por exemplo, no repositório do engenho Radix utilizado nos testes descritos na Seção 4.5 com 11 milhões de páginas apenas o termo brasil aparece em cerca de 3 milhões de documentos onde seriam necessários 22MB em memória para armazenar a lista descompactada para apenas este termo. A la de prioridade armazena os H documentos com maior relevância ordenados pelo menor de modo que, entre estes, o documento com menor relevância é facilmente recuperado. Esta la é atualizada durante o processamento a partir dos documentos que são lidos e, ao nal do processamento, a la contém os H documentos com maior peso de relevância que são retornados ao usuário. Este limite pode estar em torno de 100 ou 1000 itens sem afetar ao usuário, já que, a maioria dos usuários (85,2%) visitam apenas os primeiros 10 itens de resposta [57]. Outra forma de realizar processamento eciente é organizar as listas invertidas do índice ordenadas em relação ao peso de relevância [37]. Desta forma, consultas simples ou booleanas simples são processadas rapidamente apenas lendo o início das listas invertidas. Entretanto, para resolver consultas mais complexas como frase e proximidade devem ser realizados operações mais complexas fazendo a checagem de listas de posições, de modo que para estes tipos de consultas o custo do processamento se torna maior.

64 3.7 Considerações nais Considerações nais Este capítulo descreve estruturas utilizadas em sistemas de recuperação de informação e técnicas aplicadas a índices invertidos que servem de base para o trabalho resultado desta dissertação descrito no próximo capítulo (Capítulo 4) onde são utilizados os métodos de compressão de índice, as técnicas de criação e atualização do índice e processamento de consultas observados neste capítulo.

65 50 4 Especicação do VIF Este capítulo descreve a estrutura de dados para índice invertido VIF - Vertical Inverted File. O VIF foi elaborado para ser utilizado no engenho de busca Radix tendo como objetivo oferecer uma API (Application Programming Interface) de gerenciamento do índice capaz de manipular e oferecer acesso aos dados de forma eciente. Inicialmente, a Seção 4.1 descreve um resumo do problema atacado pelo projeto implementado nesta dissertação. Em seguida, a Seção 4.2 aborda a arquitetura do engenho de busca Radix descrevendo os principais módulos e os processos de busca de indexação implementados no sistema, e, em seguida, é descrita a estrutura de índices utilizada previamente pelo sistema. Na seqüência, segue a especicação do trabalho proposto nesta dissertação, a estrutura de índices VIF (Seção 4.3). Na Seção 4.4 são mostrados detalhes do projeto e da implementação do índice VIF. Por m, na Seção 4.5, são descritos os experimentos e testes de vericação e os resultados obtidos. 4.1 Descrição do Problema e Objetivo A Web é um repositório de documentos com características únicas, entre elas o dinamismo e a grande quantidade de dados (Seção 2.3). Estudos indicam que 23% das páginas na Web são modicadas todos os dias (Seção 2.3.2) e existem poucos estudos na área especícos para tratar deste problema. O VIF visa atacar estes dois problemas de grandeza e dinamismo oferecendo uma estrutura que utilize técnicas de compressão de índices e também uma forma de atualização dinâmica baseada em uma B + -Tree. O VIF é um índice implementado para incorporar o engenho de busca Radix com objetivo de resolver estes problemas, principalmente o de espaço utilizado. No engenho Radix, como descrito na próxima seção utiliza dois índices chamados IF e PL que tem custo muito elevado de espaço, onde para uma base de 11 milhões de páginas chegam a ocupar 35.1 GB de disco (Tabela 11).

66 4.2 Arquitetura do Radix Arquitetura do Radix A arquitetura do Radix segue um modelo semelhante ao descrito na Seção Nesta dissertação é exposto apenas a arquitetura centralizada do sistema, sem entrar em detalhes da distribuição do engenho de busca descrita nos trabalhos de Rocha [58] e Fernandes [59]. Na Figura 19 estão descritos os módulos presentes na arquitetura com as ligações representando a tramitação de dados entre os módulos. Figura 19: Arquitetura Básica do Engenho de Busca Radix A arquitetura do Radix é formada por dois módulos principais: (i) o módulo de busca que é responsável por processar as consultas dos usuários do sistema e (ii) o módulo de indexação que gerencia a base de índices do sistema catalogando as páginas da Web e atualizando o índice de busca. Na camada de dados existem basicamente duas bases, uma para indexação e outra para busca onde existem quatro estruturas utilizadas pelo processo que são: índice: é o próprio índice invertido usado no processamento de consulta;

67 4.2 Arquitetura do Radix 52 página: é a estrutura que armazena os dados com informações da página. Estas informações contêm dados mostrados para o usuário que são retirados dos documentos durante a indexação como o título do documento, um parágrafo descrevendo o conteúdo do documento, as datas de criação e última modicação do documento, o tamanho do documento em bytes; centróide: esta estrutura é um índice para acesso ao centróide do documento. O centróide é um vetor com todos os termos que estão presentes no documento. Este índice é utilizado na atualização de páginas; função: é a estrutura que armazena os dados referentes ao componente de função de termos e de urls (Seção 4.2.2) Módulo de Busca O módulo de busca do Radix é dividido em componentes onde cada um é responsável por gerenciar vários aspectos diferentes no engenho como apresentação, distribuição, cache de resultados, agrupamento, etc. Estes componentes (desenhados na Figura 20) podem ser divididos em camadas de acordo com o uxo de dados. Inicialmente existe a camada de apresentação que interage diretamente com o usuário, nesta camada estão o Servlet, o Search, o Console e o FacadeSearch. Em uma instância do sistema existe apenas um na camada de apresentação (dentre estes citados), sendo que normalmente é utilizado o Servlet que é responsável por fazer a interação com o usuário usando um navegador web via requisições http. Este componente sempre acessa diretamente um FacadeSearch que é responsável por receber a consulta no servlet e transformá-la em uma representação interna para ser processada na próxima camada, a de negócios, e também é responsável por recuperar informação textual da resposta gerada nesta camada. É na camada de negócios onde estão denidas as regras de distribuição, de gerenciamento de cache, de agrupamento de respostas e de coleta de dados. Os componentes presentes nesta camada e suas características estão listados na Tabela 8. Todos eles implementam uma interface CoreSearch que é utilizada pelo FacadeSearch para acessar a camada de apresentação. Mais detalhes da arquitetura de busca do engenho estão descritos em [58]. As estruturas descritas nesta dissertação estão presentes apenas na camada de dados. Existem dois componentes nesta camada que são Storage e DataCoreSearch. O primeiro é acessado no FacadeSearch para recuperar informação que é mostrada para o usuário a

68 4.2 Arquitetura do Radix 53 Figura 20: Componentes do módulo de busca do Radix [58] Componente Característica DataCoreSearch Processamento consulta no índice CachedCoreSearch Gerenciamento de cache de resultados RouterCoreSearch Gerenciamento do acesso a bases replicadas GroupCoreSearch Agrupamento de respostas de bases distintas RemoteCoreSearch e Distribuição do processamento de consultas RemoteCoreServer CoreSearch Interface de entre camada de negócios e apresentação Tabela 8: Componentes de busca e suas características partir de um resultado de consulta retornado por um CoreSearch. Como resultado da pesquisa de um CoreSearch são retornados apenas valores de docid para os documentos. A partir destes docids o Storage recupera dados, como por exemplo, a string do endereço, o título da página, o tamanho da página, entre outros. O DataCoreSearch é responsável por realizar o processamento lógico da consulta usando o índice da base de busca gerando o resultado da consulta ordenado por relevância Função de Termos e de Urls As Funções de termos e de urls são os dois componentes do sistema que fazem o mapeamento entre palavra-chave e termid (e vice-versa) e entre url e docid (e vice-versa)

69 4.2 Arquitetura do Radix 54 respectivamente. Ambos os componentes são implementados de forma equivalente. Cada umgerenciaumrepositóriolocalcomomapeamentoentreuma string eumnúmero. Cada vez que um string é solicitado ao componente este retorna o valor associado à string (ao termo para a função de termos e à url para a função de urls). Caso essa string não exista no repositório, o componente gera um novo identicador para a string, armazena o novo mapeamento no seu repositório e retorna o novo identicador. Estes dois componentes trabalham independentes do sistema executando em um processo servidor, eles são usados durante a indexação para gerar identicadores de termos e de urls. Esses dois componentes podem ser compartilhados entre duas ou mais instâncias do sistema. A vantagem desses componentes para a busca é a possibilidade de realizar agrupamento de respostas de duas instâncias de forma eciente, visto que, quando o domínio dos mapeamentos entre urls e termos em docid e termid são compartilhados entre as duas ou mais instâncias então não há necessidade de recuperar o endereço para descobrir se dois itens de resposta são equivalentes para eliminar as redundâncias durante o agrupamento processado usando apenas o índice Módulo de Indexação O Módulo de indexação no Radix é composto por crawlers, Servidor de Indexação e servidor de links. Os crawlers são responsáveis por coletar as páginas na Web fazer a análise sintática dos documentos e gerar o objeto Página que contém a representação interna do documento HTML. O objeto página é composto pelos atributos: a url do documento, o título da página, um parágrafo descrevendo o conteúdo do documento, as palavras-chave com o peso associado a cada palavra, a lista de posições de cada palavra do documento, e a lista de links apontados pelo documento. OsrobôsenviamosobjetosPáginaparaoservidordeindexaçãoqueéresponsávelpor armazenar as páginas no repositório do sistema. Os dados relativos a cada documento são armazenados em arquivos de transação. Estes arquivos contêm os dados que devem ser adicionados ao índice de busca para incorporar os documentos indexados. Estes arquivos de transação são usados no processo de Release para atualizar o índice de busca. Além disso, o servidor de indexação envia os links do documento para o servidor de links que é o componente responsável por manter as listas de endereços de páginas que devem ser enviados aos robôs. O servidor de links gerencia o que está sendo indexado pelo sistema identicando urls de documentos novos e documentos para serem atualizados e também controlando o agendamento das urls fazendo o rodízio de servidores.

70 4.2 Arquitetura do Radix Atualização de Base O processo de atualização de base (Release) é responsável pela atualização da base de busca a partir dos dados que foram catalogados pelo módulo de indexação. Este processo executa de forma esporádica gerando um novo índice para ser usado pelo módulo de busca (normalmente a atualização é feita uma vez por semana). Este processo faz uso intensivo de disco e CPU para gerar o novo índice Estrutura IF A estrutura da dados usada no Radix é um índice invertido simples chamado de IF (Inverted File) com granularidade no nível de documentos, onde as listas invertidas são armazenadas seqüencialmente em dois arquivos: um arquivo if.index que armazena os ponteiros dentro do arquivo de dados para as listas invertidas de cada termo; e o arquivo if.data contendo todas as listas invertidas armazenadas em formato ASCII com caracteres separadores de números. Cada lista invertida de um termo armazena no início o próprio termid do termo em questão seguido do caracter separador de dois pontos ( :) e do valor do df termid. Em seguida é armazenada a lista de todos os docid e freq das páginas da lista invertida separados por um caracter de vírgula (,) em ordem crescente de docid. Cada entrada de docid e freq é separada com o caracter do símbolo igual ( =) como mostrado na Figura 21. Figura 21: Estrutura IF Estrutura PL A estrutura PL (Position List) é um índice auxiliar utilizado durante o ordenamento para recuperar a lista de posições de cada docid da resposta possibilitando o processamento de consultas baseado em proximidade dos termos (Seção 2.4). O PL armazena todas as entradas de duplas (termid, docid) e a lista de posições (pl termid,docid ) em dois arquivos. O arquivo que armazena os dados é chamado de pl.data onde cam armazenados os blocos

71 4.2 Arquitetura do Radix 56 com as entradas PL. Cada bloco armazena um número xo de entradas contínuas. A estrutura interna do bloco é formada por um cabeçalho mais as entradas do PL, e é ilustrada na Figura 22. No cabeçalho é armazenado o número de entradas do bloco (valor e) e o intervalo de cobertura. No exemplo o valor de e é xo para todos os blocos exceto para o último que armazena menos entradas. O intervalo de cobertura do bloco são duas duplas (termid, docid) especicando os limites inferiores e superiores do bloco. No PL as entradas são armazenadas em formato binário usando uma codicação com número variável de bytes bastante semelhante à codicação VBC (Seção 3.3.1). Este arquivo de blocos é indexado por uma B-Tree, ilustrado como a estrutura pl.btree na Figura 22. Esta B-Tree é utilizada para encontrar o bloco de uma entrada qualquer. Ela armazena pares (intervalo, ponteiro) onde o intervalo é o mesmo intervalo que identica um bloco e o ponteiro é o valor que aponta para o início do bloco no arquivo pl.data. Figura 22: Estrutura PL Atualização dos Índices IF e PL No Release, os processos de atualização dos índices IF e PL ocorrem de forma distinta, apesar de serem tratados de forma equivalente pelo módulo de indexação. Durante a indexação, o servidor de indexação gera os arquivos de transação chamados de if.trans e pl.trans armazenando um pequeno índice IF e PL, respectivamente, cada um com uma pequena quantidade de documentos. Estes arquivos são resultado da inversão em memória dos documentos indexados descarregados em disco para serem usados posteriormente como entrada para o processo de release. O procedimento do release funciona da seguinte maneira. Para os arquivos do IF, o release é realizado em dois passos. Primeiro é feita a união de todos os arquivos if.trans gerando um índice IF mediano. Este índice é resultado do que foi catalogado pelo módulo de indexação no período entre o release corrente e o último release processado. O segundo

72 4.3 Especicação VIF 57 passofazauniãoentreestearquivomediano eoíndicecorrentedebuscagerandooíndice IF grande com o resultado nal contendo o índice para todas os documentos catalogados pelo sistema. A construção do PL é realizada de outro modo. Os arquivos de transação do PL são guardados todos juntos em um mesmo repositório e o processo de release gera por completo um novo PL a cada atualização de base. Isto é feito unindo todos os arquivos pl.trans existentes. O processo de release também lida com atualização e remoção de documentos. No PL isto é feito simplesmente removendo as entradas anteriores do arquivo de transação antigo e, no caso de atualização, armazenando as novas entradas como se fosse uma inserção normal. Para o IF, a atualização é realizada adicionando entradas que devem ser removidas no IF anterior e entradas que devem sobrepor as entradas antigas Processamento de Consultas no IF e PL O processamento de consultas usando os índices IF e PL é realizado em duas etapas. Para uma consulta qualquer, primeiro é feito o processamento lógico da consulta para recuperar os documentos. Este processamento é realizado usando o índice IF. Nesta fase uma consulta booleana é processada gerando o conjunto com as entradas de (docid, peso) que satisfazem à consulta, onde peso é o valor de peso de ordenamento baseado no tfidf descrito na Seção Este primeiro passo resolve as consultas booleanas simples. O segundo passo acontece apenas para consultas por proximidade (Seção 3.6). Neste passo é usado o índice PL para identicar a lista de posições para cada termo presente na consulta. Para cada docid no conjunto de resposta gerado no passo anterior é calculado um novo valor de peso agora baseado na proximidade dos termos da consulta no documento. 4.3 Especicação VIF O VIF(Vertical Inverted File) é uma estrutura de arquivo invertido com granularidade no nível de termos, compactada e com estrutura dinâmica organizada sobre uma B + -Tree. Além disso, o VIF oferece uma API de processamento de consultas e de atualização e geração do índice. O índice VIF é dividido em 3 estruturas. A primeira é o arquivo de dados vif.data que armazena todas as entradas VIF. Este arquivo pode ser visto como uma seqüência

73 4.3 Especicação VIF 58 contínua de entradas VIF em ordem crescente. Este arquivo é indexado pela segunda estrutura a vif.btree que é uma B -Tree responsável pelo gerenciamento da disposição dos blocos com as entradas no arquivo + de dados. E a última estrutura é o vif.df que é o arquivo que armazena os valores de df de todos os termos. Os dados armazenados no VIF são entradas de tuplas (termid, docid) associadas com o valor de peso, peso i,j, que é um valor atribuído em tempo de indexação pelos robôs para cada palavra-chave, e mais a lista de posições(pl) onde cada palavra ocorre no documento como descrito na Tabela 9. Valor Descrição termid Identicador de palavra-chave docid Identicador de documento peso termid,docid Peso do termo no documento size Número de vezes que o termo ocorre no documento pl Lista de posições do termo no documento Tabela 9: Atributos de uma entrada VIF Basicamente o VIF contém a mesma informação de um índice PL. A diferença é o atributo peso que não existia no PL. Este atributo equivale ao mesmo atributo presente no IF de peso de relevância de um documento em uma lista invertida. Este valor tem o mesmo objetivo, ser usado no cálculo do peso de relevância durante o processamento de consultas. Além disto, no VIF existe outro atributo não presente no PL. O df de cada termo é armazenado em uma estrutura separada dos dados, o vif.df Estrutura VIF A estrutura de armazenamento dos dados se baseia no gerenciamento de blocos contendo partes de listas invertidas. As listas cam dispostas nos blocos, sendo que uma lista pode usar um ou mais blocos dependendo do tamanho desta. Isto é, no caso de a lista não caber em um bloco, ela é armazenada em tantos quantos forem necessários. Em caso de listas pequenas, um bloco pode conter entradas de uma ou mais listas. Esta distribuição das listas é organizada em intervalos, cada intervalo é especicado pelo limite de intervalo. Um intervalo é representado por dois pares de códigos de termo e códigos de página indicando a primeira e a última entrada do intervalo, equivalente ao PL. A Figura 23 ilustra um exemplo da estrutura VIF onde no arquivo vif.data estão dispostas quatro entradas VIF. Cada linha mostra um exemplo de uma entrada VIF onde os dois primeiros valores separados pelo caracter : em negrito são os valores do termid

74 4.3 Especicação VIF 59 Figura 23: Estrutura básica índice VIF seguido do docid da entrada, os dois valores seguintes, também separados pelo caracter : são o peso da entrada seguido de size, o tamanho da lista de posições. Em seguida seguem size valores de posicão em ordem crescente. Nesta visão lógica toda informação aparenta estar disposta de forma contínua distribuída entre vários blocos. Entretanto, esses blocos são distribuídos no arquivo vif.data de forma não seqüencial sendo organizados pela B + -Tree. Cada bloco tem tamanho xo e armazena uma quantidade variável de entradas, como dito antes, esta quantidade depende de como as entradas foram adicionadas à estrutura onde o arquivo de dados sofre o mesmo dinamismo de um arquivo de B + -Tree. A política de atualização do arquivo de dados é semelhante à de uma B-Tree, por isso, as duas estruturas vif.btree e vif.data podem ser vistas como uma única estrutura de uma B + -Tree onde os dados das folhas cam armazenados no arquivo vif.data. A diferença para uma B + -Tree comum está no uso de codicação especíco de entradas de índice invertido presente nos blocos VIF Organização blocos VIF No VIF os blocos são organizados pela vif.btree, esta estrutura faz controle do acesso aos blocos VIF (Figura 24). Isto é feito armazenando uma chave de identicação de intervalo de cada bloco e o ponteiro do bloco semelhante ao PL. Entretanto, no VIF é necessário armazenar apenas uma entrada (termid,docid). Isto acontece porque o VIF mantém sempre todo o intervalo de cobertura das tuplas sobre controle. Como exemplo, no caso inicial um índice VIF vazio contém no vif.btree um entrada {( : )} apontando para um bloco VIF vazio na estrutura vif.data. Neste caso a entrada ( : ) indica, de forma implícita, que existe apenas um bloco VIF de intervalo inicial (1:1) e nal (, ). Quando a estrutura ocupar dois blocos VIF então existirá duas entradas de chavenovif.btree,digamos{(t 1 :d 1 ),( : )}indicandoestesdoisblocosidenticadospelos intervalos de entradas [(1,1),(t 1 :d 1 )] e outro intervalo para ](t 1 :d 1 ),( : )].

75 4.3 Especicação VIF 60 Figura 24: Organização dos blocos no VIF O índice VIF é armazenado de forma compactada. A compactação está presente internamente nos blocos VIF na estrutura vif.data. Cada bloco é compactado independentemente dos outros onde são utilizadas as codicações Delta, VBC, Elias e Golomb descritas na Seção Desta forma, a quantidade de espaço utilizado em cada bloco varia não apenas em função do número de entradas e do tamanho de cada entrada (que é variável) mas, varia também em função da taxa de compactação aplicada pelo método de compressão utilizado. Isto faz com que exista um espaço vazio variável no nal de cada bloco VIF, como ilustrado na Figura Processamento de Consulta no VIF O processamento de consultas no VIF segue o modelo de processamento de expressões booleanas como descrito na Seção Para que este processamento seja possível é necessário recuperar a lista invertida de um termo qualquer do índice. No VIF as entradas de uma mesma lista podem estar distribuídas de forma dispersa em diferentes blocos VIF no arquivo de dados vif.data. Desta forma, é necessário recuperar a lista de forma ordenada do índice. No VIF isto é feito em tempo de consulta. Este algoritmo de construção em tempo de consulta da lista invertida no VIF é denido da seguinte forma. Dado uma palavra-chave qualquer p primeiro deve-se recuperar o termid de p, em seguida é feita umabuscana B + -Tree paraencontraroblocoquecontémaprimeiraentradadalista, isto é feito buscando na B + -Tree o intervalo da entrada (termid, 1). A B + -Tree irá retornar um blockid que é usado para recuperar do disco o bloco VIF com as entradas que pode ou não conter a entrada buscada. O segundo passo é procurar a entrada no bloco, isto é feito fazendo uma busca binária no bloco até encontrar a primeira entrada com o termid que se procura. Deste ponto basta ler seqüencialmente as entradas do bloco até encontrar uma entrada de outro termid. Quando as entradas do bloco terminarem, então deve-se

76 4.3 Especicação VIF 61 recuperaropróximoblocoatravésda B + -Tree fazendoumabuscausandoaúltimaentrada do bloco corrente Processamento com Fila de Prioridade Algumas consultas podem retornar muitos itens de resposta e muitas vezes estes itens não são relevantes. Além disso, pesquisas mostram que quase a totalidade dos usuários analisam apenas os 10 ou 20 primeiros itens [57]. O custo de gerar uma lista de resposta completa não vale o esforço. Para evitar o problema de ordenar num conjunto muito extenso de itens de resposta. O processamento da busca faz a coleta das páginas relevantes usando uma la de prioridade que armazena apenas os itens de resposta com maiores pesos. À medida que uma consulta é processada é gerada a lista de resultado com a dupla (docid, peso) onde peso é o valor de peso de relevância da página. Este peso é usado para ordenar a lista de respostas que é retornada ao usuário. Em algumas consultas podem ser retornados muitos itens. Por exemplo no nosso corpus de exemplo o termo brasil aparece em mais de um milhão de páginas. Na prática vários desses itens podem ser descartados. A la de prioridade serve para manter em memória os itens de resposta com os maiores pesos. Durante o processamento, esta la de prioridade, possibilita rapidamente descobrir o menor peso dentre os maiores. Quando uma tupla nova é processada o algoritmo verica se o peso desta tupla é maior que o menor peso na la. Se não for maior então a entrada é descartada imediatamente. Caso contrário esta entrada é adicionada à la. Se a la estiver cheia então o menor elemento é descartado Salto de Blocos A estrutura do VIF oferece de forma nativa um índice B + -Tree que pode ser usado para otimizar o processamento de consultas que geram muitos casamentos incorretos. Um exemplo deste tipo de consulta é a consulta brasil E izoneiro onde o termo brasil ocorre em milhões de páginas e o termo izoneiro ocorre apenas em uma dezena de páginas. O algoritmo clássico de processamento para esta consulta deveria percorrer toda a lista invertida do termo brasil. No VIF pode ser feita uma pequena modicação no processamento de consultas para saltar blocos que não possuem casamento, isto pode ser feito alterando o algoritmo de leitura seqüencial da lista invertida do termo para quando se estiver processando uma consulta do tipo E observar o maior valor de docid dos termos

77 4.4 Projeto e Implementação do VIF 62 presentes utilizando a B + -Tree para encontrar o próximo bloco VIF que contém o docid dado evitando a leitura dos blocos intermediários Construção e Atualização do VIF O processo de construção e atualização (release) do VIF é responsável por atualizar um índice VIF baseado em um conjunto de páginas realizando operações de inserção, atualização e remoção de entradas VIF. O processo de atualização é realizado de forma incremental e inplace. Novas páginas são adicionadas ao índice que se reorganiza mantendo a estrutura balanceada como uma B + -Tree. O processo de atualização é realizado da seguinte forma. Inicialmente o módulo de indexação gera os arquivos de transação, vif.trans, com os dados para atualização do índice de busca. Estes arquivos são usados como entrada para o processo de release que é executado em dois passos. O primeiro passo faz a união dos arquivos vif.trans gerando um único arquivo de atualização ordenado. E, o segundo passo basicamente atualiza o índice VIF de busca diretamente fazendo a leitura seqüencial do arquivo com os dados de transação identicando os blocos que devem ser alterados como ilustrado na Figura 25. Deste modo é realizada a atualização localizada no índice VIF onde apenas os blocos com dados que precisam ser alterados são lidos e modicados. Figura 25: Atualização localizada no VIF 4.4 Projeto e Implementação do VIF Esta seção descreve os detalhes do projeto e da implementação realizados na elaboração do índice VIF.

78 4.4 Projeto e Implementação do VIF Ambiente de Desenvolvimento Linguagem de Implementação e de Modelagem A linguagem de Programação utilizada é Java1 por ser uma linguagem orientada a objetos (OO), por ser uma linguagem multiplataforma, e por oferecer uma gama de APIs para acessos a rede, manipulação de entrada e saída, entre outros. Além disso é a linguagem utilizada no Radix e, por ser OO, facilita a integração e incorporação de novos componentes de acesso a dados. São utilizados diagramas de classes, de seqüências, de colaboração e de atividades da linguagem de modelagem UML [60] para modelar as classes, processos e algoritmos descritos neste trabalho Plataforma Operacional A implementação do VIF foi realizada utilizando as plataformas oferecidas no engenho de busca Radix. A principal plataforma operacional utilizada para rodar o sistema foi uma combinação de máquinas com arquitetura Intel Pentium 3 2 e sistema operacional Linux. A vantagem em utilizar esta combinação é o custo nal muito menor, sem sacri- car o desempenho, comparado com outras alternativas de hardware e outros sistemas operacionais de prateleira. Foram utilizadas várias versões de máquinas virtuais Java (JVM), todas compatíveis com a API Java 2. Entre elas as JVM da Sun3, da IBM4 e blackdown5. Como todo o sistema é feito em Java, teoricamente ele executa em qualquer máquina que possua sua implementação de JVM. Por exemplo, o engenho Radix executou em outras plataformas usando máquinas de arquitetura Sun ou Sparc e sistemas operacionais SunOS ou AIX Arquitetura VIF A arquitetura do engenho utilizando o VIF não sofreu alteração em relação à arquitetura original (Seção 4.2) mas foram feitas alterações dos componentes de acesso a dados. A Figura 26 exibe os componentes que foram modicados marcados em cinza. Cada com- 1java.sun.com 2www.intel.com 3www.sun.com 4www.ibm.com 5www.blackdown.org

79 4.4 Projeto e Implementação do VIF 64 ponente foi alterado deixando de usar o índice anterior, baseado em índices IF e PL, e passando a utilizar a estrutura VIF. Figura 26: Componentes modicados para usar o VIF Modelo Acesso e Manipulação do Índice VIF Esta seção descreve as classes básicas de acesso e manipulação do índice VIF. As principais classes de acesso aos dados são VIFEntry que representa uma entrada VIF e a classe VIFBucket que representa um bloco VIF no arquivo de dados vif.data. A Figura 27 mostra o diagrama de classes UML para estas classes. Abaixo segue um resumo de cada classe presente no diagrama. VIFEntry: É a interface que representa uma entrada VIF com métodos para recuperar os valores de termid, docid e rank realizados nos métodos gettermid, getdocid e getrank, respectivamente, e para enumerar a lista de posições usando os métodos startwalk para começar a listagem das posições da entrada, nextposition para passar para a próxima posição e getposition para recuperar o valor da posição corrente na listagem;

80 4.4 Projeto e Implementação do VIF 65 Figura 27: Diagrama de Classes dos componentes de acesso e manipulação do índice VIF VIFBucket: É a interface que representa um bloco VIF no arquivo de dados vif.data. Esta interface oferece métodos para recuperar o cabeçalho do bloco através dos métodos getsize, getstarttermid, getstartdocid, getendtermid e getenddocid e recuperar uma entrada de um índice qualquer pelo método getentry passando como parâmetro o índice da entrada; VIFEntryImpl e VIFBucketImpl: São implementações das interfaces VIFEntry e VIFBucket, respectivamente, que fazem acesso usando dados do bloco VIF carregado em memória; VIFReader: Interface que representa um leitor de entradas VIF. Uma classe deste tipo enumera seqüencialmente objetos VIFEntry atráves dos métodos startreading para iniciar a leitura, next para passar para a próxima entrada e getentry para recuperar a entrada corrente. Possui uma assinatura do método setjumpid usado para saltar entre as entradas que recebe como parâmetro um docid indicando que

81 4.4 Projeto e Implementação do VIF 66 a próxima entrada a ser listada deve ter, no mínimo, um docid maior ou igual ao especicado no parâmetro; VIFReaderByTerm: É uma classe do tipo VIFReader que representa objetos que listam entradas de um termo especíco. Esta classe é utilizada no processamento de consultas; VIFReaderMerge: Representa objetos do tipo VIFReader que fazem a listagem de entradas a partir da união(merge) de vários outros leitores. Esta classe é utilizada para fazer a união dos arquivos de transação vif.trans gerados pelo Servidor de Indexação; VIFFileReader: É uma classe do tipo VIFReader que opera como uma enumeração listando entradas VIF a partir dos dados de um arquivo gerado por um objeto escritor do tipo VIFEntryWriter. Esta classe é utilizada no processo de Release para listar os arquivos de transação gerados pelo Servidor de Indexação; VIFDecoder: Interface que descreve o objeto que realiza a decodicação de um bloco VIF e gera um objeto em memória do tipo VIFBucket de acesso às entradas deste bloco. Possui na assinatura o método decode que recebe como parâmetro um inteiro identicador do bloco VIF e um array de bytes representando o buer com os dados brutos compactados do bloco VIF e retorna um objeto do tipo VIFBucket; VIFCompressor: Interface que representa um objeto responsável por fazer codicação de entradas VIF gerando um buer em memória compactado para ser armazenado em disco no arquivo de dados vif.data. Esta interface descreve um escritor onde os métodos principais são reset, que prepara o objeto para escrita, add, que recebe como parâmetro uma entrada VIF do tipo VIFEntry e adiciona esta entrada no buer em memória, e nish, que naliza um bloco VIF em memória gerando um buer que pode ser recuperado pelo método getbuer; VIFDecoderImpl e VIFCompressorImpl: São as implementações de VIFDecoder e VIFCompressor respectivamente. As duas implementações usam uma combinação de codicação Elias, Golomb, VBC e Delta descritas na Seção As duas classes devem respeitar o mesmo modelo de codicação e decodicação; VIFBucketReader: É a interface que dene um leitor de blocos VIF. Esta interface dene um método produce que recebe como parâmetro um inteiro identicado do bloco VIF no arquivo de dados vif.data e retorna um objeto do tipo VIFBucket;

82 4.4 Projeto e Implementação do VIF 67 VIFBucketReaderImpl: É a implementação do leitor de blocos VIFBucketReader. Esta classe faz acesso direto ao arquivo de dados vif.data para recuperar os dados brutos do bloco e usa uma instância de decodicador VIFDecoder para gerar o objeto VIFBucket resultado do método produce; VIFBucketIdIndex: Esta interface dene os métodos de acesso e manipulação do arquivo vif.btree através de uma B + -Tree. O método de acesso presente é o readbucketid que recebe como parâmetro dois inteiros especicando a chave de uma entrada pelos valores de termid e docid e retorna um inteiro indicando o identicador bucketid do bloco VIF no arquivo de dados vif.data no qual a entrada especicada deve estar, se existir. Além deste, existem dois métodos de manipulação que são: (1) splitrange(startt ermid, startdocid, endt ermid, enddocid, midt ermid, middocid, bucketidlef t, bucketidright), que recebe como parâmetro três duplas de chaves de entradas VIF (termid, docid) onde as duas primeiras indicam o intervalo de um bloco existente no arquivo de dados vif.data formado por [ (startt ermid, startdocid), (endt ermid, enddocid) ] e a outra é uma entrada intermediária (midt ermid,middocid) do intervalo do bloco indicando que o bloco será dividido em dois. Um bloco com entradas menores que a entrada intermediária e o outro bloco com o restante das entradas. O bloco das entradas menores é atribuído ao identicador bucketidlef t e o outro bloco é atribuído o parâmetro bucketidright. E o segundo método (2) unionranges(startt erm 1, startdoc 1, endt erm 1, enddoc 1, startt erm 2, startdoc 2, endt erm 2, enddoc 2, bucketid) de- ne uma operação de união de dois blocos especicados pelos dois intervalos na assinatura do método e mais com o identicador do bloco bucketid que é atribuído ao intervalo com o resultado da união no arquivo vif.btree; VIFBucketIdIndexBtree: É a implementação da interface VIFBucketIdIndex que usa uma instância de uma árvore B + -Tree para implementar as operações de acesso e manipulação do arquivo vif.btree; BPlusTree: Classe que implementa operações de acesso e manipulação de um índice B + -Tree. Osprincipaismétodosutilizadossão searchge,quefazabuscapelo menor elemento maior ou igual que a chave passada como parâmetro do método e retorna o valor associado ao elemento encontrado, insert, que adiciona uma nova entrada na árvore passada como parâmetro, delete, que remove uma entrada, e update, que atualiza o valor associado a uma chave; Key: Interface que representa uma chave utilizada pela classe BPlusTree. Esta

83 4.4 Projeto e Implementação do VIF 68 interface oferece as operações de comparação, armazenamento e leitura da chave; TwoIntKey: Implementação de um objeto do tipo Key onde a chave são dois valores de inteiros representando uma chave de entrada de VIF, sendo que o primeiro valor indica o termid e o segundo indica o docid de uma entrada; VIFEntryWriter: Esta classe representa um objeto escritor de um arquivo com entradas VIF em seqüência. Esta classe utiliza um compressor do tipo VIFCompressor para adicionar entradas e gerar blocos VIF em memória. Estes blocos são armazenados em disco em um arquivo. Esta classe é utilizada para gerar os arquivos de transação vif.trans pelo Servidor de Indexação; VIFBlockedMerge: Esta classe dene o objeto responsável por atualizar um VIF de busca a partir do arquivo com os dados de atualização gerados pelo Servidor de Indexação fazendo atualizações localizadas nos blocos VIF. O Objeto possui uma instância para um leitor de entradas VIF VIFReader utilizado para listar as entradas coletadas durante a indexação. Estas entradas são atualizadas no arquivo de dados vif.data de forma pontual utilizando o índice vif.btree através de um objeto do tipo VIFBucketIdIndex. Estes blocos atualizados são armazenados de volta no arquivo de dados compactados usando o compressor Servidor de Indexação O Servidor de Indexação é o componente responsável por fazer o armazenamento das páginas coletadas pelos crawlers como visto na Seção Este componente é composto pela união de vários componentes que fazem o armazenamento em transações de cada estrutura do sistema (listadas na Seção 4.2). A Figura 28 mostra o diagrama de seqüências ilustrando o passo-a-passo de chamadas feitas aos componentes que compõem o Servidor de Indexação. O início do processo acontece quando o Servidor de Indexação recebe um objeto Página criado pelos crawlers onde é feito a análise do documento e são extraídas as informações que são encapsuladas no objeto Página para serem recuperadas pelo servidor de indexação. A partir deste momento o objeto é repassado para os outros sub-componentes que compõem o Servidor de Indexação. Cada um coleta a informação pertinente à estrutura em que o componente é responsável. Abaixo segue a lista de cada componente descrevendo os dados pelos quais cada um é responsável:

84 4.4 Projeto e Implementação do VIF 69 Figura 28: Diagrama de seqüência do Servidor de Indexação do Radix PageStorage: Componente responsável por armazenar os dados informativos da página como: endereço, título, descrição, tamanho da página, etc; CentroidStorage: Neste componente é feito o armazenamento das informações do índice do centróide da página usado durante a atualização de páginas; LinkStorage: Faz a coleta os links das páginas e envia para o Servidor de Links para que ocorra a realimentação dos crawlers com endereços para novas páginas; VIFStorage: Componente que faz o armazenamento dos dados do índice VIF. Cada componente armazena na base de indexação os dados das páginas que servem para atualizar o índice de busca durante o processo de release. Todos os componentes armazenam estes dados em arquivos de transação relativo à estrutura pela qual o componente é responsável. Cada arquivo contém uma quantidade máxima de documentos, como exemplo 100, onde a cada 100 documentos enviados pelos crawlers é gerado um arquivo de transação para estes documentos. O VIFStorage armazena cada arquivo de transação como um pequeno índice VIF chamado de vif.trans onde são armazenadas as entradas que devem ser atualizadas no índice de busca gravados em disco usando um objeto VIFEntryWriter. Cada entrada presente no arquivo de transação pode ter três signicados que são: (a) uma entrada de um documento novo; (b) uma entrada de atualização ou (c) uma entrada que deve ser

85 4.4 Projeto e Implementação do VIF 70 removida. As entradas (a) e (b) são consideradas entradas normais enquanto as entradas de remoção (c) são entradas especiais com uma marca indicando que a entrada deve ser removida do índice de busca durante o processo de release Processador de Consultas O Processador de consultas equivale ao componente DataCoreSearch descrito na Seção Este componente é o núcleo do processamento de consultas, é neste componente que é realizado o acesso ao índice VIF. A Figura 29 mostra as classes que participam no componente processador de consultas. Figura 29: Diagrama de Classes do Processador de Consultas A descrição de cada classe presente é listada abaixo: FacadeStorage e CoreSearch: São as classes que recebem a consulta do usuário e iniciam o processo de busca. Estas classes integram o módulo de busca original e estão descritas na Seção 4.2.1;

86 4.4 Projeto e Implementação do VIF 71 Query: Este tipo de classe representa um objeto com a expressão booleana especicada pelo usuário do sistema. Este objeto faz o tratamento da consulta original sendo usado para criar a árvore de processamento de consultas; Request: Representa uma requisição do usuário. Contém a consulta do usuário denida como um objeto do tipo Query, o índice da requisição do usuário e o tamanho da página de resposta (número de endereços que deve ser mostrado no resultado); Result: Representa o objeto de resultado de uma consulta retornado para a camada de interface. Este objeto armazena a lista de docid que foram processadas no objeto DataCoreSearch; TupleCollection: Classe dos objetos que representam uma coleção de entradas de resultado do processamento. Além de armazenar o docid também armazena um valor rank que é o valor de relevância de cada documento gerado durante o processamento da consulta; DataCoreSearch: Classe que representa o objeto responsável por realizar o processamento de consultas gerando à lista de docid que respondem a requisição do usuário. Esta função é executada por uma chamada ao método search que tem como parâmetro um objeto da classe Request e retorna como resultado um objeto da classe Result. A lista de docid é criada usando um objeto SearchResultRetrieve criado localmente, usado pela fábrica retrievfactory para responder à consulta; SearchTreeFactory: Esta classe representa uma fábrica de árvores de processamento de consulta. Uma árvore de processamento é a estrutura utilizada para processar consultas geradas a partir da expressão booleana especicada pelo usuário. O método produce recebe uma consulta do usuário representada pelo objeto Query e gera a árvore de processamento retornando como resultado do método o nó raiz da árvore de processamento; SearchNode: Representa um nó na árvore de processamento de consultas criada a partir da expressão booleana da consulta do usuário denida no objeto Query; SearchResultRetrieve: Responsável por coletar a lista de docid que responde à consulta, criando uma árvore de processamento de consulta representada por um objeto do tipo SearchNode criado a partir da fábrica treefactory.

87 4.4 Projeto e Implementação do VIF 72 Figura 30: Diagrama de Seqüência do Processador de Consultas

88 4.4 Projeto e Implementação do VIF 73 O diagrama de seqüências do processo realizado pelo componente DataCoreSearch está ilustrado na Figura 30. Em resumo, o processo ocorre nos seguintes passos. Inicialmente o componente DataCoreSearch recebe uma chamada do método search pelo objeto fachada do sistema (FacadeSearchEngine) junto com um objeto Request passado como parâmetro com a requisição do usuário. Este objeto é usado para produzir um objeto SearchResultRetrieve chamando o método produce da fábrica. A fábrica representada pela classe SearchResultRetrieveFactory cria a árvore de processamento de consulta a partir do objeto Query da requisição do usuário usando a fábrica de árvore de processamento. O método run do objeto SearchResultRetrieve faz o processamento da consulta chamando o método processindex na raiz da árvore de processamento. Ao nal do método run o objeto tuples estará preenchido com a lista de docid de resposta da consulta. Por m, esta lista é adicionada a um objeto de resultado Result sendo retornado para a fachada do sistema Árvore de Processamento de Consultas O processador de consultas é baseado em expressões booleanas. Nele uma consulta é inicialmente processada sendo construída a árvore de processamento da consulta (como descrito na seção anterior). Esta árvore é usada para processar as consultas, gerar a lista de resposta e calcular o peso de relevância de cada documento. É na árvore de processamento que acontece o acesso ao índice e leitura das listas invertidas. São as folhas da árvore os elementos de acesso, este acesso é realizado pelo objeto que implementa a interface VIFReader que faz a leitura das entradas VIF realizadas nos objetos do tipo VIFEntry. A Figura 31 mostra o diagrama de classes UML para as classes presentes nas árvores de processamento. Abaixo segue a descrição de cada classe: SearchNode: É a interface que representa a abstração de nó da árvore de processamento. A operação principal de um nó é realizada pelo método processindex usado para fazer o processamento da consulta; AbstractSearchNode: Esta classe implementa as funções básicas de um nó de processamento SearchNode e deixa a implementação do comportamento do nó para ser implementado por uma subclasse; SearchNodeTerm: É a classe que representa os objetos que são folhas na árvore de processamento. Este objeto faz a leitura da lista invertida usando o leitor de entradas VIF, VIFReader;

89 4.4 Projeto e Implementação do VIF 74 Figura 31: Diagrama de Classes dos Nós de Processamento da Busca VIFReader: Interface que representa um objeto que faz a leitura seqüencial de entradas do VIF. Basicamente são implementados os métodos para enumerar as entradas VIF e um método adicional setjumpid para saltar entradas não necessárias; VIFEntry: Interface que representa uma entrada VIF. Possui métodos para recuperar o termid, docid, rank e lista de posições da entrada; VIFReaderByTerm: É a implementação da interface VIFReader utilizada para enumerar as entradas do índice VIF de um termo especíco; SearchNodeOR: Esta classe representa um nó interno na árvore de processamento que faz a união dos elementos dos nós da sub-árvore implementando no método internalprocessnext o comportamento de uma operação booleana OU. São listadas todas os documentos presentes em qualquer uma das sub-árvores; SearchNodeAND: Esta classe representa um nó interno da árvore de processamento estendendo a classe SearchNodeOR sobrescrevendo o método internalprocessnext para implementar o comportamento de uma operação booleana E. Onde são processados os elementos presentes em todas as sub-árvores;

90 4.4 Projeto e Implementação do VIF 75 SearchNodeNOT: Esta classe representa um nó interno que implementa o comportamento de um conectivo do tipo NÃO para consultas por expressão booleana. Esta classe estende a AbstractSearchNode implementando o método internalprocessnext para listar os documentos presentes na expressão da sub-árvore do atributo node que não acontecem na sub-árvore do atributo notnode; RankFunction: Interface que representa um objeto responsável por calcular o peso de relevância de um documento durante o processamento. Cada nó da árvore de processamento possui um atributo para a função de ordenamento do nó; TupleCollection: Representa uma coleção de resultado do processamento. Cada árvore de processamento possui um TupleCollection que ca localizado na raiz da árvore fazendo a coleta dos valores de docid e rank (peso de relevância) de resultado do processamento da árvore; TupleFilter: Interface para objeto que indica se um documento deve ser ltrado ou não. Cada nó de processamento pode ter ou não um ltro associado. O uxo de processamento segue em direção das folhas para a raiz onde são armazenados no objeto TupleCollection. A instância real utilizada para armazenar os documentos de resultado é a coleção LimitedTupleCollection. Este tipo de objeto implementa uma coleção de tuplas usando uma la de prioridade com limite máximo de entradas, digamos (mil), que armazena durante o processamento os documentos de maior peso de relevância como descrito na Seção Outra otimização, descrita na Seção 4.3.5, é implementada na árvore de processamento. Cada nó da árvore possui um método chamado setjumpid que serve para enviar um mensagem às sub-árvores de cada nó indicando um docid mínimo a ser processado (apenas para processamento de nós tipo E). Esta mensagem chega nos nós folhas e é repassada para o leitor de entradas VIF, VIFReader. O Leitor se ajusta para que a próxima entrada listada tenha docid maior ou igual ao especicado e, caso seja necessário, faz o salto para o bloco do VIF que a entrada especicada esteja armazenado. Como exemplo, a Figura 32 mostra o diagrama de colaboração UML para os objetos presentes no processamento da consulta (arquivo OU índice) E invertido e a interação entre os objetos. O processamento ocorre da seguinte maneira. Inicialmente o sistema cria um objeto do tipo SearchRetrieve para responder à consulta (como descrito na seção anterior) para então chamar o método processindex na raiz da árvore de processamento (chamada 1). No caso da gura, o nó raiz é um objeto do tipo SearchNodeAND, a partir

91 4.4 Projeto e Implementação do VIF 76 Figura 32: Diagrama de Colaboração para Árvore de Processamento deste ponto a própria raiz faz chamadas consecutivas ao método internalprocessnext do próprio objeto (chamada 2). Neste caso, o objeto implementa um conectivo booleano de consultas do tipo E. O processamento é baseado em uso de la de prioridade onde é recolhido o resultado do processamento das sub-árvores pelo objeto do tipo PriorityQueue com chamadas ao método removetop (chamada 3) que retorna o menor elemento das subárvores. O nó do tipo SearchNodeAND retorna apenas os valores de docid que ocorram em todasassub-árvores. Aalimentaçãodaladeprioridadedonóéfeitaatravésdechamadas ao método internalprocessnext das sub-árvores (chamadas 4 e 5). Uma das sub-árvores é a consulta do tipo SearchNodeOR que processa a expressão índice OU arquivo. O

92 4.4 Projeto e Implementação do VIF 77 processamento para um conectivo OU é realizado de forma semelhante ao de um conectivo do tipo E com uso de uma la de prioridade e chamadas ao método removetop (chamada 6). A diferença é que para o objeto do tipo SearchNodeOR sua implementação retorna todos os valores de docid que ocorrem nas sub-árvores sem restrição. No exemplo, todos os valores retornados nas sub-árvores pelas chamadas de internalprocessnext são retornados (chamadas 7 e 8). Os nós folhas são representados por objetos do tipo SearcNodeTerm. Eles são responsáveis pela leitura da lista invertida de cada termo que é feito através de chamadas ao método next no leitor de entradas VIF VIFReaderByTerm (chamadas 9, 10 e 11). Durante o processamento da árvore todos os documentos que são processados como resultado da expressão são adicionados ao objeto do tipo LimitedTupleCollection através do método add na raiz da árvore (chamada 12). Ao nal do processamento o SearchResultRetrieve recupera a lista dos documentos que foram processados através do método getsortedtuplecollection (chamada 13) e a partir deste ponto o processamento continua como descrito na seção anterior. Por m, a interface RankFunction representa uma função de ordenamento usada para calcular o peso de relevância dos documentos como dito antes. Cada nó de processamento tem a sua instância de função que é utilizada de acordo com o tipo de consulta do usuário (Seção 2.4). As principais implementações são: RankFunctionProximity que implementa uma função para calculo de relevância de acordo com a proximidade dos termos no documento, RankFunctionTFIDF, que calcula o peso de relevância a partir da fórmula de tf idf, a função RankFunctionHITS, que calcula o peso de relevância baseado no algoritmo de HITS implementado no Radix descrito em [22], RankFunctionAverage que calcula o peso de relevância baseado na média dos pesos dos nós das sub-árvores, e o RankFunctionCollection, que calcula o peso de relevância usando uma combinação de outras funções de ordenamento Processo de Release no VIF O processo de release do VIF faz a atualização do índice de busca adicionando o que foi coletado durante a indexação. Como dito antes, o release é realizado em dois passos. Primeiro é feito a união dos arquivos de indexação e em seguida a atualização do índice de busca. O primeiro passo é realizado como demonstrado na Figura 33. Na gura ca ilustrada a interação entre os objetos do processo realizada nesta etapa. O objeto principal é o VIFReaderMerge, que é responsável por realizar a união de outros N leitores do tipo

93 4.4 Projeto e Implementação do VIF 78 Figura 33: Diagrama de Colaboração para o Passo 1 do Release do VIF VIFReader, na gura é feita a união de três. Esta união é realizada através de uma la de prioridades representada por um objeto da classe PriorityQueue. O merge é então realizado por várias chamadas seqüenciais ao método removetop (operação 1) da la de prioridade. Este método retorna o menor elemento da la removendo-o e atualizando a lista. Esta atualização é processada baseada nos leitores de arquivos de transação representados por objetos do tipo VIFFileReader. Cada objeto é utilizado para listar as entradas de um arquivo vif.trans, gerado pelo Servidor de Indexação, usando o método next() (operações 2,3,4). Por m, todas as entradas lidas pelo VIFMergeReader são armazenadas em um arquivo temporário usando o objeto escritor do tipo VIFEntryWriter com chamadas seqüenciais do método add para cada entrada listada (operação 5). No exemplo da gura, o processo opera sobre os três arquivos de transação sendo que na prática são gerados incontáveis arquivos de transação durante a indexação. Deste modo, este processo é executado várias vezes até que todos os arquivos de transação vif.trans sejam unicados. A segunda etapa do processo do Release no VIF é realizar a atualização do arquivo de dados do índice VIF de busca. Esta operação é realizada pelo objeto da classe VIF- BlockedMerge. Basicamente, o objeto faz a leitura seqüencial do arquivo com os dados da união das transações vif.trans do passo anterior, gera buers das entradas de atualização de cada bloco VIF e atualiza este bloco no arquivo de dados vif.data. A Figura 34 mostra o diagrama de atividades realizadas pelo VIFBlockedMerge. O procedimento pode ser dividido em duas sub-etapas. A primeira visa ler o arquivo de dados e gerar o buer de entradas de atualização. Este buer é gerado baseado em um bloco VIF. Inicialmente é lida a primeira entrada de atualização do arquivo vif.trans. De