distjoin: plataforma de processamento distribuído de operações

UNIVERSIDADE FEDERAL DE GOIÁSINSTITUTO DE INFORMÁTICA

SÁVIO SALVARINO TELES DE OLIVEIRA

DistJoin: Plataforma de ProcessamentoDistribuído de Operações de Junção

Espacial com Bases de Dados Dinâmicas

Goiânia2013

UNIVERSIDADE FEDERAL DE GOIÁS

INSTITUTO DE INFORMÁTICA

AUTORIZAÇÃO PARA PUBLICAÇÃO DE DISSERTAÇÃO

EM FORMATO ELETRÔNICO

Na qualidade de titular dos direitos de autor, AUTORIZO o Instituto deInformática da Universidade Federal de Goiás – UFG a reproduzir, inclusive em outroformato ou mídia e através de armazenamento permanente ou temporário, bem comoa publicar na rede mundial de computadores (Internet) e na biblioteca virtual da UFG,entendendo-se os termos “reproduzir” e “publicar” conforme definições dos incisos VIe I, respectivamente, do artigo 5o da Lei no 9610/98 de 10/02/1998, a obra abaixoespecificada, sem que me seja devido pagamento a título de direitos autorais, desde quea reprodução e/ou publicação tenham a finalidade exclusiva de uso por quem a consulta,e a título de divulgação da produção acadêmica gerada pela Universidade, a partir destadata.

Título: DistJoin: Plataforma de Processamento Distribuído de Operações de JunçãoEspacial com Bases de Dados Dinâmicas

Autor(a): Sávio Salvarino Teles de Oliveira

Goiânia, 28 de Junho de 2013.

Sávio Salvarino Teles de Oliveira – Autor

Dr. Vagner José do Sacramento Rodrigues – Orientador




Dissertação apresentada ao Programa de Pós–Graduação doInstituto de Informática da Universidade Federal de Goiás,como requisito parcial para obtenção do título de Mestre emComputação.

Área de concentração: Sistemas Distribuídos.Orientador: Prof. Dr. Vagner José do Sacramento Ro-drigues

Goiânia2013




Dissertação defendida no Programa de Pós–Graduação do Instituto deInformática da Universidade Federal de Goiás como requisito parcialpara obtenção do título de Mestre em Computação, aprovada em 28 deJunho de 2013, pela Banca Examinadora constituída pelos professores:

Prof. Dr. Vagner José do Sacramento RodriguesInstituto de Informática – UFG

Presidente da Banca

Prof. Dr. Fábio Moreira CostaInstituto de Informática – UFG

Prof. Dr. João Batista da Rocha JuniorUniversidade Estadual de Feira de Santana – UEFS

Todos os direitos reservados. É proibida a reprodução total ou parcial dotrabalho sem autorização da universidade, do autor e do orientador(a).

Sávio Salvarino Teles de Oliveira

Possui graduação em CIÊNCIAS DA COMPUTAÇÃO pela UniversidadeFederal de Goiás (2009) e atualmente é aluno regular do Programa deMestrado do Instituto de Informática da UFG (Universidade Federal deGoiás). Tem experiência na área de Ciência da Computação, com ênfaseem Sistemas Distribuídos e GeoProcessamento, atuando principalmente nosseguintes temas: implementação de algoritmos espaciais distribuídos, apli-cações Web (Java, Spring, Ajax (dwr), JavaScript, XMPP) e modelagem deaplicações distribuídas.

Dedico este trabalho:Aos meus pais, José Salvarino de Oliveira e Maria Francisca Teles da Cunha.Ao meu irmão Vinícius Teles de Oliveira.A minha namorada Silvana Pereira de Souza.

Agradecimentos

Este trabalho devo muito a algumas pessoas, por diversas razões, e gostaria deagradecer especialmente:

Ao meu orientador Professor Dr. Vagner José do Sacramento Rodrigues porcompartilhar comigo seu tema de pesquisa. Gostaria de agradecê-lo pela orientação eincentivo durante o desenvolvimento deste trabalho.

Ao grupo de trabalho do Laboratory for Ubiquitous and Pervasive Applications(LUPA/UFG) pela grande ajuda. Sem eles, com certeza, este trabalho não teria sidoconcretizado.

A meus pais, José Salvarino de Oliveira e Maria Francisca Teles da Cunha, pelosincentivos durante toda a minha formação acadêmica.

A Silvana Pereira de Souza por todo apoio e compreensão ao longo da trajetóriaque me levou à concretização deste trabalho.

Resumo

de Oliveira, Sávio Salvarino Teles. DistJoin: Plataforma de ProcessamentoDistribuído de Operações de Junção Espacial com Bases de Dados Dinâmi-cas. Goiânia, 2013. 70p. Dissertação de Mestrado. Instituto de Informática,Universidade Federal de Goiás.

Os Sistemas de Informação Geográfica (SIG) têm recebido cada vez mais destaque nosinstitutos de pesquisa e na indústria nos últimos anos. Um Sistema de Gerência de Bancosde Dados Espaciais (SGBDE) é um dos principais componentes de um SIG e a junçãoespacial uma das operações mais importantes nos SGBDEs. Ela envolve o relacionamentoentre duas bases de dados, combinando as geometrias de acordo com algum predicadoespacial, como intersecção. Devido à crescente disponibilidade de dados espaciais, aoaumento no número de usuários dos SIGS e ao alto custo de processamento das operaçõesespaciais, os SGBDE distribuídos (SGBDED) surgem com uma boa opção para processara junção espacial de forma eficiente em um cluster de computadores. Esse processamentodistribuído traz consigo alguns desafios, tais como a distribuição dos dados pelo cluster

e o processamento paralelo e distribuído da junção espacial. O objetivo deste trabalho éapresentar uma plataforma de geoprocessamento paralelo e distribuído da junção espacialem um cluster de computadores, utilizando técnicas de distribuição de dados para basesde dados dinâmicas. Os trabalhos encontrados na literatura têm explorado técnicas dedistribuição de dados indicadas para bases de dados estáticas, onde qualquer atualizaçãoda base de dados requer que todos os dados sejam novamente distribuídos pelo cluster.Isto se torna inviável com grandes bases de dados e que sofrem constantes atualizações.Por isso, este trabalho propõe duas novas técnicas de distribuição de dados com bases dedados dinâmicas: Proximity Area e Grid Proximity Area. Estas técnicas foram avaliadaspara definir em quais cenários cada uma delas é mais apropriada. Para tal, estas técnicasforam avaliadas em um ambiente real com bases de dados com características diferentes,para que fosse possível experimentar a junção espacial distribuída em cenários diversoscom cada técnica de distribuição de dados.

Palavras–chave

Junção Espacial Distribuída, Bases de Dados Dinâmicas, R-Tree.

Abstract

de Oliveira, Sávio Salvarino Teles. DistJoin: Platform for Distributed Pro-cessing of Spatial Join Operations with Dynamic Datasets. Goiânia, 2013.70p. MSc. Dissertation. Instituto de Informática, Universidade Federal deGoiás.

Geographic Information Systems (GIS) have received increasing attention in research ins-titutes and industry in recent years. A Spatial Database Managament System (SDBMS)is one of the main components of a GIS and spatial join is one of the most importantoperations in SDBMS. Spatial join involves the relationship between two datasets, com-bining the geometries according some spatial predicate, such as intersection. Due to theincreasing availability of spatial data, the growing number of GIS users, and the highcost of the processing of spatial operations, distributed SGBDEs (SGBDED) have beenproposed as a good option to efficiently process spatial join on a cluster. This distributedprocessing brings some challenges, such as the data distribution and parallel and dis-tributed processing of spatial join. This paper presents a platform for parallel and dis-tributed processing of spatial joins in a cluster using data distribution techniques for dy-namic datasets. Studies in the literature have explored data distribution techniques forstatic datasets, where any update requires data redistribution. This becomes unfeasiblewhen using large datasets with frequent updates. Therefore, this paper proposes two newdata distribution techniques for dynamic datasets: Proximity Area and Grid ProximityArea. These techniques have been evaluated to determine which scenarios each techniqueis more appropriate for. For this purpose, these techniques are evaluated in a real environ-ment using datasets with different characteristics. Therefore, it is possible to evaluate thespatial join operation in real scenarios with each technique.

Keywords

Distributed Spatial Join, Dynamic Dataset, R-Tree.

Sumário

Lista de Figuras 10

Lista de Tabelas 13

1 Introdução 14

2 Processamento de Dados Espaciais 182.1 R-Tree 182.2 Junção espacial 19

3 Processamento da junção espacial distribuída 233.1 Algoritmo de junção espacial distribuída 243.2 DistJoin: Plataforma de Processamento Distribuído da Junção Espacial 25

3.2.1 Visão geral da Arquitetura 263.2.2 Protocolo de Comunicação 273.2.3 Detalhes da Implementação 283.2.4 Considerações Finais 29

4 Distribuição de Dados com Bases de Dados Dinâmicas 314.1 Proximity Area 324.2 Grid Proximity Area 344.3 Considerações Finais 38

5 Avaliação de Desempenho 405.1 Ambiente Experimental 415.2 Avaliação da Junção Espacial Distribuída com as técnicas de distribuição de

dados: Grid Proximity Area e Proximity Area 425.2.1 Junção espacial entre as Bases de dados Bioma do Cerrado e Desmatamento

do Cerrado 435.2.2 Junção espacial entre as Bases de dados Bioma da Caatinga e Localidades 465.2.3 Junção espacial entre as Bases de dados Rodovias e Hidrografia 49

5.3 Considerações Finais 52

6 Trabalhos Correlatos 546.1 Distribuição de Dados 546.2 Processamento Paralelo e Distribuído da Junção Espacial utilizando a Técnica

de Semi-Junção Espacial 586.3 Considerações Finais 59

7 Conclusão 607.1 Trabalhos Futuros 61

Referências Bibliográficas 63

A Uso de memória pelas técnicas de Distribuição de Dados Grid Proximity Area eProximity Area 68

Lista de Figuras

1.1 Junção espacial entre as bases de dados de Estados e Hidrovias doBrasil para descobrir quais estados brasileiros apresentam intersecçãocom alguma hidrovia 15(a) Base de Dados de Estados 15(b) Base de Dados de Hidrovia 15(c) Junção espacial entre as bases de dados de Estados e Hidrovias do

Brasil 15

2.1 Estrutura de dados espacial 19(a) Índice espacial R-Tree 19(b) Disposição espacial dos objetos geográficos 19

2.2 Aproximações geométricas 20(a) Aproximação geométrica de um polígono. 20(b) Visão de uma junção entre dois polígonos com suas respectivas

aproximações geométricas 202.3 Junção espacial entre as relações R e S 21

(a) Disposição espacial das relações R e S 21(b) Indexação das relações R e S na R*-Tree 21

2.4 Processamento do algoritmo de intersecção entre os polígonos de (1, D)e (2, A). 21

2.5 Exemplo com área morta e área de sobreposição. 22

3.1 R-Tree distribuída 243.2 Arquitetura da Plataforma DistJoin 26

4.1 Inserção de um objeto utilizando a técnica Proximity Area com k = 0,5 34(a) Antes da inserção 34(b) Depois da inserção 34

4.2 Divisão do espaço do mundo em uma Grid 354.3 Mapeamento de um novo objeto na grid para os servidores. 364.4 Visão da grid na junção espacial entre dois objetos espaciais 1 e D 36

(a) Junção entre dois objetos com cópias armazenadas no mesmo servidor 36(b) Junção entre dois objetos com cópias armazenadas em servidores

diferentes 36

5.1 Visão territorial da Junção Espacial entre as Bases de Dados: Bioma doCerrado e Desmatamento do Cerrado. 43(a) Base de dados Bioma do Cerrado 43(b) Base de dados Desmatamento do Cerrado 43

(c) Junção espacial entre as Bases de dados Bioma do Cerrado eDesmatamento do Cerrado 43

5.2 Tempo de Resposta da Junção Espacial entre as Bases de Dados: Biomado Cerrado e Desmatamento do Cerrado 44

5.3 Tráfego de rede na Junção Espacial entre as Bases de Dados Bioma doCerrado e Desmatamento do Cerrado com 8 máquinas. 45

5.4 Número de intersecções realizadas em cada servidor na Junção Espacialentre as Bases de Dados Bioma do Cerrado e Desmatamento do Cerradocom 8 máquinas. 45

5.5 Média do uso da CPU na Junção Espacial entre as Bases de DadosBioma do Cerrado e Desmatamento do Cerrado com 8 máquinas. 46

5.6 Visão territorial da Junção Espacial entre as Bases de Dados: Bioma daCaatinga e Localidades. 47(a) Base de dados Bioma da Caatinga 47(b) Base de dados Localidades 47(c) Junção espacial entre as Bases de dados Bioma da Caatinga e

Localidades 475.7 Tempo de Resposta da Junção Espacial entre as Bases de Dados: Bioma

da Caatinga e Localidades 485.8 Distribuição do processamento na Junção Espacial entre as Bases de

Dados Bioma da Caatinga e Localidades. 48(a) Distribuição do processamento na etapa de refinamento com 4

máquinas 48(b) Distribuição do processamento na etapa de refinamento com 8

máquinas 485.9 Tráfego de dados na rede na Junção Espacial entre as Bases de Dados

Bioma da Caatinga e Localidades com 8 máquinas 495.10 Visão territorial da Junção Espacial entre as Bases de Dados: Rodovias e

Hidrografia. 50(a) Base de dados Rodovias 50(b) Base de dados Hidrografia 50(c) Junção espacial entre as Bases de dados Rodovias e Hidrografia 50

5.11 Tempo de Resposta da Junção Espacial entre as Bases de Dados:Rodovias e Hidrografia 50

5.12 Pares de candidatos filtrados nas folhas na Junção Espacial entre asRodovias e Hidrografia. 51(a) Quantidade de pares de candidatos analisados nas folhas 51(b) Quantidade de pares de candidatos que satisfazem as condições

espaciais da consulta 515.13 Distribuição do processamento na etapa de refinamento na Junção Espa-

cial entre as Bases de Dados Rodovias e Hidrografia. 515.14 Uso de CPU na Junção Espacial entre as Bases de Dados Rodovias e

Hidrografia. 52

6.1 Arquitetura da plataforma proposta em [6] 56

A.1 Uso de memória na Junção Espacial entre as Bases de Dados Bioma doCerrado e Desmatamento do Cerrado. 68

(a) 3 máquinas 68(b) 6 máquinas 68(c) 9 máquinas 68

A.2 Uso de memória na Junção Espacial entre as Bases de Dados Bioma daCaatinga e Localidades. 69(a) 3 máquinas 69(b) 6 máquinas 69(c) 9 máquinas 69

A.3 Uso de memória na Junção Espacial entre as Bases de Dados Rodoviase Hidrografia. 70(a) 3 máquinas 70(b) 6 máquinas 70(c) 9 máquinas 70

Lista de Tabelas

5.1 Descrição das bases de dados 41

CAPÍTULO 1Introdução

Nos últimos anos, aplicações espaciais, como os Sistemas de Informação Geo-gráfica (SIG), têm recebido cada vez mais destaque nos institutos de pesquisa e naindústria. Estes sistemas são projetados para capturar, armazenar, manipular, analisar eapresentar todos os tipos de dados geográficos.

