Analisando  o  Tempo  de  Resposta  da  Junção  Espacial

Devido à comparação do cenário monoprocessado com o cenário paralelo e distribuído, para confirmar a hipótese de redução de tempo de execução, este deve ser observado do ponto vista da aplicação cliente. Isto significa que a comparação dos resultados levará em conta o tempo de resposta da consulta, ou seja, desde a emissão da consulta pela aplicação cliente até a resposta recebida pelo cliente. Além disso, o tempo de resposta da consulta (tanto no cenário monoprocessado quanto no cenário seguindo a abordagem CG-OLAP proposta) foi coletado considerando diversas etapas da execução, de forma a permitir análises mais detalhadas. As seções a seguir detalham cada um destes cenários. a) Cenário A Frio

Foram realizados testes coletando-se o tempo de resposta da consulta com o banco de dados frio (ou seja, recém iniciado), para que otimizações de execução como planos de consulta ou cache do SGBDE não interferissem no resultado da próxima consulta executada.

A Figura 20 ilustra o tempo de execução da consulta monoprocessada e das execuções a frio com um, dois e três nós. O tempo do eixo y é dado em ms. É visível no gráfico que mesmo usando somente dois nós, existe uma redução no tempo de execução total (7%) em relação à consulta monoprocessada, e esta redução se acentua ao adicionar o terceiro nó ao cluster (21%). Pode-se notar que a execução utilizando-se

apenas 1 nó do cluster apresentou uma perda significativa de desempenho em relação à execução monoprocessada (diretamente no console do PostgreSQL). Uma possível justificativa para isso é que ao invés de executar uma única consulta o nó executou sozinho uma série de subconsultas, devido ao limite de pares que forçou a divisão em subconsultas.

Figura 20 – Execuções a frio com um, dois e três nós

O número de nós para executar o cenário foi fisicamente limitado ao número de computadores disponíveis no cluster. Uma oportunidade para trabalhos futuros seria a avaliação do impacto causado pelo aumento de nós, considerando mais do que 3 nós. b) Cenário A Frio: Para onde vai o tempo em cada etapa da execução?

Para permitir uma análise mais detalhada sobre cada etapa da execução da consulta no ambiente distribuído, foram coletados os tempos parciais dentro de uma mesma execução, usando três nós. O tempo total da consulta utilizando o CG-OLAP pode ser dividido da seguinte forma:

b) Reconhecimento da consulta como espacial c) Execução do primeiro passo

d) Divisão da consulta em subconsultas e) Execução das subconsultas nos NQPs

f) Composição do resultado final e envio para a aplicação cliente

O gráfico apresentado na Figura 21 mostra a distribuição do tempo de execução da consulta do ponto de vista do CQP.

Figura 21 – Distribuição do tempo de execução da consulta no CQP

Analisando o gráfico da Figura 21, observa-se que a tarefa que tem maior influência no tempo total de execução da consulta é exatamente o processamento exato dos objetos. Esta tarefa acontece de maneira distribuída nos nós do cluster, o que indica que se o número de nós aumentar, a carga de processamento necessária no segundo passo será melhor distribuída e pode reduzir ainda mais o tempo de execução.

c) Cenário A Quente

A avaliação segundo este cenário é tradicional na avaliação de bancos de dados distribuídos. A intenção é verificar o tempo de execução de uma consulta, após o SGBD

tê-la executado uma primeira vez. As execuções seguintes podem aproveitar-se de dados colocados em cache pelo SGBD e um plano de consulta já elaborado. Assim, o comportamento esperado em cenários tradicionais é que a execução da consulta se torne mais rápida na medida em que uma mesma consulta é executada repetidas vezes.

No entanto, este comportamento não era o esperado para os cenários endereçados pelo CG-OLAP, uma vez que a estratégia de divisão em sub-consultas e a utilização de uma estrutura de dados maior e mais complexa em memória (para armazenar o conjunto de pares de identificadores de objetos) dificultam o aproveitamento dos dados em cache. De fato, na prática, a execução dos testes a quente no cenário distribuído apresentou um aumento do tempo de resposta na medida em que o número de execuções sucessivas da consulta crescia, como mostra a Figura 22. A consulta foi executada 6 vezes com três nós e 4 vezes com dois nós. Na Figura 22 estão expostos os tempos obtidos, excetuando o tempo da última consulta com dois nós que foi maior que vinte minutos (1.452.291ms), ultrapassando o limite do gráfico e portanto foi desconsiderado.

