Trocador de Consulta

Como já vimos anteriormente, toda vez que uma nova consulta submetida pelo usuário for indicada para ser armazenada em cache, o gerenciador da cache do Integra verifica se há espaço livre na cache suficiente para abrigar a nova consulta. Caso não haja, o gerenciador, através do módulo que decide qual consulta deverá deixar a cache, decide que consulta(s) deve(m) ser retiradas da cache para a entrada da nova.

Se a saída de apenas uma consulta da cache for suficiente, e essa consulta tiver um tamanho sensivelmente maior que o espaço necessário para a entrada da nova consulta, o Gerenciador de Cache aciona o módulo trocador de consulta. Esse módulo irá avaliar se há a possibilidade

de a consulta da Cache não ser removida por completo, ou seja, se é viável remover apenas uma parte da consulta. Assim, temos um melhor aproveitamento do espaço da cache.

A técnica de remoção de parte da consulta, que chamamos de substituição parcial de consul- tas, tenta remover do resultado da consulta escolhida para sair da cache apenas alguns atributos que fazem parte da sua resposta. Esta remoção não afeta a lógica da consulta.

Para a remoção de atributos do resultado da consulta, o trocador deve executar os seguintes passos:

1. Identificar a ordem de prioridade de remoção de cada atributo; 2. Analisar se é viável a remoção do(s) atributo(s);

3. Remover o(s) atributo(s) necessários; e

4. Alterar o corpo da consulta que sofreu a remoção do(s) atributo(s).

O primeiro passo é necessário para que o sistema possa decidir que atributo(s) devem(s) ser eliminado(s). Para obter essa informação, o sistema deve varrer toda a resposta da consulta e calcular o tamanho que cada atributo ocupa no total.

Calculados os tamanhos, monta-se a ordem de prioridade de eliminação dos atributos. Defi- nimos que a ordem de prioridade deve começar do atributo que ocupa o maior espaço para o que ocupa o menor. Ou seja, os atributos de maior tamanho serão os primeiros a serem eliminados. Essa definição prioriza sempre deixar o maior número de atributos possível dentro da res- posta da consulta. Resolvemos adotar essa ordem de prioridade porque partimos do pressu- posto que quanto maior o número de atributos retornados por uma consulta na cache, maiores as chances dessa consulta ser capaz de responder uma outra consulta submetida pelo usuário.

É importante observar que nesta versão do Trocador de Consulta que implementamos, não levamos em consideração a relevância de cada atributo para a consulta. A decisão de remoção dos atributos é baseada apenas no tamanho que cada um ocupa. Essa não é a melhor solução, visto que atributos mais relevantes dentro da consulta podem ser removidos, enquanto outros menos importantes continuam dentro da consulta. A consideração da relevância nessa decisão está destacada como um dos trabalhos futuros nesta dissertação.

Após montada a ordem em que os atributos deverão ser eliminados, o sistema verifica a quantidade de atributos que deve ser removida para que o resultado da nova consulta seja ar- mazenado na cache. Essa quantidade dependerá do tamanho de cada atributo.

O sistema analisa o tamanho de cada consulta, uma a uma, de acordo com a ordem de prio- ridade, até que o tamanho acumulado dos atributos seja um valor maior que o espaço necessário para a entrada na cache da consulta que foi submetida pelo usuário.

78

Para garantir que o espaço que será liberado com a remoção dos atributos seja realmente suficiente para a entrada da nova consulta, o sistema trabalha com uma margem de segurança em relação ao espaço necessário. Essa margem de segurança está atualmente definida como 100 bytes a mais do que o previsto. Ou seja, o espaço necessário para a entrada da nova consulta na cache é calculado como sendo o tamanho real dessa consulta acrescido de 100 bytes.

Dependendo da quantidade de atributos que deve ser removida, o módulo trocador identifica se é realmente viável realizar a substituição parcial. Atualmente, o sistema só considera viável se tiverem que ser eliminadas, no máximo, 80% de todos os atributo da consulta. Esse valor foi decidido arbitrariamente para esta versão inicial.

