Detalhamento  da  Abordagem  CG-­‐OLAP

Figura 11 – Abordagem de Processamento de Consultas Espaciais do CG-OLAP

Cada nó do cluster recebe um conjunto de pares de identificadores de objetos para processar a consulta exata. Após a execução dos testes exatos, o nó do cluster retorna o resultado para o CQP. Ao receber todas as respostas, o CQP as consolida e retorna para o usuário que emitiu a consulta. A proposta pressupõe o uso de nós anônimos, ou seja, todos os nós presentes são capazes de atender qualquer consulta. Este requisito é atendido pelo uso de um cluster de banco de dados.

3.3 Detalhamento da Abordagem CG-OLAP

Esta seção apresenta o detalhamento da abordagem CG-OLAP proposta. Para ilustrar o seu funcionamento, será utilizado um exemplo de otimização do operador de junção espacial.

O exemplo considera dois conjuntos de polígonos representados por uma relação de municípios, com o atributo espacial contorno, e uma relação de áreas de risco de desmoronamento, com o atributo espacial area_risco. A consulta utilizada no exemplo é apresentada na Figura 12 e retorna uma lista de todos os municípios e as áreas de risco de desmoronamento neles existentes.

Figura 12 – Consulta SQ01: Exemplo de consulta usando uma junção espacial 3.3.1Passo 1 - Divisão da consulta

Ao receber uma consulta que tenha uma operação de junção espacial presente (de acordo com o padrão OGC definido pela OMG), o middleware executa a mesma sobre um índice espacial obtendo os pares candidatos a fazerem parte do conjunto solução.

Usando como exemplo a Consulta SQ01, cada par é composto pelo identificador de um município e pelo identificador de uma área de risco que possuem alguma interseção dos MBRs dos seus atributos espaciais. Estes pares são transmitidos aos nós do cluster para processamento paralelo.

É importante ressaltar que, uma vez que o MAE (usando aproximações) já eliminou objetos que certamente não participam da consulta, e já possui a informação dos objetos que podem ter intersecção, tornar a usar critérios espaciais nos nós do cluster anularia os efeitos do primeiro passo, fazendo com que a consulta fosse reexecutada sobre o índice espacial no nó. Portanto, optou-se por usar identificadores únicos (chaves primárias, não espaciais) para compor as subconsultas a serem enviadas para cada nó local. Isso permite que nós locais usem um índice unidimensional, o qual é muito mais eficiente do que um índice espacial, conforme a proposta original do ParGRES. Portanto, na abordagem CG-OLAP, seguindo a mesma ideia que sua antecessora ParGRES, assume-se que exista um índice clusterizado sobre a chave primária de uma tabela.

3.3.2Passo 2 - Execução distribuída

Os NQPs recebem conjuntos de pares e formam as subconsultas, combinando-os à consulta original, seguindo a abordagem da fragmentação virtual (Lima, 2004), detalhada no Capítulo 2.

A partir da consulta original são geradas subconsultas adicionando pares de identificadores dos objetos como predicados. A proposta do CG-OLAP difere da fragmentação virtual simples (SVP), pois o número de pares candidatos que compõem cada subconsulta é limitado a um número pré-definido. Esta adaptação foi feita porque foi observado experimentalmente que a definição de uma subconsulta para cada par candidato individualmente acarretaria no aumento de atraso (gerado pela transmissão de várias subconsultas do CQP e aos NQPs). Por outro lado, a geração de subconsultas dividindo-se o número de pares candidatos pelo número de nós para formar cada subconsulta (ou seja, gerar uma subconsulta por nó do cluster) acarretaria em um grande número de predicados para cada subconsulta, resultando em planos de consulta muito complexos, impossibilitando o SGBD de executá-los em determinados SGBDs espaciais. Assim, o número máximo de pares usados como filtro é parametrizável, com o intuito de equilibrar o número de subconsultas e a complexidade do plano das subconsultas.

Uma vez definidas, as subconsultas são executadas, desta vez sobre a representação exata dos objetos espaciais. Como o conjunto relevante para cada subconsulta é uma fração do conjunto original de objetos e, principalmente, as subconsultas são executadas de forma distribuída e paralela, o tempo necessário para a conclusão é reduzido em relação ao tempo da consulta original.

No exemplo da consulta SQ01, supondo que o primeiro passo tenha retornado o seguinte conjunto de pares candidatos:

{(1, 1001), (1, 1002), (2, 1002), (3, 1002), (3, 1003), (3, 1004)}.

Se existirem 2 nós no cluster de banco de dados e o número máximo de pares candidatos for 3, as seguintes subconsultas serão definidas por cada NQP (Figura 13 e Figura 14):

Figura 13 – Consulta SQ02: Exemplo de subconsulta formada no NQP 0

Figura 14 – Consulta SQ03: Exemplo de subconsulta formada no NQP 1

Voltando ao exemplo citado, cada nó recebe conjuntos de pares compostos de um identificador de um município e um identificador de uma área de risco. Cada par desses conjuntos é usado em um predicado lógico, que é adicionado à consulta original. Neste passo os municípios são comparados com as áreas de risco, e não mais suas aproximações.

3.3.3Composição dos resultados

Após a conclusão dos resultados da execução de cada subconsulta, os NQPs enviam os resultados parciais para o CQP para este compor o resultado final. Como não há interseção entre os conjuntos gerados no primeiro passo, esta composição é simplesmente uma justaposição ou agregação (dependendo da consulta original). Caso a consulta original busque um somatório, valor máximo, ou média, é preciso agregar os resultados. No caso da consulta original retornar relações de objetos, ou de seus atributos, o resultado final é a justaposição dos parciais recebidos dos NQPs pelo CQP. Uma vez completo, este resultado é enviado para a aplicação que executou a consulta original sobre o middleware.

No exemplo citado o retorno esperado da consulta é uma lista dos nomes dos municípios e das áreas de risco de desmoronamento que têm intersecção. Logo, é suficiente combinar (justapor) todos os resultados parciais.