A habilidade de explorar propriedades físicas, lógicas e temporais tornam osSIGs imprescindíveis em várias áreas: demografia, análise de terrenos, mineração, plane-jamento militar, logística e robótica, além de várias outras aplicações que utilizam a lo-calização geográfica para prover serviços.

Com o desenvolvimento de tecnologias de observação do planeta Terra, adisponibilidade de dados espaciais tem crescido de forma exponencial a cada ano (atual-mente em uma escala de petabytes) [47]. Com isto, os SIGs têm se tornado cada vezmais populares, com um aumento significativo no número de usuários destes sistemas.Esses usuários conseguem fornecer em tempo real, por exemplo, através da tecnologia deGlobal Positioning System (GPS), informações de lugares onde estiveram, aumentandoainda mais a quantidade de dados espaciais disponíveis.

Um Sistema de Gerência de Bancos de Dados Espaciais (SGBDE) é um dos prin-cipais componentes de um SIG, pois nele estão armazenados e são gerenciados os objetosdas bases de dados espaciais. Por meio do SGBDG é possível realizar processamentosgeométricos, análise espacial e fazer relação entre dados relacionais e espaciais.

A junção espacial é uma das operações mais importantes nos SGBDEs. Elaenvolve o relacionamento entre duas bases de dados, combinando as geometrias de acordocom algum predicado espacial, como intersecção.

A Figura 1.1 apresenta um exemplo de junção espacial entre as bases de dadosde Estados e Hidrovias para identificar quais hidrovias estão presentes em quais estadosbrasileiros. Para descobrir esta informação, foi realizada a junção espacial entre a base dedados de Estados (Figura 1.1(a)) e a base de dados de Hidrovias (Figura 1.1(b)). A Figura1.1(c) apresenta a visão geográfica da junção espacial entre as duas bases de dados, ondese pode observar a intersecção de alguns estados com algumas hidrovias.

15

(a) Base de Dados de Esta-dos

(b) Base de Dados deHidrovia

(c) Junção espacial entre asbases de dados de Estados eHidrovias do Brasil

Figura 1.1: Junção espacial entre as bases de dados de Esta-dos e Hidrovias do Brasil para descobrir quais es-tados brasileiros apresentam intersecção com algumahidrovia

Os algoritmos de processamento da junção espacial apresentam alto custo devidoa dois fatores: i) tamanho e complexidade dos objetos das bases de dados envolvidas e ii)algoritmos de geometria computacional com alta demanda de uso da CPU [21].

Os SIGs devem ser capazes de executar consultas de junção espacial de formaeficiente para atenderem aos requisitos de tempo real das aplicações. As soluções centrali-zadas são limitadas pelo poder de processamento e armazenamento de um único servidor.Mesmo soluções paralelas com réplicas de servidores de grande porte têm a sua esca-labilidade de processamento e armazenamento de dados limitada pelas necessidades deprocessamento de grande quantidade de requisições simultâneas, sincronização, movi-mentação e armazenamento de grande volume de dados em cada réplica, além de muitasvezes tornar a solução inviável financeiramente [11].

Com isto emergiram os SGBDE distribuídos (SGBDED), que podem serdefinidos como um conjunto de computadores interconectados por uma rede de com-putadores que cooperam para a realização de operações de geoprocessamento nas basesde dados disponíveis no sistema. Esta solução possui diversas vantagens:

• A utilização de clusters de computadores permite aumentar ou diminuir o poderde processamento com a inclusão ou exclusão de servidores. Desta forma, investi-mentos são realizados de acordo com a demanda de recursos computacionais (CPU,memória, armazenamento, etc);• A carga de trabalho pode ser distribuída entre os servidores do cluster.• Caso um servidor venha a falhar, o serviço continua a ser disponibilizado pelos

outros servidores do cluster;• Os clusters podem ser formados por computadores convencionais de baixo custo.

16

Diante dos recursos computacionais disponíveis em um cluster de computadores,os SGBDEDs devem ser capazes de paralelizar o processamento da junção espacialentre estes computadores de forma a aproveitar os recursos disponíveis. Com isso,alguns desafios são identificados, tais como a distribuição dos dados pelo cluster e oprocessamento paralelo e distribuído da junção espacial.

O objetivo deste trabalho é apresentar uma plataforma de processamento parale-lo e distribuído da junção espacial em um cluster de computadores, utilizando técnicasde distribuição de dados para bases de dados dinâmicas. Esta plataforma apresentauma arquitetura peer-to-peer com tratamento de falhas, protocolos de comunicação, umsistema de armazenamento, funções de manipulação de objetos espaciais e tratamento deconcorrência e consistência que permitem que a junção espacial seja executada de formaparalela e distribuída.

Duas novas técnicas de distribuição de dados com bases de dados dinâmicas sãopropostas neste trabalho: Proximity Area e Grid Proximity Area. Os trabalhos encontradosna literatura têm explorado técnicas de distribuição de dados indicadas para bases dedados estáticas, onde qualquer atualização da base de dados requer que todos os dadossejam novamente distribuídos pelo cluster. Isto se torna inviável com grandes basesde dados e que sofrem constantes atualizações. As técnicas de distribuição de dadospropostas neste trabalho conseguem atualizar a base de dados sem que haja a necessidadede redistribuir os objetos pelo cluster.

Essas técnicas foram avaliadas para determinar em quais cenários cada uma delasé mais indicada. Para tal, foram realizados experimentos utilizando bases de dados comcaracterísticas diferentes e com clusters de tamanho variável com o objetivo de avaliar ajunção espacial distribuída com cada técnica de distribuição de dados.

As principais contribuições deste trabalho são:

• Uma plataforma de geoprocessamento distribuído que pode ser utilizada na pro-visão de diversos serviços de inteligência geográfica;• Um algoritmo distribuído para o processamento da junção espacial;• Duas novas técnicas de distribuição de dados para bases de dados dinâmicas;• Estudo do impacto da distribuição de dados no processamento da junção espacial

distribuída com bases de dados dinâmicas.

O restante do trabalho está organizado como segue. O Capítulo 2 apresenta umarevisão das estruturas de dados espaciais existentes e a visão geral da operação de junçãoespacial. O Capítulo 3 apresenta a arquitetura da plataforma DistJoin e o algoritmo dejunção espacial em um ambiente distribuído. No Capítulo 4 são apresentadas as técnicasde distribuição de dados para bases de dados dinâmicas: Proximity Area e Grid Proximity

Area. O Capítulo 5 descreve a metodologia e os resultados dos testes de junção espacial

17

executados na plataforma. O Capítulo 6 compara a plataforma DistJoin com as estratégiasencontradas na literatura para o processamento da junção espacial distribuída com basesde dados dinâmicas. O Capítulo 7 apresenta as conclusões deste trabalho e uma brevedescrição dos trabalhos futuros.

CAPÍTULO 2Processamento de Dados Espaciais

Árvores de pesquisa são uma forma comum de indexar um conjunto de dados epermitir que a busca por um elemento seja executada em tempo logarítmico em relaçãoao número de nós da árvore [7].

Os sistemas de bancos de dados relacionais apresentam diversas estruturas deindexação, sendo a árvore B [7] a mais utilizada. Entretanto, em sistemas de bancos dedados espaciais, estas estruturas de dados relacionais não são apropriadas para o proces-samento de consultas espaciais, pois os objetos armazenados são multidimensionais [14].

A indexação de dados espaciais vem sendo pesquisada desde 1975, o queocasionou o surgimento de diversas estruturas de dados, sendo estas as principais: K-

D Tree[3], Quad-Tree[37], R-Tree [14] e a Hilbert R-Tree [19]. A R-Tree é a estruturade dados mais comumente utilizada nos bancos de dados espaciais e foi escolhida comoestrutura de dados para indexar as bases de dados no nosso trabalho.

2.1 R-Tree

Uma R-Tree é uma árvore balanceada por altura, semelhante a árvores B+[8],com ponteiros para objetos espaciais nos nós folhas. É uma estrutura de dados hierárquicaque utiliza retângulos para organizar um conjunto dinâmico de objetos espaciais, demaneira que objetos colocalizados fiquem armazenados próximos uns dos outros e quehaja uma redução no espaço de busca a cada nível da árvore [14].

Os nós internos da R-Tree contêm a delimitação de retângulos que englobamtodos os retângulos dos nós nos níveis inferiores. Estes retângulos, chamados de MBRs(Minimum Bounding Rectangle), possuem área o menor possível para envolver as geome-trias dos filhos. Na Figura 2.1(b), o MBR de r1 é o menor retângulo possível para envolveros filhos 1 e 2. A Figura 2.1(b) retrata o desenho dos MBRs de r1 e r2 agrupando os ob-jetos espaciais de 1 a 4 em subconjuntos, de acordo com sua localização.

A Figura 2.1(a) ilustra a estrutura hierárquica da R-Tree com um nó interno raiz

(raiz ⊂ r1,r2), nós folhas (r1..r2 ⊂ 1..4) e um último nível com os objetos espaciais.As regras básicas para formação de uma R-Tree são semelhantes às de uma árvore B+,

2.2 Junção espacial 19

onde todas as folhas aparecem sempre no mesmo nível da árvore. Cada nó armazena nomáximo M e no mínimo m≤ M

2 entradas [14].Para cada entrada (I, child) em um nó interno, I representa o MBR que contém

espacialmente o retângulo do nó filho e child contém o ponteiro para o nó filho. Paracada entrada (I, ptr) em um nó folha, I representa o MBR que contém espacialmente opolígono da entrada e ptr o ponteiro para o objeto espacial no banco de dados.

O nó raiz da R-Tree apresentada da Figura 2.1(a) possui duas entradas: umaaponta para r1 e a outra para r2. Para a entrada que aponta para r1, por exemplo, I éo menor retângulo que engloba r1 e child o ponteiro para r1. O nó r1 apresenta duasentradas: uma aponta para o objeto espacial 1 e outra para o objeto espacial 2. Para aentrada que aponta para 1, I representa o menor retângulo possível que engloba o polígonode 1 e ptr o ponteiro que indica onde o objeto espacial 1 está armazenado no banco dedados.

(a) Índice espacial R-Tree

(b) Disposição espacial dos objetos geográficos

Figura 2.1: Estrutura de dados espacial

2.2 Junção espacial

A junção espacial pode ser definida a partir de duas relações R = r1, ...,rn e S =s1, ...,sm, onde ri e s j são objetos espaciais, 1 ≤ i ≤ n e 1 ≤ j ≤ m. A operação verificatodos os pares (ri, s j) que satisfazem o predicado de um operador topológico, por exemplo,a interseção, isto é, ri

⋂s j 6= /0 [18]. Este trabalho utiliza um algoritmo de junção espacial

que caminha por duas relações R e S indexadas por R-Trees [5].O processamento da junção é realizado em duas etapas: etapa de filtragem e

etapa de refinamento [33]. A etapa de filtragem inicia na raiz das duas relações R e S e é


realizada nos nós internos da R-Tree. A etapa de refinamento é processada entre os objetosespaciais das bases de dados para descartar resultados incorretos resultantes da etapa defiltragem.

A etapa de filtragem utiliza aproximações das geometrias dos objetos na ope-ração de intersecção para gerar um conjunto de possíveis respostas à consulta. Aproxi-mações são polígonos utilizados para reduzir a complexidade das geometrias para poucospontos geométricos [4]. A Figura 2.2(a) apresenta um exemplo de uma geometria comvários pontos representada por uma aproximação com MBR que contém dois pontos.Estas aproximações são utilizadas na operação de junção espacial para descartar resulta-dos que não fazem parte da resposta, pois apresentam menor custo de processamento deintersecção do que os polígonos que representam, devido ao menor número de pontos.

A ocorrência de intersecção entre duas aproximações não significa que suas res-pectivas geometrias também intersectam. Um exemplo pode ser observado na Figura2.2(b), onde as aproximações (MBRs) dos dois polígonos se intersectam, mas os polí-gonos não. Desta forma, as geometrias são verificadas somente quando as aproximaçõesintersectam, já que as aproximações englobam estes polígonos.

(a) Aproximação geométrica de umpolígono.

(b) Visão de uma junção entre doispolígonos com suas respectivasaproximações geométricas

Figura 2.2: Aproximações geométricas

A Figura 2.3(a) apresenta um exemplo de junção espacial entre as relações R e S.Os retângulos serrilhados que englobam os polígonos representam suas aproximações naforma de MBR. No nível raiz, o MBR de r1 intersecta com os MBRs de s1 e s2 e o MBRde r2 intersecta com o MBR de s2. Por isso, o conjunto de saída da etapa de filtragem éformado pelos pares (r1, s1), (r1, s2) e (r2, s2).

Observando a Figura 2.3(b), nas folhas são analisados os nós filhos de (r1, s1),(r1, s2) e (r2, s2). Nesta fase, houve a necessidade de verificar os seguintes conjuntos depares de candidatos {(1, A), (1, B), (1, C), (1, D), (1, E), (1, F), (2, A), (2, B), (2, C), (2,D), (2, E), (2, F), (3, D), (3, E), (3, F), (4, D), (4, E), (4, F)}.


(a) Disposição espacial das relações R e S (b) Indexação das relações R e S naR*-Tree

Figura 2.3: Junção espacial entre as relações R e S

Dentre o conjunto de pares de candidatos, apenas (1, D) e (2, A) fizeram parte doresultado de processamento da fase de filtragem nos nós internos. Isto porque apenas suasrespectivas aproximações (MBRs serrilhados) intersectam dentre o conjunto de pares decandidatos.

Neste caso, são obtidas as geometrias associadas aos pares de candidatos paraexecução da fase de refinamento. Como apresentado na Figura 2.4, apenas (1, D) fez partedo resultado final por apresentar intersecção entre seus respectivos polígonos. O par decandidatos (2, A) apresenta intersecção das aproximações, mas não apresenta intersecçãoentre os polígonos.

Figura 2.4: Processamento do algoritmo de intersecção entre ospolígonos de (1, D) e (2, A).

A utilização de R-Trees na junção espacial traz consigo os problemas da R-Tree,isto é, áreas de sobreposição e áreas mortas, como pode ser visto no exemplo a seguir.Estas áreas de sobreposição resultam em uma grande quantidade de comparações e asáreas mortas em comparações desnecessárias, o que prejudica o desempenho da operaçãode junção espacial [31]. As duas relações R e S estão indexadas, no nosso trabalho, porduas R*-Trees para reduzir estas áreas de sobreposição e áreas mortas.

Este problema, entretanto, só é resolvido de forma eficiente com a ciência a prioridos objetos a serem inseridos e a construção de estruturas de indexação espacial estáticas[31]. Estas estruturas de indexação devem ser reconstruídas a cada atualização da base dedados, o que é inviável para o escopo deste trabalho, que utiliza bases de dados dinâmicas.


Figura 2.5: Exemplo com área morta e área de sobreposição.

No exemplo apresentado na Figura 2.3, pode-se observar o efeito de espaçosmortos e áreas de sobreposição no processamento da junção espacial. Espaço morto é aárea adicional do MBR necessária para cobrir a geometria como um todo. Na Figura 2.5,a área não preenchida pelo polígono é um exemplo de espaço morto. Áreas sobrepostassão regiões de interseção entre polígonos ou aproximações de polígonos, como ilustradona Figura 2.5, entre os objetos espaciais 1 e 2.

