Universidade Federal de Pernambuco

Centro de Informática

Pós-Graduação em Ciência da Computação

Uma proposta para o Gerenciamento deCache de um Sistema de Integração de

Dados

Walter de Carvalho Mattos Galvão

Dissertação de Mestrado

Recife

2007

ii

Galvão, Walter de Carvalho Mattos

Uma proposta para o gerenciamento de cache de um sistema de integração de dados / Walter

de Carvalho Mattos Galvão. - Recife: O autor, 2007. xii, 96 folhas: il., fig., tab.

Dissertação (mestrado) - Universidade Federal de Pernambuco. CIN. Ciência da Computa-

ção, 2007.

Inclui bibliografia e anexo.

1.Dados em sistemas computacionais. 2. Cache. 3. Query containment. 4. Políticas de

substituição. I.Título.

005.7 CDD (22.ed.) MEI2007-052

Universidade Federal de Pernambuco

Centro de Informática

Walter de Carvalho Mattos Galvão

Uma proposta para o Gerenciamento de Cache de umSistema de Integração de Dados

Trabalho apresentado ao Programa de Pós-Graduação em

Ciência da Computação do Centro de Informática da Uni-

versidade Federal de Pernambuco como requisito parcial

para obtenção do grau de Mestre em Ciência da Computa-

ção.

Orientador: Ana Carolina Salgado

Recife

2007

Aos meus pais, Lucinda e Aristides, e meus irmãos, Tatiana

e Arlindo.

Agradecimentos

Agradeço a Deus, meu eterno amigo, pela força para que eu pudesse completar mais um trecho

da longa caminhada da vida, pelo afago nos momentos difíceis, discernimento nos momentos

de dúvidas e pelas pessoas especiais que colocou em meu caminho.

À professora Ana Carolina Salgado, minha orientadora, por ter apostado na minha capaci-

dade e me presenteado com essa oportunidade, pela brilhante orientação, paciência, serenidade,

cobranças e conselhos dados desde a graduação.

À minha mãe, meu maior exemplo de vida, pela garra e persistência inspiradoras, pelos

beijos e cafunés e pelos diversos "eu te amo"mesmo sabendo que tenho certeza disso. Ao meu

pai e meus irmãos, por alegrarem cada dia da minha vida e pelo incentivo ao meu crescimento

pessoal e profissional. Aos meus avós paternos, Walter e Margarida, e maternos, Arlindo e

Maria do Carmo, pelos valiosos ensinamentos. À Barbara, minha namorada e braço direito,

pelo carinho e incansável disposição para me ajudar em tudo.

À equipe do Integra, em especial a Maria Conceição Batista, Bernadette Lóscio e Thiago

Alves Costa pela disponibilidade em me ajudar sempre que precisei. A Haroldo Amaral, em

particular, por ter compartilhado comigo experiências e angústias e ter me incentivado a seguir

até o fim.

Ao Serviço Federal de Processamento de Dados (SERPRO) e à UNISYS do Brasil, empre-

sas onde trabalhei durante esse período, pelo apoio dado, permitindo flexibilidade no expedi-

ente para que eu pudesse me dedicar ao mestrado.

Aos meus amigos, presentes em todos os momentos e testemunhas das minhas alegrias

e tristezas vividas ao longo desses anos, por terem me mostrado o verdadeiro significado da

palavra amizade.

Enfim, a todos que direta ou indiretamente, torceram por mim: muito obrigado!

v

Resumo

Sistemas de Integração de Dados (SID) proporcionam ao usuário uma visão unificada de dados

que estão armazenados em diversas fontes diferentes. Essas fontes são independentes e cada

uma possui um esquema próprio, elaborado para atender as necessidades dos usuários de cada

banco. Cada SID possui um conjunto de fontes de dados distintas relevantes para o seu domí-

nio, e deve colher de cada uma os dados necessários para responder as consultas do usuário.

Uma vez obtidos esses dados, o SID deverá traduzi-los para um esquema global (esquema de

mediação), integrá-los e exibi-los ao usuário.

Para Sistemas de Integração de Dados na Web, como o Integra - SID desenvolvido por

alunos e professores do Centro de Informática da UFPE e utilizado para a implementação das

nossas contribuições - os desafios são ainda maiores, visto que a disponibilidade das fontes se

torna um fator bastante relevante. Sendo assim, o custo para se buscar os dados sempre nas

fontes pode ser bastante alto. Por isso, alguns SID, como o Integra, possuem umacachepara

o armazenamento dos dados resultantes das consultas que o sistema considera mais relevantes.

Desta forma, quando alguma consulta que já esteja armazenada emcachefor novamente soli-

citada pelo usuário, o sistema não mais necessitará acessar as fontes de dados para respondê-la,

o que otimizará o processamento.

O objetivo desta dissertação de mestrado é apresentar uma proposta de um Gerenciador

de Cachepara um Sistema de Integração de Dados. Esse Gerenciador é composto por um

módulo que controla o espaço dacache, decidindo que consultas devem entrar e quais devem

permanecer em cache. Possui outro módulo que identifica se a consulta submetida pelo usuário

está contida em outra que esteja armazenada emcache(técnica dequery containment). E por

último, um módulo que realiza a substituição parcial de uma consulta, para o melhor aprovei-

tamento do espaço da cache.

Palavras-chave: Sistema de Integração de Dados,cache, query containment, políticas de

substituição, substituição parcial de consultas, XQuery

vi

Abstract

Data Integration Systems (DIS) provide to the user an unified view of data stored in many

different data sources. Those data sources are independent and each one has a particular schema

elaborated to attend its user’s needs. Each DIS has a group of different data sources related to

a specific domain and must obtain from each one the necessary data to answer user’s queries.

The query results will be translated according to a global schema (mediator schema), combined

and showed to the user.

There are several challenges for data integration systems on web as Integra system (DIS

developed on Centro de Informatica, UFPE and used to implement our contributions), since

data sources availability is a very important factor. Furthermore, the cost to always access data

on data sources may be very high. Because of this, some DIS have a cache to store query results

that are somehow interesting for the system. In this way, when the user requests some query

that has already been stored in cache the system do not need to access data sources to answer

it, improving the processing.

The main purpose of this master thesis is to propose a Cache Manager for a data integration

system. This Cache Manager is composed by a module that controls the cache space deciding

which queries must enter and which ones must be kept in cache. There is another module

that identifies if the query submitted by the user is a subquery of a query already stored in

cache (technique of query containment). Finally, there is a module that achieves the partial

substitution of a query allowing a best use of cache space.

Keywords: Data Integration Systems,cache, query containment, replacement strategies,

partial replacement, XQuery

vii

Sumário

1 Introdução 1

1.1 Motivação 1

1.2 Objetivos 2

1.3 Contribuições Esperadas 3

1.4 Estrutura da Dissertação 3

2 Sistemas de Integração de Dados 5

2.1 Integração de Dados 5

2.2 Sistemas de Integração de Dados 6

2.2.1 Abordagens para Sistemas de Integração de Dados 7

2.2.2 Arquiteturas 8

2.2.3 Exemplos 10

2.3 Integra 11

2.3.1 Arquitetura 11

2.3.1.1 Ambiente Comum 12

2.3.1.2 Ambiente de Geração e Manutenção do Mediador 13

2.3.1.3 Ambiente do Usuário 14

2.3.1.4 Ambiente de Integração de Dados 14

2.4 Considerações Finais 17

3 Cachee seu Gerenciamento 18

3.1 Cacheem Bancos de Dados 18

3.2 Substituição de Elementos em Cache 20

3.3 Atualização dos Elementos em Cache 21

3.3.1 Fatores de qualidade 21

3.3.2 Consistência da informação 23

3.4 Técnicas Auxiliares 26

3.4.1 Identificação de Subconsultas 26

3.4.1.1 Normalização 29

viii

ix

3.4.1.2 Problemas relacionados 31

3.5 Considerações Finais 34

4 Estado da arte em Gerenciamento de Cache 35

4.1 Algoritmos de Substituição 35

4.1.1 LRU/k 37

4.1.2 2Q 38

4.1.3 Least Semantically Related 40

4.2 Cacheem Sistemas de Integração de Dados 42

4.2.1 Denodo 43

4.2.2 YACOB 44

4.2.3 ACE-XQ 45

4.2.3.1 Identificação de Subconsultas 46

4.2.3.2 Substituição de elementos emcache 49

4.3 Discussão 50

4.4 Considerações Finais 50

5 Gerenciador deCachedo Integra 51

5.1 Soluções Propostas 51

5.2 Arquitetura do Gerenciador de Cache 52

5.3 Gerenciador de Log 53

5.4 Identificador de Subconsultas 54

5.4.1 Arquitetura do Identificador de Subconsultas 54

5.4.2 Buscador de Consultas 55

5.4.3 Conversor de Consultas 56

5.4.3.1 Representação XML de consultas XQuery 57

5.4.3.2 A ferramenta 59

5.4.4 Comparador de Consultas 60

5.4.4.1 Implementação 60

5.4.4.2 Funcionamento 65

5.5 Gerenciador de Substituição 72

5.5.1 Função de Substituição 72

5.5.2 Adaptação da Função de Substituição ao Integra 75

5.6 Trocador de Consulta 76

5.6.1 Exemplo 78

5.7 Considerações Finais 83

x

6 Conclusão 84

6.1 Contribuições 85

6.2 Trabalhos Futuros 86

7 Anexo 92

7.1 Anexo 1 92

Lista de Figuras

2.1 Arquitetura de Mediadores 9

2.2 Arquitetura de Data Warehouse 10

2.3 Arquitetura do Integra ([1]) 12

2.4 Estrutura do log de uma consulta 16

3.1 Políticas de Sincronização 24

3.2 Combinação de Políticas de Sincronização 25

3.3 Três maneiras de escrever uma mesma consulta em XQuery 30

3.4 Consultas em XQuery 32

3.5 XML e resultados das consultas 33

4.1 LRU/K - sequência de ações 38

4.2 2Q - Situação inicial da cache 39

4.3 2Q - Situação dacacheapós entrada do elemento A 40

