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.
Top Related