• Nenhum resultado encontrado

Uma proposta para o Gerenciamento de Cache de um Sistema de Integração de Dados

N/A
N/A
Protected

Academic year: 2021

Share "Uma proposta para o Gerenciamento de Cache de um Sistema de Integração de Dados"

Copied!
109
0
0

Texto

(1)Universidade Federal de Pernambuco Centro de Informática. Pós-Graduação em Ciência da Computação. Uma proposta para o Gerenciamento de Cache de um Sistema de Integração de Dados Walter de Carvalho Mattos Galvão Dissertação de Mestrado. Recife 2007.

(2) 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.

(3) Universidade Federal de Pernambuco Centro de Informática. Walter de Carvalho Mattos Galvão. Uma proposta para o Gerenciamento de Cache de um Sistema 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 Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.. Orientador:. Recife 2007. Ana Carolina Salgado.

(4) Aos meus pais, Lucinda e Aristides, e meus irmãos, Tatiana e Arlindo..

(5) 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 capacidade 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, empresas onde trabalhei durante esse período, pelo apoio dado, permitindo flexibilidade no expediente 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.

(6) 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 uma cache para o armazenamento dos dados resultantes das consultas que o sistema considera mais relevantes. Desta forma, quando alguma consulta que já esteja armazenada em cache for novamente solicitada 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 Cache para um Sistema de Integração de Dados. Esse Gerenciador é composto por um módulo que controla o espaço da cache, 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 em cache (técnica de query containment). E por último, um módulo que realiza a substituição parcial de uma consulta, para o melhor aproveitamento 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.

(7) 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.

(8) Sumário. 1. 2. Introdução 1.1 Motivação 1.2 Objetivos 1.3 Contribuições Esperadas. 1 1 2 3. 1.4. Estrutura da Dissertação. 3. Sistemas de Integração de Dados 2.1 Integração de Dados. 5 5. 2.2. 2.3. 2.4 3. Sistemas de Integração de Dados 2.2.1 Abordagens para Sistemas de Integração de Dados 2.2.2 Arquiteturas 2.2.3 Exemplos Integra. 6 7 8 10 11. 2.3.1. 11 12 13 14. Arquitetura 2.3.1.1 Ambiente Comum 2.3.1.2 Ambiente de Geração e Manutenção do Mediador 2.3.1.3 Ambiente do Usuário. 2.3.1.4 Ambiente de Integração de Dados Considerações Finais. 14 17. Cache e seu Gerenciamento. 18. 3.1 3.2 3.3. Cache em Bancos de Dados Substituição de Elementos em Cache Atualização dos Elementos em Cache 3.3.1 Fatores de qualidade. 18 20 21 21. 3.3.2 Consistência da informação Técnicas Auxiliares 3.4.1 Identificação de Subconsultas 3.4.1.1 Normalização. 23 26 26 29. 3.4. viii.

(9) ix 3.4.1.2 3.5 4. Considerações Finais. Estado da arte em Gerenciamento de Cache 4.1 Algoritmos de Substituição. 4.2. 4.3 4.4 5. Problemas relacionados. 5.7. 35 35 37 38 40 42. 4.2.1 4.2.2 4.2.3. 43 44 45 46 49. Denodo YACOB ACE-XQ 4.2.3.1 Identificação de Subconsultas 4.2.3.2 Substituição de elementos em cache. Discussão Considerações Finais. 5.4.1 5.4.2 5.4.3. 5.6. 34. 4.1.1 LRU/k 4.1.2 2Q 4.1.3 Least Semantically Related Cache em Sistemas de Integração de Dados. Gerenciador de Cache do Integra 5.1 Soluções Propostas 5.2 Arquitetura do Gerenciador de Cache 5.3 Gerenciador de Log 5.4 Identificador de Subconsultas. 5.5. 31. Arquitetura do Identificador de Subconsultas Buscador de Consultas Conversor de Consultas 5.4.3.1 Representação XML de consultas XQuery. 50 50 51 51 52 53 54 54 55 56 57. 5.4.3.2 A ferramenta 5.4.4 Comparador de Consultas 5.4.4.1 Implementação 5.4.4.2 Funcionamento Gerenciador de Substituição. 59 60 60 65 72. 5.5.1 Função de Substituição 5.5.2 Adaptação da Função de Substituição ao Integra Trocador de Consulta 5.6.1 Exemplo. 72 75 76 78. Considerações Finais. 83.