4.4 2Q - Situação final da cache 41

4.5 LSR - Hierarquia de Assuntos 42

4.6 LSR - Árvore, após entrada do objeto 5 42

4.7 Denodo - Arquitetura do Sistema ([2]) 43

4.8 YACOB - Arquitetura do Sistema ([3]) 44

4.9 ACE-XQ - Arquitetura ([4]) 46

4.10 Consulta Q1 em XQuery, na cache 47

4.11 Consulta Q2 em XQuery 47

4.12 Consulta Principal e Restante 48

4.13 Consulta de Junção 48

4.14 Relação com os caminhos XML da consulta Q1 49

5.1 Arquitetura do Gerenciador deCachedo Integra 52

5.2 Arquitetura do módulo Identificador de Subconsultas do Gerenciador de Cache 54

5.3 Consulta em XQuery 57

5.4 Representação parcial da consulta XQuery em XQueryX 58

xi

xii

5.5 Representação parcial da consulta XQuery em XML através do XQNSTA 59

5.6 Pseudo-código da função IsSubConsulta 61

5.7 Pseudo-código da função ComparacaoElementos 62

5.8 Pseudo-código da função IsElementoCorrespondido 63

5.9 Análise de abrangência de comparadores 64

5.10 Consulta submetida pelo usuário 66

5.11 Consulta dacacheretornada pelo buscador de consulta 66

5.12 Mais uma consulta submetida pelo usuário 69

5.13 Consulta dacacheretornada pelo buscador de consulta 70

5.14 Cenário 73

5.15 Consulta presente nacache 79

5.16 Resultado da consulta presente nacache 80

5.17 Corpo da consulta após remoção dos atributos 81

5.18 Resultado da consulta presente nacache, após a remoção dos atributos 82

Lista de Tabelas

5.1 Ordem de prioridade de remoção dos atributos 79

xiii

CAPÍTULO 1

Introdução

A era da informação, vivida atualmente, está em sua plenitude. O advento da internet marcou o

início da globalização da informação e acelerou o processo de distribuição e compartilhamento

do conhecimento pelo mundo. A grande rede mundial de computadores permite que seu usuário

mergulhe num universo de informações científicas, culturais, políticas entre outras, sem muito

trabalho.

O grande volume de fontes de informações disponíveis fez crescer uma preocupação antiga

da comunidade científica especializada em bancos de dados: a integração de dados.

Neste capítulo, abordaremos o que motivou o desenvolvimento desta dissertação e como

ela está estruturada.

1.1 Motivação

Os Sistemas de Integração de Dados têm a função de prover ao usuário uma visão única dos

dados que estão distribuídos em fontes diferentes. Quando o usuário requisita uma informação

a um sistema desse tipo, este irá buscar todos os dados, espalhados entre as fontes, necessários

para se obter a informação desejada, integrá-los e retornar ao usuário.

Construir um sistema de integração de dados para acessar dados de um conjunto pequeno

de fontes sobre as quais se tem todo o controle, desde acesso à documentação até o monito-

ramento das manutenções que são nelas efetuadas, já é uma tarefa bastante problemática. Se

considerarmos, então, que em vez de um conjunto pequeno de fontes conhecidas, o sistema

tiver que acessar diversas fontes completamente distintas e independentes umas das outras, das

quais não se tenha acesso sequer à documentação, muito menos a garantia da disponibilidade,

teremos um problema consideravelmente maior. Este último é o cenário encontrado por qual-

quer sistema de integração que se propõe a integrar dados de fontes disponíveis na Web.

Duas abordagens para esse tipo de sistema podem ser adotadas [5]: a abordagem virtual,

em que as informações são coletadas sempre diretamente das fontes e depois integradas, e a

abordagem materializada, em que os dados são previamente buscados nas fontes, integrados

e armazenados em um DW (Data Warehouse), que irá disponibilizá-los para que as próximas

1

2

consultas não necessitem ser executadas nas fontes, mas sim no DW, diminuindo o tempo de

resposta.

A abordagem virtual é indicada para sistemas de tempo real, em que a consistência dos

dados é um fator crítico ao sistema e tem como vantagem o fato de disponibilizar sempre o

dado atualizado ao usuário. Por outro lado, mostra-se ineficiente quando o tempo de resposta

de alguma fonte é alto ou ela está indísponível momentaneamente. Para sistemas em que a

consistência não seja algo tão crítico, é indicada a abordagem materializada, que oferece uma

melhoria na performance. No entanto, sistemas que adotam essa abordagem devem possuir

alguma estratégia de atualização dos dados materializados, para que eles não fiquem inconsis-

tentes com os das fontes por muito tempo.

A motivação para o desenvolvimento deste trabalho é a elaboração de um Gerenciador de

Cachepara um sistema de Integração de Dados.

Uma equipe composta por alunos e professores do Centro de Informática da UFPE está

desenvolvendo um sistema de integração de dados: o Integra [6].

O Integra é um sistema destinado a integração de dados na Web, e adota a abordagem

materializada. Além do DW, onde ficam materializadas algumas visões, ele possui também uma

Cache, para armazenar os resultados de algumas consultas. Quando é submetida ao sistema

uma consulta cujo resultado já esteja armazenado nacache, ela não mais precisará passar por

todo o processo normal que envolve sua execução nas fontes e integração dos resultados. Nesse

caso, o Integra retorna ao usuário o resultado que está nacache, reduzindo o tempo de resposta.

O módulo Gerenciador deCacheé responsável pelas seguintes atividades:

• Gerenciar o tamanho dacache, decidindo quais consultas devem ser armazenadas e rea-

lizando substituições, quando achar necessário; e

• Manter os resultados das consultas armazenados emcacheatualizados.

Foi criada para o Integra uma versão provisória do Gerenciador deCache. Essa versão

utiliza técnicas simples para executar as duas atividades listadas acima.

Nosso trabalho propõe uma melhoria no Gerenciador deCachedo Integra, tendo como foco

principal o gerenciamento do espaço dacache.

1.2 Objetivos

Por possuir tamanho limitado, gerenciar umacache, independente da aplicação – bancos de

dados, servidores web ou sistemasstand alone– não é trivial. Decidir qual objeto deve perma-

3

necer armazenado, e qual deve ser substituído por outro é tão complexo que já rendeu diversas

propostas [7, 8, 9, 10]. São as famosas políticas de substituição(oureplacement strategies).

Para tomar essa decisão, é necessário estabelecer critérios, e cada proposta utiliza um dife-

rente. Um dos objetivos deste trabalho é apresentar uma política de substituição de resultados

de consultas armazenadas emcacheque se adeque ao sistema Integra.

Algumas técnicas auxiliares têm sido agregadas ao gerenciamento decache, para um me-

lhor aproveitamento das consultas lá armazenadas. Uma dessas técnicas é a Identificação de

Subconsultas (Query Containment) [11], que já foi aplicada em alguns Sistemas de Integração

de Dados. A identificação de subconsultas permite ao sistema encontrar resultados de outras

consultas nacacheque sejam mais abrangentes que o resultado esperado pelo usuário. Dessa

forma, o sistema aumenta o aproveitamento dacache. Neste trabalho, propomos para o Integra

uma técnica de identificação de subconsultas baseada na representação XML das consultas.

Outra técnica que também tem sido aplicada em sistemas de integração é a substituição

parcial de consultas [4]. Segundo esta técnica, em vez de se remover todo o resultado de uma

consulta dacache, tenta-se remover apenas parte dele, para que haja um melhor aproveitamento

do espaço. Também propomos a aplicação desta técnica ao Gerenciador deCachedo Integra.

1.3 Contribuições Esperadas

Esperamos, com esse trabalho, contribuir para a pesquisa na área de gerenciamento deca-

cheem sistemas de integração de dados. Para isso, iremos propor e implementar algoritmos

para realizar atividades referentes ao gerenciamento decache, tais como: políticas de substi-

tuição de consultas, identificação de subconsultas e substituição parcial de consultas.

1.4 Estrutura da Dissertação

A presente dissertação está assim distribuída, além deste capítulo:

• Capítulo 2 - Sistemas de Integração de dados: Esse capítulo mostra a origem e os

conceitos básicos dos Sistemas de Integração de Dados, tais como abordagens e arquite-

tura. Ao final do capítulo descreve-se o Integra, sistema de Integração de Dados onde foi

desenvolvido o Gerenciador deCachefruto dessa pesquisa;

• Capítulo 3 - Cachee seu Gerenciamento: Nesse capítulo são abordados conceitos sobre

4

Cache, sua aplicação em bancos de dados e as atividades que compõem o seu gerencia-

mento do espaço e da consistência dos elementos armazenados;

• Capítulo 4 - Estado da arte em Gerenciamento deCache: Esse capítulo faz um le-

vantamento do estado da arte em relação a gerenciamento decache, mostrando diversos

algoritmos de substituição e técnicas auxiliares para o gerenciamento decache, além da

aplicação decacheem sistemas de integração de dados existentes;

• Capítulo 5 - Gerenciador deCacheno Integra: Nesse capítulo são apresentadas as

soluções propostas para Gerenciador deCachedo Integra, englobando política de subs-

tituição de elementos, identificação de subconsultas e substituição parcial de consultas,

bem como suas implementações;

• Capítulo 6 - Conclusão: Esse capítulo faz um resumo da contribuição que esta pesquisa

dá à área de gerenciamento decacheem sistemas de integração de dados e sugere também

trabalhos futuros que darão prosseguimento a esta pesquisa;

• Anexo 1: Representação XQueryX completa de uma consulta escrita em XQuery.

CAPÍTULO 2

Sistemas de Integração de Dados

Na era da informação globalizada e distribuída em diversas fontes autônomas e heterogêneas,

os Sistemas de Integração de Dados aparecem como uma solução interessante para realizar a

coleta e junção da informação. Eles permitem aos seus usuários uma visão única de acesso a

informações provenientes de diferentes origens.

No decorrer deste capítulo falaremos sobre Integração de Dados, conceitos básicos sobre

Sistemas de Integração de Dados e abordaremos o sistema que será explorado nesta dissertação:

