Atualização dos Elementos em Cache

Quando um usuário executa uma consulta a um sistema qualquer, ele espera que todos os dados retornados estejam consistentes com as fontes, independente do repositório onde eles fo- ram encontrados (armazenados em cache ou materializados em um data warehouse, por exem- plo). A consistência dos dados é tida como um dos mais importantes critérios de qualidade para os usuários [21]. Alguns estudos anteriores [22, 23, 21] mostram que a consistência dos dados está intimamente ligada ao sucesso de um sistema de informação.

3.3.1 Fatores de qualidade

Por compreender um conjunto de fatores de qualidade que representam alguns aspectos de consistência e tendo suas próprias métricas, a consistência de um dado é tida como um critério de qualidade [24], e é subdividida em dois fatores:

• Atualidade [25] - Mede o intervalo de tempo entre a extração do dado das fontes e a sua entrega ao usuário. Um exemplo desse fator seria a indicação de quão antigo está o saldo

22

de uma conta apresentado ao usuário em relação ao saldo que está registrado no banco; e • Periodicidade [22] - Mede a frequência com que um dado é atualizado ou que um novo dado é criado na fonte. Por exemplo, 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 cons- tantes atualizações mas tem alguns dados que nunca mudam de valor, pode-se definir um fator que considere essa particularidade.

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

• Métricas para o fator Atualidade:

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

até sua atualização na visão materializada. Quando a mudança é propagada imedia- tamente, esse tempo é 0 (zero) [25]. Na prática, como o tempo preciso da alteração de um dado é difícil de ser obtido, é comum estimar a atualidade como a diferença entre o tempo de extração do dado e o de entrega do mesmo ao usuário. Essa es- timativa é utilizada em sistemas 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ên- cia 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.

• Métrica para o fator Periodicidade:

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

culo pode ser feito baseado no tempo da última atualização feita no dado e na sua frequência de atualização. [29].

De acordo com a frequência com que um dado é alterado, ele pode ser classificado em: • Dado Estável - É o dado cuja probabilidade de mudança é muito pequena. O nome de

um livro, por exemplo, é um dado estável. A inclusão de novos livros numa livraria é possível acontecer, mas a mudança do nome de um exemplar não é comum;

• Dado com mudança a longo prazo - Trata-se de um dado que possui uma baixa frequência de alteração do seu valor. Um exemplo é o cadastro de endereços dos funcionários de uma empresa. O conceito de “baixa frequência” é relativo de acordo com o domínio. Para aplicação 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 ar- mazenados são relacionamentos ou resultados das consultas mais constantemente executadas. Quando o usuário submete uma consulta, o sistema verifica se o resultado dela está 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 geral- mente estipulam um prazo para identificar se cada elemento em cache ainda é útil, ou seja, se

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 sin- cronização uma vez por dia num horário específico pode fornecer um dado que não corresponda às expectativas de algum usuário.

De acordo com a interação entre os sistemas de integração e as fontes de dados, o processo de extração dos dados pode adotar políticas 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

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 con- sulta (pull), ela é decomposta pelo sistema de integração e enviada às fontes de dados (pull). Essa configuração é representada pela seta (a) na Figura 3.1;

• pull / pull - Quando um usuário submete uma consulta (pull), o sistema de integração res- ponde com os dados materializados. Assincronamente, o sistema executa essa consulta nas fontes para poder atualizar os dados materializados (pull). É comum em sistemas de data 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

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