Least Semantically Related

O algoritmo Least Semantically Related, também conhecido como LSR, foi criado por Cal- savara [45]. Ele tende a deixar na cache objetos que tenham mais relação semântica entre si.

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

Diferentemente dos outros algoritmos, não se baseia nas propriedades físicas do objeto, mas sim no seu conteúdo, na semântica relacionada a ele.

Foi idealizado para ser aplicado em servidores Web ou proxies, assumindo que os clientes tendem a executar buscas a documentos que possuam alguma relação semântica entre si, por exemplo: se um usuário executa uma busca a um documento relacionado com carro, a proba- bilidade da próxima busca por ele executada ser em relação a flores é muito menor que uma busca em relação a acessórios de veículos.

Quando um novo objeto está prestes a entrar na cache, busca-se, entre todos os elementos que já estão lá, qual é o mais distante semanticamente do novo objeto. Quanto mais distante o objeto, mais chance ele terá de sair da cache.

Para implementar esse algoritmo, admite-se que cada objeto carregará consigo uma infor- mação extra, que é o “assunto” dele, e é sugerida a montagem uma árvore de “assuntos”, que modelará a relação entre eles. A árvore tem como raiz um assunto, e derivando dele, os assun- tos são representados como nós. Nas folhas da árvore estão os objetos da cache relacionados com seus respectivos assuntos. A Figura 4.5 ilustra como seria essa árvore. O assunto raiz possui os “sub-assuntos” X, Y e Z. Estes, possuem como assuntos-filho A, B, C e D. Na cache, relacionado ao assunto A, está o objeto 3, de tamanho 15; ao assunto B, o objeto 4, de tamanho 20; ao assunto C, não há objeto relacionado; e ao assunto D há os objetos 1 e 2 de tamanhos 25 e 10, respectivamente.

Ainda analisando a Figura 4.5, podemos simular a entrada de um novo objeto 5 na cache. Supondo que o novo objeto esteja relacionado ao assunto A, tenha tamanho 30 e o tamanho total da cache seja 80, percebemos que o espaço livre na cache é 10, menor que o necessário para acomodar o objeto 5. Assim, algum(ns) objeto(s) deverá(ão) sair da cache.

Para decidir os candidatos que serão removidos, o algoritmo fará uma busca na árvore procurando os objetos cujo assunto seja o mais distante do assunto do novo objeto. O resultado

42

Figura 4.5 LSR - Hierarquia de Assuntos

dessa busca trará os objetos 1 e 2, que estão relacionados ao assunto D, o mais distante de A. Para a entrada do objeto 5 basta retirar o objeto 1, porque assim o espaço livre da cache passará a ser 35, o suficiente para o novo elemento. Então, remove-se o objeto 1 e coloca-se o objeto 5 na folha abaixo do nó A, juntamente com o objeto 3. A Figura 4.6 ilustra a situação da árvore após a inclusão do objeto 5. Logo, o algoritmo segue o mesmo procedimento para novas entradas.

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

4.2

Cache em Sistemas de Integração de Dados

Diversos sistemas de Integração de Dados possuem cache para melhorar seu desempenho. A seguir, mostraremos alguns deles, localizando na arquitetura o módulo Gerenciador da Ca- che, as tecnologias utilizadas em cada um, os tipos de caching empregados e as técnicas de manutenção da cache.

em informações semânticas, como vocabulários, conceitos de hierarquia ou ontologias para auxiliar a integração de diferentes fontes. Essas técnicas não são apenas úteis para solucionar problemas de heterogeneidade e autonomia das fontes, mas também durante o processamento da consulta e sua otimização.

4.2.1 Denodo

O Denodo Platform [2] é um framework para aplicações de integração de dados. É utilizado na construção de aplicações industriais, tanto na Intranet como na Internet, integrando infor- mações de mais de 700 fontes como Web sites, bancos de dados, arquivos semi-estruturados (XML, por exemplo), entre outros.

Ele permite poderosas extração e combinação de informações provenientes das várias fontes heterogêneas, estruturadas ou semi-estruturadas, para criar o esquema global dos dados.

Sua arquitetura é mostrada na Figura 4.7.

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

O sistema adota a abordagem virtual, em que parte dos dados fica materializada para evitar que algumas consultas tenham que ser submetidas às fontes novamente. No entanto, os dados materializados não são mantidos em um data warehouse, como acontece em sistemas com esse tipo de abordagem. Para esse armazenamento o sistema utiliza uma cache, associada a seu gerenciador.

44

O Gerenciador de Cache do Denodo utiliza o algoritmo LRU para a manutenção do es- paço da cache, ou seja, nela ficam armazenados os resultados das consultas mais recentemente requisitadas pelo usuário.

É uma técnica simples para o gerenciamento do espaço de uma cache, mas o Denodo con- segue obter resultados bastante satisfatórios.

4.2.2 YACOB

O YACOB [3] é um sistema que usa domínio do conhecimento para promover a integração de dados heterogêneos na Web. A arquitetura desse sistema é mostrada na Figura 4.8.

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