Uma vez que o tempo de resposta aumentou para as execuções sucessivas da consulta, partiu-se para a investigação do número de acessos ao disco. A Figura 23 ilustra o número de acessos à memória e ao disco durante a série de 6 execuções sucessivas da mesma consulta com três nós, as quais são apresentadas no eixo das abscissas (variando de 1 a 6). Este número de acessos se divide entre os acessos realizados para capturar o conteúdo das tabelas heap e toast. A tabela heap corresponde ao acesso tradicional às tabelas existentes no SGBDE. Já a tabela toast é uma tabela auxiliar criada pelo SGBDE, quando um campo de uma tabela guarda objetos de um tipo de dados grande, como acontece com os polígonos que representam os municípios. Na Figura 23, o gráfico apresenta o número de blocos lidos no disco para recuperar o conteúdo da primeira tabela da junção (D_GEOMETRY1). Na Figura 24 os blocos lidos no disco para a segunda tabela (D_GEOMETRY2). Para a primeira tabela este número se manteve em torno de uma média a cada execução, e um aumento foi observado para a segunda tabela.

Figura 24 – Leituras de blocos no disco para a tabela D_GEOMETRY2

Para analisar se o aumento do número de acessos a disco poderia ser a causa do aumento do tempo de resposta da consulta no cenário a quente, o passo seguinte foi observar o tempo isolado de execução das subconsultas.

Os tempos isolados de execução das subconsultas durante o teste a quente foram coletados e comparados entre cada execução da consulta. Os tempos das subconsultas também apresentaram variação (Figura 25). Da primeira para a terceira execução houve redução de 18% no tempo médio das subconsultas (Figura 25), enquanto o tempo de resposta da consulta como um todo aumentou aproximadamente na mesma proporção (Figura 22). No entanto, o maior aumento no tempo médio das subconsultas acontece da terceira para a quarta execução (Figura 25). Este comportamento é diferente do observado no tempo de resposta, onde a taxa de crescimento se manteve (Figura 22) e mostra que a perda de desempenho no tempo de resposta das execuções sucessivas da

consulta não foi determinada diretamente pelo aumento no tempo isolado das subconsultas.

Figura 25 – Tempo médio de execução das subconsultas

O passo seguinte foi investigar a taxa de utilização dos recursos das máquinas, como a ocupação dos processadores e memória volátil (RAM) dos computadores. Para avaliar se a causa do aumento de tempo de resposta da consulta estaria na máquina virtual Java, foi utilizada a ferramenta VisualVM⁴, que permite monitorar a memória ocupada pela máquina virtual. Assim, foi possível constatar que o espaço ocupado em memória aumentava com as execuções consecutivas, e não se reduzia ao final de cada execução da consulta como seria esperado (Figura 26). A alta ocupação da memória RAM impediu que a máquina gerasse novos objetos e atrasou a geração dos filtros e execução das subconsultas. O aumento irreversível da ocupação de memória se apresenta como a causa mais provável do atraso observado na execução repetida da consulta.

Figura 26 – Gráfico que indica a memória reservada e usada, gerado pela VisualVM

Em aplicações Java a gerência de memória é exclusividade da máquina virtual, não sendo permitido à aplicação executada remover objetos para aumentar o espaço livre. Devido a este desvio do comportamento esperado, o cenário a quente não foi considerado como um bom resultado.

d) Testes com Maior Volume de Dados

Com o objetivo de avaliar a proposta usando uma carga de dados maior, o número de polígonos em cada tabela foi aumentado de forma que o tamanho da tabela ultrapassasse a capacidade de memória. O procedimento para a geração dessa massa de dados foi o mesmo usado anteriormente, salvo o número de repetições para a criação das tabelas que foi maior. O mapa foi replicado 161 vezes, deixando cada tabela com 896.126 registros ocupando aproximadamente 2Gb de memória em disco. Após o primeiro passo, 3.054.225 de pares candidatos foram identificados e após o segundo passo, o resultado final foi de 1.895.991 objetos se interceptam. O tempo médio da consulta monoprocessada ao ser executada foi de 3.992.847 ms (ou 1h 06min 32s 846ms).

Como esperado, o problema do aumento de ocupação da memória RAM (que foi observado durante os testes a quente com menor volume de dados relatados anteriormente) também impactou a execução da consulta com a massa de dados maior, de maneira ainda mais intensa. Como o número de pares candidatos aumenta em função do volume de dados a ser retornado pela consulta, a ocupação crítica da memória atinge o seu pico já na primeira execução, impossibilitando execuções sucessivas da consulta.