No exemplo da Figura 2.3, a área de sobreposição entre r1 e s1 causou umprocessamento desnecessário dos ramos da árvore descendentes de r1 e s1. Estes ramosnão tinham pares de objetos que fizessem parte do resultado final, já que o par (1, D)é descendente dos ramos de r1 e s2. O par r2 e s2 apresenta intersecção em uma áreade espaço morto. Isto também ocasionou um processamento desnecessário nos ramosdescendentes deste par, já que estas áreas de espaço morto não geram resultados emoperações de junção espacial.

CAPÍTULO 3Processamento da junção espacial distribuída

Os algoritmos de junção espacial apresentam alto custo de processamento de-vido aos seguintes fatores: i) tamanho e complexidade dos objetos das bases de dadosenvolvidas e ii) processamento de algoritmos de geometria computacional com alta de-manda de uso da CPU [21]. Por isso, as pesquisas têm se concentrado em processar ajunção espacial de forma paralela e distribuída em um cluster de computadores.

Entretanto, o processamento da junção espacial distribuída em um cluster decomputadores apresenta alguns desafios:

1. O tráfego de dados na rede deve ser reduzido, pois impacta de forma significativano desempenho do algoritmo de junção espacial distribuída;

2. O processamento paralelo e distribuído da junção espacial deve aproveitar da me-lhor forma possível os recursos disponíveis no cluster (e.g., CPU, disco, memória,etc);

3. Escalabilidade;4. Tratamento de falhas;5. Tratamento de concorrência e consistência.

O tráfego de dados na rede é reduzido neste trabalho utilizando uma técnica co-nhecida como Semi-Junção espacial, apresentada na Seção 3.1, e técnicas de Distribuiçãode Dados, apresentadas no Capítulo 4. Estas técnicas de Distribuição de Dados distribuemos objetos espaciais pelo cluster, de forma que os recursos disponíveis no cluster sejamaproveitados para o processamento paralelo e distribuído da junção espacial.

A plataforma DistJoin, descrita na Seção 3.2, apresenta uma arquitetura peer-to-

peer escalável com técnicas para tratamento de falhas nos servidores. Os algoritmos detratamento de concorrência e consistência necessários para o processamento paralelo edistribuído da junção espacial foram implementados de forma similar a [10].

Neste Capítulo, apresentamos na Seção 3.1 a descrição do algoritmo de junçãoespacial distribuída implementado neste trabalho, juntamente com a técnica conhecidacomo Semi-Junção Espacial. Na Seção 3.2 é apresentada a plataforma de processamentoda junção espacial distribuída, denominada DistJoin.

3.1 Algoritmo de junção espacial distribuída 24

3.1 Algoritmo de junção espacial distribuída

O algoritmo de processamento da junção espacial implementado neste trabalho ésemelhante ao apresentado na Seção 2.2 para a versão centralizada. Na versão distribuída,há a necessidade de trocar mensagens na rede para acessar os objetos distribuídos.

A Figura 3.1 ilustra as R-Trees das duas bases de dados, R e S, apresentadasna Figura 2.3(b), distribuídas em um cluster de computadores. Nem sempre os dadosnecessários para a junção entre as bases de dados estão disponíveis localmente. Noexemplo da Seção 2.2 apresentado na Figura 2.3, a junção espacial entre R e S teve comoresultado o par (1, D). Observando a Figura 3.1, percebe-se que os objetos 1 e D estãolocalizados em máquinas diferentes. Portanto, para processar a junção espacial entre osdois objetos, um deles deve ser trafegado na rede até o local em que está armazenado ooutro objeto.

Figura 3.1: R-Tree distribuída

Para reduzir o tráfego de dados na rede, este trabalho utiliza uma técnica conheci-da como Semi-Junção Espacial. O algoritmo de Semi-Junção Espacial, implementadoneste trabalho, é realizado entre dois objetos espaciais, referentes a duas bases de dadosR e S diferentes, localizadas nos servidores Rsite e Ssite, respectivamente. O algoritmoexecuta os seguintes passos:

1. Em Ssite, é construída uma aproximação, s′, do polígono s da base de dados S, paraser enviada para Rsite;

2. Em Rsite, se o polígono r, que pertence a base de dados R, e s′ apresentaremintersecção, então, envia-se r para Ssite; caso contrário, o algoritmo retorna vazio.

3. Em Ssite, é executado o algoritmo de intersecção entre os dois polígonos s e r.Caso apresentem intersecção, são retornados como um dos pares de resultados daconsulta.

O passo 1 do algoritmo envia a aproximação do polígono do objeto espacial deS, denominada s′, para Rsite. No passo 2, é realizada a junção entre s′ e o polígono r. A

3.2 DistJoin: Plataforma de Processamento Distribuído da Junção Espacial 25

aproximação têm menos pontos que a geometria real, o que minimiza o processamentoda computação geométrica entre s′ e r, já que o custo dos algoritmos espaciais sãoproporcionais ao número de pontos das geometrias envolvidas.

Como as aproximações possuem espaços mortos, elas filtram apenas os resulta-dos que não fazem parte da resposta. Por isso, é retornado o polígono r para Ssite, caso s′

e r apresentem intersecção. O algoritmo de intersecção é executado no passo 3 entre ospolígonos s e r para verificar se apresentam intersecção. Caso apresentem, os dois objetossão retornados como um dos pares de resultados da consulta.

A Semi-Junção Espacial apresenta um desafio: escolher qual das duas bases dedados envolvidas na junção espacial será R e qual será S. No passo 1 é transferida aaproximação do polígono do objeto espacial de S e no passo 2 é transferido o polígonode R como resposta. Por isso, para reduzir o tráfego na rede, a base de dados S seráaquela cuja geometria apresente maior número de pontos, já que é transferida apenas suaaproximação pela rede.

No exemplo da Figura 2.3 com o par (1, D), o polígono 1 contém mais pontosque D e, por isso, é enviada sua aproximação no passo 1 e retornado o polígono D comoresposta no passo 2. No passo 3 do algoritmo é realizada a junção final entre os doispolígonos 1 e D.

3.2 DistJoin: Plataforma de Processamento Distribuídoda Junção Espacial

Neste trabalho foi projetada e implementada uma plataforma de processamentoda junção espacial distribuída denominada DistJoin. Esta Seção apresenta a sua arquite-tura e os detalhes da implementação.

Foram criados diversos componentes na plataforma, como armazenamento, con-trole de concorrência, comunicação e gerência da distribuição dos dados. A criaçãodestes componentes tornou-se necessária para abstrair a complexidade de implementaçãodos algoritmos de operações espaciais, como a junção espacial distribuída. Além disso,estes componentes foram implementados de forma a melhorar o desempenho da junçãoespacial distribuída.

A Subseção 3.2.1 apresenta uma visão geral da arquitetura da plataforma, ASubseção 3.2.2 descreve o protocolo de comunicação utilizado entre os servidores docluster, A Subseção 3.2.3 apresenta os detalhes e desafios encontrados na implementaçãoda plataforma e a Subseção 3.2.4 apresenta as considerações finais.


3.2.1 Visão geral da Arquitetura

O interesse pela utilização de clusters de computadores para solução de pro-blemas computacionais complexos tem aumentado, principalmente, devido a seu custofinanceiro reduzido em relação à máquinas de alto desempenho. Por isso, é proposta nestetrabalho uma plataforma com arquitetura peer-to-peer escalável, denominada DistJoin,para o processamento distribuído da junção espacial em um cluster de computadores.

A Figura 3.2 apresenta a visão geral da arquitetura da plataforma DistJoin.Esta arquitetura é composta por duas camadas: Camada de Aplicações e Camada deArmazenamento e Processamento.

Figura 3.2: Arquitetura da Plataforma DistJoin

A Camada de Aplicações é composta pela API Cliente e Aplicações que utilizamo serviço. A API Cliente tem a função de abstrair os detalhes de conexão e comunicaçãocom as demais camadas e, com isso, facilitar a implementação das aplicações queutilizam a plataforma DistJoin para prover serviços de valor agregado ao usuário final.Basicamente, a API disponibiliza métodos para atualização e consultas nas bases de dadosespaciais, sem que cada aplicação tenha que lidar com detalhes da implementação dasoperações espaciais.

Devido à arquitetura peer-to-peer, as requisições de operações espaciais enviadaspelas aplicações podem ser processadas em qualquer servidor no cluster. Quando umaaplicação conecta-se a um servidor do cluster, aquele servidor torna-se o coordenadordaquela operação espacial em particular. A tarefa do coordenador é agir como um proxy

entre a aplicação e os servidores que serão requisitados na operação espacial.Na Camada de Armazenamento e Processamento estão os componentes de

armazenamento, controle de concorrência, comunicação, gerência da distribuição dosdados, além dos algoritmos de processamento da junção espacial distribuída. A plataformaDistJoin possui um conjunto de computadores independentes conectados em um cluster,onde todos os servidores deste cluster são peers. Ou seja, não existe um servidor master

ou um processo de gerenciamento centralizado que possa se tornar um ponto de falha


ou um gargalo no sistema. Em caso de falhas, os servidores com problemas podem sertrocados sem que o cluster fique inativo.

Cada objeto da base de dados é replicado em múltiplos servidores do cluster

para assegurar que o sistema apresente tolerância a falhas e confiabilidade. Além disso, asrequisições sobre um objeto podem ser balanceadas entre os servidores que apresentemalguma réplica do mesmo. O objeto é armazenado em um servidor no cluster e replicadoem n servidores, onde n é o número de réplicas do objeto no sistema. Todas as réplicassão igualmente importantes, ou seja, não existe uma réplica primária ou master.

Em operações de atualização das bases de dados, o coordenador responsável pelarequisição envia a operação para todos os servidores responsáveis por alguma réplica doobjeto ob j que será atualizado no sistema. Quando os servidores confirmarem a escrita deob j, é enviada para a Aplicação uma confirmação da operação. Em operações de consultanas bases de dados, o coordenador envia a requisição para o servidor que armazena umaréplica de ob j. Este servidor, então, fica responsável por executar a operação de consultasobre ob j.

Novas máquinas podem ser adicionadas sem que o cluster fique inativo ou sejaminterrompidos os serviços para a Camada de Aplicações. A adição de novas máquinasaumenta o throughput das operações de escrita e leitura.

A Camada de Armazenamento e Processamento possui uma memória cache,configurada em um arquivo de configuração, que guarda os objetos requisitados do discorígido ou de outros servidores. Esta cache é gerenciada utilizando um algoritmo LRU(Least Recently Used), que descarta os itens menos usados recentemente.

3.2.2 Protocolo de Comunicação

A plataforma DistJoin possui um protocolo de comunicação, baseado no proto-colo Gossip [12]. Os servidores trocam periodicamente informações com outros servi-dores que eles conhecem. Estas informações de estado carregam dados de monitoramentodas máquinas, como uso de CPU, memória, rede e disco. Quando um servidor inicia, eleentra em contato com alguns servidores semeadores para obter informações sobre todosos servidores no cluster.

Cada servidor troca mensagens de estado com até outros três servidores nocluster a cada segundo. Como os servidores trocam informações sobre si mesmos e sobreoutros dos quais eles receberam informações, então todos no cluster rapidamente recebeminformações sobre todos os servidores no cluster. Cada mensagem trocada pelo protocolopossui um número de versão associada. Usando este número de versão durante a troca demensagens, informações antigas são substituídas por informações mais recentes.


Através desta troca de informações de estado, é possível detectar pontos defalha no cluster e evitar que requisições sejam enviadas para servidores que estãoinacessíveis. Falhas em servidores podem ser provocadas por vários motivos, como falhasno hardware e na rede. Algumas falhas são temporárias e, por isso, podem resultarem uma remoção precoce do servidor do cluster. Por isso, os servidores continuam,periodicamente, contactando os servidores inativos para verificar se estes estão de volta ànormalidade.

Este protocolo também é responsável pela entrega de respostas ao cliente. Comoos resultados estão espalhados pelos servidores e o cliente não conhece a quantidadede resultados que serão retornados, foi implementada uma funcionalidade que indicaao cliente quais servidores estão processando a requisição. Os servidores enviam aocliente as respostas da consulta, caso existam, ou uma mensagem indicando o términodo processamento naquele servidor.

3.2.3 Detalhes da Implementação

A plataforma DistJoin foi implementada utilizando a linguagem Java. A escolhada linguagem foi baseada principalmente na existência de bibliotecas para manipulaçãode objetos espaciais de fácil utilização, além da maior quantidade de recursos nativos nalinguagem para se trabalhar com comunicação e paralelismo em sistemas distribuídos.

Na implementação, foram utilizadas as seguintes bibliotecas:

• Gossip: para troca de estado entre os servidores do cluster;• Zookeeper: Coordenador de sistemas distribuídos, utilizado pela ferramenta de

testes 1;• Geotools: Um conjunto de ferramentas e classes para processamento e visualização

de objetos espaciais 2;• JTS (Java Topology Suite): uma API, implementada totalmente em Java, completa,

consistente e robusta com algoritmos de manipulação de objetos espaciais 2D 3;

Cada servidor na plataforma possui uma fila local de mensagens para armazenarrequisições que chegam e não podem ser processadas no exato momento. Esta filaé processada por um pool de threads que coordena as threads do sistema e quaisrequisições da fila cada thread irá atender. Este pool de threads pode ser dimensionadoatravés de parâmetros, o que permite que o sistema explore o paralelismo oferecido porcomputadores multinúcleo ou multiprocessados.

1http://zookeeper.apache.org2http://www.geotools.org3http://www.vividsolutions.com/jts/

http://zookeeper.apache.org

http://www.geotools.org

http://www.vividsolutions.com/jts/


Todas as mensagens trocadas pelo sistema utilizam uma biblioteca RMI comocanal de comunicação. Este padrão é utilizado para enviar requisições de um cliente paraa plataforma e para troca de mensagens entre os servidores do cluster.

Um Sistema de Lock R/W distribuído, similar a [10], foi implementado naplataforma, para evitar inconsistência nas bases de dados armazenadas. Por isso, quandouma operação de leitura está sendo realizada em um determinado objeto, apenas opera-ções de leitura podem ser executadas ao mesmo tempo. Mas, quando uma operação deescrita está sendo realizada em um determinado objeto, nenhuma operação de escrita ouleitura pode processar sobre este objeto.

Uma aplicação de testes foi desenvolvida para automatizar a execução da bateriade experimentos. Esta aplicação de testes é responsável por iniciar os servidores, inseriras bases de dados, enviar as requisições de consultas e coletar os resultados e as métricasdos testes.

Esta aplicação de testes utiliza o Zookeeper para comunicar com as máquinas docluster. Por isso, cada máquina do cluster possui um cliente do Zookeeper para receberas requisições vindas da aplicação de testes.

Foi construído, na aplicação de testes, um módulo de envio e recebimento dearquivos. Este módulo é utilizado na inicialização dos servidores, onde são enviados, paratodas as máquinas que irão fazer parte dos experimentos, os arquivos necessários para queos servidores sejam iniciados de forma correta.