(10) x 6. 7. Conclusão. 84. 6.1 6.2. 85 86. Contribuições Trabalhos Futuros. Anexo. 92. 7.1. 92. Anexo 1.

(11) Lista de Figuras. 2.1 2.2. Arquitetura de Mediadores Arquitetura de Data Warehouse. 9 10. 2.3 2.4. Arquitetura do Integra ([1]) Estrutura do log de uma consulta. 12 16. 3.1 3.2. Políticas de Sincronização Combinação de Políticas de Sincronização. 24 25. 3.3 3.4 3.5. Três maneiras de escrever uma mesma consulta em XQuery Consultas em XQuery XML e resultados das consultas. 30 32 33. 4.1 4.2. LRU/K - sequência de ações 2Q - Situação inicial da cache. 38 39. 4.3 4.4 4.5 4.6. 2Q - Situação da cache após entrada do elemento A 2Q - Situação final da cache LSR - Hierarquia de Assuntos LSR - Árvore, após entrada do objeto 5. 40 41 42 42. 4.7 4.8 4.9 4.10. Denodo - Arquitetura do Sistema ([2]) YACOB - Arquitetura do Sistema ([3]) ACE-XQ - Arquitetura ([4]) Consulta Q1 em XQuery, na cache. 43 44 46 47. 4.11 4.12 4.13 4.14. Consulta Q2 em XQuery Consulta Principal e Restante Consulta de Junção Relação com os caminhos XML da consulta Q1. 47 48 48 49. 5.1. Arquitetura do Gerenciador de Cache do Integra. 52. 5.2 5.3 5.4. Arquitetura do módulo Identificador de Subconsultas do Gerenciador de Cache Consulta em XQuery Representação parcial da consulta XQuery em XQueryX. 54 57 58. xi.

(12) xii 5.5. Representação parcial da consulta XQuery em XML através do XQNSTA. 59. 5.6 5.7 5.8 5.9. Pseudo-código da função IsSubConsulta Pseudo-código da função ComparacaoElementos Pseudo-código da função IsElementoCorrespondido Análise de abrangência de comparadores. 61 62 63 64. 5.10 5.11 5.12 5.13 5.14. Consulta submetida pelo usuário Consulta da cache retornada pelo buscador de consulta Mais uma consulta submetida pelo usuário Consulta da cache retornada pelo buscador de consulta Cenário. 66 66 69 70 73. 5.15 5.16 5.17 5.18. Consulta presente na cache Resultado da consulta presente na cache Corpo da consulta após remoção dos atributos Resultado da consulta presente na cache, após a remoção dos atributos. 79 80 81 82.

(13) Lista de Tabelas. 5.1. Ordem de prioridade de remoção dos atributos. xiii. 79.

(14) C APÍ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 monitoramento 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 qualquer 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.

(15) 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 inconsistentes com os das fontes por muito tempo. A motivação para o desenvolvimento deste trabalho é a elaboração de um Gerenciador de Cache para 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 na cache, 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á na cache, reduzindo o tempo de resposta. O módulo Gerenciador de Cache é responsável pelas seguintes atividades: • Gerenciar o tamanho da cache, decidindo quais consultas devem ser armazenadas e realizando substituições, quando achar necessário; e • Manter os resultados das consultas armazenados em cache atualizados. Foi criada para o Integra uma versão provisória do Gerenciador de Cache. Essa versão utiliza técnicas simples para executar as duas atividades listadas acima. Nosso trabalho propõe uma melhoria no Gerenciador de Cache do Integra, tendo como foco principal o gerenciamento do espaço da cache.. 1.2 Objetivos Por possuir tamanho limitado, gerenciar uma cache, independente da aplicação – bancos de dados, servidores web ou sistemas stand alone – não é trivial. Decidir qual objeto deve perma-.