Caso o trocador considere que é viável a eliminação dos atributos da consulta que está na cache, o sistema varre o arquivo XML que contém o resultado da consulta e remove todas as tags – e seus respectivos conteúdos – que representam os atributos que deverão ser deletados.

Eliminados os atributos da resposta da consulta, o último passo que o módulo trocador deverá executar é reformular o corpo da consulta, visto que ele ainda traz como atributos retor- nados todos eles, inclusive os que acabaram de ser eliminados.

Para encontrar o corpo da consulta, o sistema realiza uma busca na base de dados onde estão armazenados todos os corpos das consultas cujos resultados estão em cache. Encontrado o corpo da consulta correspondente, o sistema elimina dele as tags e variáveis presentes na região de retorno da consulta e que fazem referência aos atributos que foram excluídos na resposta.

Ao final do trabalho do módulo trocador, duas situações podem ser encontradas:

• Alguns atributos da consulta que deveriam sair da cache foram eliminados, e não foi necessária a substituição total da consulta; ou

• O sistema analisou que não é viável a remoção de atributos da consulta da cache, e ela é removida por completo da cache para a entrada da consulta submetida pelo usuário.

5.6.1 Exemplo

Para exemplificar como funciona a substituição parcial de consulta, suponha que uma nova consulta deverá ser armazenada na cache e não há mais espaço disponível.

Considere que, após a aplicação da fórmula para a escolha da(s) consulta(s) que deve(m) ser eliminadas da cache, o Gerenciador de Cache do Integra decide que a consulta a ser removida é a mostrada na Figura 5.15.

Figura 5.15 Consulta presente na cache

O resultado dessa consulta – que também está armazenado na cache – pode ser visto na Figura 5.16

O resultado da consulta que está em cache ocupa 891 bytes. Considerando que a nova consulta que será armazenada na cache possui 250 bytes, nota-se que a substituição total da consulta não é uma operação muito vantajosa, visto que sobrarão 641 bytes.

Para evitar esse desperdício de espaço na cache, o módulo trocador do Gerenciador de Cache verifica se há possibilidade de remover a consulta parcialmente. Para isso, segue o passo-a-passo mostrado anteriormente.

A ordem de prioridade de remoção dos atributos é mostrada na Figura ??. Prioridade Atributo Tamanho (bytes)

1 titulo 195

2 editora 156

3 autor 151

4 paginas 110

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

Para a entrada da nova consulta, o sistema deverá liberar um espaço de 350 bytes, que corresponde ao tamanho da nova consulta acrescido da margem de segurança estabelecida, que é de 100 bytes.

80

Analisando os tamanhos de cada atributo mostrado na Tabela 5.1, o sistema conclui que será necessário remover os dois primeiros atributos (título e editora) para que sobre espaço suficiente para a entrada da nova consulta. Essa remoção será considerada viável pois atinge apenas 50% do total de atributos da consulta, obedecendo o limite de 80%.

Por fim, o módulo Trocador remove os atributos selecionados e reajusta o corpo da consulta que sofreu a remoção. Ao final do processo, o corpo da consulta que sofreu alteração ficará como mostra Figura 5.17.

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

Note que a parte referente ao retorno da consulta foi alterada para não mais retornar os atributos titulo e editora. No entanto, esses atributos continuam fazendo parte da cláusula for, visto que eles podem ser utilizados dentro de possíveis joins que existam na consulta. Se eles também fossem removidos da cláusula for a semântica da consulta poderia ser prejudicada, e a consulta se tornaria inválida.

O resultado da consulta, após a remoção dos atributos, pode ser visto na Figura 5.18. Observe que as tags e seus respectivos conteúdos referentes aos atributos titulo e editora foram removidos. Agora, a consulta ocupa um espaço de 543 bytes.

82

5.7

Considerações Finais

Neste capítulo apresentamos a nossa proposta de melhoria para o Gerenciador de Cache do Integra. Sugerimos uma nova política de substituição das consultas em cache, considerando os fatores que julgamos relevantes para o Integra: freqüência e recentidade de submissão das consultas, além do tamanho do resultado de cada consulta.

Também mostramos a aplicação da técnica de identificação de subconsultas no Gerenciador de Cache do Integra, utilizando uma forma diferenciada de realizar essa identificação: através da representação XML das consultas.