A aplicação de testes consegue identificar problemas nas operações espaciais, ereexecutar as operações caso necessário. Ao final de cada teste, limpa todo o ambiente deexecução e coleta os arquivos com os logs dos servidores.

3.2.4 Considerações Finais

A plataforma DistJoin foi implementada para processar operações espaciaisdistribuídas em um cluster de computadores com um enfoque na operação de junçãoespacial distribuída. A plataforma possui arquitetura peer-to-peer escalável, com altadisponibilidade e tolerante a falhas que permite processar a operação de junção espacialdistribuída de forma eficiente.

A DistJoin possui protocolos de comunicação, um sistema de armazenamentoe funções de manipulação de objetos espaciais que permitem facilmente a provisão denovos serviços de inteligência geográfica.

A utilização da arquitetura peer-to-peer resultou em uma complexidade maior deimplementação do Protocolo de Comunicação. Este protocolo ficou responsável, além datroca de mensagens, por identificar servidores inativos e rotear mensagens com destino


a estes servidores para outros, sem utilizar um servidor master para gerenciar estasoperações.

Devido a falta de um relógio global para sincronizar os eventos, a depuraçãodo código em busca de erros foi um grande desafio na construção da plataforma. Porisso, detectar possíveis pontos de dead lock e starvation demandaram intenso trabalho deexecução de experimentos e análise de logs coletados nos servidores do cluster.

A aplicação de testes facilitou a execução dos experimentos, pois esta configura ocluster e coleta os resultados, métricas e os logs nos servidores. Para que não fosse precisopermanecer monitorando os testes, foi implementada uma funcionalidade para identificarproblemas nos testes e reexecutá-los caso fosse necessário. Esta funcionalidade gerou umgrande desafio: identificar qual tipo de erro estava ocorrendo no teste e reagir de formacorreta ao erro.

A plataforma DistJoin ainda apresenta algumas otimizações a serem implemen-tadas. O Sistema de Balanceamento de Carga das réplicas de um objeto espacial seráevoluído. Diante de informações de estado de todos os servidores, o algoritmo irá esco-lher o servidor com menor carga para processar uma operação sobre um objeto. Destaforma, o cluster teria seus recursos melhor aproveitados e diminuiria a probabilidade desobrecarregar um servidor.

O Sistema de Lock também será evoluído para que operações de escrita e leiturapossam processar ao mesmo tempo. Para tal, estão sendo estudados alguns algoritmosde controle de concorrência utilizados em bancos de dados como PostgreSql e Oracle.Esta evolução no Sistema de Lock irá afetar diretamente o desempenho de aplicações quetrabalham com bases de dados dinâmicas.

Para processar a junção espacial distribuída de forma eficiente, são propostasneste trabalho duas técnicas de distribuição de dados para bases de dados dinâmicas:Proximity Area e Grid Proximity Area. Estas técnicas serão apresentadas no Capítulo 4.

CAPÍTULO 4Distribuição de Dados com Bases de DadosDinâmicas

A distribuição de dados pelas máquinas do cluster é o fator que mais influenciano paralelismo em um ambiente clusterizado [29] e tem como objetivo permitir que ajunção espacial seja executada de forma paralela e distribuída.

Conforme a taxonomia definida em [1], os objetos das bases de dados são inseri-dos e distribuídos pelo cluster, na plataforma DistJoin, com as seguintes características:

• Unidade de alocação: elemento – cada objeto da base de dados é alocado indivi-dualmente em uma máquina;• Política de distribuição: clustering e balanceada – aloca objetos espacialmente

próximos na mesma máquina (clustering), além de manter o balanceamento dosdados entre as máquinas do cluster.• Frequência de alocação: dinâmica – decisões sobre em qual máquina inserir um

novo objeto são realizadas dinamicamente sem que seja necessária a redistribuiçãode todos os objetos.

Os trabalhos encontrados na literatura têm explorado técnicas de distribuição embases de dados estáticas (frequência de alocação estática), onde os objetos são distribuídosnovamente pelo cluster a cada atualização da base de dados. Isto é inviável para bases dedados dinâmicas, que sofrem constantes atualizações. Este trabalho apresenta dois novosalgoritmos de distribuição apropriados para bases de dados dinâmicas: Proximity Area eGrid Proximity Area.

Estes dois algoritmos buscam atender aos dois requisitos principais de dis-tribuição de dados: a) os dados devem ser distribuídos de forma balanceada pelasmáquinas do cluster; b) uma máquina deve possuir a maior parte dos dados que pre-cisa para processar uma operação localmente (Princípio da Localidade), ou seja, não énecessário obter dados de outra máquina.

A distribuição dos dados de forma balanceada pelo cluster permite que o pro-cessamento da junção espacial seja distribuído pelas máquinas. Desta forma, os recursos

4.1 Proximity Area 32

disponíveis no cluster não ficam ociosos. Já o Princípio da Localidade reduz o tráfegode dados na rede, já que cada máquina possui localmente a maior parte dos objetosnecessários para processar a junção espacial.

4.1 Proximity Area

Seguindo o princípio de processamento distribuído da junção espacial, onde asbases de dados são particionadas e distribuídas pelo cluster, o algoritmo Proximity Area

busca manter objetos de bases de dados diferentes espacialmente próximos na mesmamáquina (colocalizar) para reduzir o tráfego de dados na rede. Para que os dados fiquemdistribuídos de forma balanceada, foi criado um fator de balanceamento k - entre 0 e 1 -que limita a diferença no número de objetos entre os servidores.

O Algoritmo 4.1 apresenta a descrição da técnica Proximity Area. Este algoritmotem como objetivo escolher o servidor S no qual o novo objeto ob j será alocado e recebetrês parâmetros: a) ob j objeto a ser inserido, b) fator de balanceamento k e c) lista quecontém as informações dos servidores do cluster. Cada elemento I em lista possui comoatributos: a referência para o servidor S correspondente a I, o número de objetos em S e oMBR que representa a área espacial que delimita todos os objetos das diferentes bases dedados alocados em S.

O Algoritmo 4.1 realiza um primeiro laço entre as linhas 2 e 9 que verifica seexiste algum servidor que não tenha nenhum objeto alocado. Caso exista, o algoritmoarmazena o objeto ob j neste servidor e retorna. Caso não exista nenhum servidor vazio,ao final do laço, a variável min guardará o número de objetos do servidor com menorquantidade de dados alocados.

No segundo laço, na linha 13, é verificado se o servidor S analisado no laço,contém um número de objetos que obedece ao fator de balanceamento k. Para isso, adivisão entre min e o número de objetos I.numOb jetos em S deve ser maior que k. Se, porexemplo, min = 1, k = 0,5 e I.numOb jetos = 2, então (min/I.numOb jetos) = 0,5 nãoé maior que k e, neste caso, devemos descartar este servidor na alocação de ob j. Entreos servidores que obedecerem ao fator de balanceamento, é escolhido aquele cujo MBRapresente menor aumento de área para alocar ob j. Desta forma, ob j é inserido no servidorque contém objetos em uma área próxima a ob j.

4.1 Proximity Area 33

Algoritmo 4.1: ProximityArea(ob j,k, lista)

Entrada: ob j objeto a ser inserido, k fator de balanceamento, lista informações de

distribuição dos servidores do cluster

1 min← inteiro máximo

2 para cada elemento I em lista faça3 se I.numOb jetos = 0 então4 armazena_original_objeto(ob j, I.re f erenciaServidor)

5 retorna

6 fim7 se I.numOb jetos < min então8 min← I.numOb jetos

9 fim

10 fim11 minArea← número de ponto flutuante máximo

12 re f erenciaServidor← null

13 para cada elemento I em lista faça14 se (min/I.numOb jetos)> k então15 area← aumento de área de I.MBR para inserir ob j

16 se area < minArea então17 minArea← area

18 re f erenciaServidor← I.re f erenciaServidor

19 fim

20 fim21

22 fim23 armazena_original_objeto(ob j, re f erenciaServidor)

24 retorna

Objetos espaciais têm características de distribuição não uniforme e, como nãoé possível controlar a ordem com que os objetos espaciais de uma base de dados sãoinseridos, as técnicas de distribuição para bases de dados dinâmicas não conseguemsempre alocar estes objetos da melhor forma possível [49]. A técnica Proximity Area

também apresenta este comportamento, como pode ser visto na Figura 4.1, na inserção deum novo objeto (pentágono) com k = 0,5. O objeto deveria ser alocado no Servidor 1, quepossui área espacial mais próxima do pentágono. Mas, como min= 1 e o Servidor 1 possui2 objetos, então o número de objetos no Servidor 1 não obedece o fator de balanceamento.Com isto, o objeto será alocado no Servidor 2 que obedece o fator de balanceamento eestá mais próximo espacialmente do objeto que o Servidor 3.

Assim, observando a Figura 4.1(b), percebe-se que a área do Servidor 2 contém

4.2 Grid Proximity Area 34

objetos que não estão colocalizados e, isto gera um aumento no número de mensagensna rede na operação de junção espacial distribuída. Isto impacta diretamente na eficiênciade processamento e escalabilidade da operação de junção espacial distribuída, em casosonde o tráfego de dados na rede é muito alto. Este problema será mitigado em trabalhosfuturos.

(a) Antes da inserção (b) Depois da inserção

Figura 4.1: Inserção de um objeto utilizando a técnica ProximityArea com k = 0,5

4.2 Grid Proximity Area

O algoritmo Grid Proximity Area busca manter os objetos de bases de dadosdiferentes, mas espacialmente próximos na mesma máquina utilizando uma grid espacial.Esta grid é formada a partir da divisão do espaço do mundo, como apresentado na Figura4.2. Cada quadrado na grid é denominado tile e cada tile é associado a uma máquina docluster.

O algoritmo Grid Proximity Area tem ideia similar a [34], mas [34] propõe umatécnica de distribuição de dados estática, onde o espaço universal deve ser previamenteconhecido. O nosso algoritmo é dinâmico e utiliza o mundo como espaço universal. Alémdisso, o algoritmo Grid Proximity Area utiliza a grid apenas para distribuição dos dados,ao contrário de [34], que não indexa as bases de dados e utiliza a grid para processar ajunção espacial. O algoritmo Grid Proximity Area tenta manter os objetos balanceadospelo cluster, ao contrário de [34] que só tenta manter os objetos colocalizados.

Quando um novo objeto ob j é inserido na base de dados, verifica-se quais tiles

apresentam intersecção com ob j e este é inserido nas máquinas associadas a cada tile. Seum tile escolhido não estiver associado a nenhuma máquina, é escolhida aquela máquinacom menor número de objetos armazenados para que o cluster fique o mais balanceadopossível.

Dado que um objeto ob j da base de dados pode intersectar com vários tiles,este objeto pode ser replicado em vários servidores, aumentando, assim, o custo de


Figura 4.2: Divisão do espaço do mundo em uma Grid

armazenamento das bases de dados. Mas, como o custo de armazenamento está cada vezmais barato, o ganho na redução de tráfego de dados na rede e, consequente, reduçãono custo do processamento da junção, compensam o investimento e justificam estaabordagem.

Para casos onde o custo de armazenamento é um problema, é proposta uma va-riação do algoritmo Grid Proximity Area, onde o objeto ob j é inserido no servidor as-sociado ao tile com maior área de intersecção com ob j. Caso mais do que um servidortenha a maior área de intersecçao com ob j, é escolhido o servidor com menor número deobjetos armazenados. Nos outros servidores associados aos tiles que apresentarem inter-secção, será armazenada uma sombra (shadow) de ob j, ou seja, apenas uma aproximaçãoda geometria de ob j.

A Figura 4.3 apresenta um exemplo de intersecção da área do novo objeto ob j

com os tiles e o mapeamento dos respectivos tiles com os servidores. O objeto ob j

apresenta intersecção com quatro tiles, sendo que um destes não está mapeado a nenhumservidor (tile em branco). Neste caso, o tile em branco é associado a um servidor.

Se o algoritmo for do tipo Shadow, então ob j é inserido no servidor 1, pois ob j

apresenta maior área de intersecção com o tile associado a este servidor. Nos demaisservidores associados a algum tile que intersectam com ob j, será armazenada somente asombra de ob j. Quando o tipo de algoritmo é Clone, então, armazena-se uma cópia doobjeto em cada servidor associado a um tile que apresenta intersecção com ob j.

Se um servidor for responsável por mais de um tile que intersectar com ob j, entãoob j será associado a todos os tiles, mas será armazenado uma única vez em cada servidor.Na Figura 4.3, por exemplo, o servidor 2 é responsável por dois tiles que intersectam comob j, mas ob j será armazenado apenas uma vez no servidor 2.

Na junção espacial distribuída serão escolhidos para serem processados, prefe-


Figura 4.3: Mapeamento de um novo objeto na grid para os servi-dores.

rencialmente, os objetos r da base de dados R e s da base de dados S que estiverem nomesmo tile. Os pares de objetos que apresentarem intersecção, terão pelo menos um tileem comum. Por isso, no algoritmo do tipo Clone, não haverá transferência de objetosna rede na etapa de refinamento da junção, já que os objetos são replicados em todos osservidores responsáveis pelos tiles que apresentam intersecção com os objetos espaciais.

No algoritmo do tipo Shadow, nem sempre os objetos originais estarão ar-mazenados no mesmo servidor. O exemplo da Figura 4.4(a), apresenta a intersecção entredois objetos espaciais 1 e D armazenados no mesmo servidor. Estes dois objetos apre-sentam cópias armazenadas no servidor 2, já que os tiles correspondentes ao servidor 2apresentam maior área de intersecção com os objetos.

Nos casos em que os objetos estão armazenados em servidores diferentes, seráescolhido o tile t que está associado ao objeto original de r e que tenha a aproximaçãos′ de s. Neste caso, será realizado um filtro espacial entre r e s′ e, caso intersectem, serábuscado o objeto s no servidor onde ele está armazenado, para realizar a junção final entrer e s.

A Figura 4.4(b) apresenta um exemplo de intersecção entre os objetos espaciais1 e D, os quais estão armazenados nos servidores 3 e 1, respectivamente. Neste caso, étransferida a aproximação de 1 para o servidor 1 e realizada a operação de intersecçãoentre esta aproximação e o polígono do objeto espacial D. O algoritmo, então, retorna opolígono D para o servidor 3 que realiza a intersecção entre os objetos espaciais 1 e D

para produzir o resultado final.

(a) Junção entre dois objetos com cópias ar-mazenadas no mesmo servidor

(b) Junção entre dois objetos com cópiasarmazenadas em servidores diferentes

Figura 4.4: Visão da grid na junção espacial entre dois objetosespaciais 1 e D


Como não são utilizadas as áreas dos servidores para escolha de qual máquina iráo novo objeto, a ordem de inserção dos elementos na base de dados tem menos influênciana qualidade da distribuição do que a técnica Proximity Area. Por outro lado, o quepode influenciar na qualidade de inserção é a aglomeração de muitos itens em poucostiles, podendo assim concentrar mais itens em uma única máquina. Isto pode prejudicara paralelização do processamento da junção espacial distribuída em várias máquinas, jáque o processamento pode ser concentrado em um pequeno conjunto de máquinas. Esteproblema será resolvido em trabalhos futuros.