As fontes de dados são conectadas através de wrappers, processam consulta em XPath e retornam um documento XML de um DTD arbitrário. Estes wrappers trabalham como web services e, portanto, podem estar localizados no ambiente do mediador, das fontes ou em algum outro lugar. Também faz parte da arquitetura um componente que armazena a cache semântica em uma base de dados local.

As consultas no YACOB são formuladas em CQuery [50]. Essa linguagem é uma extensão de outra, o XQuery – utilizada para manipulação de dados em XML, criada pela W3C [4, 51] – e permite operadores adicionais para tratamento no nível conceitual.

No YACOB, os dados em cache são armazenados em grupos de acordo com a semântica, denominados regiões semânticas. As regiões semânticas agrupam resultados de consultas que possuam alguma relação semântica entre si. Essas regiões devem ser disjuntas; sendo assim, cada elemento em cache estará em apenas uma região. Essa estratégia é útil para se obter o máximo de aproveitamento do espaço da cache. Há uma discussão a respeito dessa divisão. Alguns trabalhos ([52, 53, 54, 55]) preferem não considerar as regiões disjuntas, e sim com algum overlap entre elas, evitando, assim, a redundância de dados na cache.

Quando ocorre da consulta que está sendo processada estar parcialmente na cache, essa parte que já está armazenada é retornada e o complemento da consulta é buscado nas fontes. Após isso, é preciso decidir se o complemento é posto na cache na mesma região semântica ou se o coloca em outra. Neste último caso, o gerenciador de cache do YACOB armazena em uma nova região semântica, para evitar que se afete a granularidade da outra região.

Ambas decisões garantem que as regiões continuem disjuntas. Essa característica permite que seja aplicado um simples algoritmo de substituição de elementos na cache: substituição no nível de região, isto é, se uma região é a escolhida para ser retirada da cache, todo o conjunto de dados representativos de um elemento dessa região é apagado da memória.

Em relação à técnica de substituição de elementos em cache, o YACOB utiliza uma es- tratégia simples. Considera como critério para a escolha de qual elemento será removido de uma região uma combinação entre os timestamps correspondentes à inclusão desse elemento na cache e à última referência feita a ele.

4.2.3 ACE-XQ

O ACE-XQ [4] foi o primeiro sistema a implementar uma cache baseada em XQuery. Sua arquitetura pode ser vista na Figura 4.9.

A arquitetura pode ser dividida em dois subsistemas: o Consulta Matcher, que implementa o procedimento de reconhecimento se uma consulta está contida em outra (identificação de subconsulta) e o Gerenciador de Cache, que controla o espaço da cache e implementa os algo- ritmos de substituição dos elementos.

O Gerenciador de Cache no ACE-XQ mantém uma coleção de regiões semânticas de con- sultas, compostas por um descritor de consulta e a correspondente visão do documento XML.

46

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

Os descritores de consulta são utilizados para identificar se a nova consulta que está sendo solicitada é subconsulta de alguma que está na cache. Informações acerca de estatísticas sobre os acessos do usuário também são encontradas nesses descritores de consulta.

4.2.3.1 Identificação de Subconsultas

No ACE-XQ, quando uma consulta que esteja em cache “contém” total ou parcialmente a nova consulta, os valores de “utilidade” – números que indicam quão útil é para o sistema ter aquele dado em cache – da parte que responde à consulta são atualizados, porém a região não é dividida. Quando a cache está completamente cheia e é necessário que uma nova consulta seja armazenada nela, alguma consulta terá que ser removida para comportar a nova entrada. Porém, no ACE-XQ nem todos os dados da consulta que foi escolhida para sair são removidos; apenas os atributos com menor “utilidade” serão eliminados.

Considere uma consulta Q1, armazenada em cache, mostrada na Figura 4.10. Observe, agora, a consulta Q2, ilustrada na Figura 4.11.

Analisando as consultas Q1 e Q2, observamos que a consulta Q2 está completamente con- tida na consulta Q1, ou seja, a resposta para Q2 pode ser obtida reutilizando o resultado da

Figura 4.10 Consulta Q1 em XQuery, na cache

Figura 4.11 Consulta Q2 em XQuery

consulta Q1. Nesse caso, o usuário ainda requer na consulta Q2 informações adicionais sobre o preço do livro, que não faz parte de Q1. Assim, Q2 será quebrada em duas consultas: uma chamada consulta principal e outra chamada consulta restante.

A consulta principal é responsável por colher os dados que interessam à consulta Q2 e que estão na consulta Q1. Essa será executada sobre o resultado de Q1. A consulta restante é responsável por selecionar as informações extras, que não estão presentes em Q1 e será enviada ao servidor onde estiver a fonte de dados.

Uma vez comprovada a existência de uma intersecção entre as consultas, o próximo passo é normalizá-las, já que em XQuery uma mesma consulta pode ser definida de várias formas.

