Gerenciador de Cache do Integra
5.5 Gerenciador de Substituição
Como já foi descrito no Capítulo 2, atualmente o Gerenciador de Cache do Integra possui como política de substituição de elementos em cache o LFU (Least Frequently Used) [7].
Para um sistema de integração de dados, como o Integra, entendemos que levar em con- sideração apenas a freqüência de acesso das consultas para decidir que consultas devem ser retiradas da cache é bastante limitante. Outros fatores além da freqüência podem ser levados em consideração na política de substituição de consultas para um melhor aproveitamento do espaço da cache, sem elevar muito a complexidade do algoritmo atual.
5.5.1 Função de Substituição
Decidimos aplicar no Gerenciador de Cache do Integra uma combinação dos três fatores mais utilizados pelos algoritmos de substituição de elementos em cache: última referência e freqüência de submissão das consultas, além do tamanho resultado delas. Descrevemos cada um desses fatores no Capítulo 3.
A combinação entre última referência e freqüência de acesso já foi explorada na técnica proposta por O’Neil [8], conhecida como LRU/K, descrita no Capítulo 4. No entanto, para um sistema de integração de dados o fator tamanho do objeto – tamanho da resposta da consulta, no caso do Integra – é bastante crítico, visto que o excesso de tráfego de dados pela rede pode comprometer o desempenho do sistema. Sendo assim, decidimos utilizar o três fatores.
O algoritmo LRU/K utiliza a função backward k-distance para determinar qual elemento deve sair da cache. Essa função mede a “distância” entre duas referências feitas a um dado elemento e esse valor é o que determinará se esse elemento deve sair da cache.
Para o Gerenciador de Cache do Integra criamos uma função que contempla todas as refe- rências feitas a um dado elemento (que, no caso do Integra, corresponde ao resultado de uma consulta), atribuindo pesos maiores para as referências feitas mais recentemente. Dessa forma, o algoritmo consegue mesclar os fatores de freqüência e recentidade.
Além disso, a função também considera o tamanho de cada consulta, da seguinte forma: quanto mais próximo for o tamanho da consulta em cache do tamanho da consulta que será armazenada, maior a prioridade daquela ser eliminada.
Essa função pode ser assim definida:
Definição 5.1 (Função de Substituição).
f (c,tx) =∑xi=1(ti∗ req(c,ti)) + (|pc− pe| ∗ fa)
onde c é o identificador da consulta,
txé o instante de tempo até o qual se deseja analisar,
pcé o tamanho da consulta que está na cache,
req é uma função que retorna 1 se a consulta c foi requisitada no tempo tié 0, caso contrário
peé o tamanho da consulta que entrará na cache
faé o fator de ajuste para a análise dos tamanhos das consultas
Podemos dividir a definição da função em duas partes. A primeira parte corresponde ao somatório de todos os intervalos de tempo em que a consulta foi submetida; dessa forma é possível a análise da recentidade e da freqüência com que a consulta foi submetida. A segunda parte corresponde ao módulo da diferença entre o tamanho da consulta que está na cache e da que entrará na cache. Quanto menor o valor retornado pela função para uma consulta que esteja em cache, maior a probabilidade de essa consulta ser escolhida para ser eliminada.
Para exemplificar a aplicação dessa função, imagine o cenário mostrado na figura 5.14. Nela está ilustrada uma linha de tempo dividida em intervalos iguais (de valor k) na parte inferior, e as consultas submetidas em cada um dos intervalos na parte superior.
Figura 5.14 Cenário
Podemos notar que no decorrer de todo o tempo apenas 3 consultas diferentes foram sub- metidas pelo usuário: A, B e C. Abstraindo os tamanhos de cada uma delas, vamos montar o somatório que faz parte da função e que garante a análise da freqüência e da recentidade. Assim, teremos:
74 f (A,t9) = ∑9i=1(ti∗ req(A,ti)) + |pc− pe|
= (t1∗ 0 + t2∗ 1 + t3∗ 0 + t4∗ 0 + t5∗ 1 + t6∗ 1 + t7∗ 0 + t8∗ 0 + t9∗ 0) + |pc− pe| ∗ fa = (t2+ t5+ t6) + |pc− pe| ∗ fa = (2 ∗ k + 5 ∗ k + 6 ∗ k) + |pc− pe| ∗ fa = 13k + |pc− pe| ∗ fa f (B,t9) = ∑9i=1(ti∗ req(B,ti)) + |pc− pe| = (t1∗ 1 + t2∗ 0 + t3∗ 1 + t4∗ 0 + t5∗ 0 + t6∗ 0 + t7∗ 0 + t8∗ 1 + t9∗ 0) + |pc− pe| ∗ fa = (t1+ t3+ t8) + |pc− pe| ∗ fa = (1 ∗ k + 3 ∗ k + 8 ∗ k) + |pc− pe| ∗ fa = 12k + |pc− pe| ∗ fa f (C,t9) = ∑9i=1(ti∗ req(C,ti)) + |pc− pe| = (t1∗ 0 + t2∗ 0 + t3∗ 0 + t4∗ 1 + t5∗ 0 + t6∗ 0 + t7∗ 1 + t8∗ 0 + t9∗ 1) + |pc− pe| ∗ fa = (t4+ t7+ t9) + |pc− pe| ∗ fa = (4 ∗ k + 7 ∗ k + 9 ∗ k) + |pc− pe| ∗ fa = 20k + |pc− pe| ∗ fa
Como podemos observar, considerando apenas a freqüência e a recentidade, a consulta com o menor valor para a função é a B. Depois dela, vem a consulta A e por último a consulta C. Isso significa que, se as três consultas estivessem armazenadas em cache e o sistema tivesse que remover alguma delas para a entrada de outra, a ordem de prioridade de remoção seria:
1. Consulta B 2. Consulta A 3. Consulta C
No entanto, ainda falta calcular a parte da função que considera o fator tamanho. Podemos observar na função que, agregada à subtração entre os tamanhos das consultas está um fator de ajuste. Esse fator foi criado porque, como não há ainda uma massa de dados real para testes, não podemos prever o tamanho médio de cada consulta. Sendo assim, a subtração entre os tamanhos das consultas pode gerar números de grandezas bem diferentes das obtidas no somatório da função, o que faria com que a primeira parte da função mascarasse a segunda ou vice-versa.
Consideremos os seguintes tamanhos das consultas: • Consulta A: 500 KBytes
• Consulta B: 600 KBytes • Consulta C: 450 KBytes
Vamos considerar um fator de ajuste de 0,1 e que o intervalo de tempo seja medido em minutos e k=1. Se a nova consulta que entrará na cache possuir 400 KBytes, vamos obter os seguintes resultados da função aplicada às consultas:
f (A,t9) = 13k + |pc− pe| ∗ fa = 13 + |500 − 400| ∗ 0, 1 = 23 f (B,t9) = 12k + |pc− pe| ∗ fa = 12 + |600 − 400| ∗ 0, 1 = 32 f (C,t9) = 20k + |pc− pe| ∗ fa = 20 + |450 − 400| ∗ 0, 1 = 25
Finalizados os cálculos da função para cada uma das consultas, a ordem final de prioridade para remoção das consultas da cache é:
1. Consulta A 2. Consulta B 3. Consulta C
Podemos notar que quando passamos a considerar o tamanho das consultas, a ordem de prioridade de remoção delas mudou. Isso aconteceu porque o sistema identificou que a con- sulta A, apesar de possuir uma combinação de frequência/recentidade menos interessante que a consulta B, possui um tamanho mais parecido com o tamanho da consulta submetida pelo usuário.
5.5.2 Adaptação da Função de Substituição ao Integra
Para aplicação dessa função no Integra, tivemos que alterar a estrutura do log das consultas que existe atualmente. Foi incluído nele mais um campo para armazenar o valor da primeira
76
parte da função, ou seja, o somatório. Decidimos já armazenar no log uma parte do valor da função para agilizar o processamento do sistema. Dessa forma, o Gerenciador de Cache não precisará refazer o cálculo toda vez que precisar do valor da função. Porém, o valor que fica armazenado no log ainda não corresponde ao valor real da função, visto que só corresponde ao somatório. Decidimos armazenar dessa forma porque esse valor servirá também para decidir se uma consulta que não está armazenada em cache deva entrar. Assim, para o cálculo completo da função, o Gerenciador de Cache deverá acessar o novo campo do log, o campo referente ao tamanho da consulta, além do fator de ajuste, que é uma variável global do sistema.
A atualização do log das consultas é feita sempre que uma consulta é submetida ao sistema. Se essa consulta for nova, ou seja, nunca tenha sido executada, seu log será criado quando o Gerenciador de Consultas acionar o Gerenciador de Cache para saber se ela pode ser respondida pela cache. Se a consulta já tiver sido executada outras vezes, o seu log será atualizado também quando o Gerenciador de Cache for ativado.
Por ser o Integra um sistema que estará disponível a todo instante para diversos usuários, estabelecemos o k com o valor de 1 segundo. Para otimizar o cálculo dessa função, já que o somatório de todos os intervalos ti de 1 segundo cada seria bastante custoso, o algoritmo que
implementa a função apenas adiciona ao novo campo do log – o que representa a primeira parte da função – o valor do timestamp do momento em que o usuário submete a consulta, toda vez que a consulta for solicitada. Essa simples operação substitui o somatório presente na função.
A função de substituição de consultas criada para o Integra consegue, de forma simples, agregar todos os fatores que são relevantes para o sistema executar a substituição de elementos em cache. Nenhum dos algoritmos pesquisados e apresentados neste trabalho apresentou a combinação dos três fatores como vimos aplicados nessa função.