O Algoritmo 4.2 apresenta a descrição da técnica Grid Proximity Area. Estealgoritmo tem como objetivo escolher o servidor S no qual o novo objeto ob j será alocadoe recebe três parâmetros: a) ob j objeto a ser inserido, b) lista que contém as informaçõesdos servidores do cluster e c) tipo de estratégia (Clone ou Shadow). Cada elemento emlista possui como atributos a referência para o servidor S e o número de objetos em S.

Algoritmo 4.2: GridProximityArea(ob j, lista, tipo)

Entrada: ob j objeto a ser inserido, lista informações de distribuição dos servidores do

cluster, tipo Clone ou Shadow

1 tiles← consulta_tiles(ob j.MBR)

2 t← Tile com maior área de intersecção com ob j.MBR

3 servidor← Servidor responsável pelo tile t

4 se servidor = null então5 servidor = atribuir_tile_servidor(t, lista)

6 fim7 armazena_clone_objeto(ob j, servidor)

8 Remove o tile t da lista de tiles

9 para cada elemento t em tiles faça10 servidor← Servidor responsável pelo tile t

11 se servidor = null então12 servidor = atribuir_tile_servidor(t, lista)

13 fim14 se tipo = Shadow então15 armazena_shadow_objeto(ob j, servidor)

16 senão17 armazena_clone_objeto(ob j, servidor)

18 fim

19 fim20 retorna;

O Algoritmo 4.2 realiza uma consulta, na linha 1, com a chamada do métodoconsulta_tiles, pelos tiles que apresentam intersecção com o MBR de ob j. O algoritmo


escolhe na linha 2 o tile t que apresenta maior área de intersecção com o MBR de ob j paraassociar a ob j. Na linha 3, é escolhido o servidor referente a t. Se não houver servidorassociado a t, o algoritmo escolhe, na linha 5, o servidor do cluster que tiver menosobjetos armazenados. Para isso, o método atribuir_tile_servidor utiliza as informaçõesem lista para decidir a respeito. Na linha 7, ob j é armazenado em servidor e o tile t éentão removido de tiles na linha 8, pois já foi associado a ob j.

O laço entre as linhas 9 e 19 atribui cada tile t restante em tiles ao servidorcorrespondente. Caso não encontre um servidor correspondente, o algoritmo atribui nalinha 12 um servidor ao tile t de forma semelhante à linha 5. Entre as linhas 14 e 18,armazena uma sombra de ob j no servidor de t se o algoritmo for do tipo Shadow e umacópia caso contrário.

Caso já tenha sido armazenada uma cópia ou sombra de ob j no servidor, o ob j

é apenas associado ao tile para ser utilizado como informação na consulta de junçãoespacial. Ou seja, ob j pode intersectar com vários tiles associados a um servidor, massó será armazenado uma vez neste servidor. Na junção espacial, ob j poderá ter váriostiles associados que apontam para o mesmo servidor.

4.3 Considerações Finais

A distribuição de dados é um dos principais fatores que afetam o desempenhode um banco de dados espacial em um ambiente distribuído [35]. Esta distribuição bemrealizada permite que sejam aproveitados os recursos computacionais disponíveis e que otráfego de dados na rede seja reduzido.

Os dois algoritmos propostos neste trabalho, Proximity Area e Grid Proximity

Area, tentam manter os objetos das bases de dados espaciais balanceados e colocalizadospelo cluster de computadores. Este balanceamento é realizado de forma dinâmica, ondedecisões de qual máquina inserir o novo objeto são realizadas sem que seja necessáriaa redistribuição dos dados. Os trabalhos encontrados na literatura exploram técnicas dedistribuição de forma estática para processar a junção espacial distribuída, onde a cadaatualização da base de dados os objetos são distribuídos novamente pelo cluster. Estaestratégia é inviável para bases de dados grandes ou que sofram constantes atualizações.

Para reduzir o tráfego de dados na rede na operação de junção espacial, os doisalgoritmos propostos visam manter objetos espacialmente próximos na mesma máquina.Desta forma, quando a operação de junção espacial precisar processar uma operação entredois objetos de bases de dados diferentes, estes provavelmente estarão armazenados namesma máquina, reduzindo o tráfego de rede. Isto maximiza o uso da CPU e aumenta aeficiência no processamento da operação de junção espacial distribuída.


A técnica Proximity Area utiliza um fator de balanceamento para limitar adiferença da quantidade de objetos entre os servidores, para que o processamento dajunção espacial distribuída possa ser paralelizado de forma eficiente no cluster. Como ditona Seção 4.1, em alguns casos a técnica não consegue alocar estes objetos da melhor formapossível devido as características dos objetos espaciais e a ordem de inserção dos mesmos.Isto pode resultar em uma distribuição, na qual os objetos não ficam colocalizados, o quegera um aumento no tráfego de dados na rede.

A técnica Grid Proximity Area divide o espaço do mundo em uma grid espaciale associa cada tile na grid a um servidor do cluster. Esta divisão do espaço em uma grid

minimiza problemas relacionados a colocalização e, consequentemente, reduz o tráfegode dados na rede na execução da junção espacial [34].

Apesar de manter os objetos colocalizados e tentar balanceá-los no cluster

de computadores, o algoritmo Grid Proximity Area pode aglomerar vários objetos emum servidor. Isto pode gerar na operação de junção espacial, uma concentração deprocessamento em um pequeno conjunto de servidores e comprometer a escalabilidadedo sistema.

Para junções espaciais distribuídas, onde o tráfego de dados na rede é dominantesobre o processamento, a técnica de distribuição Grid Proximity Area é indicada, poisconsegue colocalizar os objetos de forma satisfatória. Para casos onde o processamentoé dominante sobre o tráfego de dados na rede, a técnica de distribuição Proximity

Area é indicada, pois consegue alocar os objetos de forma uniforme no cluster e,consequentemente, paralelizar de forma eficiente o processamento da junção espacialdistribuída.

CAPÍTULO 5Avaliação de Desempenho

Este capítulo apresenta os testes de desempenho executados na plataformaDistJoin com as técnicas de distribuição de dados Grid Proximity Area e Proximity Area.Os testes tiveram como objetivo avaliar a junção espacial distribuída diante dos seguintesaspectos:

• Capacidade de escalar horizontalmente à medida que mais estações de trabalho sãoadicionadas ao sistema;• Quantidade de tráfego de dados na rede;• Capacidade de aproveitar os recursos computacionais disponíveis;• Cenários de aplicação para cada técnica de distribuição de dados.

Para medir a eficiência da plataforma ao adicionar mais máquinas no cluster,foram realizados experimentos para medir a escalabilidade horizontal. A plataformadeve ser capaz de aproveitar os novos recursos computacionais adicionados de forma amelhorar o desempenho do sistema. O ideal é que o sistema tenha uma escalabilidadehorizontal linear, o que nem sempre é possível devido à necessidade de sincronizaçãode tarefas distribuídas no cluster e à limitação física de dispositivos como a rede decomunicação [10].

As técnicas de distribuição de dados Grid Proximity Area e Proximity Area foramavaliadas para medir seu impacto na operação de junção espacial distribuída. Por isso,essas técnicas foram avaliadas em relação ao tempo de resposta, tráfego de dados na redee utilização dos recursos computacionais disponíveis.

O ambiente experimental é apresentado na Seção 5.1 com a descrição das basesde dados utilizadas no teste, a descrição dos testes de junção espacial e a metodologiados testes. A Seção 5.2 apresenta a avaliação das técnicas de distribuição de dados Grid

Proximity Area e Proximity Area. Na Seção 5.3 são apresentadas as reflexões relativas aosexperimentos realizados.

5.1 Ambiente Experimental 41

5.1 Ambiente Experimental

Foram utilizadas bases de dados geográficas disponibilizadas pelo LAPIG/UFG(Laboratório de Processamento de Imagens e Geoprocessamento)1, que permitiramavaliar a plataforma DistJoin em um cluster de computadores com dados geográficosreais. Para estudar o impacto das peculiaridades de cada base de dados no desempenhoda plataforma, foram avaliadas bases de dados com características diferentes em relaçãoa: a) Tipo de geometria; b) Número de itens; e c) Tamanho em disco. As bases de dadosutilizadas estão descritas na Tabela 5.1.

Tabela 5.1: Descrição das bases de dados

Base de Dados Geometria Número de itens Tamanho(MB)Desmatamento do Cerrado Polígono 32578 11,2

Bioma do Cerrado Polígono 151986 411,3Bioma da Caatinga Polígono 10994 275,3

Hidrografia Linha 226963 64,5Rodovias Linha 51645 15,2

Localidades Ponto 21840 1,4

Para avaliar o desempenho da plataforma na execução da junção espacial dis-tribuída, foram realizadas as seguintes junções: a) Bioma do Cerrado e Desmatamento doCerrado, que retorna 60798 resultados; b) Bioma da Caatinga e Localidades, que retorna3934 resultados; c) Rodovias e Hidrografia, que retorna 55764 resultados. Essa combi-nação de experimentos permite avaliar a junção espacial utilizando bases de dados comcaracterísticas diferentes, conforme pode ser observado na Tabela 5.1.

Em [32] é apresentada uma reflexão das técnicas de distribuição de dados parabases dinâmicas, onde a técnica Proximity Area apresentou melhor desempenho que atécnica proposta em [10]. A técnica Proximity Area foi testada em [32] com três fatoresde balanceamento: 0.1, 0.5 e 0.9. Dentre estes três fatores de balanceamento, 0.9 teveo melhor desempenho, pois conseguiu reduzir o tráfego de dados na rede e paralelizarde forma eficiente a consulta de junção espacial distribuída. Por isso, a técnica Grid

Proximity Area foi comparada com a técnica Proximity Area utilizando um fator debalanceamento 0.9.

A técnica Grid Proximity Area foi testada a partir da divisão do espaço universaldo mundo em uma grid com 160000 tiles. Esse valor do número de tiles foi definidoutilizando como referência o estudo apresentado em [34].

O ambiente de execução dos testes foi configurado da seguinte forma:

• Servidores com 8 GB RAM, 8 VCPU de 2.5 Ghz (64-bit) e 50 GB de armazena-mento

1www.lapig.iesa.ufg.br

5.2 Avaliação da Junção Espacial Distribuída com as técnicas de distribuição de dados: Grid ProximityArea e Proximity Area 42

• Clientes com 2 GB RAM, 2 VCPU de 2.5 Ghz (64-bit) e 10 GB de armazenamento• Rede de 10Gps.

Foi utilizada a máquina virtual Java 1.6. Na máquina com o Cliente daplataforma, o tamanho da heap da máquina virtual Java foi configurado com 1 GB. Nasmáquinas com Servidores, o tamanho da heap foi configurado com 3 GB e o tamanho dacache em 4 GB. O restante ficou disponível para o sistema operacional.

A junção espacial distribuída foi avaliada em configurações do cluster com 1, 2,4 e 8 servidores. Os relógios das máquinas foram sincronizados para que o protocolo decomunicação da plataforma DistJoin funcione corretamente. Foram executadas 5 junçõesespaciais em cada teste, onde foram descartados o menor e o maior tempo e realizada umamédia aritmética dos três restantes.

O cliente ficou responsável por enviar os dados para inserção nas bases de dados,além de enviar as consultas de junção espacial e coletar o tempo de resposta e as métricasreferentes ao teste. Além disso, foi utilizada uma ferramenta de apoio aos testes queconfigura o ambiente, de forma automática, para a realização dos experimentos.

5.2 Avaliação da Junção Espacial Distribuída com as téc-nicas de distribuição de dados: Grid Proximity Area eProximity Area

Para avaliar as técnicas de distribuição de dados, foram realizados testes dejunção espacial entre todos os objetos das bases de dados envolvidas na operação. Atécnica Grid Proximity Area foi avaliada com as estratégias CLONE e SHADOW, onde agrid do mundo foi dividida em 16000 tiles e cada tile tinha área aproximada de 400 m2.Por isso, nos gráficos, a estratégia CLONE é denominada Grid400_clone e a estratégiaSHADOW é denominada Grid400_shadow. A técnica Proximity Area foi configuradacom fator de balanceamento 0.9 e, por isso, é denominada nos gráficos de PA09.

Uma máquina do cluster ficou responsável por armazenar os índices espaciaisR-Tree e, consequentemente, processar a junção espacial na etapa de filtragem. Osexperimentos mostraram que a etapa de filtragem teve grande demanda de uso de CPU, oque gerou uma concentração do processamento em uma máquina e não permitiu que fossegerada uma vazão satisfatória de tarefas para o processamento da etapa de refinamento.

Como dito na Seção 2.2, essa alta demanda de processamento da etapa defiltragem pode acontecer devido ao espaço morto e áreas de sobreposição na R-Tree quegeram uma grande quantidade de comparações. Estes problemas são inerentes a R-Tree esuas variantes, como a R*-Tree utilizada neste trabalho. Este problema será resolvido emtrabalhos futuros.


5.2.1 Junção espacial entre as Bases de dados Bioma do Cerrado eDesmatamento do Cerrado

A junção espacial entre Bioma do Cerrado (Figura 5.1(a)) e Desmatamento doCerrado (Figura 5.1(b)) envolve duas bases de dados com polígonos complexos (comgrande quantidade de pontos). A Figura 5.1 apresenta a visão territorial da junção entreas duas bases de dados.

(a) Base de dados Bioma do Cer-rado

(b) Base de dados Desmatamentodo Cerrado

(c) Junção espacial entre asBases de dados Bioma doCerrado e Desmatamento doCerrado

Figura 5.1: Visão territorial da Junção Espacial entre as Basesde Dados: Bioma do Cerrado e Desmatamento doCerrado.

A complexidade dos algoritmos de processamento de intersecção entre as geo-metrias é diretamente proporcional ao número de pontos das geometrias envolvidas naintersecção [22]. Como as bases de dados de Bioma do Cerrado e Desmatamento doCerrado contém polígonos complexos, esta junção apresentou considerável demanda deprocessamento na etapa de refinamento. O tráfego de dados na rede também é diretamente


proporcional ao número de pontos das geometrias envolvidas na intersecção [22] e, porisso, o tráfego de dados na rede na etapa de refinamento da junção também foi alto.

A Figura 5.2 apresenta o gráfico com os tempos de respostas das junçõesespaciais entre as bases de dados Bioma do Cerrado e Desmatamento do Cerrado. Deforma geral, a junção espacial distribuída com todas as técnicas de distribuição apresentouescalabilidade devido a grande demanda de processamento necessário para processar estajunção.

Figura 5.2: Tempo de Resposta da Junção Espacial entre as Basesde Dados: Bioma do Cerrado e Desmatamento doCerrado

A técnica de distribuição Grid Proximity Area teve desempenho melhor queProximity Area, pois gerou menos tráfego de dados na rede, como pode ser visto na Figura5.3. Utilizando a técnica Grid Proximity Area, a estratégia CLONE gerou menos tráfegona rede que a estratégia SHADOW, já que a estratégia CLONE consegue manter os objetosmais co-localizados.