(16) 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(ou replacement strategies). Para tomar essa decisão, é necessário estabelecer critérios, e cada proposta utiliza um diferente. Um dos objetivos deste trabalho é apresentar uma política de substituição de resultados de consultas armazenadas em cache que se adeque ao sistema Integra. Algumas técnicas auxiliares têm sido agregadas ao gerenciamento de cache, para um melhor 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 na cache que sejam mais abrangentes que o resultado esperado pelo usuário. Dessa forma, o sistema aumenta o aproveitamento da cache. 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 da cache, 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 de Cache do Integra.. 1.3 Contribuições Esperadas Esperamos, com esse trabalho, contribuir para a pesquisa na área de gerenciamento de cache em sistemas de integração de dados. Para isso, iremos propor e implementar algoritmos para realizar atividades referentes ao gerenciamento de cache, tais como: políticas de substituiçã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 arquitetura. Ao final do capítulo descreve-se o Integra, sistema de Integração de Dados onde foi desenvolvido o Gerenciador de Cache fruto dessa pesquisa; • Capítulo 3 - Cache e seu Gerenciamento: Nesse capítulo são abordados conceitos sobre.

(17) 4 Cache, sua aplicação em bancos de dados e as atividades que compõem o seu gerenciamento do espaço e da consistência dos elementos armazenados; • Capítulo 4 - Estado da arte em Gerenciamento de Cache: Esse capítulo faz um levantamento do estado da arte em relação a gerenciamento de cache, mostrando diversos algoritmos de substituição e técnicas auxiliares para o gerenciamento de cache, além da aplicação de cache em sistemas de integração de dados existentes; • Capítulo 5 - Gerenciador de Cache no Integra: Nesse capítulo são apresentadas as soluções propostas para Gerenciador de Cache do Integra, englobando política de substituiçã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 de cache em 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..