Por último, descrevemos sobre substituição parcial das consultas presentes em cache, evi- tando desperdícios na utilização do espaço disponível da cache.

C

6

Conclusão

Integrar dados é uma tarefa que requer bastante custo de processamento. Especialmente em sistemas de Integração de Dados na Web, como o Integra [6], a complexidade de tal atividade pode ser comprometedora para o sucesso do sistema.

O primeiro grande problema encontrado quando se elabora um sistema de integração de dados na Web é saber selecionar as fontes relevantes e confiáveis que o sistema acessará para realizar as consultas submetidas pelos usuários. Essa não é uma tarefa simples, visto que a quantidade de fontes disponíveis na Internet é imensurável, e a confiabilidade da grande maioria é discutível.

Um segundo problema para a integração de dados na Web decorre do fato de, na Internet, os dados estarem armazenados em fontes de diversos tipos. Podem estar presentes em arquivos texto, XML, HTML, bancos de dados relacionais, hierárquicos, orientados a objeto, entre ou- tros. Além disso, cada fonte não disponibiliza seus metadados. Isso dificulta a elaboração da interface que estabelece a comunicação entre o sistema de integração e as fontes de dados.

A autonomia das fontes de dados que compõem um sistema de integração também se torna um obstáculo para o funcionamento deste, visto que as fontes podem sofrer alterações diversas em seu modelo físico ou lógico sem que essas mudanças sejam repercutidas no sistema. Assim, o acesso aos dados de uma fonte que sofreu alteração pode ficar prejudicado.

Todos esses problemas estão relacionados ao acesso aos dados que estão distribuídos em diversas fontes. No entanto, ultrapassados todos esses obstáculos, o sistema ainda terá que, de posse dos dados provenientes de cada fonte, integrá-los e repassar ao usuário, de forma transparente, proporcionando a ele uma visão única dos dados.

É devido aos problemas com o acesso aos dados que se torna fundamental para um sistema de integração de dados um meio de armazenamento secundário, onde fique armazenado um subconjunto dos dados disponíveis nas fontes. Dessa forma, boa parte das consultas submetidas ao sistema pode ser respondida a partir desse repositório, sem que o sistema precise realizar o acesso às fontes de dados, poupando processamento.

Dentre as formas de armazenamento secundário está a Cache e o Data Warehouse. O Inte- gra foi o sistema de integração de dados pioneiro na utilização desses dois repositórios conco- mitantemente. Na cache ficam armazenados os resultados de algumas consultas já submetidas pelo usuário, e no DW são armazenados dados das fontes selecionados de acordo com critérios pré-definidos.

Gerenciar tudo o que envolve a cache, como a política de substituição das consultas e a estratégia de atualização dos dados armazenados é papel do Gerenciador de Cache. Foi no Gerenciador de Cache do Integra onde focamos nosso trabalho. Após o levantamento do estado da arte em relação à manutenção de cache, tanto em sistemas comuns como em de integração de dados, remodelamos boa parte do Gerenciador de Cache existente no Integra.

As mudanças no Gerenciador de Cache do Integra começaram pela linguagem de consulta utilizada por esse módulo. Até então, as consultas eram trabalhadas em SQL. Propomos a mudança para a linguagem XQuery, que permite uma melhor manipulação das consultas.

Outra alteração que realizamos no Gerenciador de Cache foi a elaboração de uma nova política de substituição de consultas, com novas funcionalidades, que permitem a identificação de subconsultas e a substituição parcial de consultas.

Obtivemos, ao final do trabalho, um Gerenciador que consegue aproveitar melhor o es- paço reservado à cache, proporcionando ao Integra um recurso de armazenamento secundário bastante útil.

6.1

Contribuições

Como principais contribuições do nosso trabalho, consideramos:

• O desenvolvimento de um Gerenciador de Cache em um Sistema de Integração de Dados; • A criação de uma nova política de substituição de elementos em cache, levando em con-

sideração a freqüência de acesso, a recentidade e o tamanho dos elementos;

• Um novo modelo de algoritmo para identificação de subconsultas em cache, escritas em XQuery;

86