A técnica Proximity Area gera mais tráfego de dados na rede na junção espacialque a técnica Grid Proximity Area, mas distribui melhor o processamento no cluster, comopode ser visto na Figura 5.4. Isto porque não concentra grande quantidade de objetos nomesmo servidor, devido ao fator de balanceamento que limita a diferença do número deitens armazenados em cada máquina.

No algoritmo Grid Proximity Area, uma grande quantidade de objetos são associ-ados ao mesmo tile. Isto causa uma grande concentração de objetos em poucos servidores.Desta forma, estes servidores acabam concentrando a maior parte do processamento naetapa de refinamento da junção espacial.

Na Figura 5.5 é apresentado o uso de CPU com 8 máquinas, onde pode-sepereceber que a média do uso de CPU foi praticamente o mesmo em todas as técnicasde distribuição. A etapa de filtragem não gerou uma vazão de tarefas que permita que


Figura 5.3: Tráfego de rede na Junção Espacial entre as Bases deDados Bioma do Cerrado e Desmatamento do Cer-rado com 8 máquinas.

Figura 5.4: Número de intersecções realizadas em cada servi-dor na Junção Espacial entre as Bases de DadosBioma do Cerrado e Desmatamento do Cerrado com 8máquinas.

a etapa de refinamento aproveite os recursos computacionais disponíveis e, assim, osrecursos computacionais ficaram subutilizados. Por isso, as técnicas não aproveitarama distribuição de processamento entre as máquinas do cluster.

É necessário otimizar a etapa de filtragem para que os servidores responsáveispor armazenarem os índices espaciais não sejam o gargalo do sistema. Esta otimizaçãoirá reduzir a subutilização dos recursos computacionais dos servidores responsáveis porprocessarem a etapa de refinamento, pois a vazão na etapa de filtragem será maior.

Em geral, com a técnica Grid Proximity Area houve menor tráfego de dadosna rede na junção espacial distribuída. Com a técnica Proximity Area, o processamento


Figura 5.5: Média do uso da CPU na Junção Espacial entre asBases de Dados Bioma do Cerrado e Desmatamentodo Cerrado com 8 máquinas.

foi melhor distribuído entre as máquinas do cluster. A técnica Grid Proximity Area tevedesempenho melhor que Proximity Area, já que o tráfego de dados na rede foi dominantena etapa de refinamento.

Na técnica Grid Proximity Area, a estratégia CLONE teve desempenho melhorque SHADOW em relação a tempo de resposta, tráfego de dados na rede e utilização dosrecursos computacionais. Por isso, a estratégia CLONE é uma boa escolha para este tipode junção espacial que envolve bases de dados com geometrias complexas.

5.2.2 Junção espacial entre as Bases de dados Bioma da Caatinga eLocalidades

A junção espacial entre Bioma da Caatinga (Figura 5.6(a)) e Localidades (Figura5.6(b)) envolve duas bases de dados com geometrias de polígonos e pontos, respectiva-mente. A Figura 5.6 apresenta a visão territorial da junção espacial entre as duas bases dedados.

Esta junção espacial trafega na rede apenas a base de dados de Localidade, poisutiliza a técnica de Semi-Junção Espacial apresentada na Seção 3.1. Por isso, o tráfego dedados na rede é muito baixo, já que a base de dados de Localidade é composta por pontos,que são geometrias com necessidade de poucos bytes para representá-las.

Como o tráfego de dados na rede é baixo e a base de dados de Bioma da Caatingapossui geometrias complexas, nessa junção o processamento é dominante sobre o tráfegode dados na rede, já que os algoritmos de geometria computacional devem analisar estasgeometrias complexas com os objetos da base de dados de Localidades.


(a) Base de dados Bioma daCaatinga

(b) Base de dados Localidades

(c) Junção espacial entre as Bases de dados Bioma da Caatingae Localidades

Figura 5.6: Visão territorial da Junção Espacial entre as Bases deDados: Bioma da Caatinga e Localidades.

A junção espacial teve um desempenho melhor com a adição de máquinas, comopode ser observado na Figura 5.7. A técnica Proximity Area teve um desempenho melhorque a técnica Grid Proximity Area, já que consegue paralelizar o processamento de formauniforme entre as máquinas do cluster.

A estratégia SHADOW da técnica Grid Proximity Area utiliza uma aproximaçãoda geometria mais acurada que o MBR para filtrar resultados que não atendem asrestrições da consulta. Por isso, em alguns casos o processamento é minimizado coma utilização desta estratégia.

A Figura 5.8(a) apresenta a distribuição de processamento na etapa de refina-


Figura 5.7: Tempo de Resposta da Junção Espacial entre as Basesde Dados: Bioma da Caatinga e Localidades

mento com 4 máquinas, onde é possível perceber que a estratégia SHADOW conseguiuparalelizar o processamento melhor que a técnica Proximity Area. Por isso, o tempo deresposta com a estratégia SHADOW também foi melhor. Com 8 máquinas, a técnica Pro-

ximity Area teve um desempenho melhor, pois conseguiu paralelizar melhor o processa-mento que a técnica Grid Proximity Area (Figura 5.8(b)).

(a) Distribuição do processamentona etapa de refinamento com 4máquinas

(b) Distribuição do processamentona etapa de refinamento com 8máquinas

Figura 5.8: Distribuição do processamento na Junção Espacialentre as Bases de Dados Bioma da Caatinga e Locali-dades.

A Figura 5.9 apresenta o tráfego de dados na rede com 8 máquinas, onde percebe-se que o tráfego foi baixo e semelhante entre as técnicas. Como a junção espacial entre asBases de Dados Bioma da Caatinga e Localidades apresentou pouco tráfego de dados narede, o processamento foi dominante na etapa de refinamento.

De uma forma geral, houve uma concentração do processamento da etapa de re-finamento em poucas máquinas com a técnica Grid Proximity Area. Este comportamentoocorreu em função da concentração de objetos nessas máquinas do cluster e comprome-


Figura 5.9: Tráfego de dados na rede na Junção Espacial entreas Bases de Dados Bioma da Caatinga e Localidadescom 8 máquinas

teu o desempenho do sistema, pois o tempo de resposta foi dominado por um pequenoconjunto de servidores, enquanto os demais ficaram ociosos. Este problema de balancea-mento de objetos geográficos inseridos no cluster será investigado em trabalhos futuros.

Como o tráfego de dados na rede foi baixo neste junção, o processamento foidominante e a técnica Proximity Area teve o melhor desempenho, já que conseguiudistribuir melhor o processamento da etapa de refinamento entre as máquinas do cluster.Por isso, para junções espaciais onde o tráfego de dados na rede é baixo, a técnicaProximity Area é indicada.

5.2.3 Junção espacial entre as Bases de dados Rodovias e Hidrografia

A junção espacial entre Rodovias (Figura 5.10(a)) e Hidrografia (Figura 5.10(b))envolve duas bases de dados com geometrias de linhas. A Figura 5.10 apresenta a visãoterritorial da junção entre as duas bases de dados.

Como estas bases de dados ocupam a mesma área territorial e existe uma grandequantidade de falsos positivos, a etapa de filtragem analisou uma grande quantidade depares de candidatos que não fizeram parte do resultado final da consulta. Consequente-mente, a etapa de filtragem exigiu grande demanda de processamento na junção espaciale a adição de máquinas não reduziu de forma significativa o tempo de resposta da junçãoespacial.

Como pode ser visto na Figura 5.11, o tempo de resposta com a técnica Proximity

Area foi melhor que a técnica Grid Proximity Area. A plataforma não apresentou aescalabilidade desejável, já que a etapa de filtragem não conseguiu dar vazão suficientepara que os recursos computacionais fossem melhor aproveitados na etapa de refinamento.


(a) Base de dados Rodovias (b) Base de dados Hidrografia

(c) Junção espacial entre asBases de dados Rodovias eHidrografia

Figura 5.10: Visão territorial da Junção Espacial entre as Basesde Dados: Rodovias e Hidrografia.

Figura 5.11: Tempo de Resposta da Junção Espacial entre asBases de Dados: Rodovias e Hidrografia

A Figura 5.12 apresenta o quanto o índice espacial filtrou o conjunto de can-didatos analisados nas folhas. A Figura 5.12(a) mostra que foram analisados aproxi-madamente 80 milhões de pares de candidatos em cada servidor. No entanto, conformeilustrado na Figura 5.12(b), aproximadamente 45 mil pares de candidatos satisfizeram as


restrições espaciais da consulta em cada servidor e foram analisados na etapa de refina-mento com as geometrias reais dos objetos.

(a) Quantidade de pares de candidatosanalisados nas folhas

(b) Quantidade de pares de candidatosque satisfazem as condições espa-ciais da consulta

Figura 5.12: Pares de candidatos filtrados nas folhas na JunçãoEspacial entre as Rodovias e Hidrografia.

Assim, como na Figura 5.13, a técnica Proximity Area conseguiu paralelizar oprocessamento da etapa de refinamento de forma satisfatória. Na técnica Grid Proximity

Area, o processamento ficou centralizado em um pequeno conjunto de máquinas e, porisso, a técnica Proximity Area teve o melhor desempenho na média.

Figura 5.13: Distribuição do processamento na etapa de refina-mento na Junção Espacial entre as Bases de DadosRodovias e Hidrografia.

O uso de CPU em todas as técnicas foi baixo, já que a etapa de filtragemnão conseguiu dar a vazão necessária para que a etapa de refinamento pudesse utilizartodos os recursos computacionais disponíveis. De fato, a etapa de filtragem foi um fatorlimitante na escalabilidade do sistema nesta junção que envolve duas bases de dados comgeometrias de linhas e que ocupam a mesma área territorial.


Figura 5.14: Uso de CPU na Junção Espacial entre as Bases deDados Rodovias e Hidrografia.


Este Capítulo apresentou a avaliação da junção espacial distribuída utilizando asduas técnicas de distribuição de dados para bases de dados dinâmicas propostas: Proximity

Area e Grid Proximity Area.O algoritmo de junção espacial distribuída foi implementado neste trabalho em

duas etapas: filtragem e refinamento. A etapa de filtragem é processada nos índicesespaciais e a etapa de refinamento é executada relacionando as geometrias dos objetosespaciais.

A plataforma apresentou escalabilidade enquanto houve demanda de processa-mento para a etapa de refinamento. As técnicas de distribuição de dados têm efeito apenassobre esta etapa, pois visam distribuir os objetos espaciais pelo cluster. Portanto, tiveramimpacto positivo na junção espacial distribuída.

A técnica de distribuição de dados proposta em [10] foi a única encontrada naliteratura que pudesse ser utilizada como parâmetro de comparação no processamentoda junção espacial distribuída com bases de dados dinâmicas. Segundo experimentosrealizados em [32], a técnica Proximity Area teve melhor desempenho do que a técnicaproposta em [10].

Diante do cenário atual em relação às abordagens de distribuição de dados, astécnicas propostas neste trabalho conseguiram, de forma eficiente, reduzir o tráfego dedados na rede, aproveitar os recursos computacionais do cluster e, consequentemente,reduzir o tempo de execução da junção espacial distribuída com bases de dados dinâmicas.

Na execução da etapa de refinamento da junção espacial, a técnica de distribuiçãode dados Grid Proximity Area conseguiu reduzir o tráfego de dados na rede se comparadocom a técnica Proximity Area. Portanto, para cenários onde o tráfego de dados na rede é


alto, a técnica Grid Proximity Area é recomendada.Com a técnica Proximity Area os recursos computacionais disponíveis foram

melhor aproveitados e o processamento da junção espacial foi distribuído entre os servi-dores do cluster. Por isso, para cenários onde o processamento é dominante, a técnicaProximity Area é recomendada.

O Apêndice A apresenta os gráficos com o uso de memória das junções espaciaiscom cada distribuição de dados. O uso de memória na linguagem de programação JAVAé muito importante, pois impacta diretamente no coletor de lixo. Quanto maior o usode memória, mais vezes o coletor de lixo é obrigado a processar para liberar memória.O processamento deste coletor de lixo impacta no desempenho final dos processosexecutados na linguagem JAVA.

Analisando os gráficos A.1, A.3 e A.2, apresentados no Apêndice A, é possíveldefinir que a técnica Proximity Area consumiu menos memória, no geral, para realizaro processamento da junção espacial. Por isso, para cenários onde a disponibilidade dememória for um problema ou o coletor de lixo estiver influenciando de forma significativano resultado da junção espacial, a técnica Proximity Area é indicada.

Foram detectados dois pontos de gargalo que comprometeram a escalabilidadedo sistema: 1) processamento do algoritmo de junção na etapa de filtragem; 2) centraliza-ção do processsamento da etapa de refinamento em alguns servidores do cluster.

Como dito na Seção 2.2, o alto consumo de processamento na etapa de filtragemacontece devido aos espaços mortos e áreas de sobreposição, resultantes da construçãoda R*-Tree, que geram uma grande quantidade de comparações de pares de candidatos.O alto processamento em alguns servidores do cluster pode ocorrer em função desituações excepcionais, tais como alta concentração de objetos numa região específica ouconcentração de objetos muito complexos (grande quantidade de pontos) numa mesmamáquina. Essas particularidades não foram tratadas nos algoritmos de distribuição dedados propostos. Já foram detectadas e projetadas as melhorias devidas para resolveresses problemas, mas não foi possível testá-las no escopo deste trabalho em função dacomplexidade e tempo disponível.

CAPÍTULO 6Trabalhos Correlatos

Este capítulo apresenta as propostas encontradas na literatura que discutemarquiteturas distribuídas de processamento de consultas espaciais. Foram identificadosnestes trabalhos, as ideias acerca de distribuição dos objetos das bases de dados em umcluster de computadores utilizando bases de dados dinâmicas.

A Seção 6.1 apresenta alguns trabalhos que discutem técnicas de Distribuição deDados em um cluster de computadores. A Seção 6.2 apresenta os trabalhos que processama junção espacial de forma paralela e distribuída, mas não discutem a distribuição dedados.

6.1 Distribuição de Dados

Nesta Seção é apresentado um grupo de trabalhos que utiliza técnicas de Dis-tribuição de Dados para otimizar o desempenho de operações espaciais em um cluster decomputadores. As técnicas de Distribuição de Dados são projetadas para bases de dados:i) estáticas: cada atualização nas bases de dados requer uma nova distribuição dos objetospelo cluster e ii) dinâmicas: as bases de dados são atualizadas sem que os objetos sejamredistribuídos.

O trabalho apresentado em [34] processa a junção espacial com uma grid emum ambiente distribuído. O algoritmo de distribuição proposto apresenta duas aborda-gens: clone e shadow. Nosso trabalho apresenta um algoritmo de distribuição de dadossemelhante ao apresentado em [34]. Entretanto, [34] propõe uma técnica de distribuiçãode dados estática, onde o espaço universal deve ser previamente conhecido, ou seja, deve-se conhecer previamente a dimensão territorial das bases de dados. Em bases de dadosdinâmicas, o espaço universal só é conhecido durante a inserção dos objetos. Por isso,este trabalho utiliza o mundo como espaço universal e realiza a divisão do espaço domundo em uma grid.

No nosso trabalho, os tiles não são previamente associados a cada servidor docluster como em [34], mas são definidos na inserção de novos objetos, levando em contao balanceamento dos objetos pelas máquinas do cluster. Além disso, a grid é utilizada