(18) C APÍ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 saté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 encontramos sites que oferecem uma lista de restaurantes de qualquer cidade. Um deles é o Guia dos Restaurantes (“http://www.guiadosrestaurantes.com.br”). Esse guia permite que o usuário escolha o tipo da culinária (árabe, italiana, chinesa, japonesa, entre outras), o estado, a cidade e até o bairro onde fica o restaurante para realizar a 5.

(19) 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 é o Guia 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 no Guia dos Restaurantes, e depois buscar os preços de cada um no Guia 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;.

(20) 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 nativas (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.

(21) 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 dispõ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 de Data 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 integrada 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..

(22) 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, o Data Warehouse [14]. Uma vez que os dados estão armazenados no Data 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 o Data Warehouse sempre 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 o Data Warehouse. Existem duas estratégias para os sistemas de integração de dados manterem os dados no Data Warehouse consistentes com as fontes de dados: • Rematerialização da visão - Remoção de todo o conteúdo do Data Warehouse e reexecuçã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.

(23) 10. Figura 2.2 Arquitetura de Data Warehouse. • Manutenção incremental - Atualização incremental do Data Warehouse toda 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 do data 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 utilizam cache para melhorar suas performances. Nesta seção, citaremos alguns deles e no Capítulo 4 descreveremos com mais detalhes a.

(24) 11 arquitetura e o funcionamento do gerenciamento da cache de cada um. O YACOB [3] é um sistema desenvolvido na Universidade de Halle-Wittenberg, na Alemanha e originalmente foi elaborado para permitir o acesso integrado a bancos de dados espalhados 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 realizar a integração dos dados. O sistema Denodo[2], desenvolvido pela Denodo Corporation, é um framework comercial 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 da cache e 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 desenvolver o novo Gerenciador de Cache, baseado na pesquisa realizada para o desenvolvimento desta dissertação. Esse sistema possui uma arquitetura mista, implementando as duas abordagens para sistemas 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 uma cache para armazenar resultados 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á na cache, 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:.

(25) 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 retornados 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.

(26) 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 realizar 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 sistema. 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 seu Lookup. A nova fonte deve ter seu esquema exportado para o mediador, para que ele possa reformular as consultas para essa fonte também. Essa tradução do esquema da fonte para o formato comum do sistema é realizada pelos Lookups. Eles interagem com o Gerenciador de Esquemas Conceituais no Ambiente de Geração e Manutenção do Mediador. Os Wrappers, juntamente com os Lookups, compõem o módulo conhecido como Middleware dentro 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 fontes enviados pelos Lookups para criar o esquema de mediação no formato proposto por [1], denominado X-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 elementos 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 correspondentes 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.

(27) 14 operadores possíveis para aplicar entre fontes diferentes e gera todas as possíveis consultas, 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 armazenados 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, consequentemente, ao desempenho do sistema. É composto pelo Mediador, Gerenciador do Data Warehouse e pelo Gerenciador de Cache. 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 mediaçã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 relevantes para responder a consulta submetida pelo usuário. Para realizar essa tarefa, ele faz uso.

(28) 15 da Base de Conhecimento do Mediador (MKB - Mediator Knowledge Base). Interagindo com o Gerenciador de Cache, ele procura por resultados de consultas já executadas anteriormente 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 os Wrappers, submetendo as subconsultas e recebendo os resultados. Também realiza a monitoração das fontes para identificar que dados podem ser materializados no data warehouse. Gerenciador do Data Warehouse Realiza a manutenção do Data Warehouse no 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 do Data Warehouse todos os dados e metadados necessários para executar a materialização. Gerenciador da Cache Quando o usuário submete uma consulta ao Integra, o primeiro passo executado pelo sistema é realizado pelo Gerenciador de Consulta, que aciona o Gerenciador de Cache para verificar se a resposta daquela consulta já está armazenada em cache. Em caso positivo, a resposta é diretamente retornada ao usuário. Caso contrário, a consulta é decomposta e submetida ao Data Warehouse e/ou às fontes de dados. Toda a manutenção da Cache do Integra é realizada pelo Gerenciador de Cache. Essa tarefa compreende as seguintes atividades: • Gerenciar o espaço da Cache - A cache possui um tamanho limitado e, por isso, não cabem nela as respostas de todas as consultas (o que seria ideal). Portanto, o Gerenciador de Cache deve saber decidir, quando a cache atingir a lotação máxima, que resultados de consultas devem permanecer e quais devem sair para a entrada de novos; e • Manter os dados da cache consistentes - O sistema deve tentar manter os dados armazenados em cache o 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 de Cache utiliza um algoritmo de substituição de elementos em cache que serve para decidir que elemento deve sair da cache para.

(29) 16 a entrada de um novo dado. Os algoritmos de substituição de elementos em cache serão mais discutidos nos capítulos 3 e 4, mas aqui citaremos o algoritmo utilizado atualmente pelo Gerenciador de Cache do Integra por ser bastante conhecido: o LFU (Least Frequently Used) [7]. Este algoritmo indica, para sair da cache, sempre o elemento menos acessado. Assim, toda vez que uma nova consulta precisa entrar na cache e não há mais espaço, o Gerenciador elimina a consulta menos acessada da cache para permitir a entrada da nova consulta. Para aplicar o algoritmo LFU, o sistema necessita de informações adicionais sobre as consultas cujos resultados estão armazenados em cache. Por exemplo, a quantidade de vezes que cada consulta foi acessada em cache é uma informação imprescindível para que o Gerenciador de Cache possa escolher a consulta menos acessada e removê-la da cache. As informações adicionais sobre cada consulta armazenada em cache estã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 da cache indica se a consulta está armazenada na cache. 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 da Cache decide quem fica e quem sai da cache. Para executar a atividade de manutenção dos dados da cache consistentes, o Gerenciador de Cache executa operações de refreshment periodicamente. No capítulo 5, mostraremos as mudanças propostas para o Gerenciador de Cache, 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..

(30) 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 ambientes que compõem a arquitetura do Integra, destacando o Gerenciador de Cache, foco desta dissertação..

(31) C APÍTULO 3. Cache e 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 solicitados, eles não mais serão buscados em suas fontes originais, e sim na cache, que os disponibilizará mais rapidamente. Geralmente, essa área de acesso rápido fica na memória principal[20]. O processo de caching consiste 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 a cache é explorada em sistemas de informação que realizam acesso a dados e também descreveremos conceitos básicos relacionados a cache e seu gerenciamento, tais como: tipos de cache, substituição de elementos na cache e a atualização desses dados.. 3.1. Cache em 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 de cache. Em bancos de dados, há três tipos de caching: resultado da consulta, planos de consulta e relacionamentos [20]. No primeiro tipo, caching do resultado da consulta, é colocada na cache a 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 requi18.

(32) 19 sição, salvará o seu resultado e lerá da cache para 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 caching de resultado, cada entrada na cache conté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á na cache é 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 da cache uma consulta idêntica à que está sendo submetida e retornar o resultado idêntico ao produzido anteriormente. Uma possível melhoria para esse tipo de caching é 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 um parser mais 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á na cache, 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 na cache para 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 da cache, 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 na cache já 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 a cache. 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.

(33) 20 feita antes da tabela ser atualizada de fato. A consulta não deve ser removida imediatamente da cache porque 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 de caching, 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 caching de 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 na cache é 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 na cache. A vantagem desta técnica é que uma consulta à cache já retorna o resultado processado, sem necessidade de transformação para o esquema global. O armazenamento em cache no 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 na cache. 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 da cache.. 3.2 Substituição de Elementos em Cache Para o desenvolvimento de um bom algoritmo de substituição de elementos numa cache, 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 da cache. Um exemplo de algoritmo que se baseia unicamente nesse princípio é o LRU (Least Recently Used) [7];.

(34) 21 • Freqüência de acesso - A tomada de decisão sobre a saída ou não de um objeto da cache 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 em cache. Um algoritmo bastante conhecido que se baseia nesse princípio é o LFU (Least Frequently Used) [7]; e • Tamanho do objeto - O espaço de uma cache geralmente é bastante limitado, devido ao alto custo. Por isso, um dos fatores levados em consideração para decidir se um objeto deve permanecer em cache é 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 em cache os 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 foram encontrados (armazenados em cache ou materializados em um data warehouse, por exemplo). 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.

(35) 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, o timeliness mede 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 constantes 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 imediatamente, 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 estimativa é utilizada em sistemas de data warehouse [26]. Em sistemas de caching, essa métrica é definida como recentidade (representando o tempo que o objeto está armazenado na cache) [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 os logs da fonte. Conhecida a obsolescência de um objeto, é possível estimar a frequência de atualização dele. Nos sistemas de caching, a obsolescência é conhecida como idade, representando o número de vezes que o objeto foi atualizado no servidor depois de ser armazenado em cache; 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 de caching, essa taxa é definida como o número de elementos que estão atualizados na cache sobre o número total de elementos..

(36) 23 • Métrica para o fator Periodicidade: – Periodicidade - Corresponde à frequência de atualização de um dado. Esse cálculo 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 de e-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 utilizam cache, geralmente o que fica nela armazenados 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á em cache. Se estiver, ele apenas entrega ao usuário; caso contrário, ele busca os resultados nas fontes, integra-os, atualiza os dados em cache e finalmente entrega ao usuário. Esses sistemas geralmente estipulam um prazo para identificar se cada elemento em cache ainda é útil, ou seja, se.

(37) 24 ele não está desatualizado. Passado esse tempo, este dado na cache passa 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 sincronizaçã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 de pull ou push [30]. Pela política pull o sistema de integração envia as consultas às fontes para obter os dados, e pela política push as fontes enviam os dados ao sistema. A notificação de que um novo dado está disponível na fonte pode ser disparada por uma trigger 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 em cache ou em data warehouse – não dão suporte à configuração pull-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.

(38) 25 dados materializados; sistemas de caching dão suporte às configurações que aplicam a política de pull 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 consulta (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 responde com os dados materializados. Assincronamente, o sistema executa essa consulta nas fontes para poder atualizar os dados materializados (pull). É comum em sistemas de data warehousing e 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 de data 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 de data marts e está representada pelas setas (d) e (c) na Figura 3.1; e.

(39) 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 de caching, 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 de caching tradicionais trabalham com o conceito de validade. Esses sistemas estimam o TTL (time-to-live), que corresponde ao tempo que supostamente cada objeto em cache já foi atualizado na fonte; assim a cache pode armazenar dados com mudança a longo prazo e dados com mudança freqüente. Quando o TTL expira, o objeto na cache passa a ser inválido para uso, então o próximo acesso ao objeto será feito diretamente à fonte e ele será atualizado na cache (políticas pull-pull e pull/pull).. 3.4 Técnicas Auxiliares Para um completo gerenciamento de cache dentro de um sistema, é necessário nos preocuparmos 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 de Cache. Alguns sistemas de integração de dados – como o ACE-XQ – já possuem gerenciadores de cache com uma visão mais ampla, apresentando funcionalidades extras bastante interessantes. Uma delas é a técnica de Identificação de Subconsultas (conhecida como Query Containment), que também faz parte da proposta de melhoria do Gerenciador de Cache do 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 utilizam cache é natural que, com a submissão de uma nova consulta, se busque dentro da cache uma consulta que case perfeitamente com a solicitada. Dessa forma, uma nova consulta só será respondida por uma que esteja na cache se ambas forem idênticas. Consideremos uma situação em que o usuário submeteu a seguinte consulta, em SQL, ao sistema:.

(40) 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 "% D a t a b a s e Cache%" AND ano > 2 0 0 5. Quando executada, ela retornará informações (titulo e autor) de todos os registros armazenados 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 uma cache e nela esteja armazenada apenas o resultado da seguinte consulta:. SELECT t i t u l o , a u t o 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 > 2 0 0 0. Ao receber a consulta submetida pelo usuário, um sistema com gerenciamento de cache convencional procuraria na cache uma consulta idêntica a que está sendo requisitada. Nesse exemplo, ele não encontraria uma consulta correspondente e ela deveria ser executada diretamente na fonte de dados. No entanto, podemos notar que a consulta que está na cache retorna 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 todos 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:.

Referências

Documentos relacionados

Nessa situação temos claramente a relação de tecnovívio apresentado por Dubatti (2012) operando, visto que nessa experiência ambos os atores tra- çam um diálogo que não se dá

Para analisar as Componentes de Gestão foram utilizadas questões referentes à forma como o visitante considera as condições da ilha no momento da realização do

Ninguém quer essa vida assim não Zambi.. Eu não quero as crianças

Na experiência em análise, os professores não tiveram formação para tal mudança e foram experimentando e construindo, a seu modo, uma escola de tempo

Para cavernas da Serra do Ramalho, região localizada no sudoeste da Bahia e parte da Bacia do Médio São Francisco (Figura 6 - localização), foram registrados

A proposta aqui apresentada prevê uma metodologia de determinação da capacidade de carga de visitação turística para as cavernas da região de Bulhas D’Água

Neste tipo de situações, os valores da propriedade cuisine da classe Restaurant deixam de ser apenas “valores” sem semântica a apresentar (possivelmente) numa caixa

A partir deste momento é dada indicação para a seleção da população em estudo e é ativado o envio da medicação pelo promotor, ficando o FH da Unidade de