Depois de normalizadas, montam-se as árvores que representam cada uma das consultas e deve-se fazer o mapeamento entre elas. O mapeamento consiste em identificar as correspon- dências entre as variáveis de cada árvore. Para isso, são utilizadas variáveis que representam os nós nas árvores, por exemplo: a variável bQ2 corresponde ao nó /bib/livro da árvore Q2, o mesmo da variável bQ1.

O primeiro mapeamento identificado é bQ1→ bQ2. Continuando esse processo, são estabe- lecidos outros mapeamentos, como bkQ1→ bkQ2, bQ1/titulo → bQ2/titulo, bkQ1/*/avaliacao → bkQ2/revisao/avaliacao. No entanto, observa-se bQ2/preco não tem nenhum correspondente na árvore de Q1. Portanto, ele será marcado para ser solicitado na consulta restante.

48

Com base nos mapeamentos encontrados, formulam-se a consulta principal com os dados que interessam à consulta Q2 no resultado da Q1 e a consulta restante, que buscará a informação que está faltando – o preço do livro – na fonte de dados. Essas duas consultas são mostradas na Figura 4.12.

Figura 4.12 Consulta Principal e Restante

Depois de executadas as duas consultas, é necessário juntar as informações trazidas por elas num mesmo resultado, para que seja repassado ao usuário. Essa junção é feita pela consulta de combinação, que é executada em cima dos resultados da consulta principal e da restante. A consulta de combinação para esse exemplo é mostrada na Figura 4.13.

Como pode ser observado, a consulta restante não traz apenas o preço do livro, como tam- bém o título dele. Como o preço por si só não identifica o livro, se fez necessário trazer o título dele para que cada registro fosse identificado unicamente e o resultado pudesse ser combinado com o resultado da consulta principal.

4.2.3.2 Substituição de elementos em cache

Quando a consulta principal é submetida a alguma região da cache, as informações contidas na relação que representa a consulta em cache são atualizadas de forma bem pontual, ou seja, apenas os caminhos do XML que foram úteis dentro daquela consulta terão suas informações (quantidade de acessos, tempo do último acesso, entre outras) atualizadas.

A Figura 4.14 mostra a relação que representa uma determinada consulta Q1 em cache, com seus caminhos do XML e as informações estatísticas sobre cada um deles.

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

O algoritmo de substituição parcial, utilizado pelo ACE-XQ, se baseia nas informações estatísticas para decidir quem deve sair da cache quando uma nova consulta for entrar. Além dos dados estatísticos, o algoritmo também leva em consideração o tamanho do documento XML e o delay na transmissão de dados pela rede. Uma função heurística para calcular a utilidade de cada caminho XML dentro de uma consulta em cache foi criada:

r p_ f un = quantAcessos × delayTransmissao × ob jBytes tamDoX ML

Essa função é calculada para cada caminho XML da consulta escolhida para ser removida. Serão escolhidos para remoção os ítens cuja r p_ f un retornou o menor valor, até que haja espaço suficiente para a entrada da nova consulta.

50

4.3

Discussão

Abordamos na seção anterior três Sistemas de Integração de Dados que, assim como o Integra, utilizam um módulo de cache para melhorar o tempo de resposta ao usuário. Fare- mos aqui uma análise crítica sobre o gerenciamento da cache em cada um desses sistemas e apresentaremos o diferencial da proposta para o Integra.

O primeiro sistema apresentado, o Denodo, possui um gerenciamento de cache simples, fazendo uso da técnica de LRU para o gerenciamento do espaço.

No YACOB podemos perceber que já existe uma maior preocupação com o gerenciamento da cache, utilizando conceitos de regiões semânticas, para poder armazenar os elementos, e de identificação de subconsultas. Por outro lado, o próprio autor reconhece que a estratégia de substituição de elementos adotada é muito simples.

O ACE-XQ foi, dos sistemas pesquisados, o que mais contribuiu para a elaboração da nossa proposta de gerenciamento de cache para o Integra, visto que também trabalha com a linguagem XQuery, e apresenta um gerenciamento bastante complexo.

No Integra, decidimos também adotar a técnica de identificação de subconsultas, visto que ela tem se mostrado bastante eficaz nos Sistemas de Integração de Dados em que tem sido apli- cada, como no YACOB e no ACE-XQ. No entanto, propomos uma técnica que não necessita da normalização das consultas nem da montagem das árvores de cada uma delas, como acon- tece nos outros sistemas. Utilizamos a representação XML de cada consulta para realizar essa identificação.

Outro diferencial da nossa proposta é uma nova estratégia de substituição de elementos em cache, considerando recentidade, frequência e tamanho dos objetos.

Por último, elaboramos um algoritmo simples para realizar a substituição parcial das con- sultas, evitando desperdício no espaço da cache.

4.4

Considerações Finais

Neste capítulo, citamos diversos algoritmos de substituição de elementos em cache que fazem parte do Estado da Arte e descrevemos com mais detalhes alguns deles.

Foram descritos também o funcionamento e a arquitetura de alguns exemplos de sistemas de integração atuais que utilizam cache.