6.1 Distribuição de Dados 55

apenas para distribuição dos dados, sendo que a junção espacial é processada utilizandoo índice espacial R-Tree, ao contrário de [34], que não indexa as bases de dados e utilizaa grid para processar a junção espacial.

Em [25] é apresentada a proposta de uma arquitetura, onde os índices R-Tree dasduas bases de dados R e S ficam armazenados em uma máquina (master) e os objetos sãodistribuídos pelas outras máquinas disponíveis (clientes). Em [38], são criados índices nosclientes para os dados armazenados localmente e deixando no master um índice para osclientes. Esses trabalhos apresentam técnicas de distribuição de dados que não mantêm osobjetos colocalizados, o que aumenta o tráfego de dados na rede para operações de junçãoespacial distribuída.

Em [29], o índice é replicado entre todas as máquinas do cluster e os dados sãodistribuídos segundo uma política circular (Round-Robin). Entretanto, este trabalho [29]foi desenvolvido para processamento da junção espacial distribuída com bases de dadosestáticas, já que utiliza índices estáticos para indexar as bases de dados. Além disso, apolítica circular de distribuição dos objetos não mantém os objetos colocalizados.

Em [1] é proposta uma arquitetura com uma máquina dedicada (coordenador)que coordena as atividades das outras máquinas do cluster (servidores). As requisições docliente, para atualização e consultas nas bases de dados, são enviadas para o coordenadorque distribui as tarefas para os outros servidores. A arquitetura proposta neste trabalho,pode gerar um gargalo no coordenador, caso o sistema receba uma grande quantidade derequisições dos clientes. As principais contribuições de [1] são: uma taxonomia para adistribuição de dados em um cluster de computadores e a análise do impacto do númerode servidores, tamanho e características das bases de dados nas operações de inserção econsulta. Entretanto, esse trabalho não analisou o desempenho do sistema em operaçõesde junção espacial distribuída.

Em [6], cada base de dados é replicada em algumas máquinas do cluster. Cadaconsulta é enviada a um servidor chamado Processador da Consulta. Este servidor espalhaa consulta para cada máquina que contém uma replica das bases de dados envolvidasna junção espacial. Além da consulta, ele envia uma área espacial lógica delimitando aárea de processamento de cada máquina. As respostas de cada servidor são enviadas aoProcessador da Consulta que devolve o resultado ao usuário.

A Figura 6.1 apresenta um exemplo da distribuição dos dados pelos três servi-dores e o roteamento da consulta para os servidores 1 e 3. Cada servidor fica responsávelpor processar a junção espacial em uma determinada área. Este trabalho requer grandeespaço de armazenamento para guardar as réplicas de cada base de dados. Além disso,realiza o particionamento dos dados de forma estática e, por isso, não foi projetado paraser utilizado com bases de dados dinâmicas.

Em [42], os índices espaciais são replicados entre todas as máquinas do cluster


Figura 6.1: Arquitetura da plataforma proposta em [6]

e os dados são agrupados em blocos, de forma semelhante a Packing R-Tree [20],e distribuídos uniformemente pelo cluster. Por utilizar a estrutura de dados estáticaPacking R-Tree para indexar as bases de dados, o algoritmo proposto neste trabalho foiimplementado para ser processado com bases de dados estáticas, pois cada atualização dabase de dados requer que o índice seja reconstruído novamente.

Um framework é proposto em [45] para realizar o processamento de consultasespaciais com um esquema de balanceamento de carga em duas fases. A primeira faseenvolve a distribuição uniforme dos dados pelas máquinas do cluster e a segunda fasevisa balancear a carga de processamento entre os computadores. Este trabalho não discuteideias de como processar a junção espacial de forma distribuída.

Em [46] é proposta uma arquitetura que utiliza o modelo MapReduce paraprocessar as operações espaciais. A junção espacial com MapReduce tem inicio na fasede mapeamento. A fase de mapeamento coloca os objetos em tiles e agrupa estes tiles

em blocos utilizando um algoritmo de ordenação. A informação de qual tile e bloco estãoassociados a cada objeto é armazenada para ser utilizada na fase de Redução. Objetoscom mesmo número de bloco são enviados para a mesma tarefa de Redução.

Nas tarefas de Redução, a junção espacial é realizada em cada bloco usando umalgoritmo que utiliza as informações de localização relacionadas ao tile de cada objeto. Autilização do tile evita que resultados duplicados sejam gerados ao mesmo tempo.

A distribuição de dados pelas máquinas é realizada pelo HDFS (Hadoop’s

Distributed FileSystem), que não utiliza nenhuma informação espacial para realizar estaoperação. Por isso, o trabalho apresentado [46] não mantém os objetos colocalizados, oque aumenta o tráfego de dados na rede e influi de forma significativa no desempenhoda junção espacial distribuída. Além disso, a arquitetura é indicada, segundo os própriosautores, para casos onde as bases de dados não estão indexadas.

Uma arquitetura que utiliza o modelo MapReduce, com a plataforma Hadoop, éapresentada em [47]. Um método de distribuição é proposto, onde são construídos os blo-cos do HDFS com objetos espaciais de uma determinada região geográfica. Isto garanteque objetos dentro de uma região serão armazenados na mesma máquina, aumentando o


desempenho da recuperação dos dados na fase de Redução.A plataforma possui um índice espacial distribuído em dois níveis: índice global

e índice local. O índice global é baseado em um índice distribuído QuadTree [37], o qual éutilizado para determinar a localização do bloco de dados. O índice local é construído paralocalizar espacialmente objetos dentro de um bloco. A fase de Mapeamento do MapRe-

duce processa as tarefas em paralelo nas máquinas do cluster e gera como resultado ospares de objetos que satisfizerem as condições da consulta. Na fase de Redução, é execu-tado o processamento dos polígonos destes pares de objetos para gerar o resultado final.

O trabalho busca manter objetos espacialmente próximos no mesmo bloco e,consequentemente, na mesma máquina. Mas, deve ser informado previamente o espaçoterritorial das bases de dados para o algoritmo de distribuição de dados. Em bases dedados dinâmicas, o espaço territorial só é conhecido na inserção dos objetos, já que nãose sabe previamente quais objetos irão fazer parte da base de dados.

Além disso, para casos onde um conjunto de objetos espacialmente próximosestoure a capacidade máxima do bloco, este conjunto de objetos pode ser armazenado emmáquinas diferentes. Nestes casos, há um aumento na quantidade de tráfego de dados narede, o que prejudica o desempenho da junção espacial distribuída.

Uma técnica híbrida de distribuição de dados é proposta em [49]. Nesta técnica,a base de dados é particionada utilizando uma estratégia de distribuição estática, sendoque atualizações são tratadas utilizando uma estratégia de distribuição dinâmica. Estaestratégia foi desenvolvida para consultas em uma base de dados e, por isso, visa manterobjetos espacialmente próximos em máquinas diferentes para aumentar o paralelismoda consulta. Esta abordagem, entretanto, degrada o desempenho da junção espacialdistribuída, pois gera grande tráfego de dados na rede.

Em [10] é proposta uma estratégia de distribuição dinâmica de dados semelhanteao algoritmo Round-Robin. Nesta estratégia, cada servidor armazena uma lista circularcom a referência para os outros servidores do cluster. Quando um novo objeto é inseridono sistema, obtém-se o próximo servidor na lista circular. Os autores provaram queeste algoritmo gera uma distribuição de partições quase uniforme entre os servidores.Entretanto, esta estratégia foi idealizada para processar operações espaciais sobre umabase de dados. Em junções espaciais distribuídas, os objetos não ficam colocalizados, oque gera uma grande quantidade de tráfego de dados na rede.

6.2 Processamento Paralelo e Distribuído da Junção Espacial utilizando a Técnica de Semi-Junção Espacial58

6.2 Processamento Paralelo e Distribuído da Junção Es-pacial utilizando a Técnica de Semi-Junção Espacial

Esta seção apresenta um grupo de trabalhos que processam a junção espacialde forma paralela e distribuída. Esses trabalhos não discutem técnicas de distribuição dedados, mas analisam o impacto da cardinalidade das bases de dados no processamentoda junção espacial distribuída utilizando a técnica de Semi-Junção apresentada na Seção3.1. Para tal análise, esses trabalhos indexam as duas bases de dados R e S envolvidas najunção espacial e as armazenam em duas máquinas diferentes Rsite e Ssite respectivamente.

Em [40] as bases de dados R e S indexadas com o índice R-Tree e utilizados trêsestratégias para os testes: i) RT-N: transmite a base de dados R inteira para Ssite e realizaa junção espacial; ii) RT-L: as aproximações dos objetos da base de dados S são enviadospara Rsite e são retornados para Ssite os objetos de R que apresentarem intersecção comestas aproximações. A junção final é então realizada em Ssite entre os objetos de S e osobjetos de R retornados; iii) RT-I: semelhante a RT-L, mas as aproximações são geradasa partir dos MBRs dos nós internos do índice R-Tree de S em um nível imediatamenteacima das folhas.

O trabalho apresentado em [36] utiliza aproximações mais precisas para proces-sar a junção espacial. Essas aproximações requerem maior demanda de processamentogeométrico, mas reduzem os pares de candidatos falsos gerados. Esta redução de falsospositivos minimiza o processamento desnecessário de pares de polígonos e reduz o tráfegode dados na rede. As duas bases de dados R e S são indexadas por índices R-Tree.

Em [21], são propostos alguns modelos de custo para o processamento da junçãoespacial distribuída. A consulta é enviada pelas aplicações para um servidor centralizadoresponsável pelas consultas, que encaminha a consulta para os servidores Rsite e Ssite.Cada servidor processa uma determinada porção dos dados para gerar o resultado final.Esta porção é definida dividindo o espaço universal em vários tiles, onde os objetos emcada tile são processados por um servidor. Os modelos de custo são utilizados para definirquais tiles serão processados por cada servidor.

Em [22] também são propostos vários modelos de custo detalhados para oprocessamento da junção espacial distribuída utilizando R-Trees para indexar as basesde dados R e S. O trabalho discute, principalmente, técnicas de otimização para a semi-junção, onde um framework é proposto para reduzir os custos de transmissão dos dadose processamento da operação de semi-junção espacial. Alguns destes modelos de custosforam utilizados como base para implementar o algoritmo de Semi-Junção espacial donosso trabalho.



Apesar da extensa pesquisa na literatura sobre plataformas de processamento deoperações espaciais distribuídas, nenhuma proposta possui uma solução completa para oprocessamento da junção espacial com bases de dados dinâmicas.

Na Seção 3.1, alguns trabalhos [34, 29, 6, 42] não possuem algoritmos dedistribuição de dados para bases de dados dinâmicas. Outros trabalhos, [45, 25, 38, 1]utilizam uma máquina central, que recebe todas as requisições vindas dos clientes daaplicação e que pode se tornar um gargalo.

A solução proposta em [46] não apresenta técnicas para redução do tráfegode dados na rede para o processamento da junção espacial distribuída e a arquitetura éindicada para casos onde as bases de dados não estão indexadas.

A solução proposta em [47] mantém objetos espacialmente próximos no mesmobloco e, consequentemente, na mesma máquina. Entretanto, deve ser informado previa-mente o espaço territorial das bases de dados para o algoritmo de distribuição de dados.Em bases de dados dinâmicas, o espaço territorial só é conhecido na inserção dos objetos,já que não se sabe previamente quais objetos irão fazer parte da base de dados.

Em [49, 10] são apresentadas soluções de distribuição de dados para basesde dados dinâmicas, mas que são indicadas para consultas em uma bases de dados.Estas propostas mantêm objetos espacialmente próximos em máquinas diferentes paraaumentar o paralelismo de consultas sobre uma base de dados. No processamento dajunção espacial, isto gera muito tráfego de dados na rede.

Na Seção 6.2, os trabalhos [40, 36, 21, 22] armazenam as duas bases de dados R

e S, envolvidas na junção espacial, em apenas duas máquinas, não apresentando soluçõespara o processamento da junção espacial distribuída em um cluster de computadores.Além disso, nenhuma técnica de distribuição de dados é discutida nestes trabalhos.

CAPÍTULO 7Conclusão

A junção espacial apresenta alto custo por relacionar objetos espaciais que sãocompostos por geometrias multidimensionais complexas e que exigem algoritmos degeometria computacional de uso intensivo da CPU. Para que a junção espacial fosseprocessada de forma eficiente, os Sistemas de Gerência de Bancos de Dados Espaciais(SGBDE) foram distribuídos em um cluster de computadores para poder paralelizar edistribuir o processamento.

A partir do desenvolvimento deste trabalho fica evidente que o futuro dasplataformas de mineração de grandes volumes de dados espaciais está pautado no poder daescalabilidade horizontal para operar de forma distribuída e paralela. No entanto, até ondeconhecemos, poucos trabalhos na literatura implementaram operações de Junção EspacialDistribuída visando escalar a solução horizontalmente, fazendo avaliações utilizandobases de dados com diferentes tipos de geometrias, diferentes configurações no cluster

e avaliando as restrições e possibilidades de melhorias num cenário real de uso.Por isso, foi implementada neste trabalho uma plataforma denominada DistJoin.

Esta plataforma apresenta uma arquitetura peer-to-peer para viabilizar a escalabilidadeevitando ter um ponto único de falha, implementando protocolos de comunicação efi-cientes, sistema de armazenamento distribuído, funções de manipulação de objetos es-paciais e tratamento de concorrência e consistência que permitem a provisão de novosserviços de inteligência geográfica.

Nesta plataforma, também foram implementados um algoritmo de junção espa-cial distribuída e duas técnicas de distribuição de dados: Grid Proximity Area e ProximityArea. Estas duas técnicas tentam manter os objetos das bases de dados espaciais coloca-lizados e balanceados pelo cluster de computadores.

A técnica Proximity Area relaciona cada servidor do cluster a uma área espaciale busca manter objetos próximos a esta área neste servidor. Para manter o cluster

balanceado, foi criado um fator de balanceamento, onde quanto maior este fator maisbalanceado fica o cluster. Na técnica Grid Proximity Area, os objetos são distribuídosutilizando uma grid espacial e cada tile da grid é associado a um servidor. Os tiles sãoassociados de forma dinâmica aos servidores, onde é dada preferência aos servidores com

7.1 Trabalhos Futuros 61

menos objetos armazenados para que o cluster fique balanceado.Dentre os trabalhos pesquisados, nenhum apresentou técnicas de distribuição de

dados para bases de dados dinâmicas para o processamento da junção espacial distribuída.Alguns trabalhos exploram técnicas de distribuição para bases de dados estáticas, onde osobjetos são distribuídos novamente pelo cluster a cada atualização da base de dados. Estaestratégia é inviável para bases de dados grandes ou que sofram constantes atualizações.Nos trabalhos [49, 10] são apresentadas soluções de distribuição de dados para bases dedados dinâmicas, mas que são indicadas para consultas em uma base de dados.

Nos experimentos realizados, a plataforma DistJoin apresentou escalabilidadeem junções espaciais nos casos em que houve demanda de processamento na fase derefinamento. Portanto, os algoritmos de distribuição de dados tiveram impacto positivono processamento da junção espacial distribuída, já que a etapa de filtragem não é afetadapelas técnicas de distribuição de dados propostas neste trabalho.