o Integra.

2.1 Integração de Dados

A evolução tecnológica a que o mundo assistiu nas últimas décadas permitiu a propaga-

ção e a disponibilização da informação de diversas formas, jamais imaginadas pelos nossos

antepassados mais visionários.

As redes de comunicação compostas por telecomunicações móveis, comunicações via sa-

télite e, particularmente, a Internet, contribuíram para a chamada globalização da informação.

A informação passou a trafegar por canais cada vez mais rápidos e de maior abrangência.

Além disso, a acessibilidade a essa informação tornou-se cada vez mais democrática, estando

disponível a qualquer ser humano que estivesse conectado a uma rede como a Internet.

Por outro lado, qualquer pessoa também pode disponibilizar uma informação para o mundo.

Isso permitiu que as fontes das informações se reproduzissem a ponto de hoje termos um grande

número de possibilidades para busca de informações.

O grande número de fontes de informação possibilita o acesso a um vasto conteúdo sobre

qualquer assunto que se deseja pesquisar. No entanto, para se obter uma informação completa,

muitas vezes é necessário buscá-la em mais de uma fonte e combinar os resultados encontrados.

Por exemplo, na Internet encontramossitesque oferecem uma lista de restaurantes de qual-

quer cidade. Um deles é oGuia dos Restaurantes(“http://www.guiadosrestaurantes.com.br”).

Esse guia permite que o usuário escolha o tipo da culinária (árabe, italiana, chinesa, japo-

nesa, entre outras), o estado, a cidade e até o bairro onde fica o restaurante para realizar a

5

6

busca. No entanto, esse guia não disponibiliza o preço médio do prato cobrado em cada

restaurante. Se essa informação for relevante ao usuário, ele deverá procurá-la em outro

lugar. Uma das opções de site em que o usuário poderá obter essa informação é oGuia

Mais (“http://www.guiamais.com.br/restaurantes/”). Este último disponibiliza a informação

do preço; no entanto, não informa o bairro do restaurante. Então, se o usuário procura por um

restaurante no bairro de Boa Viagem (Recife-PE) cujo preço médio do prato seja 30 reais, ele

deverá primeiro procurar todos os restaurantes de Boa Viagem noGuia dos Restaurantes, e

depois buscar os preços de cada um noGuia Mais.

Essa junção dos dados provenientes de fontes diferentes é chamada integração de dados.

Para facilitar a vida dos usuários, em meados da década de 90 começaram a surgir os primeiros

Sistemas de Integração de Dados, que automatizaram a integração dos dados provenientes de

várias fontes diferentes.

2.2 Sistemas de Integração de Dados

A vantagem mais importante dos Sistemas de Integração de Dados é permitir que seus

usuários especifiquem o que eles desejam e o sistema se encarrega de obter as respostas [12].

Assim sendo, o usuário não precisa se preocupar em buscar as fontes relevantes, interagir com

as diferentes interfaces nem combinar as respostas de cada uma das fontes, basta conhecer o

esquema global do sistema de integração de dados que está utilizando. Esse esquema, também

conhecido como esquema de mediação, representa as entidades presentes nas fontes integradas

(ou locais) [13].

As fontes de dados acessadas por um sistema de integração de dados são autônomas e

independentes. Ou seja, cada uma possui características particulares e a manutenção delas

pode ser realizada a qualquer momento, de acordo com as necessidades das aplicações que as

utilizam. Essa manutenção engloba tanto alteração nos dados quanto nos esquemas de cada

fonte.

Algumas das incompatibilidades que podem existir entre as fontes estão listadas abaixo:

• Modelos de Dados - As fontes de dados podem apresentar modelos de dados distintos,

como relacional, orientado a objetos, multidimensional ou semi-estruturado;

• Esquema - Um esquema determina relações, atributos e restrições sobre os dados das

fontes. Fontes de dados podem ter esquemas altamente estruturados e restritivos como

podem ter esquemas apenas indicativos;

7

• Codificação dos valores - Valores e itens de dados podem estar codificados de maneira

distinta, por exemplo: um valor de pedido está em dólar em uma fonte e em real em outra

fonte, o item endereço pode ser um string em uma fonte e uma tupla relacional em outra;

• Linguagem de consulta - Algumas fontes podem apresentar linguagens de consultas na-

tivas (SQL, OQL, entre outras) e outras não possuem esse recurso;

• SGBD ou sistema de arquivo - Fontes que estão sendo gerenciadas por SGBD ou sistemas

de arquivos e fontes sem gerenciamento; e

• Sistema operacional e hardware

Essa autonomia das fontes é uma grande preocupação para sistemas de integração de dados.

Administrar a heterogeneidade das fontes de dados [6] é uma tarefa complexa.

2.2.1 Abordagens para Sistemas de Integração de Dados

Uma das primeiras decisões que deve ser tomada quando se deseja construir um sistema de

integração de dados é o tipo de abordagem que ele terá: virtual ou materializada [5].

Os sistemas com abordagem virtual só realizam acessos aos dados quando o usuário solicita

uma consulta. Esse acesso sempre é feito diretamente nas fontes de dados, o que garante que o

dado retornado ao usuário estará sempre atualizado. No entanto, por ter que sempre ir buscar

os dados nas fontes, os sistemas com essa abordagem encontram problemas quando alguma

das fontes está temporariamente indisponível ou quando as etapas de tradução e integração das

informações são extensas, tornando o processamento muito custoso. Essa abordagem é mais

indicada para sistemas que necessitam trabalhar com dados sempre atualizados.

Na abordagem materializada, os sistemas utilizam um repositório extra – comumente um

Data Warehouse– onde armazenam as informações mais relevantes. Dessa forma, quando o

usuário solicitar uma consulta sobre esse subconjunto de informações, o sistema não precisará

acessar as fontes, bastando apenas executar a consulta no repositório local. A grande vantagem

dessa abordagem é permitir que o tempo de resposta ao usuário seja bem inferior em relação

à abordagem virtual. Além disso, o usuário tem a garantia que a resposta sempre será dada,

independente da disponibilidade das fontes. No entanto, os dados retornados ao usuário podem

não estar consistentes com o das fontes. Essa abordagem é indicada em algumas situações, tais

como:

• Quando é possível identificar, entre todos os dados disponíveis, um subconjunto dos

8

mais relevantes – aqueles que serão mais procurados pelas consultas submetidas pelos

usuários;

• Quando o tempo de resposta da consulta é mais importante para o usuário do que a

necessidade dos dados retornados estarem atualizados; e

• Quando é necessário disponibilizar ao usuário informações a mais do que as fontes dis-

põem, como histórico dos dados, entre outros.

A escolha de qual abordagem é mais adequada para um sistema de integração de dados

varia de acordo com a finalidade de cada sistema. No entanto, para aplicações complexas e de

larga escala, pode ser necessária a utilização de recursos de ambas abordagens.

2.2.2 Arquiteturas

São duas as principais arquiteturas adotadas pela maioria dos sistemas de integração de

dados: a Arquitetura de Mediadores, adotada por sistemas que utilizam a abordagem virtual e

a Arquitetura deData Warehouse, ideal para sistemas com abordagem materializada. A seguir,

descreveremos cada uma.

Arquitetura de Mediadores

A arquitetura de mediadores implementa a abordagem virtual, que oferece uma visão inte-

grada de todos os dados armazenados nas várias fontes de dados e disponibiliza um esquema

para essa visão. Esse esquema é chamado de Esquema de Mediação e, baseado unicamente

nele, é que o usuário deverá montar suas consultas.

O componente mais representativo dessa arquitetura é o Mediador. Trata-se de um mó-

dulo de software que recebe e trata as consultas submetidas pelos usuários. Essas consultas

são formuladas baseadas no Esquema de Mediação. O Mediador também é responsável por

reformular cada consulta recebida em subconsultas que serão enviadas às fontes de dados.

A Figura 2.1 ilustra essa arquitetura. A quantidade de fontes de dados que participam de

um sistema é variável.

Essas subconsultas precisam ser traduzidas para as linguagens de consulta suportadas por

cada fonte. Esse é o trabalho do componente Tradutor. Após convertidas, as subconsultas são

submetidas às fontes, que retornam o resultado ao Tradutor, e este fará uma nova conversão,

transformando os dados originais das fontes de acordo com o modelo de dados comum do

sistema de integração de dados.

9

Figura 2.1 Arquitetura de Mediadores

Arquitetura de Data Warehouse

Implementando a abordagem materializada, este tipo de arquitetura recupera previamente

os dados, integra-os e armazena-os em um repositório central, oData Warehouse[14].

Uma vez que os dados estão armazenados noData Warehouse, as consultas submetidas

pelos usuários serão respondidas com base nos dados materializados, não sendo necessário que

o sistema acesse as fontes de dados. Esta arquitetura está ilustrada na Figura 2.2.

Uma das maiores preocupações dos sistemas de integração de dados que utilizam esse tipo

de arquitetura é tentar manter oData Warehousesempre consistente e atualizado com relação

às fontes de dados [15]. Esse problema não é trivial visto que as fontes são independentes e,

portanto, os seus dados podem sofrer alterações sem que elas sejam propagadas para oData

Warehouse.

Existem duas estratégias para os sistemas de integração de dados manterem os dados no

Data Warehouseconsistentes com as fontes de dados:

• Rematerialização da visão - Remoção de todo o conteúdo doData Warehousee reexe-

cução do processo de materialização dos dados atualizados. É um processo muito caro,

visto que elimina toda a visão materializada e a constrói novamente; e

10

Figura 2.2 Arquitetura de Data Warehouse

• Manutenção incremental - Atualização incremental doData Warehousetoda vez que

alguma fonte sofrer alteração.

Para decidir qual estratégia deve ser seguida, é necessário avaliar a capacidade que as fontes

de dados têm de enviar as modificações realizadas, para que a atualização dodata warehouse

consiga ser efetuada. Baseado nessa característica, as fontes de dados podem ser classificadas

como [13]:

• Fonte de dados com atividade satisfatória - A fonte é capaz de enviar todas as alterações

nela realizadas para o sistema de integração de dados;

• Fonte de dados com atividade restrita - A fonte apenas envia mensagens simples para

informar que sofreu alguma alteração; e

• Fonte sem atividades: A fonte não é capaz de informar quando sofrer alguma alteração.

Nesses casos, deve-se adotar a estratégia de rematerialização da visão.

2.2.3 Exemplos

Diversos Sistemas de Integração de Dados utilizamcachepara melhorar suas performan-

ces. Nesta seção, citaremos alguns deles e no Capítulo 4 descreveremos com mais detalhes a

11

arquitetura e o funcionamento do gerenciamento dacachede cada um.

O YACOB [3] é um sistema desenvolvido na Universidade de Halle-Wittenberg, na Alema-

nha e originalmente foi elaborado para permitir o acesso integrado a bancos de dados espalha-

dos pela Web, de artefatos culturais perdidos ou roubados durante a Segunda Guerra Mundial

[16]. Ele utiliza o domínio do conhecimento, baseado em vocabulários e ontologias, para rea-

lizar a integração dos dados.

O sistema Denodo[2], desenvolvido pelaDenodo Corporation, é um frameworkcomer-

cial utilizado por aplicações de integração de dados e apresenta um gerenciamento de cache

simples, mas que tem mostrado resultados bastante satisfatórios.

Dentre os sistemas pesquisados, o que mais chamou atenção foi o ACE-XQ, por ter sido o

pioneiro na utilização de XQuery [17] – linguagem de consulta que também é utilizada pelo

Integra – além de apresentar técnicas inovadoras para a manutenção do espaço dacachee da

consistência dos dados nela armazenados.

A seguir, descreveremos com detalhes o sistema Integra.

2.3 Integra

O Integra é um sistema de integração de dados na Web, proposto por [1], que fornece uma

visão integrada sobre diversas fontes de dados heterogêneas. É nesse sistema que iremos de-

senvolver o novo Gerenciador deCache, baseado na pesquisa realizada para o desenvolvimento

desta dissertação.

Esse sistema possui uma arquitetura mista, implementando as duas abordagens para sis-

temas de integração de dados: a virtual e a materializada [6]. Ou seja, o Integra possui um

repositório (Data Warehouse) onde ficam materializados alguns dados, e também faz acesso

às fontes de dados para a execução de consultas que não podem ser respondidas pelos dados

materializados.

Além desta arquitetura mista, o Integra também possui umacachepara armazenar resul-

tados de algumas consultas já submetidas pelos usuários. Esses resultados serão úteis quando

consultas idênticas se repetirem, visto que o resultado delas já estará nacache, poupando o

sistema de ter que acessar as fontes de dados.

2.3.1 Arquitetura

A arquitetura do Integra está ilustrada na Figura 2.3:

12

Figura 2.3 Arquitetura do Integra ([1])

A arquitetura do Integra é composta por quatro ambientes: Ambiente Comum, Ambiente

de Integração de Dados, Ambiente de Geração e Manutenção do Mediador e o Ambiente do

Usuário.

Cada ambiente será descrito a seguir, mas daremos maior ênfase ao Ambiente de Integração

de Dados, onde reside o foco principal do nosso trabalho.

2.3.1.1 Ambiente Comum

O Ambiente Comum é responsável por fornecer os dados que serão materializados ou retor-

nados para as consultas, além de informações sobre os esquemas das fontes para o Mediador.

Ele é composto por:

• Fontes de Dados - São as fontes da Web que fazem parte do Integra e fornecem ao sistema

todos os dados que são necessários para a materialização ou para responder às consultas

submetidas pelos usuários. Essas fontes são heterogêneas (podem ser de diversos tipos

diferentes: orientadas a objetos, relacionais, entre outras), autônomas (independentes do

Integra e entre si) e dinâmicas (seus esquemas são frequentemente alterados). O sistema

deve estar apto para mudanças nas suas fontes de dados, tais como: remoção ou adição de

13

uma nova fonte e alterações nos esquemas das fontes. As fontes de dados devem publicar

as versões mais recentes de seus esquemas exportados, para manter a consistência entre

as informações disponíveis para os usuários e os dados armazenados em cada fonte;

• Wrappers- São também conhecidos como tradutores e têm como função principal reali-

zar a conversão das consultas submetidas ao sistema no formato específico de cada fonte

e traduzir os dados retornados das fontes para o formato comum do sistema. No caso

do Integra, esse formato comum é o XML [18] que, devido a sua grande flexibilidade,

vem sendo largamente utilizado como linguagem para apresentação, troca e integração

de dados em diversos sistemas; e

• Lookups- São responsáveis por extrair os esquemas das fontes que participam do sis-

tema. A idéia é manter todos os esquemas das fontes atualizados na DSKB (Data Source

Knowledge Base). A adição de uma nova fonte ao sistema é realizada pelo seuLookup.

A nova fonte deve ter seu esquema exportado para o mediador, para que ele possa refor-

mular as consultas para essa fonte também. Essa tradução do esquema da fonte para o

formato comum do sistema é realizada pelosLookups. Eles interagem com o Gerenciador

de Esquemas Conceituais no Ambiente de Geração e Manutenção do Mediador.

Os Wrappers, juntamente com osLookups, compõem o módulo conhecido comoMid-

dlewaredentro do Ambiente Comum.

2.3.1.2 Ambiente de Geração e Manutenção do Mediador

Este ambiente é responsável pela manutenção do Mediador e das consultas de mediação. É

formado pelos seguintes componentes:

• Gerenciador de Esquemas Conceituais - Responsável por receber os esquemas das fon-

tes enviados pelosLookupspara criar o esquema de mediação no formato proposto por

[1], denominadoX-Entity. Trata-se da extensão do ER [19] para esquemas XML. Esse

componente também trata modificações nos esquemas das fontes;

• Comparador de Esquemas - Tem a finalidade de identificar correspondências entre os ele-

mentos dos esquemas. Para isso, realiza uma análise sintática e semântica, com o intuito

de verificar quais elementos de um determinado esquema são logicamente corresponden-

tes aos elementos de outro esquema;

• Gerador de Consultas de Mediação - Seleciona as fontes relevantes que potencialmente

permitem computar uma determinada consulta de mediação. Além disso, identifica os

14

operadores possíveis para aplicar entre fontes diferentes e gera todas as possíveis consul-

tas, a partir das fontes e operadores.

• Gerenciador de Consultas de Mediação - Interage diretamente com o Gerenciador de

Esquemas Conceituais, recebendo dele os eventos ocorridos nas fontes e propagando-os

para o esquema de mediação. Eventos como adição de novas fontes, remoção de fontes

existentes ou alteração em alguma delas são refletidos no esquema de mediação;

• Avaliador de Consultas de Mediação - Utiliza métricas como disponibilidade da fonte de

dados e tempo de resposta para analisar o impacto de propagações das modificações de

esquema na qualidade do sistema como um todo; e

• Base de Conhecimento das Fontes de Dados (DSKB): Repositório onde ficam armazena-

dos os esquemas das fontes de dados.

2.3.1.3 Ambiente do Usuário

O Ambiente do Usuário trata das questões referentes aos requisitos especificados pelo usuá-

rio. O Mediador necessita desses requisitos para poder montar o esquema de mediação. O

Gerenciador de Consultas de Mediação será encarregado de propagar os requisitos do usuário

para o sistema.

2.3.1.4 Ambiente de Integração de Dados

Este ambiente é responsável por aspectos relacionados à reformulação de consultas e, con-

sequentemente, ao desempenho do sistema. É composto pelo Mediador, Gerenciador doData

Warehousee pelo Gerenciador deCache.

Mediador

O Mediador é o componente responsável por receber a consulta submetida pelo usuário.

De posse da consulta, o mediador a decompõe em subconsultas, chamadas consultas de medi-

ação, e seleciona as fontes de dados que receberão cada uma das subconsultas. Após as fontes

responderem às subconsultas que lhes foram destinadas, o Mediador recebe todas as respostas

e as integra para responder ao usuário.

O Mediador é composto por:

• Gerenciador de Consultas - Responsável por identificar quais fontes de dados são relevan-

tes para responder a consulta submetida pelo usuário. Para realizar essa tarefa, ele faz uso

15

da Base de Conhecimento do Mediador (MKB -Mediator Knowledge Base). Interagindo

com o Gerenciador deCache, ele procura por resultados de consultas já executadas an-

teriormente para agilizar o processamento das consultas. Além disso, a tarefa de integrar

os dados retornados pelas subconsultas também é de responsabilidade do Gerenciador de

Consultas; e

• Gerenciador das Fontes - Trabalha em conjunto com osWrappers, submetendo as sub-

consultas e recebendo os resultados. Também realiza a monitoração das fontes para

identificar que dados podem ser materializados nodata warehouse.

Gerenciador doData Warehouse

Realiza a manutenção doData Warehouseno que diz respeito à materialização dos dados,

sugerida pelo Gerenciador das Fontes, e à atualização (refreshment) dos dados materializados.

Para materialização dos dados, o Gerenciador das Fontes fornecerá ao Gerenciador doData

Warehousetodos os dados e metadados necessários para executar a materialização.

Gerenciador daCache

Quando o usuário submete uma consulta ao Integra, o primeiro passo executado pelo sis-

tema é realizado pelo Gerenciador de Consulta, que aciona o Gerenciador deCachepara veri-

ficar se a resposta daquela consulta já está armazenada emcache. Em caso positivo, a resposta

é diretamente retornada ao usuário. Caso contrário, a consulta é decomposta e submetida ao

Data Warehousee/ou às fontes de dados.

Toda a manutenção daCachedo Integra é realizada pelo Gerenciador deCache. Essa tarefa

compreende as seguintes atividades:

• Gerenciar o espaço daCache- A cachepossui um tamanho limitado e, por isso, não

cabem nela as respostas de todas as consultas (o que seria ideal). Portanto, o Gerenciador

deCachedeve saber decidir, quando acacheatingir a lotação máxima, que resultados de

consultas devem permanecer e quais devem sair para a entrada de novos; e

• Manter os dados dacacheconsistentes - O sistema deve tentar manter os dados arma-

zenados emcacheo mais atualizado possível, para evitar que eles fiquem inconsistentes

com as fontes de dados e que a resposta ao usuário seja inválida.

Para executar a primeira atividade, o Gerenciador deCacheutiliza um algoritmo de subs-

tituição de elementos emcacheque serve para decidir que elemento deve sair dacachepara

16

a entrada de um novo dado. Os algoritmos de substituição de elementos emcacheserão mais

discutidos nos capítulos 3 e 4, mas aqui citaremos o algoritmo utilizado atualmente pelo Ge-

renciador deCachedo Integra por ser bastante conhecido: o LFU (Least Frequently Used) [7].

Este algoritmo indica, para sair dacache, sempre o elemento menos acessado. Assim, toda vez

que uma nova consulta precisa entrar nacachee não há mais espaço, o Gerenciador elimina a

consulta menos acessada dacachepara permitir a entrada da nova consulta.

Para aplicar o algoritmo LFU, o sistema necessita de informações adicionais sobre as con-

sultas cujos resultados estão armazenados emcache. Por exemplo, a quantidade de vezes que

cada consulta foi acessada emcacheé uma informação imprescindível para que o Gerenciador

deCachepossa escolher a consulta menos acessada e removê-la dacache.

As informações adicionais sobre cada consulta armazenada emcacheestão armazenadas no

Log da consulta. Os logs ficam armazenados num repositório exclusivo e possuem a estrutura

mostrada na Figura 2.4.

Figura 2.4 Estrutura do log de uma consulta

O identificador da consulta é a chave que identifica unicamente cada consulta armazenada

no log. O script da Consulta corresponde à consulta em si. O indicador dacacheindica se

a consulta está armazenada nacache. Informações como tamanho do resultado (em Kbytes),

freqüência de submissões da consulta, tempo de resposta da consulta, e um identificador do

usuário também compõem o log. É com base nesses dados que o Gerenciador daCachedecide

quem fica e quem sai dacache.

Para executar a atividade de manutenção dos dados dacacheconsistentes, o Gerenciador

deCacheexecuta operações derefreshmentperiodicamente.

No capítulo 5, mostraremos as mudanças propostas para o Gerenciador deCache, para

que ele consiga ser mais eficiente e, consequentemente, responder uma maior quantidade de

consultas submetidas pelos usuários, evitando que o sistema tenha que acessar as fontes de

dados.

17

2.4 Considerações Finais

Neste capítulo pudemos constatar que os Sistemas de Integração de Dados, como o Integra,

são poderosas ferramentas que servem como grande auxílio aos usuários que desejam obter

informações de diversas fontes diferentes em um único lugar. Descrevemos os principais am-

bientes que compõem a arquitetura do Integra, destacando o Gerenciador deCache, foco desta

dissertação.

CAPÍTULO 3

Cachee seu Gerenciamento

A cacheé uma área de memória de acesso mais fácil, onde são armazenadas as informações

requisitadas com mais frequência. Assim, das próximas vezes em que esses dados forem solici-

tados, eles não mais serão buscados em suas fontes originais, e sim nacache, que os disponibi-

lizará mais rapidamente. Geralmente, essa área de acesso rápido fica na memória principal[20].

O processo decachingconsiste no mecanismo de armazenamento dos objetos nessa área

de memória, e possui três objetivos: reduzir a quantidade de acessos ao disco, reduzir o uso de

memória (utilização da CPU) e diminuir o tempo de resposta ao usuário.

Neste capítulo, abordaremos como acacheé explorada em sistemas de informação que

realizam acesso a dados e também descreveremos conceitos básicos relacionados acachee seu

gerenciamento, tais como: tipos decache, substituição de elementos nacachee a atualização

desses dados.

3.1 Cacheem Bancos de Dados

Normalmente, quando se pensa em construir um grande banco de dados, que possa ser

acessado por vários usuários ao mesmo tempo, uma das preocupações é como desenvolvê-lo a

fim de dar suporte aos múltiplos acessos simultâneos, de forma confiável e satisfatória. Para

isso, é necessário que o banco retorne dados completos e consistentes ao usuário, com uma

performance aceitável.

Vários mecanismos podem ser empregados para atingir tais objetivos. Um meio bastante

utilizado em bancos de dados para redução do tempo das respostas às consultas submetidas é o

uso decache.

Em bancos de dados, há três tipos decaching: resultado da consulta, planos de consulta e

relacionamentos [20].

No primeiro tipo,cachingdo resultado da consulta, é colocada nacachea saída exata da

consulta (SELECT) submetida ao banco; esse resultado será útil para as próximas vezes em

que a mesma consulta for requerida. Assim, se 1000 pessoas solicitam a consulta “SELECT

* FROM aluno” a uma determinada base de dados, o banco a executará para a primeira requi-

18

19

sição, salvará o seu resultado e lerá dacachepara responder às outras 999 requisições. Isto

evita que o banco de dados faça qualquer acesso ao disco, praticamente remove o uso de CPU

e diminui o tempo de resposta da consulta.

No cachingde resultado, cada entrada nacachecontém: a própria consulta, seu resultado,

o status, o tempo de acesso, entre outras informações úteis. O campo de status é um indicador

que determina se a consulta que está nacacheé válida. Ela pode não ser válida para um usuário

mas ainda ser útil para outros.

Quando uma consulta SELECT é processada, ela é transformada em uma forma padrão,

para facilitar a comparação com as consultas em memória. A idéia é buscar dentro dacache

uma consulta idêntica à que está sendo submetida e retornar o resultado idêntico ao produzido

anteriormente. Uma possível melhoria para esse tipo decachingé conseguir fazer com que

o sistema considere, por exemplo, as consultas “SELECT nome, matricula FROM ALUNO”

e “SELECT matricula ,nome FROM ALUNO” como sendo consultas “idênticas” e retornar o

mesmo resultado para as duas, mas isso requer umparsermais avançado.

Quando é encontrada uma consulta em memória idêntica à nova consulta, o banco de dados

retorna o resultado que está armazenado, atualiza o tempo da última solicitação, o contador e

termina a execução. Esse processo é extremamente rápido, não realizando nenhum acesso ao

disco e usando pouquíssimo processamento. A complexidade da consulta não influencia muito

(uma consulta simples será processada tão rapidamente quanto uma consulta com 12 sorts e 28

joins).

Se uma consulta não está nacache, o sistema a executará e, após retornar o resultado ao

usuário, tentará armazená-la em memória. Para isso, verifica primeiro se há espaço suficiente

nacachepara comportar a nova consulta e o seu resultado. Se houver, a consulta e seu retorno

são armazenados, com o status “ativo”, contador 1 e com o tempo de acesso atual. Caso

não haja espaço, o sistema terá que remover uma ou mais consultas dacache, para que a

nova “candidata” consiga ser armazenada. A escolha de qual(is) consulta(s) deve(m) sair da

memória é uma parte crítica do sistema e é baseada nos dados extras (último acesso, quantidade

de acessos, entre outros) armazenados com cada consulta. Vários algoritmos para substituição

de elementos nacachejá foram propostos [7]: remoção da consulta requisitada há mais tempo,

a que tiver a menor quantidade de acessos, a que ocupar o maior espaço na memória, entre

outros. Esses algoritmos serão mostrados em detalhe no Capítulo 3.

Sempre que o registro de uma tabela é alterado, deve-se verificar acache. Uma lista de todos

os atributos que foram atualizados deve ser comparada com os atributos retornados em cada

consulta em memória. Se alguma mudança for identificada, o indicador do status da consulta

deve ser trocado para “inválido”, já que os dados estão inconsistentes. Essa verificação deve ser

20

feita antes da tabela ser atualizada de fato. A consulta não deve ser removida imediatamente da

cacheporque ela ainda está dentro da transação. Quando a transação acaba, todas as consultas

marcadas como inválidas são removidas da memória e a tabela é atualizada.

O segundo tipo decaching, o dos planos da consulta, consiste em salvar os resultados do

“otimizador”, que é responsável por indicar “como” o banco de dados de fato realiza a busca aos

dados solicitados. Se uma consulta do tipo “SELECT * FROM aluno WHERE matricula=?”

é executada para 500 valores diferentes de “matricula”, o plano de execução da consulta é

armazenado da primeira vez e reutilizado para as demais solicitações.

O cachingde relacionamentos consiste em armazenar a entidade por inteiro na memória,

para ser acessada de forma mais rápida e, em conjunto, deve ser armazenado o tempo do último

acesso e o contador.

Uma decisão importante com relação ao armazenamento das consultas nacacheé escolher

em que nível estas serão armazenadas: nível conceitual ou nível de fonte. O armazenamento no

nível conceitual significa que as consultas serão armazenadas já adaptadas ao esquema global.

Dessa forma, os resultados das consultas vindos da fonte são transformados antes de serem

colocados nacache. A vantagem desta técnica é que uma consulta àcachejá retorna o resultado

processado, sem necessidade de transformação para o esquema global.

O armazenamento emcacheno nível da fonte é realizado antes da transformação para o

esquema global. Cada consulta de uma fonte possui uma entrada separada de outra fonte na

cache. A principal vantagem desta técnica é a maior granularidade de informação nacache.

Por outro lado, os resultados nela armazenados ainda não estão transformados para o esquema

global, o que demandará um certo processamento, diminuindo a performance dacache.

3.2 Substituição de Elementos em Cache

Para o desenvolvimento de um bom algoritmo de substituição de elementos numacache,

geralmente se leva em consideração três fatores:

• Última referência - É baseada no princípio da localidade temporal, segundo o qual a

probabilidade de se acessar um objeto A após um intervalo de tempo t do primeiro acesso

é maior que a de ele ser acessado após um intervalo t + 1. Dessa forma, é identificado

quão recentemente foi acessado um objeto para decidir se ele deve sair ou não dacache.

Um exemplo de algoritmo que se baseia unicamente nesse princípio é o LRU (Least

Recently Used) [7];

21

• Freqüência de acesso - A tomada de decisão sobre a saída ou não de um objeto dacache

deve ser baseada na frequência de acessos que esse objeto teve até então; assim, quanto

mais vezes um objeto foi acessado dentro de um certo intervalo de tempo, maiores são

suas chances de permanecer emcache. Um algoritmo bastante conhecido que se baseia

nesse princípio é o LFU (Least Frequently Used) [7]; e

• Tamanho do objeto - O espaço de umacachegeralmente é bastante limitado, devido ao

alto custo. Por isso, um dos fatores levados em consideração para decidir se um objeto

deve permanecer emcacheé o tamanho dele. Quanto maior o objeto, menos chance ele

terá de ficar armazenado, visto que ele poderia ocupar o espaço equivalente ao de mais

de um objeto. No entanto, para sistemas que operam em redes cujo tráfego de dados é

crítico, é mais interessante manter emcacheos objetos maiores.

O algoritmo pode considerar apenas um desses fatores ou utilizar conceitos de mais de um

fator, de acordo com as características do sistema onde será empregado. Por exemplo, veremos

no Capítulo 4 que o algoritmo LFU [7] leva em consideração apenas o fator freqüência de

acesso, enquanto o LRU/k [8] utiliza aspectos relacionados à freqüência de acesso e à última

referência a um objeto.

3.3 Atualização dos Elementos em Cache

Quando um usuário executa uma consulta a um sistema qualquer, ele espera que todos os

dados retornados estejam consistentes com as fontes, independente do repositório onde eles fo-

ram encontrados (armazenados emcacheou materializados em umdata warehouse, por exem-

plo). A consistência dos dados é tida como um dos mais importantes critérios de qualidade

para os usuários [21]. Alguns estudos anteriores [22, 23, 21] mostram que a consistência dos

dados está intimamente ligada ao sucesso de um sistema de informação.

3.3.1 Fatores de qualidade

Por compreender um conjunto de fatores de qualidade que representam alguns aspectos de

consistência e tendo suas próprias métricas, a consistência de um dado é tida como um critério

de qualidade [24], e é subdividida em dois fatores:

• Atualidade [25] - Mede o intervalo de tempo entre a extração do dado das fontes e a sua

entrega ao usuário. Um exemplo desse fator seria a indicação de quão antigo está o saldo

22

de uma conta apresentado ao usuário em relação ao saldo que está registrado no banco; e

• Periodicidade [22] - Mede a frequência com que um dado é atualizado ou que um novo

dado é criado na fonte. Por exemplo, otimelinessmede com que frequência o preço

de um produto é alterado ou a frequência com que novos livros são adicionados a uma

livraria.

Analogamente, outros fatores podem ser definidos, por exemplo: se uma fonte sofre cons-

tantes atualizações mas tem alguns dados que nunca mudam de valor, pode-se definir um fator

que considere essa particularidade.

Para cada um desses fatores, existem métricas que ajudam a medir o grau de consistência

de um dado, como abaixo.

• Métricas para o fator Atualidade:

– Tempo de atualização - Mede o tempo decorrido desde a alteração do dado na fonte

até sua atualização na visão materializada. Quando a mudança é propagada imedia-

tamente, esse tempo é 0 (zero) [25]. Na prática, como o tempo preciso da alteração

de um dado é difícil de ser obtido, é comum estimar a atualidade como a diferença

entre o tempo de extração do dado e o de entrega do mesmo ao usuário. Essa es-

timativa é utilizada em sistemas dedata warehouse[26]. Em sistemas decaching,

essa métrica é definida comorecentidade(representando o tempo que o objeto está

armazenado nacache) [27] e idade(representando quão antigo é o objeto) [28];

– Obsolescência - Indica o número de atualizações realizadas na fonte desde a extra-

ção do dado. Pode ser medida utilizando oslogsda fonte. Conhecida a obsolescên-

cia de um objeto, é possível estimar a frequência de atualização dele. Nos sistemas

de caching, a obsolescência é conhecida comoidade, representando o número de

vezes que o objeto foi atualizado no servidor depois de ser armazenado emcache;

e

– Taxa de consistência - Corresponde à porcentagem dos elementos extraídos que

estão com seus valores iguais aos da fonte de dados. Em sistemas decaching, essa

taxa é definida como o número de elementos que estão atualizados nacachesobre

o número total de elementos.

23

• Métrica para o fator Periodicidade:

– Periodicidade - Corresponde à frequência de atualização de um dado. Esse cál-

culo pode ser feito baseado no tempo da última atualização feita no dado e na sua

frequência de atualização. [29].

De acordo com a frequência com que um dado é alterado, ele pode ser classificado em:

• Dado Estável - É o dado cuja probabilidade de mudança é muito pequena. O nome de

um livro, por exemplo, é um dado estável. A inclusão de novos livros numa livraria é

possível acontecer, mas a mudança do nome de um exemplar não é comum;

• Dado com mudança a longo prazo - Trata-se de um dado que possui uma baixa frequência

de alteração do seu valor. Um exemplo é o cadastro de endereços dos funcionários de

uma empresa. O conceito de “baixa frequência” é relativo de acordo com o domínio.

Para aplicação dee-commerce, se a frequência de alteração do estoque dos produtos é

de uma vez na semana, pode ser considerada uma “baixa frequência”; no entanto, um

cinema que mude o filme em cartaz uma vez por semana pode ter uma alta frequência,

no ponto de vista dos espectadores; e

• Dado com mudança freqüente - É o dado cuja frequência de mudança é altíssima, como

informações de um sistema de tempo real, sensores que monitoram temperatura, entre

outros. Essa frequência pode ser constante ou randômica, por exemplo um sensor que

está programado para aferir a temperatura do ambiente a cada intervalo de tempo possui

uma frequência fixa, já um sistema que registra as vendas de uma loja em tempo real não

possui uma frequência definida.

3.3.2 Consistência da informação

A consistência de um dado entregue ao usuário depende não só da consistência do dado que

foi extraído, mas também do processo de extração, integração e entrega desse dado [30]. Estes

processos são muito importantes porque adicionam atrasos ao processamento.

Em sistemas de integração de dados que utilizamcache, geralmente o que fica nela ar-

mazenados são relacionamentos ou resultados das consultas mais constantemente executadas.

Quando o usuário submete uma consulta, o sistema verifica se o resultado dela está emcache.

Se estiver, ele apenas entrega ao usuário; caso contrário, ele busca os resultados nas fontes,

integra-os, atualiza os dados emcachee finalmente entrega ao usuário. Esses sistemas geral-

mente estipulam um prazo para identificar se cada elemento emcacheainda é útil, ou seja, se

24

ele não está desatualizado. Passado esse tempo, este dado nacachepassa a ficar inválido e

devemos atualizá-lo com o valor que está na fonte.

Outro fator que contribui para a consistência dos dados é a política de sincronização com as

fontes que o sistema de integração de dados adota, por exemplo: um sistema que execute a sin-

cronização uma vez por dia num horário específico pode fornecer um dado que não corresponda

às expectativas de algum usuário.

De acordo com a interação entre os sistemas de integração e as fontes de dados, o processo

de extração dos dados pode adotar políticas depull ou push[30]. Pela políticapull o sistema

de integração envia as consultas às fontes para obter os dados, e pela políticapushas fontes

enviam os dados ao sistema. A notificação de que um novo dado está disponível na fonte pode

ser disparada por umatrigger ou por constantes verificações do sistema nas fontes.

Considerando as diversas formas de interação entre usuários, sistemas de integração e as

fontes de dados, existem seis diferentes possíveis configurações com as políticas citadas acima.

Essa configurações podem ser vistas na Figura 3.1

Figura 3.1 Políticas de Sincronização

Nem todas as combinações entre os tipos de aplicações e as políticas de sincronização

são válidas, por exemplo: sistemas virtuais – aqueles que não materializam qualquer dado,

seja emcacheou emdata warehouse– não dão suporte à configuraçãopull-pull; sistemas

com materialização – aqueles que materializam grande volume de dados, sempre mantendo-os

atualizados – dão suporte a configurações que exigem um repositório interno para armazenar os

25

dados materializados; sistemas decachingdão suporte às configurações que aplicam a política

depull nas fontes de dados (síncrona e assíncrona). A Figura 3.2 mostra as combinações válidas

entre os tipos de sistemas e as políticas de sincronização.

Figura 3.2 Combinação de Políticas de Sincronização

Representando essas configurações como a política aplicada na comunicação entre usuários

e sistema de integração, seguida da política aplicada na interação sistema de integração e fontes

de dados, obtemos as seguintes combinações (o símbolo ’/’ representa assincronismo e ’-’,

sincronismo) [30]:

• pull - pull - A interação é inteiramente síncrona. Quando um usuário submete uma con-

sulta (pull), ela é decomposta pelo sistema de integração e enviada às fontes de dados

(pull). Essa configuração é representada pela seta (a) na Figura 3.1;

• pull / pull - Quando um usuário submete uma consulta (pull), o sistema de integração res-

ponde com os dados materializados. Assincronamente, o sistema executa essa consulta

nas fontes para poder atualizar os dados materializados (pull). É comum em sistemas de

data warehousinge está representada pelas setas (b) e (c) na Figura 3.1;

• pull / push- Quando um usuário submete uma consulta (pull), o sistema de integração

responde usando os dados materializados. Assincronamente, as fontes enviam os dados

ao sistema para poder atualizar os elementos materializados (push). É representada pelas

setas (b) e (e) na Figura 3.1. Também é comum em sistemas dedata warehousing;

• push/ push- As fontes enviam os dados ao sistema de integração (push), eles são usados

para atualizar as materializações. Assincronamente, o sistema envia os dados ao usuário

(push). É representada pelas setas (d) e (e) na Figura 3.1;

• push/ pull - Os dados materializados são entregues assincronamente ao usuário (push) e,

assincronamente, o sistema de integração de dados consulta as fontes para atualizar suas

materializações (pull). É comum em aplicações dedata martse está representada pelas

setas (d) e (c) na Figura 3.1; e

26

• push- push- A interação é síncrona. Quando as fontes enviam os dados ao sistema de

integração (push), imediatamente o sistema entrega esses dados ao usuário (push). Essa

configuração é representada pela seta (f) na Figura 3.1. É característica dos sistemas de

tempo-real.

Em sistemas decaching, o dado é considerado consistente se for idêntico ao dado que

está na fonte, então a consistência é representada pelo fator atualidade e é medida através das

métricas (tempo de atualização, obsolescência e taxa de consistência).

Sistemas decachingtradicionais trabalham com o conceito devalidade. Esses sistemas

estimam o TTL (time-to-live), que corresponde ao tempo que supostamente cada objeto em

cachejá foi atualizado na fonte; assim acachepode armazenar dados com mudança a longo

prazo e dados com mudança freqüente. Quando o TTL expira, o objeto nacachepassa a ser

inválido para uso, então o próximo acesso ao objeto será feito diretamente à fonte e ele será

atualizado nacache(políticaspull-pull epull/pull).

3.4 Técnicas Auxiliares

Para um completo gerenciamento decachedentro de um sistema, é necessário nos preocu-

parmos com fatores além de substituição e atualização dos dados que estão armazenados.

Algumas técnicas auxiliares são de grande valor para um Gerenciador deCache. Alguns

sistemas de integração de dados – como o ACE-XQ – já possuem gerenciadores decachecom

uma visão mais ampla, apresentando funcionalidades extras bastante interessantes. Uma delas é

a técnica de Identificação de Subconsultas (conhecida comoQuery Containment), que também

faz parte da proposta de melhoria do Gerenciador deCachedo sistema Integra, com algumas

modificações. Esta técnica será descrita com mais detalhes a seguir.

3.4.1 Identificação de Subconsultas

Em sistemas de informação que utilizamcacheé natural que, com a submissão de uma nova

consulta, se busque dentro dacacheuma consulta que case perfeitamente com a solicitada.

Dessa forma, uma nova consulta só será respondida por uma que esteja nacachese ambas

forem idênticas.

Consideremos uma situação em que o usuário submeteu a seguinte consulta, em SQL, ao

sistema:

27

SELECT t i t u l o , a u t o r

FROM l i v r o s

WHERE t i t u l o l i k e "% Database Cache%"

AND ano > 2005

Quando executada, ela retornará informações (titulo e autor) de todos os registros armaze-

nados na tabela livros cujo campo título contenha o texto“Database Cache”e cujo ano seja

maior que 2000.

Supondo que o sistema em questão possui umacachee nela esteja armazenada apenas o

resultado da seguinte consulta:

SELECT t i t u l o , au to r , ano , e d i t o r a

FROM l i v r o s

WHERE t i t u l o l i k e "% Cache%"

AND ano > 2000

Ao receber a consulta submetida pelo usuário, um sistema com gerenciamento decache

convencional procuraria nacacheuma consulta idêntica a que está sendo requisitada. Nesse

exemplo, ele não encontraria uma consulta correspondente e ela deveria ser executada direta-

mente na fonte de dados.

No entanto, podemos notar que a consulta que está nacacheretorna os mesmos campos

da primeira, além de informações adicionais, como ano e editora. Analisando ainda restrição

desta consulta, constata-se que ela é mais abrangente que a primeira, visto que recupera to-

dos os livros cujo título contenha a palavra“Cache” e o ano seja maior que 2000. Se essas

duas consultas fossem executadas no mesmo banco de dados, ao mesmo tempo, o resultado

da primeira corresponderia a um subconjunto do resultado da segunda, visto que esta é mais

abrangente. Nesse caso, dizemos que a primeira consulta é uma subconsulta total da segunda,

ou seja, a resposta da primeira está completamente contida na da segunda.

Considere, agora, que o usuário submeteu uma nova consulta:

28

SELECT t i t u l o , au to r , p reco

FROM l i v r o s

WHERE t i t u l o l i k e "% Database Cache%"

AND ano > 2005

Nota-se que a única diferença entre ela e a primeira é que agora ele busca mais uma infor-

mação sobre o livro: o preço. Essa informação também não é retornada pela consulta que está

nacache. No entanto, comparando a restrição das duas, notamos mais uma vez que a consulta

dacacheé mais abrangente que a que o usuário submeteu. O único problema é que o campo

preco não está na consulta emcache. Nesse caso, dizemos que a consulta do usuário é uma

subconsulta parcial da que está nacache, visto que esta contém parcialmente aquela.

Se o sistema for capaz de identificar nacacheuma consulta que possa ser utilizada para

responder – parcialmente ou totalmente – a do usuário, obviamente ele terá um maior aprovei-

tamento de suacache. Quando a consulta dacachecontiver parcialmente a consulta do usuário,

esta deve ser reformulada em duas: uma para ser executada sobre a consulta que está nacache

e outra para ser executada na fonte.

Essa limitação em relação à busca de consultas emcachecomeçou a ser discutida em [31],

que sugeriu como melhoria a técnica de Identificação de Subconsultas entre consultas relaci-

onais. Foi o primeiro passo nos estudos de uma técnica que virou tendência entre os sistemas

que utilizamcache.

Identificar se uma consulta contém outra total ou parcialmente, ou seja, se um subconjunto

dos dados que respondem uma consulta pode ser encontrado em outra, não é um trabalho trivial.

No contexto relacional, esse problema já foi amplamente estudado ([32, 33, 34, 35]). Em [31] é

provado que se trata de um problema NP-Completo. No entanto, os estudos para solução desse

problema quando se tem consultas em XML ainda estão em fase bem inicial.

Recentemente, alguns pesquisadores iniciaram estudos sobre o problema de Identificação

de Subconsultas para consultas em XPath [36, 37, 38, 39] e em XQuery [40, 41, 42]. Os dois

problemas são bastante diferentes visto que as consultas em XPath retornam um conjunto de

nós. Como o Integra trabalha com consultas em XQuery, focamos nossos estudos no escopo

das consultas em XPath e XQuery, que possuem características semelhantes visto que XPath é

um subconjunto de XQuery.

Em [43], os autores definem que uma consultaQ1 está contida em uma consultaQ2 deno-

tado porQ1v Q2 se, para qualquer banco de dadosD, a resposta paraQ1 corresponde a umsubconjunto da resposta da consultaQ2. As duas consultas são ditas equivalentes, denotado por

29

Q1≡Q2, seQ1vQ2 e Q2vQ1. Chandra e Merlin em [31] provam que para duas consultasconjuntivasQ1 e Q2, Q1v Q2 se, e somente se, houver um mapeamento das variáveis deQ1para as variáveis deQ2.

Identificação de Subconsultas e Reescrita de Consultas são assuntos já bem estudados para

consultas conjuntivas em álgebras relacionais. No entanto, para consultas em XML, pesquisas

sobre Identificação de Subconsultas ainda estão num estágio bastante imaturo.

Alguns procedimentos são comuns para identificação de Identificação de Subconsultas

tanto em consultas em XQuery quanto em XPath: montagem das árvores representativas, nor-

malização e minimização das consultas.

As técnicas de Identificação de Subconsultas para consultas em XQuery propostas, apesar

de diversas, aparecem sempre agregadas a atividades em comum, como a normalização. Essa

atividade será descrita na sessão a seguir.

3.4.1.1 Normalização

Da mesma forma que em SQL e em outras linguagens, em XQuery uma mesma consulta

também pode ser formulada de várias formas. Isso se dá devido à vasta gama de funcionalidades

que essas linguagens oferecem. A Figura 3.3 mostra três formas diferentes de se escrever uma

mesma consulta em XQuery.

As diferenças entre as consultas podem ser simples, como entre a consulta A e a consulta B

– que se diferenciam apenas pela ordem como estão dispostas as variáveis – ou mais complexas,

como entre a consulta C e as outras – que se diferenciam pela estrutura. No entanto, todas elas

retornam sempre os mesmos resultados quando executadas numa mesma base de dados.

Por conta dessa possibilidade de se escrever uma mesma consulta de várias formas diferen-

tes, para que se possa realizar comparações para identificar se uma determinada consulta está

nacacheou contida em outra que lá esteja, é necessário estabelecer um padrão de estrutura de

consulta para facilitar as comparações.

A conversão de uma consulta formulada em uma determinada estrutura para a estrutura

padrão consiste no processo chamado de Normalização.

Atualmente existem algumas técnicas de normalização de consultas definidas como em

[17, 40, 44].

Em [40], os autores definem regras de normalização específicas para um grupo restrito de

consultas que o sistema proposto trata. Em [17], estão definidas as regras de normalização

adotadas pelo consórcio criador da linguagem XQuery, o W3C(World Wide Web Consortium).

30

Figura 3.3 Três maneiras de escrever uma mesma consulta em XQuery

Algumas regras são comuns a todas as técnicas de normalização encontradas. Por exemplo,

na normalização de expressões do tipo FLWOR (expressões que contenham as cláusulasfor,

let, where, order bye return) o tratamento de cláusulasfor mais complexas é feito da mesma

forma. Essa regra determina que umfor complexo deve ser reescrito como uma composição de

várias expressõesfor mais simples. Aplicando essa regra em uma expressão do tipo:

FOR Var1 in Exp1, Var2 in Exp2, ... , Varn in Expn return Exp

obtém-se a seguinte expressão normalizada:

FOR Var1 in Exp1 return FOR Var2 in Exp2 return ... FOR Varn in Expn return Exp

ondeVar1, Var2, ...,Varn são variáveis eExp1, Exp2, ...,Expn são expressões.

Observando a regra, notamos que ela desmembra oFOR da expressão em vários outros

FOR, para que cada um contemple apenas um par de variável e expressão.

Esta é apenas uma entre as diversas regras de normalização para consultas em XQuery.

31

Em [17], estão definidas as demais regras de normalização para diversos componentes dessa

linguagem:

• Literais;

• Expressões Aritméticas;

• Expressões Comparativas;

• Expressões Lógicas; e

• Expressões FLWOR.

Já em [40], os autores elaboraram um outro conjunto de regras de normalização – contendo

inclusive a regra doFOR– para contemplar apenas um subconjunto de consultas em XQuery

que o sistema por eles proposto atende.

3.4.1.2 Problemas relacionados

Ao identificar-se que uma consulta está contida em outra cujo resultado está armazenado

na cache, para se obter o resultado daquela basta executá-la sobre o resultado da que já foi

executada anteriormente. Teoricamente, a resposta será igual à resposta que seria dada se a

consulta fosse executada diretamente na fonte de dados – considerando que acachenão esteja

inconsistente com a fonte. No entanto, muitos dos algoritmos de Identificação de Subconsultas

propostos nem sempre identificam com segurança se uma dada consulta está de fato contida

e, portanto, pode ser respondida por outra. Eles apresentam falhas quanto à completude do

resultado, ou seja, essas técnicas não garantem que o resultado obtido a partir da execução de

uma consulta que está contida em outra nacachecorresponda ao esperado.

Isso acontece com os algoritmos propostos em [40] e em [42]. As duas técnicas se baseiam

no homomorfismo entre as árvores representativas de cada consulta com algumas condições de

mapeamento adicionais para identificar se uma está contida na outra. Em [41], o homomorfismo

entre árvores é assim definido:

Definição 3.1(Homomorfismo entre árvores). Dado um par de árvores T1 e T2, um mapea-

mentoΨ dos nós de T1 para os nós de T2 é considerado um homomorfismo entre árvores sesatisfizer as seguintes condições:

• Ψ mapeia a raiz de T1 na raiz deT2;

• se o nó n2 é filho do nó n1 em T1, entãoΨ(n2) é um filho deΨ(n1) em T2; e

32

• para todo nó n∈ T1, o nome do nó em T1 é o mesmo do nóΨ(n) em T2.

Para exemplificar esse problema, a Figura 3.4 mostra duas consultas (Q1 e Q2) que são

aplicadas a um mesmo arquivo XML (bib.xml) e ambas retornam pares formados por título e

autor dos livros.

Figura 3.4 Consultas em XQuery

A árvore representativa do arquivobib.xmlpode ser vista na primeira parte da Figura 3.5.

Como pode ser observado, o arquivo possui três livros diferentes. As duas partes seguintes da

figura mostram os resultados das consultas Q1 e Q2 quando aplicadas nos dados do arquivo

bib.xml.

Nota-se que a consulta Q1 retornou todas as combinações possíveis de título com autor

dos livros, independente se a combinação pertence ou não a um mesmo livro. A consulta Q2

retornou um conjunto menor de pares, no entanto, cada uma das combinações de título com

autor retornadas pertence a um livro.

As diferenças entre os resultados é explicada pela forma como as variáveis$t e $a são

definidas em cada consulta. Em Q1, essas variáveis são definidas baseadas no elementoroot do

documentobib.xml. Em Q2, $t e$a são baseadas em outra variável ($b) que corresponde a cada

elementolivro do XML. Dessa maneira, todos os pares título-autor retornados pela consulta Q2são derivados de um mesmo livro (contido na variável$b). Em Q1, o que acontece é um simples

produto cartesiano título x autor com todos os títulos e autores contidos no documento XML.

33

Figura 3.5 XML e resultados das consultas

Aplicando as técnicas propostas por Tatarinov [42] ou Deutsch [40] em Q1 e Q2, os algo-

ritmos de ambas indicarão que Q2⊆Q1, ou seja, a resposta para Q2 está contida na resposta deQ1.

Executando a consulta Q2 no resultado de Q1, obtém-se os seguintes pares (título-autor)

como resposta:t1-a1, t1-a2, t2-a1, t2-a2, t3-a1 e t3-a2. Esse conjunto de pares não corres-

ponde ao esperado, visto que Q2 busca títulos e autores de um mesmo livro e acabou trazendo

pares de título-autor – comot1-a1, t1-a2, t3-a1e t3-a2– que não correspondem a um mesmo

livro.

Conclui-se que os algoritmos elaborados por Tatarinov [42] e Deutsch [40] não garantem a

completude do resultado porque não levam em consideração a dependência das variáveis.

34

Considerar a dependência das variáveis onera muito a complexidade do algoritmo. Por

exemplo: em [41] é apresentada uma técnica de Identificação de Subconsultas que garante a

completude. A complexidade do seu algoritmo é NEXPTIME (da ordem deO(2p(n))), en-quanto os algoritmos apresentados em [42] e [40] são PTIME (tempo polinomial).

3.5 Considerações Finais

Neste capítulo, estudamos conceitos básicos decachee sua aplicação em bancos de da-

dos, detalhando cada um dos três tipos de armazenamento emcache: cachingdo resultado

da consulta, do planos da consulta, e dos relacionamentos. Discutimos também as limitações

(espaço e atualização dos dados armazenados) de umacachee os princípios básicos utilizados

para elaboração de algoritmos de substituição e atualização de elementos emcache, que serão

detalhados no próximo capítulo.

Foram abordadas também técnicas auxiliares de grande importância para o gerenciamento

decachede um sistema de integração de dados.

CAPÍTULO 4

Estado da arte em Gerenciamento de Cache

Cachingé alvo de estudos há um certo tempo. Vimos um pouco de sua aplicação para bancos

de dados, mas essa é uma prática já realizada em outras áreas, desde o surgimento dos primeiros

sistemas operacionais, visando diminuir a quantidade de acessos ao disco.

Uma das linhas de pesquisa nessa área busca um algoritmo ideal para realizar as substitui-

ções de elementos que estão nacache, para permitir a entrada de novos dados e um algoritmo

para realizar de forma eficaz as atualizações, para que os dados em memória não fiquem incon-

sistentes.

Muitos algoritmos já foram propostos, desde os pioneiros LFU (least frequently used) e

LRU (least recently used) até os mais complexos, como o LSR (least semantically related)

[45]. Vários deles foram criados para aplicações que não tinham nenhuma proximidade com

bancos de dados, mas puderam ter suas idéias utilizadas para a aplicação em SGBD (sistema

de gerenciamento de bancos de dados), como é o caso do LFU e LRU.

Neste capítulo, citaremos vários algoritmos de substituição, explicando em detalhes alguns

deles. Posteriormente, descreveremos o estado da arte sobre aplicação decacheem sistemas

de integração de dados.

4.1 Algoritmos de Substituição

A seguir, mostraremos alguns dos algoritmos de substituição de elementos emcachemais

relevantes e aplicados na literatura, muitos deles bastante conhecidos:

1. Least Recently Used (LRU) [7] - É o algoritmo de substituição decachemais popular.

Baseia-se no princípio da localidade temporal, que diz que elementos acessados recente-

mente têm mais chances de serem acessados num futuro próximo;

2. Least Frequently Used (LFU) [7] - Substitui o objeto dacachemenos frequentemente

acessado, ignora a recentidade dos acessos e pode acabar retirando dacacheobjetos

recém acessados, e que poderiam ser muito requisitados no futuro. Porém, preserva na

35

36

cacheelementos mais referenciados, o que é uma vantagem. No entanto, pode poupar

objetos muito referenciados num passado distante e que não serão mais úteis no futuro;

3. LRU/k [8] - Variação do LRU que retira dacacheo objeto cuja k-ésima referência é a

menos recente. Utiliza princípios do LRU e do LFU;

4. LRUMin [46] - Outra variação do LRU, que se baseia no tamanho do objeto para decidir

quem sairá dacache. Quando um novo elemento vai entrar nacache, o algoritmo verifica

quais objetos armazenados possuem tamanho igual ou maior do que o que está prestes a

entrar. Havendo mais de um objeto que satisfaça essa condição, o LRU é aplicado entre

eles;

5. 2Q [9] - Algoritmo de baixooverheadque simula o LRU/k. Mantém duas partições de

cache: uma primária, chamada “quente” e uma secundária, a “fria”. Nacacheprimária

estão os elementos mais requisitados e, portanto, os mais preservados. Na outra partição

ficam os objetos que foram requisitados aos menos uma vez. Quando ocorre uma referên-

cia a um objeto, este é colocado nacachesecundária. Uma outra referência feita a esse

mesmo objeto implica a mudança dele para a partição primária. A entrada de um novo

objeto em qualquer uma das partições pode necessitar a remoção de algum elemento que

já esteja armazenado na partição de destino, se ela estiver cheia. Logo, organiza-se cada

partição como uma fila do tipo FIFO (First in First out), de forma que o objeto a ser

eliminado para a entrada do novo é sempre o primeiro a ter entrado naquela partição;

6. Size [7] - Privilegia os elementos de menor tamanho. Quando um novo elemento vai

entrar nacache, o objeto de maior tamanho que esteja lá é o primeiro a ser removido,

e assim por diante, até que o espaço liberado seja suficiente para a entrada do novo

elemento. Criado para ser aplicado em servidoresproxy, visto que a quantidade de do-

cumentos que trafegam na Web é imensa e, em sua maioria, é de tamanho pequeno (4

Kbytes). Dessa forma, não é interessante deixar acacheocupada com documentos muito

grandes, que podem estar ocupando o espaço de inúmeros outros menores;

7. LRV 2000 [10] - Atribui a cada objeto emcacheum “valor de utilidade” e substitui

aquele que possuir o menor valor. É baseado na atualidade, tamanho e freqüência de

acesso ao objeto e utiliza funções matemáticas que são aproximações da distribuição dos

tempos entre acessos a um mesmo objeto e da probabilidade de mais acessos, dado que

o objeto foi acessado previamente i vezes. A aplicação acumula, em tempo de execução,

estatísticas de cada objeto requisitado, atualizadas a cada acesso, o que torna seu custo

bastante elevado;

37

8. Least Normalized Cost Replacement (LNC-R) [47] - Estima a probabilidade de um ob-

jeto ser referenciado novamente no futuro, usando uma movimentação média dos últimos

tempos de chegada de K requisições do objeto;

9. GreedyDual - Size (GD-Size) [48] - Mais um algoritmo híbrido que considera recen-

tidade dos acessos, tamanho e custo de busca de um objeto. Os autores mostram que

considerar a latência não leva a bons resultados devido à grande variabilidade de latência

de busca de um mesmo objeto.