A técnica de distribuição de dados Grid Proximity Area conseguiu reduzir otráfego de dados na rede se comparado a técnica Proximity Area. Em contrapartida, aparalelização do processamento da junção espacial distribuída foi prejudicada utilizando atécnica Grid Proximity Area, em função da concentração de objetos em algumas máquinasdo cluster.

Com a técnica Proximity Area, os recursos computacionais disponíveis forammelhor aproveitados e a junção espacial distribuída foi paralelizada entre os servidoresdo cluster. Por isso, a técnica Grid Proximity Area é indicada para casos onde o tráfegode dados na rede é dominante sobre o processamento na junção espacial distribuída. Emcenários onde o processamento é dominante, a técnica Proximity Area é mais apropriada.

A complexidade de desenvolvimento de uma plataforma para processamentodistribuído de operações de Junção Espacial é significativa e pode ser um fator limitantepara a criação de novas técnicas de análise de dados espaciais. Neste trabalho, foinecessário lidar com as limitações dos protocolos de rede, sistema operacional, depuraçãoe correção de erros em algoritmos distribuídos, etc. No entanto, em trabalhos futuros,será possível utilizar a plataforma DistJoin como base para desenvolver novos algoritmosde Junção Espacial, Consultas Skyline, Multiway Join, Spatial Data Analytics, dentreoutros serviços de inteligência baseada em localização que lidam com o processamentode grande volume de dados.

7.1 Trabalhos Futuros

Devido à abrangência do escopo e a quantidade de desafios envolvidos no desen-volvimento de uma arquitetura de processamento da junção espacial distribuída, muitos

7.1 Trabalhos Futuros 62

requisitos importantes não foram tratados devido à complexidade de sua implementaçãoe à restrição de tempo para o desenvolvimento deste trabalho.

O Sistema de Balanceamento de Carga das réplicas da plataforma DistJoinserá evoluído. Diante de informações de estado de todos os servidores, o algoritmo iráescolher o servidor com menor carga para processar uma operação sobre um objeto. Destaforma, o cluster teria seus recursos melhor aproveitados e diminuiria a probabilidade desobrecarregar um servidor. O Sistema de Lock também será evoluído para que operaçõesde escrita e leitura possam ser processados ao mesmo tempo de forma eficiente. Paratal, estão sendo estudados alguns algoritmos de controle de concorrência utilizados embancos de dados como PostgreSql e Oracle. Esta evolução no Sistema de Lock irá afetardiretamente o desempenho de aplicações que trabalham com bases de dados altamentedinâmicas.

A técnica Proximity Area será evoluída de forma a redistribuir os objetos pelocluster, em determinados períodos de tempo, para que os objetos sejam realocadosem servidores que armazenam objetos mais próximos espacialmente. Isto irá reduzir oimpacto da ordem da inserção no desempenho desta técnica.

A técnica Grid Proximity Area será evoluída para poder minimizar casos emque muitos objetos da base de dados intersectam com o mesmo tile e que podem gerara concentração de um grande conjunto de objetos na mesma máquina. Para mitigar esteproblema, estes tiles serão divididos e associados a servidores diferentes.

O processamento do algoritmo de junção na etapa de filtragem comprometeu aescalabilidade do sistema. Já foram detectadas e projetadas as melhorias devidas pararesolver esse problema, mas não foi possível testá-las no escopo deste trabalho emfunção da complexidade e tempo disponível. Estas melhorias serão avaliadas em trabalhosfuturos.

O algoritmo de Semi-Junção espacial será evoluído utilizando modelos de custospropostos em [22] para reduzir o tráfego de dados na rede e minimizar processamentodesnecessário de objetos espaciais.

Referências Bibliográficas

[1] AN, N.; LU, R.; QIAN, L.; SIVASUBRAMANIAM, A.; KEEFE, T. Storing spatial data

on a network of workstations. Cluster Computing, 2(4):259–270, 1999.

[2] BECKMANN, N.; KRIEGEL, H.; SCHNEIDER, R.; SEEGER, B. The R*-tree: an

efficient and robust access method for points and rectangles. ACM SIGMOD

Record, 19(2):322–331, 1990.

[3] BENTLEY, J. Multidimensional binary search trees used for associative search-

ing. Commun. ACM, 18, 1975.

[4] BRINKHOFF, T.; KRIEGEL, H.; SCHNEIDER, R.; SEEGER, B. Multi-step processing

of spatial joins, volume 23. ACM, 1994.

[5] BRINKHOFF, T.; KRIEGEL, H.; SEEGER, B. Efficient processing of spatial joins

using R-trees, volume 22. ACM, 1993.

[6] CHUNG, W.; PARK, S.; BAE, H. Efficient parallel spatial join processing method

in a shared-nothing database cluster system. Embedded Software and Systems,

p. 81–87, 2005.

[7] CORMAN, T.; LEISERSON, C.; RIVEST, R.; STEIN, C. Introduction to algorithms.

MIT press Cambridge, MA, USA, 1990.

[8] CORNER, D. The ubiquitous B-tree. ACM Computing Surveys, 11(2):121–137,

1979.

[9] DE ARAUJO, R. Computação Ubíqua: Princípios, Tecnologias e Desafios. XXI

Sompósio Brasileiro de Redes de Computadores, 2003.

[10] DE OLIVEIRA, T. B.; SACRAMENTO, V. J.; OLIVEIRA, S. T.; ALBUQUERQUE, P. I.;

CARDOSO, M. C. DSI-Rtree - Um Índice R-Tree Escalável Distribuído. XXIX

Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos, 2011.

[11] DE OLIVEIRA, T. B. DSI-Rtree - Um Índice R-Tree Escalável. Mestrado, Instituto

de Informática - UFG, 2011.


[12] DEMERS, A.; GREENE, D.; HAUSER, C.; IRISH, W.; LARSON, J.; SHENKER, S.;

STURGIS, H.; SWINEHART, D.; TERRY, D. Epidemic algorithms for replicated

database maintenance. In: Proceedings of the sixth annual ACM Symposium on

Principles of distributed computing, p. 1–12. ACM, 1987.

[13] FALOUTSOS, C.; ROSEMAN, S. Fractals for secondary key retrieval. In: Pro-

ceedings of the eighth ACM SIGACT-SIGMOD-SIGART symposium on Principles of

database systems, p. 247–252. ACM New York, NY, USA, 1989.

[14] GUTTMAN, A. R-trees: A dynamic index structure for spatial searching. ACM

Sigmod Record, 14(2):47–57, 1984.

[15] VEGTER, G. Computational topology. In: Goodman, J. E.; O’Rourke, J., editors,

Handlebook of Discrete Computational Geometry, p. 517–536. CRC Press, 1997.

[16] HUANG, Y.; JING, N.; RUNDENSTEINER, E. Spatial joins using R-trees: Breadth-

first traversal with global optimizations. In: Proceedings of the International

Conference on Very Large Data Bases, p. 396–405. Citeseer, 1997.

[17] II, G.; KUMAR, A. Attitude toward Location-Based Advertising. JIAD, 2007.

[18] JACOX, E.; SAMET, H. Spatial join techniques. ACM Transactions on Database

Systems (TODS), 32(1):7, 2007.

[19] KAMEL, I.; FALOUTSOS, C. Hilbert R-tree: An improved R-tree using fractals. In:

Proceedings of the international conference on very large data bases, p. 500–500.

INSTITUTE OF ELECTRICAL & ELECTRONICS ENGINEERS (IEEE), 1994.

[20] KAMEL, I.; FALOUTSOS, C. On packing r-trees. In: Proceedings of the second

international conference on Information and knowledge management, p. 490–499.

ACM, 1993.

[21] KANG, M.; CHOY, Y. Deploying parallel spatial join algorithm for network

environment. In: High Speed Networks and Multimedia Communications 5th IEEE

International Conference on, p. 177–181. IEEE, 2002.

[22] KARAM, O.; PETRY, F. Optimizing distributed spatial joins using r-trees. In:

Proceedings of the 43rd annual Southeast regional conference-Volume 1, p. 222–

226. ACM, 2005.

[23] KÖLMEL, B.; ALEXAKIS, S. Location based advertising. In: Proceedings of the 1st

International Conference on Mobile Business, p. 8–9, 2002.

http://www.cs.rug.nl/~gert/

http://cs.smith.edu/~orourke/books/discrete.html


[24] KOTLER, P.; AMSTRONG, G. Introdução ao marketing. Livros Técnicos e Científi-

cos, 2000.

[25] KOUDAS, N.; FALOUTSOS, C.; KAMEL, I. Declustering spatial databases on a

multi-computer architecture. Advances in Database Technology-EDBT’96, p. 592–

614, 1996.

[26] LEUTENEGGER, S. T.; LOPEZ, M. A.; EDGINGTON, J. Str: A simple and efficient

algorithm for r-tree packing. In: Data Engineering, 1997. Proceedings. 13th Inter-

national Conference on, p. 497–506. IEEE, 1997.

[27] MANOLOPOULOS, Y.; NANOPOULOS, A.; PAPADOPOULOS, A.; THEODORIDIS, Y. R-

trees have grown everywhere. Submitted to ACM Computing Surveys, 2003.

[28] MONNERAT, L. R.; AMORIM, C. L. D1ht: a distributed one hop hash table. In: Pa-

rallel and Distributed Processing Symposium, 2006. IPDPS 2006. 20th International,

p. 10–pp. IEEE, 2006.

[29] MUTENDA, L.; KITSUREGAWA, M. Parallel r-tree spatial join for a shared-

nothing architecture. In: Database Applications in Non-Traditional Environments,

1999.(DANTE’99) Proceedings. 1999 International Symposium on, p. 423–430. IEEE,

1999.

[30] NIELSEN, J.; HACKOS, J. T. Usability engineering, volume 125184069. Academic

press Boston, 1993.

[31] NOBARI, S.; TAUHEED, F.; HEINIS, T.; KARRAS, P.; BRESSAN, S.; AILAMAKI, A.

Touch: In-memory spatial join by hierarchical data-oriented partitioning. SIG-

MOD, 2013.

[32] OLIVEIRA, S. T.; SACRAMENTO, V. J.; CUNHA, A. R.; ALEIXO, E. L.; DE OLIVEIRA,

T. B.; CARDOSO, M. C.; JUNIOR, R. R. Processamento Distribuído de Ope-

rações de Junção Espacial com Bases de Dados Dinâmicas para Análise de

Informações Geográficas. XXXI Simpósio Brasileiro de Redes de Computadores e

Sistemas Distribuídos, 2013.

[33] PATEL, J.; DEWITT, D. Partition based spatial-merge join. In: ACM SIGMOD

Record, volume 25, p. 259–270. ACM, 1996.

[34] PATEL, J.; DEWITT, D. Clone join and shadow join: two parallel spatial join

algorithms. In: Proceedings of the 8th ACM international symposium on Advances

in geographic information systems, p. 54–61. ACM, 2000.


[35] RAHM, E.; MAREK, R. Analysis of dynamic load balancing strategies for parallel

shared nothing database systems. In: Proc 19th VLDB Conf, p. 182–193. Citeseer,

1993.

[36] RAMIREZ, M.; DE SOUZA, J. Distributed processing of spatial join. In: Proc. of the

Anais do III Workshop Brasileiro de GeoInformática GeoInfo, volume 2001, p. 1–8,

2001.

[37] SAMET, H. The quadtree and related hierarchical data structures. ACM Comput-

ing Surveys (CSUR), 16(2):187–260, 1984.

[38] SCHNITZER, B.; LEUTENEGGER, S. Master-client r-trees: A new parallel r-tree

architecture. In: Scientific and Statistical Database Management, 1999. Eleventh


[39] SELLIS, T.; ROUSSOPOULOS, N.; FALOUTSOS, C. The R+-tree: A dynamic index

for multi-dimensional data. In: Proceedings of VLDB, p. 507–518. VLDB, 1987.

[40] TAN, K.; OOI, B.; ABEL, D. Exploiting spatial indexes for semijoin-based join

processing in distributed spatial databases. Knowledge and Data Engineering,

IEEE Transactions on, 12(6):920–937, 2000.

[41] TEOTONIO, F. Comparação do desempenho dos índices R-Tree, grades fixas e

curvas de hilbert para consultas espaciais em bancos de dados geográficos.

Instituto Nacional de Pesquisas Espaciais - INPE, SP, Brazil, 2008.

[42] WEI, H.; WEI, Z.; YIN, Q. A new parallel spatial query algorithm for distributed

spatial databases. In: Machine Learning and Cybernetics, 2008 International Con-

ference on, volume 3, p. 1570–1574. IEEE, 2008.

[43] WEI, X.; SEZAKI, K. DHR-Trees: A Distributed Multidimensional Indexing Struc-

ture for P2P Systems. In: Parallel and Distributed Computing, 2006. ISPDC’06. The

Fifth International Symposium on, p. 281–290, 2006.

[44] XIA, T.; ZHANG, D. Improving the R*-tree with outlier handling techniques.

In: Proceedings of the 13th annual ACM international workshop on Geographic

information systems, p. 125–134. ACM New York, NY, USA, 2005.

[45] XIE, Z.; YE, Z.; WU, L. A two-phase load-balancing framework of parallel gis

operations. In: Geoscience and Remote Sensing Symposium, 2008. IGARSS 2008.

IEEE International, volume 2, p. II–1286. IEEE, 2008.


[46] ZHANG, S.; HAN, J.; LIU, Z.; WANG, K.; FENG, S. Spatial queries evaluation

with mapreduce. In: Grid and Cooperative Computing, 2009. GCC’09. Eighth


[47] ZHONG, Y.; HAN, J.; ZHANG, T.; LI, Z.; FANG, J.; CHEN, G. Towards parallel spatial

query processing for big spatial data. In: Parallel and Distributed Processing

Symposium Workshops & PhD Forum (IPDPSW), 2012 IEEE 26th International, p.

2085–2094. IEEE, 2012.

[48] ZHOU, X.; ABEL, D.; TRUFFET, D. Data partitioning for parallel spatial join

processing. In: Advances in Spatial Databases, p. 178–196. Springer, 1997.

[49] ZHOU, Y.; ZHU, Q.; ZHANG, Y. Spatial data dynamic balancing distribution

method based on the minimum spatial proximity for parallel spatial database.

Journal of Software, 6(7):1337–1344, 2011.

APÊNDICE AUso de memória pelas técnicas de Distribuiçãode Dados Grid Proximity Area e Proximity Area

(a) 3 máquinas (b) 6 máquinas

(c) 9 máquinas

Figura A.1: Uso de memória na Junção Espacial entre as Basesde Dados Bioma do Cerrado e Desmatamento doCerrado.

Apêndice A 69


(c) 9 máquinas

Figura A.2: Uso de memória na Junção Espacial entre as Basesde Dados Bioma da Caatinga e Localidades.

Apêndice A 70


(c) 9 máquinas

Figura A.3: Uso de memória na Junção Espacial entre as Basesde Dados Rodovias e Hidrografia.

distjoin: plataforma de processamento distribuído de operações

Documents