Uma Máquina de Execução de Consultas Distribuída em...
136
Gustavo Gaburro Trevisol Uma Máquina de Execução de Consultas Distribuída em Ambiente de Grid Vitória - ES 2006
Transcript of Uma Máquina de Execução de Consultas Distribuída em...
Gustavo Gaburro Trevisol
Uma Máquina de Execução de Consultas
Distribuída em Ambiente de Grid
Vitória - ES 2006
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
Gustavo Gaburro Trevisol
Uma Máquina de Execução de Consultas
Distribuída em Ambiente de Grid
Dissertação apresentada ao Programa de Pós-Graduação em Informática do Centro Tecnológico da Universidade Federal do Espírito Santo, como requisito parcial para obtenção do Grau de Mestre em Informática, na área de concentração em Banco de Dados.
Orientador:
Prof. Dr. Álvaro C. P. Barbosa
UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO - UFES CENTRO TECNOLÓGICO
DEPARTAMENTO DE INFORMÁTICA
Vitória - ES 2006
Uma Máquina de Execução de Consultas
Distribuída em Ambiente de Grid
COMISSÃO EXAMINADORA
_____________________________________________________ Prof. Dr. Álvaro Cesar Pereira Barbosa Universidade Federal do Espírito Santo
Orientador
_____________________________________________________ Prof. Dr. Bruno Richard Schulze
Laboratório Nacional de Computação Científica Membro Externo
_____________________________________________________ Prof. Dr. José Gonçalves Pereira Filho Universidade Federal do Espírito Santo
Membro Interno
Vitória, 19 de dezembro de 2006.
Resumo
Nos dias de hoje, a quantidade de dados disponíveis vem aumentando
consideravelmente. Assim, é cada vez mais notável a necessidade de sistemas capazes de
prover acesso integrado a esses dados. Na tentativa de solucionar esse problema, sistemas
middleware de integração de dados, tal como o CoDIMS (Configurable Data Integration
Middleware System), vêm sendo desenvolvidos com o objetivo de fornecer, a partir de fontes
de dados essencialmente heterogêneas e distribuídas, uma visão única, uniforme e
homogênea.
Grid é um ambiente de computação no qual aplicações podem utilizar múltiplos
recursos computacionais distribuídos de forma segura, coordenada, eficiente e transparente.
Considerando que os Sistemas de integração de dados são, por natureza, distribuídos eles
podem se beneficiar de ambientes Grid para obter melhor desempenho e uso racional dos
recursos disponíveis. Em casos onde existem várias fontes de dados com grandes quantidades
de dados a serem integradas, o uso de computação em Grid mostra-se promissora. A Camada
Wrapper-Grid do CoDIMS permite a execução de sub-consultas em um ambiente de Grid.
Contudo, mesmo os sub-resultados estando disponíveis nos nós do Grid, a composição é
realizada de maneira centralizada pela Máquina de Execução de Consultas (MEC).
Como solução para essa limitação este trabalho apresenta uma Máquina de Execução de
Consultas Distribuída (MECD) inserida em um ambiente de Grid, para execução de sub-
consultas e operadores de uma forma distribuída e paralela. Usando a MECD é possível: i)
realizar o processamento distribuído do Plano de Execução de Consultas (PEC) através de
operadores algébricos que serão executados remotamente nos nós do Grid; ii) disponibilizar o
resultado gerado pela execução de um operador para ser utilizado por outros operadores de
acordo com hierarquia da árvore que descreve o PEC; iii) alocar/desalocar instâncias dos
operadores em nós do Grid de modo a otimizar o uso dos recursos computacionais disponíveis
e diminuir o tempo de processamento da consulta.
Abstract
Nowadays the amount of available data is increasing substantially. Thus, the need of
systems to provide integrated access to these data is notable. Middleware systems for data
integration, such as CoDIMS (Configurable Data Integration Middleware System), are being
developed in the attempt to solve this problem. The goal is to supply, from heterogeneous and
distributed data sources, a unique, homogeneous and uniform vision.
Grid is a computational environment in which applications can use multiple distributed
computational resources in a safe, coordinated, efficient and transparent way. Regarding
Data Integration Systems are distributed they can make use of Grid environments to obtain a
better performance and a rational use of available resources. In cases where there are many
and large data sources to be integrated, the use of Grid computing seams promising. The
CoDIMS’ Wrapper-Grid layer permits to execute sub-queries in a Grid environment.
However, despite the sub-results available in the Grid nodes, the composition is done in a
centralized way by the Query Execution Engine (QEE).
As solution for this limitation this work presents a Distributed Query Execution Engine
(DQEE) inserted in a Grid environment for execution of sub-queries and operators in a
distributed and parallel way. Using DQEE it’s possible: i) distributed processing of all Query
Execution Plan (QEP), through algebraic operators that are executed remotely in the Grid
nodes; ii) availability of the result produced by the execution of one operator to be used by
other operators, accordingly to the tree hierarchy described by the QEP; iii)
alocating/realocating instances of the operators in Grid nodes, optimizing the use of
computational resources available and decreasing the time of query processing.
Sumário
1 Introdução ..................................................................................................13
1.1 Contexto........................................................................................................... 13
1.1.1 CoDIMS ............................................................................................... 15
1.1.2 Execução de Consultas.......................................................................... 18
1.2 Motivação do Trabalho..................................................................................... 19
1.3 Objetivo............................................................................................................ 21
1.4 Contribuições Esperadas................................................................................... 21
1.5 Metodologia ..................................................................................................... 21
1.6 Organização da Dissertação .............................................................................. 22
2 Trabalhos Relacionados..............................................................................24
2.1 Contexto........................................................................................................... 24
2.2 ParGRES .......................................................................................................... 25
2.3 CoDIMS-G....................................................................................................... 27
2.4 Active Proxy-G................................................................................................. 29
2.5 MOCHA........................................................................................................... 32
2.6 OGSA-DAI ...................................................................................................... 34
2.7 OGSA-DQP...................................................................................................... 36
2.8 Características gerais dos sistemas.................................................................... 40
3 Conceitos e Tecnologias .............................................................................42
3.1 Processamento de Consultas ............................................................................. 42
3.2 Processamento de Consultas em SGBDs Distribuídos....................................... 43
3.3 Álgebra Relacional ........................................................................................... 45
3.4 Operadores ....................................................................................................... 46
3.5 Interface dos Operadores .................................................................................. 49
3.6 Planos de Execução de Consultas (PEC)........................................................... 51
3.7 Modelos de Execução de Consulta.................................................................... 54
3.8 Grid .................................................................................................................. 55
3.8.1 Utilização de Grid ................................................................................. 56
3.8.2 Vantagens de Computação em Grid....................................................... 57
3.8.3 Deficiência............................................................................................ 58
3.8.4 Algumas Comparações.......................................................................... 58
3.8.5 Ferramentas de Desenvolvimento.......................................................... 61
4 Especificação Funcional .............................................................................67
4.1 Introdução ........................................................................................................ 67
4.2 Atual Sistemática.............................................................................................. 67
4.3 Soluções propostas ........................................................................................... 71
4.4 MECD.............................................................................................................. 74
4.4.1 Processamento do PEC.......................................................................... 75
4.4.2 Execução remota das sub-consultas....................................................... 76
4.4.3 Execução remota das operações ............................................................ 77
4.5 Camada MEC-Grid........................................................................................... 78
4.5.1 Componente Access Grid ...................................................................... 78
4.5.2 Componente MECGC ........................................................................... 80
4.6 A nova sistemática de execução de consultas .................................................... 81
5 Modelagem.................................................................................................84
5.1 Componentes do CoDIMS ................................................................................ 84
5.2 Diagramas de Pacotes e de Classes ................................................................... 87
5.2.1 Classes do Pacote MECD...................................................................... 88
5.2.2 Classes do Pacote Acesso a Dados ........................................................ 93
5.2.3 Classes do Pacote Access Grid .............................................................. 94
5.2.4 Classes do Pacote MECGC ................................................................... 97
5.3 Diagramas de Seqüência ................................................................................. 102
6 Estudo de Caso ......................................................................................... 104
6.1 Introdução ...................................................................................................... 104
6.2 Descrição da Aplicação .................................................................................. 104
6.3 Configuração do ambiente de testes ................................................................ 106
6.4 Cenários de Teste ........................................................................................... 110
6.4.1 Cenário 1 ............................................................................................ 112
6.4.2 Cenário 2 ............................................................................................ 112
6.4.3 Cenário 3 ............................................................................................ 113
6.5 Resultados Alcançados ................................................................................... 115
6.6 Decompondo o tempo total de execução ......................................................... 117
6.6.1 Cenário 1 ............................................................................................ 119
6.6.2 Cenário 2 ............................................................................................ 119
6.6.3 Cenário 3 ............................................................................................ 119
7 Conclusões ............................................................................................... 121
7.1 Conclusões Gerais .......................................................................................... 121
7.2 Contribuições ................................................................................................. 123
7.3 Trabalhos futuros............................................................................................ 124
Referências...................................................................................................... 126
Lista de Figuras
Figura 1. Uma possível configuração do CoDIMS (BARBOSA, 2001). ............................... 16
Figura 2. CoDIMS e seus componentes básicos.................................................................... 18
Figura 3. Camada Wrapper-Grid (BIANCARDI, 2005). ...................................................... 20
Figura 4. Visão Geral da Arquitetura do ParGRES (MATTOSO, 2005). .............................. 25
Figura 5. Arquitetura do CoDIMS-G (FONTES et al., 2004)................................................ 27
Figura 6. Active Proxy-G (ANDRADE et al., 2002). ............................................................ 30
Figura 7. Active Proxy-G e seus componentes principais (ANDRADE et al., 2002).............. 31
Figura 8. Arquitetura de Comunicação do Mocha................................................................. 33
Figura 9. Arquitetura de Serviço do OGSA-DAI (OPEN. . . , 2004a). .................................. 34
Figura 10. Descoberta e acesso a serviços no OGSA-DAI (OPEN. . . , 2004a). .................... 35
Figura 11. Framework OGSA-DAI: Interação cliente - OGSA-DAI (QI, 2004). .................. 36
Figura 12. Camada arquitetural do OGSA-DQP (ALPDEMIR et al., 2003a). ....................... 37
Figura 13. Interação entre os frameworks OGSA-DQP e OGSA-DAI (OPEN. . . , 2004b).... 38
Figura 14. Interações durante uma execução de consulta no OGSA-DQP (ALPDEMIR et al.,
2003a).................................................................................................................................. 39
Figura 15. Operadores Algébricos e de Controle. ................................................................. 47
Figura 16. Algoritmo do operador junção de laço aninhado (SILBERSCHATZ; KORTH;
SUDARSHAN, 2006). ......................................................................................................... 48
Figura 17. Algoritmo do operador junção união (SILBERSCHATZ; KORTH; SUDARSHAN,
2006). .................................................................................................................................. 48
Figura 18. Relacionamentos entre operadores produtores e consumidores. ........................... 50
Figura 19. Implementação da interface iterator para o NestedLoop (AYRES, 2003)............. 50
Figura 20. Exemplo de um PEC. .......................................................................................... 51
Figura 21. Exemplos de Topologias de PECs. ...................................................................... 52
Figura 22. Uma visão geral do sistema Globus Toolkit (FERREIRA et al., 2002). ................ 62
Figura 23. Interação entre as partes componentes (SOTOMAYOR, 2003). .......................... 66
Figura 24. Arquitetura de Camadas (BIANCARDI, 2005).................................................... 67
Figura 25. Um exemplo de PEC. .......................................................................................... 68
Figura 26. Wrappers em todos os WGC's. ............................................................................ 69
Figura 27. Componente Access Grid. ................................................................................... 72
Figura 28. MECD, Camada MEC-Grid e Componente Access Grid. .................................... 73
Figura 29. MECD do CoDIMS ............................................................................................ 74
Figura 30. Execução assíncrona de operadores. .................................................................... 76
Figura 31. Access Grid, MECD e Acesso a Dados................................................................ 78
Figura 32. Configurações com ambientes de Grid diferentes. ............................................... 79
Figura 33. Componente MECGC. ........................................................................................ 80
Figura 34. Exemplo de execução de uma Consulta. .............................................................. 82
Figura 35. Diagrama de Componentes do CoDIMS (BARBOSA, 2001). ............................. 84
Figura 36. As Fachadas do Componente do CoDIMS (Barbosa, 2001). ................................ 85
Figura 37. Evolução arquitetura de comunicação entre os componentes. .............................. 87
Figura 38. Dependência entre Pacotes. ................................................................................. 88
Figura 39. Diagrama de classes do Pacote MECD. ............................................................... 89
Figura 40. Diagrama de classes do Pacote Acesso a Dados................................................... 93
Figura 41. Diagrama de classes do Pacote Access Grid. ....................................................... 95
Figura 42. Diagrama de classes do Pacote MECGC. ............................................................ 98
Figura 43. Diagrama de Seqüência do método executarSubConsulta. ................................. 102
Figura 44. Diagrama de Seqüência do método executarOperação. ...................................... 103
Figura 45. DTDs das fontes de dados Atendimentos, Pacientes, Hospitais e Cidades.......... 105
Figura 46. Consulta enviada ao CoDIMS, em linguagem SQL. .......................................... 107
Figura 47. PEC otimizado da consulta submetida. .............................................................. 108
Figura 48. PEC da consulta em forma de árvore. ................................................................ 109
Figura 49. Sub-Consulta para a fonte Atendimentos. .......................................................... 109
Figura 50. Sub-Consulta para a fonte Pacientes. ................................................................. 109
Figura 51. Sub-Consulta para a fonte Cidades. ................................................................... 110
Figura 52. Sub-Consulta para a fonte Hospitais. ................................................................. 110
Figura 53. Ambiente de testes. ........................................................................................... 111
Figura 54. Arquitetura de testes. Camada Wrapper-Grid. ................................................... 113
Figura 55. Transferência dos sub-resultados e execução das operações............................... 115
Figura 56. Gráfico de comparação entre as três abordagens com pequena quantidade de
registros (< 100)................................................................................................................. 116
Figura 57. Gráfico de comparação entre as três abordagens com grande quantidade de
registros (> 100)................................................................................................................. 117
Figura 58. Fatores que compõem o tempo total de execução. ............................................. 118
Lista de Tabelas
Tabela 1: Níveis de abstração da execução de consulta (AYRES, 2003)............................... 54
Tabela 2. Dados das fontes envolvidas na consulta............................................................. 105
Tabela 3. Esquema global. Tabela de Atendimentos........................................................... 106
Tabela 4. Esquema global. Tabela de Cidades .................................................................... 106
Tabela 5. Esquema global. Tabela de Pacientes. ................................................................. 106
Tabela 6. Esquema global. Tabela de Hospitais. ................................................................. 106
Tabela 7. Configuração da Infra-estrutura utilizada. ........................................................... 111
Tabela 8. Funções de tempos de execução.......................................................................... 118
Lista de Abreviaturas e Siglas
APG Active Proxy-G
CoDIMS Configurable Data Integration Middleware System
CQP Cluster Query Processor
DAISGR Data Access and Integration Service Group Registry
DAP Fornecedor de Acesso aos Dados
DQEP Plano de execução de consulta distribuído
GDQS Grid Distributed Query Service
GDS Grid Data Services
GDSF Grid Data Services Factories
GQES Grid Query Evaluation Service
GSH Grid Service Handle
GSR Grid Service Reference
LDS Light Directory Service
LNCC Laboratório Nacional de Computação Científica
LPRM Laboratório de Pesquisa em Redes e Multimídia
MEC Máquina de Execução de Consultas
MECD Máquina de Execução de Consultas Distribuída
MECGC Componentes MEC Grid
MM Gerenciador de Metadados
MOCHA Middleware Based On a Code SHipping Architecture
NQP Node Query Processor
OGSA Open Grid Services Architecture
OGSA-DAI Grid Service Architecture Data Access and Integration
OGSA-DQP Open Grid Service Architecture - Distributed Query Processor
OV Organização Virtual
PDSS Persistent Data Store Service
PEC Plano de Execução de Consultas
QE Máquina de Consulta
QEEF Query Execution Engine Framework
QEM Gerenciador da Máquina de Execução
QO Otimizador de Consulta
QPC Coordenador de Processamento de Consultas
QS Query Server
SGBD Sistema Gerenciador de Banco de Dados
SGBDD Sistema de Gerência de Banco de Dados Distribuído
SQL Structured Query Language
UML Unified Modeling Language
WGC Componentes Wrapper Grid
WMS Workload Monitor Service
XML eXtensible Markup Language
13
1 Introdução
1.1 Contexto
O atual modelo de desenvolvimento mundial está centrado no acesso a informação que
deve ser disponibilizada em um tempo cada vez menor. O problema é que a quantidade de
informação e de aplicações existentes nas organizações cresce muito rapidamente, geralmente
são de diferentes formatos, podendo estar distribuídos, o que demanda o desenvolvimento de
novos Sistemas de Informação que necessitam acessar dados de outros.
Ainda que exista uma grande proximidade no significado dos dados, a integração destes
sistemas, em alguns casos, torna-se complexa. Em um caso mais simples, que diz respeito
somente ao acesso de um sistema a outro, a integração pode ser facilmente resolvida por meio
de uma conexão remota usando a internet, que possibilita a troca de informações de maneira
rápida e confiável. Quando existe a necessidade de se ter uma visão única e homogênea dos
dados armazenados em diversos sistemas, a integração é bem mais complexa, visto que os
dados podem estar armazenados em fontes de dados heterogêneas, distribuídas e
desenvolvidas independentemente.
Fontes de dados são entendidas como uma generalização dos Bancos de Dados
tradicionais, onde os dados podem estar organizados de diferentes formas: estruturada
(exemplo: banco de dados relacional), semi-estruturada (exemplo: arquivos XML) ou não
estruturada (exemplos: arquivos texto; e-mails; páginas web, etc.).
No que se refere ao problema de integração de dados, diversos tipos de soluções têm
sido propostas. Historicamente, podem-se destacar os Sistemas de Gerenciamento de Bancos
de Dados Heterogêneos (SGBDH) (LITWIN; MARK; ROUSSOPOULOS, 1990; SHETH;
LARSON, 1990; THOMAS et al., 1990; PITOURA; BUKHRES; ELMAGARMID, 1995;
SILBERSCHATZ; ZDONIK, 1997; CONRAD et al., 1997) e os Sistemas Mediadores
(WIEDERHOLD; GENESERETH, 1997; WIEDERHOLD, 1998).
14
Mais recentemente, sistemas integradores têm sido classificados, de uma maneira geral,
como middleware para integração de dados (BARBOSA, 2001; HAAS; MILLER; AL., 1999;
RODRIGUEZ-MARTINEZ; ROUSSOPOULOS, 2000). O objetivo maior desses sistemas é
liberar o usuário de ter que localizar as fontes de dados, interagir com cada uma isoladamente
e combinar/integrar os dados manualmente (HAKIMPOUR; GEPPERT, 2001; HALEVY,
2003).
Desde o surgimento dos sistemas de gerenciamento de banco de dados, o problema de
integração de dados tem sido reconhecido como ubíquo e criticamente importante (MILLER
et al., 2001), e vem constantemente demandando pesquisa na área de Banco de Dados
(SHETH; LARSON, 1990; LITWIN; MARK; ROUSSOPOULOS, 1990; SILBERSCHATZ;
ZDONIK, 1997; ABITEBOUL et al., 2003; HALEVY, 2003; ZIEGLER; DITTRICH, 2004).
Na literatura são encontrados diversos sistemas para integração de dados heterogêneos e
distribuídos. A descrição de alguns desses sistemas - os mais citados na literatura - pode ser
encontrada em (BARBOSA, 2001) e em (SILVESTRE; BIANCARDI; BARBOSA, 2004).
Apesar das diversas soluções existentes, pode-se constatar, pelo surgimento de novas
propostas, que a integração de dados é uma área cada vez mais importante (ZIEGLER;
DITTRICH, 2004; CARVALHO et al., 2006).
Segundo (ÖZSU; VALDURIEZ, 2001), o problema de integração de dados apresenta
três características fundamentais: autonomia, distribuição e heterogeneidade, as quais são
representadas como dimensões ortogonais. As características das dimensões são descritas a
seguir:
Autonomia: a autonomia se refere à distribuição de controle, e não de dados. Ela indica
até que grau fontes de dados individuais podem operar independentemente. A autonomia é
uma função de diversos fatores, como o fato de sistemas componentes trocarem ou não
informações, de poderem executar informações de forma independente e de um deles ter ou
não permissão para modificá-las;
Distribuição: enquanto a autonomia se refere à distribuição de controle, a dimensão de
distribuição lida com dados, considerando sua distribuição física. O usuário deve enxergar os
dados como um único pool lógico;
Heterogeneidade: como os esquemas das fontes são desenvolvidos independentemente,
eles possuem, freqüentemente, estruturas e terminologias diferentes (heterogeneidades
15
estrutural e semântica, respectivamente) (KIM; SEO, 1991; PITOURA; BUKHRES;
ELMAGARMID, 1995; RAHM; BERNSTEIN, 2001), o que ocorre quando os esquemas vêm
de domínios diferentes, ou mesmo quando eles modelam o mesmo domínio do mundo real,
pelo fato de serem desenvolvidos por pessoas diferentes, em diferentes contextos e tempos.
Dadas as características dos sistemas de integração de dados e as dificuldades
envolvidas no problema da execução de consultas que envolvem fontes de dados distribuídas,
principalmente aquelas com grande volume de dados, o uso de um ambiente de Grid para a
execução das tarefas necessárias para o processamento de consultas tem se tornado uma opção
promissora (ParGRES (MATTOSO et al., 2005), CoDIMS-G (SILVA et al., 2006), Active
Proxy-G (ANDRADE et al., 2002), MOCHA (MIDDLEWARE. . . , 2000), OGSA-DAI
(ATKINSON; BAXTER; HONG, 2002; OPEN. . . , 2004a), OGSA-DQP (ALPDEMIR et al.,
2003a; OPEN. . . , 2004b)), tendo em vista que ele propicia uma melhor utilização dos
recursos computacionais disponíveis no ambiente distribuído.
Computação em Grid tem se tornado muito difundida e vários projetos têm sido
iniciados para suportar, em parte, a visão de um Grid (FOSTER; KESSELMAN, 1999). Com
isso, a computação em Grid tem emergido como um importante campo, distinto da
computação distribuída convencional, dado que o seu foco está no compartilhamento de
recursos, onde a principal idéia é criar a ilusão de um supercomputador virtual, em grande
escala, facilmente gerenciável e com uma grande quantidade de recursos (ciclos de CPU,
dados, dispositivos de armazenamento, etc.) sendo compartilhados (BERSTIS, 2003). Os
dispositivos podem estar em uma mesma sala ou distribuídos através do mundo, podem estar
utilizando diferentes plataformas de hardware ou diferentes sistemas operacionais, e podem
pertencer a diferentes empresas ou instituições.
Um projeto que vem utilizando a computação em Grid para tirar proveito dos seus
benefícios e aprimorar o processamento de consultas que envolvam fontes de dados
distribuídas e heterogêneas é o CoDIMS, descrito a seguir.
1.1.1 CoDIMS
O CoDIMS (Configurable Data Integration Middleware System) (BARBOSA, 2001;
BARBOSA; PORTO; MELO, 2002; TREVISOL, 2004; PINHEIRO, 2004; BIANCARDI,
2005; SILVESTRE, 2005; GOMES, 2005; CÔCO, 2005; LAQUINE, 2006; TREVISOL;
16
BARBOSA, 2006) é um ambiente flexível e configurável para gerar sistemas middleware de
integração de dados, configurados para aplicações específicas. Seu maior objetivo é estudar,
avaliar e incorporar técnicas recentes ou difundidas para aprimorar o processo de integração
de dados. Ele vem sendo desenvolvido no Laboratório de Pesquisa em Redes e Multimídia
(LPRM) do Departamento de Informática da Universidade Federal do Espírito Santo. Alguns
trabalhos relacionados ao CoDIMS têm sido realizados em conjunto com instituições
parceiras como a PUC-Rio e o Laboratório Nacional de Computação Científica (LNCC),
como por exemplo (AYRES, 2003) e (SILVA et al., 2006).
Sua principal característica é o fato de ser baseado na técnica de composição de
frameworks (FAYAD; SCHMIDT; JOHSON, 1999), possibilitando, com isso, flexibilidade e
configuração, podendo ser adaptado para ser utilizado em diversos domínios de aplicação que
exigem diferentes tipos de serviços (BARBOSA, 2001). Flexível, no sentido de que permite:
gerar sistemas de integração específicos para poder integrar diferentes fontes de dados;
utilizar diferentes técnicas de comunicação, tanto entre os componentes internos quanto com
as fontes de dados; possibilitar a utilização de diferentes modelos de dados internamente.
Configurável, de forma que o middleware pode ser configurado apenas com os componentes
necessários para uma aplicação específica e que seja instanciado de acordo com os requisitos
da aplicação e das características das fontes de dados que se deseja integrar.
Figura 1. Uma possível configuração do CoDIMS (BARBOSA, 2001).
17
A Figura 1 mostra uma possível configuração do CoDIMS. Os componentes Controle,
Gerência de Metadados, Processamento de Consultas e Acesso aos Dados são os componentes
básicos, ou seja, aqueles que devem existir em todas as configurações. Já os componentes
Gerência de Regras, Gerência de Transação, Controle de Concorrência poderiam não estar
presentes em uma determinada configuração, dependendo do domínio da aplicação para o
qual está sendo gerado o sistema. Já aplicações mais complexas, como por exemplo, aquelas
que tratam dados no formato de multimídia, podem requisitar novas funcionalidades, que
devem ser incorporadas quando do processo de configuração, através da inclusão de novos
componentes.
Na Figura 2, é mostrada uma configuração do CoDIMS com seus componentes básicos,
assim como as possíveis interações entre eles. O componente Controle é a essência do
ambiente CoDIMS, pelo fato de disponibilizar os mecanismos que implementam as
configurações física e lógica. A configuração física diz respeito à seleção e ao registro dos
componentes que farão parte do sistema a ser configurado, incluindo os serviços oferecidos e
requisitados por cada um destes componentes. A configuração lógica é modelada através de
um mecanismo baseado no conceito de workflow (JABLONSKI; BUSSLER, 1996;
KOBIELUS, 1997; LAWRENCE, 1997), sendo responsável por efetuar um escalonamento
dos serviços, ou seja, determinar a seqüência de execução dos serviços oferecidos pelos
componentes necessários para o processamento de um comando submetido ao sistema
configurado. O componente Gerência de Metadados é responsável por gerenciar os esquemas
envolvidos no processo de integração de dados. Ele mantém o modelo de dados global do
CoDIMS e disponibiliza funcionalidades para o mapeamento entre o modelo global os
modelos nativos das fontes de dados. O componente Processamento de Consultas analisa, re-
escreve, otimiza e executa as consultas submetidas ao sistema. Por fim o componente Acesso
aos Dados é responsável por, através dos wrappers, traduzir e encaminhar as sub-consultas a
serem executadas sobre as fontes de dados e recuperar os resultados das mesmas. É
importante ressaltar que, na versão atual do CoDIMS, seus componentes são implementados
como Web Services (TREVISOL, 2004).
18
Figura 2. CoDIMS e seus componentes básicos.
Para o processo de configuração, customização e modelagem de uma instância do
CoDIMS, são necessárias as etapas de configuração física, configuração lógica e carga dos
metadados de acordo com os requisitos de uma aplicação específica, conforme definido em
(BARBOSA, 2001). Um exemplo de configuração (instância) do CoDIMS é o CoDIMS-G
(PORTO et al., 2004; FONTES et al., 2004; GIRALDI et al., 2005; SILVA et al., 2006), que
vem sendo desenvolvido para suportar aplicações de visualização científica executando em
um ambiente de Grid no LNCC. Uma outra instância do framework CoDIMS vem sendo
utilizada nos projetos de pesquisa Infraware (PEREIRA FILHO et al., 2006) e Telecárdio
(ANDREAO, 2006), para integração de dados em ambientes Context-Aware;
1.1.2 Execução de Consultas
Para que o CoDIMS consiga realizar a integração de dados de fontes heterogêneas é
definido um modelo global para o qual os diferentes modelos de dados locais das fontes a
serem integradas são mapeados, utilizando ontologias (SILVESTRE, 2005). Quando uma
19
consulta global é submetida ao CoDIMS ela é analisada pelo Parser para verificar se está
sintaticamente correta e se as entidades (tabelas e campos) estão contidas no modelo global do
CoDIMS. Ao final da análise e validação, o parser gera um Plano de Execução de Consulta
(PEC) inicial. Após isso, o Re-escritor, através do mapeamento entre o modelo global e os
modelos nativos de cada fonte de dados, refaz o PEC de forma a gerar apenas uma sub-
consulta para cada fonte de dados envolvida na consulta global. O próximo passo é realizado
pelo Otimizador (GOMES, 2005), que gera um PEC otimizado e pronto para a execução. A
Máquina de Execução de Consultas (MEC) (PINHEIRO, 2004) gerencia a execução do PEC,
repassando as sub-consultas ao componente Acesso aos Dados, que as envia às fontes de
dados por meio dos wrappers (CÔCO, 2005). Estes exercem papel de tradução entre os
modelos de dados e fazem a comunicação com as fontes de dados. Ou seja, um wrapper
recebe do componente Acesso aos Dados uma sub-consulta no modelo global do CoDIMS,
converte-a para o modelo da respectiva fonte, interage com a fonte gerando o resultado da
sub-consulta (sub-resultado). Este sub-resultado novamente é novamente convertido para o
modelo global e é enviado para o componente Acesso aos Dados, que o repassa para a MEC
de modo que seja feita a composição do resultado final, integrando os sub-resultados gerados
pelas diversas sub-consultas.
1.2 Motivação do Trabalho
Em (BIANCARDI, 2005) foi proposta e implementada a camada Wrapper-Grid (Figura
3) com o objetivo de desacoplar os wrappers do componente Acesso aos Dados do CoDIMS.
Os wrappers foram alocados em um ambiente distribuído, mais precisamente em um Grid,
para permitir a execução paralela das sub-consultas. Com essa abordagem reduziu-se a
sobrecarga do servidor Acesso aos Dados, através da execução remota dos wrappers. Além
disso, os sub-resultados gerados por cada sub-consulta são disponibilizados, de forma
distribuída, nos próprios nós do Grid, alocados aos wrappers, permitindo executar o PEC de
forma distribuída (ÖZSU; VALDURIEZ, 2001) em um Grid.
20
Figura 3. Camada Wrapper-Grid (BIANCARDI, 2005).
A camada Wrapper-Grid foi desenvolvida no CoDIMS com os seguintes objetivos:
• Disponibilizar um ambiente com acesso distribuído e paralelo às diversas fontes de
dados pertencentes a uma configuração;
• Dar suporte ao processamento distribuído de consultas que requerem maior poder de
processamento, permitindo que elas sejam processadas em paralelo nos nós do Grid;
• Prover escalabilidade ao CoDIMS, permitindo que seja realizada a integração de uma
grande quantidade de fontes de dados sem que haja perda de desempenho na
execução das sub-consultas;
• Tirar proveito das vantagens oferecidas pelo ambiente de Grid, como a otimização e
compartilhamento de recursos computacionais disponíveis.
Apesar dos avanços com a incorporação da Camada Wrapper-Grid, a MEC continua
centralizada em um único servidor, de forma que a composição dos sub-resultados, para se
gerar o resultado final, continua sendo realizada de forma centralizada e seqüencial. Em casos
onde diversas fontes de dados com grande quantidade de informações devem ser integradas, é
21
natural imaginar a utilização de um ambiente de Grid não somente para a execução das sub-
consultas, mas também para a execução das operações necessárias à composição dos sub-
resultados, com o objetivo de diminuir ao máximo o tempo de execução das consultas
enviadas ao CoDIMS.
Um ambiente computacional de Grid (FOSTER et al., 2002; FOSTER, 2002) é aquele
no qual aplicações podem utilizar, de forma segura, coordenada, efetiva e transparente,
múltiplos recursos computacionais que podem estar dispersos geograficamente. Considerando
que o ambiente de integração de dados é essencialmente distribuído, e que as sub-consultas e
as operações para composição dos seus resultados são realizadas de forma independentes e
distribuídas entre si, o uso de computação em Grid apresenta-se como uma boa opção.
1.3 Objetivo
Este trabalho tem por objetivo desenvolver uma Máquina de Execução de Consultas
Distribuída (MECD) para o CoDIMS, inserida em um ambiente de Grid.
1.4 Contribuições Esperadas
Com a MECD esperam-se os seguintes resultados: primeiro, possibilitar a execução
distribuída de todo o PEC através de operadores algébricos que serão executados nos Nós do
Grid; segundo, permitir que o resultado gerado pela execução de um operador do PEC fique
disponível para ser utilizado por outros operadores de acordo com a hierarquia da árvore que
descreve o PEC; terceiro, alocar/realocar instâncias dos operadores em nós do Grid de modo a
otimizar o uso dos recursos computacionais disponíveis e diminuir o tempo de processamento
da consulta.
1.5 Metodologia
Para a realização deste trabalho foi necessário um estudo sobre o tema de integração de
dados heterogêneos e distribuídos, e sobre os trabalhos mais diretamente relacionados a
máquinas de execução de consultas distribuídas, verificando seus pontos positivos e
deficiências.
22
O conhecimento do CoDIMS foi conseguido ainda na graduação, onde foi desenvolvido
um projeto final de curso, o qual focou-se na incorporação de uma nova forma de
comunicação entre os componentes CoDIMS, passando a utilizar tecnologia de Web Services
(TREVISOL, 2004).
A partir das disciplinas do curso de mestrado, dos estudos dos sistemas de integração de
dados heterogêneos e distribuídos e do trabalho realizado em (BIANCARDI, 2005), notou-se
a possibilidade de utilizar o ambiente de Grid para aumentar o desempenho do processamento
de consultas no CoDIMS com a execução paralela das operações sobre os sub-resultados de
cada fonte. Foram então realizados estudos sobre tecnologia de Grid, seus principais
conceitos, ferramentas e ambientes que poderiam ser utilizados para processamento
distribuído de consultas. Logo após, foi realizada uma pesquisa sobre sistema de integração de
dados que utilizam ambiente de Grid, de forma a investigar como esses sistemas maximizam
o processamento de consultas utilizando o poder computacional oferecido por um Grid.
Com os estudos realizados foi então elaborada uma proposta inicial para a MECD
(TREVISOL, 2006). Em seguida elaborada a especificação funcional, a respectiva
modelagem em UML (Unified Modeling Language) e a implementação do presente trabalho.
Por fim, foram definidas as estratégias para a execução de testes com o objetivo de verificar a
eficiência da sistemática proposta.
1.6 Organização da Dissertação
O restante deste trabalho está assim organizado:
No capítulo 2, são apresentados e discutidos trabalhos de integração de dados
heterogêneos e distribuídos que de alguma forma utilizam a distribuição do ambiente para
realizar a execução de consultas, ou seja, os que estão mais diretamente relacionados a este
trabalho.
No capítulo 3, são apresentados os principais fundamentos relacionados a este trabalho,
tais como: Processamento de consultas, Álgebra Relacional, PEC, Grid, etc. Também são
apresentadas algumas tecnologias utilizadas neste trabalho.
No capítulo 4, é apresentada a especificação funcional da MECD do CoDIMS, com a
descrição dos seus requisitos.
23
No capítulo 5, é apresentada a modelagem UML da MECD, incluindo diagramas de
componentes, classes e seqüência.
No capítulo 6, é apresentado um estudo de caso com objetivo de avaliar e validar a
eficiência sistemática proposta comparando-a com as já implementadas anteriormente no
CoDIMS, apresentadas em (BARBOSA, 2001; BIANCARDI, 2005). São então apresentadas:
a descrição da aplicação, os cenários de testes e os resultados alcançados.
Finalmente, o capítulo 7 apresenta uma síntese do trabalho realizado, suas principais
contribuições e a indicação de alguns trabalhos futuros para a continuidade desta pesquisa.
Em seguida, são listadas as referências bibliográficas utilizadas.
24
2 Trabalhos Relacionados
2.1 Contexto
O problema de integração de dados tem recebido grande atenção da comunidade de
banco de dados, tendo sido estudado desde o início da década de 80 (ZIEGLER; DITTRICH,
2004). São encontrados, na literatura, diversos sistemas e propostas tentando solucionar tal
problema. O aparente vasto número de soluções pode, erroneamente, indicar uma área de
pesquisa já resolvida. Pelo contrário, é uma área cada vez mais importante, na qual não existe
uma solução geral que seja adequada ou que se ajuste aos diversos problemas de integração, o
que se constata pelo surgimento de novas propostas e desafios (CARVALHO et al., 2006).
Considerando as características do CoDIMS de flexibilidade e configuração, e as
necessidades envolvidas no problema da execução de consultas que envolvem fontes de dados
distribuídas, a utilização de um ambiente de Grid para a execução das operações sobre os sub-
resultados é opção que vem se tornando extremamente viável, tendo em vista que ele propicia
uma melhor aproveitamento dos recursos computacionais disponíveis no ambiente
distribuído. Assim, deu-se ênfase ao estudo dos sistemas de integração de dados que utilizam
alguma infra-estrutura para distribuição do processamento das tarefas envolvidas na execução
de consultas. São apresentados alguns sistemas clássicos, aqueles mais citados na literatura,
até os mais atuais, dos quais se pode notar que a utilização de um ambiente distribuído para
execução de consultas tem ganhado ênfase recentemente. Nosso objetivo foi investigar a
forma como esses sistemas distribuem a execução das sub-consultas e das operações sobre os
sub-resultados. A apresentação de suas arquiteturas tem o objetivo de nos proporcionar um
maior embasamento para a definição dos serviços e funcionalidades da MECD.
A seguir são apresentados alguns sistemas de integração de dados mais diretamente
relacionados a este trabalho:
25
2.2 ParGRES
Como as demais soluções para clusters de bancos de dados, o ParGRES (MATTOSO et
al., 2005) consiste em uma camada intermediária de software (middleware) que orquestra
instâncias de SGBDs em execução nos diferentes nós do cluster para a implementação de
técnicas de processamento paralelo.
O ParGRES, possui arquitetura descentralizada, como ilustra a Figura 4. Seus diferentes
componentes se encontram distribuídos entre os Nós do cluster.
Figura 4. Visão Geral da Arquitetura do ParGRES (MATTOSO, 2005).
O componente mais importante e que atua como coordenador de todos os demais é o
Cluster Query Processor (CQP). Ele é o responsável pelo controle da execução de requisições
no ParGRES. O componente Intermediador tem a função é repassar as requisições das
aplicações para o CQP e, no sentido inverso, repassar as respostas do CQP às aplicações.
Há três tipos de tarefas executadas pelo ParGRES: processamento de consultas com
paralelismo inter-consultas, processamento de consultas com paralelismo intra-consulta e
processamento de operações de atualização de dados. O CQP é o responsável por analisar as
consultas e decidir que tipo de paralelismo será utilizado no processamento de cada uma, bem
como os nós utilizados nesse processamento. Para tanto, utiliza informações presentes no seu
Catálogo. Esse catálogo é, no entanto, muito simples e armazena apenas as informações
26
necessárias à implementação da fragmentação virtual adaptativa, que é uma técnica não
intrusiva.
Sendo assim, esse catálogo não necessita de informações específicas do SGBD
PostgreSQL (POSTGRESQL, 2005), mantendo a filosofia de se utilizar o SGBD como um
componente do tipo “caixa-preta”.
A execução paralela de operações de atualização e de consultas com paralelismo intra-
consulta em um ambiente com replicação total de dados poderia gerar resultados
inconsistentes. Como atualizações de dados em um ambiente OLAP são realizadas,
tipicamente, em momentos predeterminados (GORLA, 2003), o ParGRES adota uma política
conservadora e não permite a execução paralela de atualizações e consultas. Além disso,
enquanto que as atualizações são rápidas, as consultas possuem um tempo de processamento
significativo (TPC, 2003). Para tanto, o CQP possui um escalonador, responsável por ordenar
consultas e atualizações. Enquanto atualizações são processadas, todas as demais operações
no cluster são bloqueadas. Quando só há consultas, o CQP permite suas execuções em
paralelo.
Após determinar o tipo de paralelismo e os nós envolvidos no processamento de uma
requisição, o CQP inicia seu processamento. No caso de uma consulta sem paralelismo intra-
consulta, o CQP apenas a envia ao Node Query Processor (NQP) do nó escolhido para a
execução. O NQP repassa a consulta ao PostgreSQL, que a processa. O resultado segue então
o caminho inverso até a aplicação cliente. No caso de uma operação de atualização, o CQP
bloqueia a execução de consultas, e a envia ao NQP de cada nó. Após a confirmação do
processamento da operação por todos os NQPs, o CQP libera novamente a execução de
consultas. No caso de uma consulta a ser processada com paralelismo intra-consulta, o CQP
atua em conjunto com os NQPs para a produção do resultado final. Inicialmente, ele aloca os
NQPs e envia a cada um deles um plano de execução local para a consulta. Cada NQP
processa localmente o seu plano e gera um resultado parcial, que é enviado ao CQP para a
composição do resultado final da consulta. Após receber os resultados parciais de todos os
NQPs, o CQP finaliza a composição de resultados e os envia à aplicação cliente.
ParGRES é um projeto que tem como objetivo desenvolver um sistema de software
livre para processar com eficiência consultas pesadas que envolvam grandes quantidades de
dados, usando para isso, o SGBD PostgreSQL sobre clusters de PCs.
27
2.3 CoDIMS-G
O CoDIMS-G (SILVA et al., 2006) é um sistema de integração de dados e programas
gerado a partir de uma configuração do CoDIMS (BARBOSA; PORTO; MELO, 2002;
BARBOSA, 2001), que vem sendo desenvolvido no LNCC. Também pode ser visto como um
serviço de integração de dados e programas para Grid, sendo utilizado essencialmente para
dar suporte a aplicações científicas.
O principal foco do CoDIMS-G é prover uma camada de dados sobre um middleware
de Grid, oferecendo capacidade de processamento de forma transparente e eficiente para
consultas compreendendo formatos de dados não tradicionais e programas específicos de
usuários. Na sua implementação inicial combinam tipos de dados espaciais e temporais com
programas científicos para formar um cenário de uma aplicação cientifica.
Figura 5. Arquitetura do CoDIMS-G (FONTES et al., 2004).
A arquitetura do CoDIMS-G pode ser observada na Figura 5. Nela, o componente
Controle (Control) armazena, gerencia, valida e verifica uma instância de configuração. O
Controle orquestra a comunicação entre os componentes. Usuários acessam o serviço através
uma aplicação Web. A requisição de um usuário é encaminhada para o componente Controle,
que a envia para o componente Analisador (Parser). Este transforma a requisição do usuário
em uma representação de grafo de consulta. O Otimizador de Consulta (Query Optimizer -
QO) recebe o grafo e gera um plano de execução de consulta distribuído (DQEP), usando um
28
modelo de custo baseado em estatísticas de dados e programas armazenadas no Gerenciador
de Metadados (Metadata Manager - MM). Para DQEPs que incluem operações para a
avaliação de programas de uso paralelo, o otimizador chama o componente Escalonador
(Scheduler - SC). Este último acessa o MM para capturar o histórico de desempenho de
execução de nós do Grid e custos de avaliação de programas de usuário, além de estatísticas
dos resultados intermediários. Baseado nas estatísticas coletadas, o SC aplica um algoritmo de
escalonamento de nós do Grid para encontrar um sub-conjunto de nós a serem alocados pelo
gerenciador da máquina de execução (Query Engine Manager - QEM), onde serão executados
os programas do usuário.
O QEM é responsável por implantar os serviços da máquina de execução de consulta
(QE) nos Nós especificados no DQEP, e gerenciar os seus ciclos de vida durante a execução
da consulta. O QEM gerencia o desempenho, em tempo real, dos QEs por consultar as
estatísticas de vazão de dados e decidir por realocação, em tempo de execução, das QEs com
um plano re-otimizado. Os QEs são implementados como instâncias do framework de
execução de consulta (AYRES; PORTO; MELO, 2005). Cada QE recebe um fragmento de
um DQEP completo, e é responsável pela instanciação dos operadores e pelo controle de
execução, incluindo a comunicação com outros fragmentos para recuperação das tuplas.
Como parte do DQEP, o operador Scan acessa as fontes de dados com wrappers, que
preparam os dados de acordo com o formato de dados comum.
O modelo de processamento de consultas do CoDIMS-G segue uma estratégia de
execução adaptativa denominada Eddies (AVNUR; HELLERSTEIN, 2000). Esta estratégia
provê um escalonamento dinâmico de operadores de acordo com sua necessidade de
utilização. Como as estatísticas de desempenho e das características dos dados podem variar
durante a execução de uma consulta, ou podem não estar disponíveis inicialmente, a idéia é
produzir um plano de execução de consultas distribuído inicial (DQEP), sem gastar muito
tempo buscando um plano ótimo e, posteriormente, definir um escalonamento dos operadores
da DQEP em tempo de execução da consulta. Durante a execução, a alocação inicial dos nós é
reavaliada, de acordo com as estatísticas de transferência, e uma nova estratégia de alocação
pode ser escolhida pelo escalonador dinâmico.
Para cada operador presente no DQEP uma estratégia de paralelismo é escolhida dentre
as três seguintes: 1) a estratégia para o operador é avaliada de acordo com a que foi aplicada
29
ao operador anterior; 2) uma nova estratégia é definida baseada em um algoritmo de
escalonamento; 3) é decida uma estratégia baseando-se como próximo operador do DQEP.
O CoDIMS-G está voltado para o desenvolvimento de soluções para problemas de
aplicações científicas, tal como o desenvolvimento de um serviço para suportar um estágio de
processamento de aplicações de visualização científica que simulam um fluxo de fluído
através de um caminho (PORTO et al., 2004). Nesse sentido, o CoDIMS-G usa o ambiente de
Grid para a execução em paralelo de programas sobre uma grande base de dados, não tendo o
objetivo de ser uma extensão do CoDIMS de forma a adaptá-lo, de maneira mais geral, ao
ambiente de Grid para efetuar integração de dados essencialmente heterogêneos e
distribuídos.
2.4 Active Proxy-G
O Active Proxy-G (APG) (ANDRADE et al., 2002) é um serviço middleware para
execução de consultas sobre várias fontes de dados (servidores de aplicações) de forma
transparente para o usuário. Ele parte do princípio de que em ambientes multi-usuário é
bastante comum que consultas distintas busquem a mesma porção de dados. Tendo isso em
vista, é interessante a reutilização de dados retornados de consultas passadas que são
armazenados em caches temporárias para otimizar a execução de consultas e prevenir
gargalos na rede com tráfego de informações não necessárias. Para consultas que necessitem
de dados que não estão em cache, se faz necessário o envio de sub-consultas aos servidores de
aplicação. Os sub-resultados gerados devem ser integrados com os já disponíveis em cache
para gerar o resultado final.
Como apresentado na Figura 6, usuários podem realizar acesso aos servidores e
aplicação diretamente, porém, neste caso, não serão utilizados os serviços de otimização e uso
de caches de dados do Active Proxy-G.
30
Figura 6. Active Proxy-G (ANDRADE et al., 2002).
O Active Proxy-G possui quatro componentes principais, destacados na Figura 7.
Query Server (QS). Componente responsável por receber as consultas dos usuários ou
mesmo de outras instancias do Active Proxy-G. Uma fila de prioridade é utilizada para o
escalonamento da execução. A consulta global é decompostas em sub-consultas, de acordo
com as meta-informações armazenas no componente. Estas por sua vez são encaminhadas
para o componente LDS para prosseguir os seus processamentos. Após todos os sub-
resultados serem gerados e retornados para o componente QS, a composição dos sub-
resultados é realizada de forma centralizada.
Light Directory Service (LDS). Após o componente QS retirar a consulta da fila de
prioridade as suas sub-consultas são repassadas para o componente LDS. Este por sua vez
determinará quais os servidores de aplicação mais apropriados para a execução das consultas
derivadas da consulta global. Esta escolha é feita baseando-se no tipo da sub-consulta, dados a
serem retornados, capacidade de processamento dos servidores de aplicação e proximidades
das fontes de dados e caches.
31
Figura 7. Active Proxy-G e seus componentes principais (ANDRADE et al., 2002).
Workload Monitor Service (WMS). Componente responsável por monitorar os
servidores de aplicações integrados pelo ambiente, armazenar estatísticas e disponibilizar
serviços para fornecer informações sobre uso de memória, CPU, disco e capacidade de I/O
para o componente LDS.
Persistent Data Store Service (PDSS). A principal responsabilidade do PDSS é
identificar a possibilidade de reuso de dados armazenados temporariamente em caches para
responder a uma sub-consulta. A utilização de apenas uma instância do Active Proxy-G
aumenta a possibilidade de serem encontrados fragmentos de dados que podem ser utilizados
na consulta. Caso o PDSS não consiga encontrar todos os dados necessários para a consulta
ele deverá acessar a fonte de dados que os possuem. Os resultados gerados
A utilização do Active-Proxy-G está voltada para integração de dados que não são
atualizados com muita freqüência. Entretanto, a utilização de caches pode gerar um problema
de inconsistência dos dados nelas armazenados no caso de atualização, exclusão ou inserção
nas fontes de dados.
32
Mesmo realizando otimização, por meio de caches, e paralelismo das sub-consultas, a
composição dos sub-resultados é realizada de forma centralizada pelo componente QS, o que
pode gerar um sobrecarga neste nó do Grid.
2.5 MOCHA
MOCHA (Middleware Based On a Code SHipping Architecture) (MIDDLEWARE. . . ,
2000) é um middleware desenvolvido para interconectar fontes de dados distribuídas em uma
grande rede (RODRIGUEZ-MARTINEZ et al., 2000). MOCHA foi desenvolvido tendo como
base a idéia de que um middlware, para um ambiente distribuído, deve ser auto-extensível
(RODRIGUEZ-MARTINEZ; ROUSSOPOULOS, 2000). Ou seja, novos tipos de dados e
operadores de uma aplicação que utilize o middleware, necessários para o processamento de
uma consulta, são enviados para sites remotos, de uma maneira automática, pelo sistema. Isto
é feito enviando classes Java, que implementam estes tipos ou operadores, para um site
remoto, onde eles serão usados para manipulação de dados. Todas as classes Java estão
armazenadas em um ou mais repositórios do MOCHA, a partir dos quais são posteriormente
recuperadas e enviadas de acordo com suas necessidades.
Pelo fato de enviar operadores de consulta, o MOCHA pode produzir planos de
consultas que usam operadores para redução de dados (filtros) para executarem nas fontes de
dados, diminuindo com isso o tráfego que dados entre o site e o middleware.
A arquitetura do MOCHA, mostrada na Figura 8, é composta de quatro componentes
principais:
33
Figura 8. Arquitetura de Comunicação do Mocha.
Aplicação Cliente: uma aplicação Java usada para submeter consultas ao sistema;
Coordenador de Processamento de Consultas (QPC): fornece serviços tais como
análise de consulta, otimização de consulta, escalonamento de operador de consulta,
gerenciamento de catálogo e execução de consulta, além de ser o responsável por implantar
todas as funcionalidades necessárias para o cliente e para os sites remotos, a partir dos quais
os dados serão extraídos;
Fornecedor de Acesso aos Dados (DAP): fornece ao QPC um mecanismo de acesso
uniforme para uma fonte de dados remota, e executa alguns dos operadores na consulta
(aqueles que filtram os dados sendo acessados). Mesmo realizando filtros sobre os sub-
resultados a composição do resultado geral é realizada de forma centralizada pelo QPC;
Servidor de Dados: armazena um conjunto de dados de um site em particular.
No MOCHA, pode-se enxergar os DAPs como sendo wrappers, porém, com capacidade
de processamento de consulta, podendo utilizar tipos de dados e operadores específicos de
uma aplicação, que são enviados automaticamente, com o objetivo de auxiliar no
processamento de uma consulta. Para cada tipo de fonte existe um DAP específico, sendo
assim, um DAP só pode acessar a sua fonte de dados. Além disso, os DAPs são previamente
instalados em máquinas, podendo ser no próprio site remoto ou próximo a ele, nos quais serão
34
executados. Como as máquinas nas quais os DAPs estão instalados podem ficar
sobrecarregadas e um DAP não pode acessar outras fontes diferentes daquela a qual está
associado, o sistema integrador pode ter sua execução afetada, dado que o QPC pode ficar
parado esperando os dados proveniente de um DAP que está com o processamento lento ou
até mesmo parado. Além disso, os DAPS não possuem a funcionalidade de tradução entre
modelos. As sub-consultas enviadas para cada DAP já devem ter sido traduzidas para o
modelo local da fonte de dados acessada pelo DAP.
A comunicação entre os seus componentes, é feita usando RMI (Remote Method
Invocation). A comunicação baseada em RMI pode apresentar alguns problemas com relação
a tráfego sobre http e firewalls, além de cliente e servidor serem fortemente acoplados e terem
que ser desenvolvidos em Java.
2.6 OGSA-DAI
O projeto OGSA-DAI (Open Grid Service Architecture Data Access and Integration)
(ATKINSON; BAXTER; HONG, 2002; OPEN. . . , 2004a) tem o objetivo de criar um
middleware para permitir acesso e integração de fontes de dados utilizando um ambiente de
Grid. Ele permite a representação de banco de dados como serviços Grid, que são então
acessíveis a partir de outras máquinas de uma maneira segura e transparente. Assim,
baseando-se na idéia de serviços Grid, o OGSA-DAI expõe as fontes de dados para serem
acessadas por outras aplicações, tendo como base o middleware Globus Tookit (GLOBUS,
2004). A Figura 9 ilustra a arquitetura de serviços do OGSA-DAI.
Figura 9. Arquitetura de Serviço do OGSA-DAI (OPEN. . . , 2004a).
35
São definidos três principais tipos de serviços (Figura 9) para descoberta e acesso a
dados: Data Access and Integration Service Group Registry (DAISGR), Grid Data Services
Factories (GDSF) e o Grid Data Services (GDS). O DAISGR é um serviço persistente que
fornece a informação necessária para clientes descobrirem serviços e recursos dinamicamente.
O DAISGR lista as GDSFs que fornecem um método persistente para a criação de GDSs. A
Figura 10 representa este procedimento.
Figura 10. Descoberta e acesso a serviços no OGSA-DAI (OPEN. . . , 2004a).
O GDS fornece uma representação transient e statefull de alguns recursos de dados ou
serviços, sob os quais um número de atividades pré-definidas podem ser executadas
(MUNRO, 2004). Ele representa um link primário para o banco de dado sendo acessado,
podendo ser usado para funções de acesso, integração e entrega de dados. Assim, uma
instância de GDS pode interagir com um banco de dados para criar, recuperar, atualizar ou
remover dados. Os serviços oferecidos pelo GDS são a principal contribuição OGSA-DAI
(ALPDEMIR et al., 2003b).
O cliente interage com o GDS utilizando um documento escrito em XML, chamado de
Perform. Este documento contém descrições de uma ou mais atividades que o GDS deverá
executar. A Figura 11 ilustra o framework básico do OGSA-DAI para a interação com um
cliente.
36
Figura 11. Framework OGSA-DAI: Interação cliente - OGSA-DAI (QI, 2004).
Segundo (ATKINSON, 2004), muitos desafios importantes ainda permanecem em
aberto no OGSA-DAI, como, por exemplo: adaptação automática de esquemas e
transformação nos dados em resposta à mudanças nas fontes; otimização integrada de
computação, gerenciamento e movimentação de dados; apresentação em alto nível de
transformação, composição, análise de dados e operações.
2.7 OGSA-DQP
OGSA-DQP (Open Grid Service Architecture - Distributed Query Processor)
(ALPDEMIR et al., 2003a; OPEN. . . , 2004b) é uma extensão do OGSA-DAI que provê um
processador de consultas distribuído baseado em serviços. Ele é um framework para
integração de dados e orquestração de serviços no qual é possível fazer a coordenação e a
incorporação de serviços Web para efetuar análise e recuperação de dados (ALPDEMIR et al.,
2003a).
37
Figura 12. Camada arquitetural do OGSA-DQP (ALPDEMIR et al., 2003a).
O OGSA-DQP usa os serviços oferecidos pelo framework OGSA-DAI (Figura 12) para
acessar, de forma homogênea, as fontes de dados, abstraindo a suas possíveis
heterogeneidades. Em um nível mais baixo, a camada GT3 (Globus Toolkit 3) é usada tanto
pelo OGSA-DAI quanto pelo OGSA-DQP para criação de instâncias, acesso ao estado e
gerenciamento do tempo de vida das instâncias de serviços no Grid. A Figura 13 mostra a
interação entre os componentes OGSA-DQP e OGSA-DAI.
No OGSA-DQP, serviços utilizados na execução de consultas são enviados para nós do
Grid para criar paralelismo de programas de usuário. Operadores algébricos, tais como
exchange e operation-call, implementam comunicação entre os nós do Grid e invocação de
programas de usuário, respectivamente. O OGSA-DQP fornece dois serviços:
Grid Distributed Query Service (GDQS): O GDQS ou Coordinator é o principal ponto
de interação com os clientes. No momento da sua instanciação os metadados das fontes de
dados e outras informações de recursos computacionais necessários para compilar, otimizar,
particionar e escalonar o plano de execução de consultas sobre os nós do Grid. Ele é
construído sobre o Polar (SMITH et al., 2002). Ele também atua como um coordenador entre
a máquina de otimização/compilação de consultas e as instâncias GQES.
Grid Query Evaluation Service (GQES): O GQES ou Evaluator é usado pelo GDQS
para executar os planos de execução de consultas gerados pelo compilador, otimizador e
escalonador de consultas. Cada GQES avalia uma sub- plano de execução de consultas que
lhe foi enviado pelo GDQS. O número de instâncias GQES e sua localização no Grid são
38
especificados pelo GDQS baseado nas decisões tomadas pelo otimizador, e representado
como um escalonamento para partições de consulta (sub-planos). As instâncias GDES são
criadas e escalonadas dinamicamente e suas interações coordenadas pelo GDQS.
Figura 13. Interação entre os frameworks OGSA-DQP e OGSA-DAI (OPEN. . . , 2004b).
Para submeter uma consulta ao OGSA-DQP, uma aplicação cliente deve, assim como
no OGSA-DAI, embuti-la em um documento XML chamado Perform. Essa consulta é
compilada e otimizada pelo GDQS, criando assim um plano de execução de consulta. As sub-
consultas geradas, escritas na linguagem OQL (Object Query Language), são escalonadas
para serem executadas em diferentes instâncias GQES, de acordo com a árvore descrita por
esse plano. O GDQS cria instâncias GQES em seus nós de execução, e envia os sub-planos
para serem executados em seus respectivos GQES. GQES podem interagir com outras
instâncias GDS para obter dados. Os sub-resultados são retornados para o GDQS, que por sua
vez os compõem no resultado final de uma operação. Ao final da execução de todas as
operações pelos GDQS o resultado final é retornado para a aplicação cliente. Esta visão geral
das interações durante uma execução de consulta poder ser observada na Figura 14.
39
Figura 14. Interações durante uma execução de consulta no OGSA-DQP (ALPDEMIR et al., 2003a).
Assim como o OGSA-DAI, o OGSA-DQP possui algumas restrições que devem ser
explicadas. Dentre elas estão as que foram herdadas do próprio OGSA-DAI, já que o mesmo é
utilizado pelo OGSA-DQP, e outras pertencentes somente ao OGSA-DQP. Uma delas está
relacionada com a obtenção dos esquemas das fontes de dados, pois nenhuma integração de
esquemas e resolução de conflitos é suportada durante a importação dos esquemas. Os
esquemas importados são simplesmente acumulados e mantidos localmente. Isso pode
ocasionar dificuldades ao usuário final, pois ele terá que integrar, de maneira manual, os
esquemas e resolver conflitos semânticos e/ou estruturais entre os mesmos. Uma outra
restrição diz respeito ao plano de execução de consulta gerado pelo OGSA-DQP, o qual é
estático. Além disso, existe a possibilidade de um ou mais nós alocados para este plano
estático ficarem sobrecarregados, ou a fonte com a qual eles se comunicam não estar mais
respondendo. Neste sentido, no OGSA-DQP, não é possível fazer uma análise, em tempo de
execução, dos nós alocados no Grid para que, se necessário, seja feita a geração de um novo
plano e a realocação dos seus operadores. Pelo fato de todos os sub-resultados gerados pelos
GQES serem retornados para o GDQS para então serem gerados o resultado final de uma
operação, é possível que este componente se torne um gargalo para o sistema. O OGSA-DQP
suporta apenas a utilização de um modelo de dados e uma única linguagem de consulta
40
(OQL), ao contrário do CoDIMS que permite a configuração do modelo de dados e da
linguagem de consulta, dependendo da instância criada.
2.8 Características gerais dos sistemas
Os sistemas analisados apresentam algumas características em comum no que diz
respeito à estratégia de execução paralela de consultas.
De maneira geral, a partir da consulta enviada, os sistemas produzem um plano de
execução de consulta distribuído inicial, que descreve sub-consultas e operações a serem
executadas. É característica comum a todos os sistema a execução remota e paralela das sub-
consultas, entretanto, o escalonamento em tempo de execução de quais sites executarão as
sub-consultas só é suportado pelo CoDIMS-G e pelo Active Proxy-G.
Mesmo realizando a execução das sub-consultas de maneira paralela, os sistemas
apresentam uma deficiência quando o assunto é a integração dos sub-resultados gerados e a
composição do resultado final da consulta. Eles realizam as operações sobre os sub-resultados
de maneira centralizada em um único site. Em caso de consultas que envolvam várias fontes
de dados e necessitem de um alto poder de processamento, pode ser gerada uma sobrecarga
neste site, comprometendo assim a desempenho do ambiente como um todo.
Apesar do OGSA-DAI ser uma implementação de referência sobre acesso e integração
de dados do Global Grid Forum (GLOBAL. . . , 2004), ele não é utilizado no CoDIMS, pois,
não foram encontradas as funcionalidades de tradução de modelos, mapeamentos e
conversões. Mais especificamente para este trabalho, o OGSA-DAI não foi necessário, pois
não existem serviços para integração de dados provenientes de fontes heterogêneas e
distribuídas utilizando os recursos computacionais do ambiente de Grid.
De forma diferente dos trabalhos descritos neste capítulo, o CoDIMS apresenta-se como
um sistema integrador completo, provendo facilidades de resolução de conflitos através de
integração de esquemas, com conseqüente elaboração de um esquema global. Além disso, os
wrappers e operadores algébricos são implementados através da utilização de Grid Services,
que podem ser vistos como uma evolução de Web Services. Esta abordagem possibilita a
execução distribuída e paralela do Plano de Execução de Consultas (PEC), tornando possível
um melhor desempenho do sistema como um todo.
41
Além dos sistemas apresentados anteriormente, existem na literatura diversos outros
para integração de dados. Contudo, estes sistemas não possuem as características de
flexibilidade e configuração apresentadas no CoDIMS (BARBOSA, 2001), nem a distribuição
dos wrappers e operadores algébricos para a execução de forma paralela de todas as etapas de
uma consulta.
Uma melhor descrição desses e de alguns outros sistemas estudados pode ser encontrada
em (SILVESTRE; BIANCARDI; BARBOSA, 2004).
No próximo capítulo são apresentados os principais fundamentos relacionados a este
trabalho, e também algumas tecnologias utilizadas na especificação e implementação da
MECD.
42
3 Conceitos e Tecnologias
3.1 Processamento de Consultas
O processamento de consulta em um sistema de integração de dados é baseado nos dos
SGBDs, e é iniciado quando o usuário submete uma consulta ao sistema, interativamente ou
através de uma aplicação, utilizando uma linguagem de consulta de alto nível. De uma
maneira geral, o processamento de consultas envolve os seguintes passos, conforme (AYRES,
2003):
1. Tradução: analisa sintaticamente e traduz a consulta para uma expressão interna
equivalente;
2. Validação: valida a consulta com relação ao esquema do banco de dados
(metadados) garantindo que a consulta contém somente referências válidas para
objetos do banco de dados;
3. Otimização: mapeia o grafo da consulta para um plano de execução da consulta
otimizado de forma a minimizar as principais medidas de desempenho que são:
� Tempo de CPU, e quantidade de operações de entrada/saída;
� Custos de memória (alocação máxima e a relação tempo x espaço necessário para
alocação).
4. Execução: executa o plano de execução da consulta, gerado pelo otimizador,
através de uma Máquina de Execução de Consultas (MEC).
Estes passos podem ser sub-divididos ou agrupados de acordo com a implementação do
SGBD.
Ainda segundo (AYRES, 2003), a adoção do processamento distribuído e/ou paralelo na
maioria dos SGBDs faz-se necessária pelos principais motivos:
43
• Desempenho (speed-up): os SGBDs devem lidar cada vez mais com o aumento da
complexidade das consultas e do tamanho do banco de dados;
• Escalabilidade (scale-up): devido ao crescimento do banco de dados, as empresas
necessitam de uma maneira fácil de escalar seus sistemas (hardware e software) para
acompanhar este crescimento;
• Disponibilidade (availability): significa manter o banco de dados o maior tempo
possível em funcionamento para suportar sua utilização 24 horas x 7 dias em
aplicações críticas tais como: bancos, companhias aéreas, comércio eletrônico, etc.
Como há vários componentes semelhantes, pode-se explorar a replicação dos dados
aumentando a disponibilidade e reduzindo o risco de falhas.
A motivação fundamental por trás do processamento distribuído é ser capaz de resolver
da melhor maneira os grandes e complexos problemas com que nos defrontamos hoje, usando
uma variação da famosa regra de dividir e conquistar (ÖZSU; VALDURIEZ, 2001). Sob um
ponto de vista de economia, a computação distribuída proporciona um método econômico
para se conseguir maior poder de computação. Com base nesses fatores, sistemas de banco de
dados distribuídos surgiram como uma evolução dos bancos de dados centralizados, visando,
entre outros objetivos, tornar o processamento de consultas mais eficiente.
Os conceitos e problemas encontrados em processamento de consultas em sistemas de
integração de dados são basicamente os mesmos de banco de dados distribuídos. Assim, serão
apresentados a seguir os conceitos de processamento de consulta em banco de dados
distribuídos.
3.2 Processamento de Consultas em SGBDs Distribuídos
Um banco de dados distribuídos é uma coleção de vários bancos de dados logicamente
inter-relacionados e distribuídos por uma rede de computadores. Um Sistema de Gerência de
Banco de Dados Distribuídos (SGBDD) é um sistema de software que permite a gerência do
banco de dados distribuídos e que torna a distribuição (de controle e de dados) transparente ao
usuário (ÖZSU; VALDURIEZ, 2001). Sob o ponto de vista do usuário, um SGBDD deve se
parecer exatamente como um SGBD não distribuído, no sentido que os bancos de dados
44
distribuídos podem ser acessados por qualquer um dos nós. Segundo (DATE, 2004), é
desejável que um SGBDD possua certas características tais como:
• Grande autonomia dos SGBDs locais nos sites, os quais devem ser tratados como
iguais e devem depender, o mínimo possível, de um site central;
• Processamento distribuído de consultas, ou seja, as consultas submetidas a um site
devem ser otimizadas e podem ser executadas em outros sites, se necessário;
• Transparência no acesso a dados distribuídos (fragmentos e réplicas);
• Independência de plataforma de hardware, de sistema operacional, de rede e de
SGBD local.
Existem muitas arquiteturas propostas na literatura que implementam gerência de banco
de dados distribuídos. Em (ÖZSU; VALDURIEZ, 2001) utiliza-se uma classificação mais
geral baseada em três dimensões: autonomia, distribuição e heterogeneidade. Atualmente,
muitos sistemas se baseiam na arquitetura cliente-servidor, na qual existe um banco de dados
armazenado num computador servidor e as consultas são iniciadas a partir de computadores
clientes. Contudo, existem variações nesta arquitetura dependendo da cardinalidade do
relacionamento entre clientes e servidores (KOSSMANN, 2000; DATE, 2004). Na arquitetura
cliente-servidor com transparência de distribuição, o cliente pode obter acesso a muitos
servidores simultaneamente, isto é, cada solicitação individual de banco de dados pode
combinar dados de vários servidores, sendo possível dentro de uma única solicitação,
combinar dados de dois ou mais servidores. Neste caso o usuário não precisa saber onde os
fragmentos estão armazenados. Além disso, a gerência do processamento distribuído é de
responsabilidade do servidor para o qual o cliente submeteu a sua consulta. Este servidor por
sua vez, processará a consulta de duas formas possíveis:
• de forma centralizada: o servidor executa toda a consulta utilizando os dados dos
outros servidores envolvidos na consulta, ou;
• de forma distribuída: o servidor divide a consulta e submete as sub-consultas aos
respectivos servidores de acordo com os dados envolvidos.
Atualmente, existem muitas pesquisas relacionadas às arquiteturas cliente/servidor com
processamento distribuído, em particular, a arquitetura Ponto-a-Ponto (Peer to Peer)
45
(MILOJICIC, 2003) onde cada site pode agir como um servidor, processando uma consulta de
forma distribuída, ou como um cliente, iniciando uma consulta.
Um dos principais objetivos do processamento de consultas distribuído é reduzir, ao
máximo possível, o custo de comunicação (transporte de dados, de mensagens, etc.) entre os
sites envolvidos numa consulta. Este custo pode variar de acordo com a topologia da rede,
mas passa a ser mais importante que os outros dois existentes apenas no processamento
centralizado, que são: custo de entrada/saída e de processamento. Para que o otimizador
global decida em qual site cada operação será executada, ele deverá considerar algumas
questões, tais como:
• Executar as operações em sites com maior poder de processamento, mas sem
sobrecarregá-los;
• Os dados devem ser processados em sites mais próximos possíveis dos seus;
• Deve-se balancear o volume de dados a ser transportado com o custo total de
processamento (custo de transmissão mais o custo de processamento em cada site).
De uma maneira geral, o processamento de consultas envolve a criação de um plano de
execução. Ele descreve os relacionamentos entre operadores algébricos que deverão ser
executados durante o seu processamento para geração do resultado final da consulta. Os
operadores algébricos são implementados de modo a compor uma álgebra de um determinado
modelo de dados. No caso de operadores criados para integração de relações do modelo
relacional, a álgebra gerada é a Álgebra Relacional, descrita a seguir:
3.3 Álgebra Relacional
A álgebra relacional consiste na criação de uma nova relação a partir de uma ou duas
relações já existentes, associadas com um conjunto de operações (SILBERSCHATZ;
KORTH; SUDARSHAN, 2006). A criação das novas relações é obtida através da aplicação
de operações como seleção, projeção, produto cartesiano e junção natural.
A operação de seleção determina quais tuplas satisfazem uma condição. Desta forma
podemos criar um novo subconjunto de elementos (relação). As condições são criadas
utilizando as comparações =, ≠≠≠≠, <, ≤≤≤≤, > e ≥≥≥≥ e os conectivos lógicos e (^) e ou (v). A operação
46
de seleção é representada pela letra grega minúscula sigma (σ) e os predicados (condições)
aparecem subscritos.
A operação de projeção determina quais atributos de uma relação são necessários para a
execução da consulta, descartando os não necessários. Como podem ser gerados elementos
replicados, a operação de projeção também tem o objetivo de eliminar esses elementos
duplicados. A operação de projeção é representada pela letra grega minúscula pi (π) e os
atributos aparecem subscritos.
A operação de produto cartesiano permite que atributos de duas relações sejam
combinados. A combinação dos elementos de cada relação resulta em um conjunto onde cada
tupla de uma relação foi combinada com todas as tuplas da outra relação. O tamanho desse
conjunto, em linhas, é dado pelo número de tuplas existente na relação A multiplicado pelo
número de tuplas existente da relação B, e em colunas pela soma do número de atributos de A
mais B. A operação de produto cartesiano é representada por (x).
A operação de junção natural tem como objetivo simplificar a operação produto
cartesiano: ela incorpora as operações produto cartesiano e seleção. O produto cartesiano é
feito utilizando o critério de equivalência entre os atributos que existem nas duas relações.
Após o produto cartesiano removem-se os atributos duplicados. A operação de junção natural
é representada por (|X|).
Para que uma MEC possa suportar a execução das operações da álgebra relacional é
necessário que ela contenha operadores algébricos que implementem cada uma das operações
descritas pela álgebra.
3.4 Operadores
Os operadores de uma MEC podem ser agrupados em duas categorias:
• Operadores algébricos: representam os algoritmos de implementação as operações
algébricas correspondentes ao plano físico da consulta;
• Operadores de controle: são meta-operadores que estabelecem a comunicação entre
os operadores algébricos.
47
A principal diferença entre os dois grupos é o fato de que os operadores algébricos
manipulam dados e os de controle simplesmente transferem os dados entre os operadores
algébricos sem processá-los. A Figura 15 exemplifica o relacionamento entre operadores
algébricos (op1 e op2) e de controle (C1) dentro de um fragmento de PEC.
Figura 15. Operadores Algébricos e de Controle.
Uma álgebra, no contexto de banco de dados, consiste num conjunto de operadores
lógicos pertencentes a um modelo de dados, que definem quais consultas podem ser expressas
neste modelo de dados (GARCIA-MOLINA et al., 2000). Assim, podemos criar dois
conjuntos de operadores algébricos: lógicos e físicos. Os operadores lógicos são comuns a
todas as MECs pois são operadores abstratos, sendo eles: seleção, projeção, produto
cartesiano, junção etc. Os operadores físicos são os operadores que a MEC realmente
implementam e que os otimizadores podem utilizar. Os operadores lógicos são mapeados em
um ou mais operadores físicos. Por exemplo, o operador lógico junção natural (natural join)
pode ser implementado como uma junção de laço aninhado (loop nested join) ou uma junção
união (merge join). O mapeamento entre operadores lógicos e físicos é realizado pelo
otimizador e é, na maioria dos SGBDs, uma tarefa complexa (SELINGER et al., 1979) pois
envolve a escolha correta e eficiente dos operadores físicos que farão parte do PEC. Quanto
mais operadores físicos para um mesmo operador lógico a MEC possuir, maior será o espaço
de busca de possíveis planos do otimizador, devido ao fato que diferentes algoritmos
geralmente possuem custos de execução diferenciados.
A junção de laço aninhado é uma das formas mais simples de executar a junção natural
de duas relações. A junção das relações com este operador é feita combinando todas as tuplas
de uma relação com todas as tuplas da segunda relação. Supondo duas relações, R e S, a
combinação resulta em uma nova relação (R |X| S) com tamanho igual ou menor que o
48
tamanho(R) * tamanho(S). O algoritmo deste operador é composto por dois comandos de loop
aninhados. Os atributos que estão repetidos podem ser eliminados através da operação de
projeção (GARCIA-MOLINA et al., 2000). A Figura 16 mostra o algoritmo utilizado no
operador junção de laço aninhado onde tr é uma tupla que pertence à relação R, ts é uma tupla
que pertence à relação S e tr.ts é uma tupla que pertence a relação R |X| S.
for each tr of R do begin
for each ts of S do begin
teste o par(tr, ts) para ver se satisfazem a condição
if satisfazem then
adicionar tr.ts ao resultado
end;
end;
end;
Figura 16. Algoritmo do operador junção de laço aninhado (SILBERSCHATZ; KORTH; SUDARSHAN, 2006).
ordenar r por r[AtribJunção];
ordenar s por s[AtribJunção];
pr := primeira tupla de r;
ps := primeira tupla de s;
while (ps ≠ nulo and pr ≠ nulo) do begin
ts := tupla de ps;
Ss := {ts};
ps := recebe próxima tupla de s;
acabou := falso;
while not acabou and ps ≠ nulo do begin
ts’ := tupla de ps;
if ( ts’[AtribJunção] = ts[atribJunção] ) then begin
Ss := {Ss} + ts’;
ps := próxima tulpa de s;
else
acabou := verdadeiro;
end;
end;
tr := tupla de pr;
while pr ≠ nulo and tr[AtribJunção] < ts[AtribJunção] do begin
pr := próxima tupla de r;
tr := tupla de pr;
end;
while pr ≠ nulo and tr[AtribJunção] = ts[AtribJunção] do begin
for each ts in Ss do begin
resultado := tr |x| ts; end;
pr := próxima tupla de r;
tr := tupla de pr
end;
Figura 17. Algoritmo do operador junção união (SILBERSCHATZ; KORTH; SUDARSHAN, 2006).
Já na junção união, a junção das relações é realizada de outra forma. A junção união
possui este nome, pois a idéia principal de seu algoritmo é semelhante o algoritmo de
49
ordenação merge sort. A Figura 17 ilustra o algoritmo, onde [AtribJunção] são os atributos
comuns as duas relações. O algoritmo inicialmente ordena S relações pelo atributo em comum
entre as duas relações. Depois, o algoritmo associa um ponteiro a tupla inicial de cada relação.
Conforme o algoritmo prossegue, os ponteiros avançam através das relações. Um grupo de
relações que possuem o mesmo valor para os atributos comuns as duas relações é armazenado
em Ss. Finalmente as tuplas correspondentes da outra relação são lidas e processadas
(GARCIA-MOLINA et al., 2000).
3.5 Interface dos Operadores
A construção de um PEC exige que os operadores da MEC relacionem-se formando
pares consumidor-produtor. Para isso, faz-se necessário implementar esses operadores usando
uma interface comum. Todo o fundamento sobre MECs está baseada na interface denominada
iterator (GRAEFE, 1993). Esta interface apresenta as três operações:
• Open: prepara o operador para produzir dados;
• Next: produz um dado para o operador consumidor;
• Close: finaliza a execução do operador.
A interface favorece a extensibilidade dos operadores, já que a implementação de um
operador não se necessita conhecer o operador para o qual produzirá ou do qual consumirá
dados. Como conseqüência, um PEC pode ser escalonado em qualquer tipo de árvore e
nenhum operador é afetado pela complexidade de um outro operador ou do PEC como um
todo. Cada operador do PEC é escalonado pelo seu consumidor e escalona seu(s) produtor(es)
através das chamadas aos métodos open, next e close. Considerando a Figura 18, o operador 1
é consumidor do operador 2, que por sua vez é consumidor dos operadores 3 e 4. Por
associatividade, os operadores 3 e 4 são produtores do operador 2 e o operador 2 é produtor
do operador 1.
50
Figura 18. Relacionamentos entre operadores produtores e consumidores.
Através da interface iterator, cada operador (algébrico ou de controle) deve
implementar seu algoritmo baseando-se nestas três operações básicas da interface. Por
exemplo, a Figura 19 mostra uma implementação do operador de junção NestedLoop baseado
nesta interface.
/* R e S são as entradas */
/* r,s,t são tuplas definidas a partir de um modelo de dados */
Open (R,S); begin
R.Open () ; S.Open () ; s := S.Next () ;
end;
Next (R, S) : Tupla; begin
repeat
r := R.Next () ;
if (r = null) then begin // R está esgotado para o valor atual de s
R.Close () ;
s := S.Next () ;
if (s=null)
return null; // R e S estão ambos esgotados
R.Open () ;
r := R. Next () ;
end;
until ( pode_juntar(r,s) ) ;
t := juntar (r,s);
return t;
end;
Close (R,S); begin
R.Close () ; S.Close () ;
End;
Figura 19. Implementação da interface iterator para o NestedLoop (AYRES, 2003).
A implementação da interface iterator pode sofrer algumas variações, tais como: (i) o
método open pode ser opcional ou usado apenas para produzir o primeiro dado do operador;
(ii) o método next pode antecipar a produção de vários dados (bloco) e (iii) a indicação de
término dos dados pode ser feita por um método específico (por exemplo: hasnext
(BERCKEN et al., 2001) ou pelo próprio método next retornando valor nulo. Além disso,
51
pode ser conveniente que as operações da interface possam receber (via parâmetro) o
operador responsável pela sua chamada, para que seja possível executar alguma tarefa
(WAAS, 1999). A interface iterator pode ser adaptada para outras interfaces tais como a
interface ResultSet, nativa da linguagem Java.
3.6 Planos de Execução de Consultas (PEC)
Um PEC é composto por um conjunto de operadores que se relacionam de forma a
produzir o mais cedo possível, os resultados da consulta submetida ao SGBD. A maioria dos
SGBDs representam um PEC através de uma árvore, onde os nós são operadores, as folhas
são as fontes de dados, e os arcos são os relacionamentos entre os operadores na forma
produtor-consumidor. Portanto, cada operador de um PEC exerce o papel de produtor de
dados e/ou de consumidor de dados. A Figura 20 ilustra um PEC contendo operadores
(algébricos e de controle) relacionados na forma produtor-consumidor, onde as setas indicam
o fluxo dos dados no sentido produtor-consumidor.
Figura 20. Exemplo de um PEC.
Na geração de um PEC, o otimizador escolhe a melhor combinação de operadores
algébricos obtendo assim um PEC intermediário. Para completar o PEC final, é necessário
incluir operadores de controle, permitindo isolar os operadores algébricos de detalhes de
52
implementação, tais como: leitura de disco, transferência pela rede, materialização dos dados,
comunicação entre processos etc.
A abordagem de utilização de operadores de controle proporciona, aos algoritmos dos
operadores algébricos, a independência de implementação uma vez que eles podem ser
concebidos sem a preocupação com o ambiente de implementação (GRAEFE, 1993).
Os PECs podem assumir duas topologias: Linear (à esquerda ou à direita) e Ramificada
(mais conhecida como Bushy), como ilustrado na Figura 21. Os planos lineares se diferenciam
basicamente quanto ao ramo da árvore onde fluem os dados. É possível ainda existir um PEC
na forma de um grafo direcionado. Neste caso, a parte comum pode ser executada
separadamente e seus resultados intermediários são, em geral, materializados e lidos
repetidamente.
Figura 21. Exemplos de Topologias de PECs.
A escolha da topologia a ser adotada pela MEC influencia o processo de otimização e
de execução de consultas.
• Quanto ao processo de otimização, a utilização de planos lineares (i.é., planos de
topologia linear), em consultas com predicados, torna-se bastante interessante na
medida em que cada operação de redução (seleção ou junção) beneficia-se da
operação subseqüente, reduzindo o número de dados da relação intermediária e
acarretando menor tempo de execução, o que nem sempre acontece com a utilização
de planos bushy (i.é., planos de topologia bushy). Além disso, o espaço de busca
coberto por planos bushy é extremamente maior do que o produzido por planos
53
lineares. Embora isto acarrete uma probabilidade maior de obtenção de um PEC
ótimo, o tempo gasto neste processo de otimização pode torná-lo inviável, em
contraste com o tempo de execução de consultas pouco complexas.
• Quanto ao processo de execução, a utilização de planos bushy favorece o paralelismo
horizontal e a distribuição, enquanto que os planos lineares favorecem o paralelismo
vertical.
� Na estratégia de paralelismo horizontal distribuído, os PECs são expressos através
de árvores bushy compostas de sub-consultas submetidas aos sites contendo os
dados distribuídos. Neste caso, cada sub-consulta, a ser executada por um site,
representa um PEC independente e paralelizável. A adoção deste paralelismo
minimiza, em alguns casos, o tempo de duração da consulta (tempo de resposta),
em detrimento do tempo total de execução (soma dos tempos gastos em cada
operador), que pode aumentar na medida em que um operador não se beneficia
das reduções de dados de outro operador, executado em paralelo;
� Na estratégia de paralelismo vertical, utiliza-se uma árvore linear e aloca-se cada
operador em um processador diferente. Dados que atendem ao predicado de uma
operação são passadas ao próximo operador que inicia seu processamento. Dessa
forma, a partir do instante em que um dado passa por todas as operações, o
conjunto de processadores alocados mantém-se em carga constante processando
as operações em paralelo. Há um ganho de execução na medida em que as
operações, nos nós mais altos da árvore de execução, processam apenas o sub-
conjunto de dados produzido pelas demais operações. Por outro lado, a
dependência de execução entre os operadores pode apresentar desequilíbrio (skew)
na distribuição de carga entre os processadores na medida em que variações, em
tempo de execução (ex: seletividade, disponibilidade de fontes de dados, etc),
impeçam a progressão uniforme dos dados pela árvore de execução.
A estratégia de execução dos operadores de um PEC é baseada num modelo de
execução utilizado pela MEC que, por sua vez, está fortemente relacionado com um
determinado cenário de execução de consultas.
54
3.7 Modelos de Execução de Consulta
As MECs são construídas com o objetivo de suportar um modelo de execução pré-
definido em sua arquitetura. O modelo que a MEC irá seguir é determinado pelo cenário em
que ela irá atuar. Dessa forma, o conjunto de operadores que o otimizador pode utilizar na
criação dos PECs se torna limitado, uma vez que esse conjunto é definido no código da MEC.
As MECs voltadas para middlewares de integração realizam acesso à fontes de dados
heterogêneas e distribuídas em cenários muitos diversificados. Portanto a MEC deve ter a
capacidade de ser configurada para cada cenário.
Neste trabalho, a configuração da MEC foi feita tendo como base os conceitos de
características, módulos e modelos de execução descritos em (AYRES, 2003). Esses
conceitos se encaixam como níveis de abstração onde os mais abstratos são o cenário da
aplicação e a MEC, e os menos abstratos são os modelos de dados e as tuplas. Esses níveis
são relacionados na Tabela 1.
Nível Conceito Físico Conceito Lógico 1 MEC Cenário da Aplicação 2 PEC Modelo de Execução 3 Módulo Características de Execução 4 Operadores Execução 5 Tuplas Modelos de Dados
Tabela 1: Níveis de abstração da execução de consulta (AYRES, 2003).
O nível 1, o maior, tem como implementação a MEC configurada para cada cenário. No
nível 2, um PEC implementa um modelo de execução utilizando diferentes módulos. No nível
3, um módulo implementa um determinado estado de uma característica de execução,
combinando um ou mais operadores. No nível 4, os operadores implementam o fluxo das
tuplas através do uso das operações de controle e algébricas. No nível 5, o menor, as tuplas de
dados são implementadas com base em uma ou mais estruturas de dados.
A MECD foi desenvolvida tendo como plataforma uma infra-estrutura de Grid, sendo
assim, torna-se necessário a apresentação de alguns conceitos referentes a tecnologia de Grid.
55
3.8 Grid
Um Grid é uma infra-estrutura de hardware e software que permite acesso a
capacidades computacionais geograficamente distribuídas, de forma confiável, consistente,
econômica e transparente. O conceito é relativamente antigo (meados da década de 90),
contudo, vem sendo apresentado com uma nova dinâmica (FOSTER; KESSELMAN, 1997,
1999; FOSTER; KESSELMAN; TUECKE, 2001; FOSTER, 2002; FOSTER et al., 2002;
FOSTER; GANNON, 2003), em que se pode utilizar a capacidade de computação dos
recursos disponíveis a serem compartilhados (ex. armazenamento, CPU) sem ter que se
preocupar de onde vem e como é mantida, fazendo uma metáfora às redes elétricas, nas quais
um usuário utiliza a eletricidade sem ao menos saber na qual ela foi gerada, sendo totalmente
transparente aos seus usuários. Nesse sentido a tecnologia de Grid visa fornecer o acesso
compartilhado a recursos de computação, de uma maneira a quem for utilizá-los não necessite
de conhecer os detalhes dos componentes computacionais envolvidos, onde eles estão
localizados, como gerenciá-los, como corrigir erros ou mesmo como efetuar uma atualização.
Dessa forma, a infra-estrutura Grid conecta diversos recursos de hardware, software e dados
através de uma rede, fornecendo um acesso flexível e seguro para aplicações e dados
(MALAIKA; EISENBERG; MELTON, 2003).
Grid visa suportar a demanda das organizações virtuais para um compartilhamento
coordenado de recursos e a resolução de problemas em escala global, tais como aquelas que
necessitam de computação intensiva e que manipulam muitos dados (GOBLE; ROURE,
2002). Uma Organização Virtual (OV) (FOSTER; KESSELMAN; TUECKE, 2001) pode ser
vista como uma infra-estrutura que habilita o compartilhamento de recursos de forma
coordenada, transparente, segura e flexível entre coleções dinâmicas de indivíduos ou
instituições. Ou seja, chama-se de Organização Virtual quando existem participantes que
desejam compartilhar recursos para poder concluir uma tarefa. Além disso, o
compartilhamento está além de apenas troca de documentos, podendo envolver acesso direto a
software remoto, computadores, dados, sensores dentre outros recursos.
De uma forma simples, um ambiente de Grid é aquele no qual as aplicações podem
utilizar múltiplos recursos computacionais que podem estar distribuídos geograficamente.
Mais recentemente, têm-se os recursos de dados, como por exemplo, os bancos de dados.
56
Levando em consideração que cada nó de um Grid executa tarefas distintas, as
aplicações mais adequadas ao Grid são as que possuem tarefas independentes, ou seja, tarefas
que não dependem da execução de outras e podem ser executadas em qualquer ordem e, a
princípio, em qualquer nó do Grid.
Da mesma maneira que a Internet, a computação em Grid teve seu desenvolvimento nas
comunidades acadêmicas e de pesquisa. Entre os fatores que influenciaram o seu
desenvolvimento, podem ser considerados importantes:
• com o fato de pesquisas incluírem um grande número de pesquisadores e estes,
geralmente, estarem localizados em locais dispersos, notou-se a necessidade de criar
um ambiente computacional para compartilhar recursos e resultados dinamicamente;
• a importância de escalonar serviços e dados facilmente, para poder acomodar uma
quantia cada vez maior de dados e poder computacional;
• redução de custos.
Esses requisitos são suportados pela arquitetura dos Grids, na qual é possível escalonar,
de maneira dinâmica, os recursos computacionais. Além disso, um Grid pode englobar
máquinas localizadas em lugares diferentes, utilizando seus recursos ociosos. Com isso, é
possível utilizar hardware comum, não sendo necessário fazer a utilização de máquinas de
grande porte como supercomputadores.
3.8.1 Utilização de Grid
Sistemas em Grid são utilizados para os mais diversos fins. Entre alguns dos problemas
que os sistemas em Grid são capazes de resolver encontram-se os problemas de “grande
desafio” (Grand Challenge). Um problema de grande desafio é um tipo específico de
problema para o qual não existe solução conhecida e que se caracteriza, basicamente, por pelo
menos uma das seguintes características:
• requer avanços significativos na capacidade requerida para resolvê-lo;
• deve ter uma solução, idealmente deve fornecer uma maneira plausível de quantificar
o progresso em relação à solução final do problema;
57
• a solução do problema tem um impacto econômico ou social significativo.
Entre os problemas de grande desafio, pode-se citar: enovelamento de proteínas
(processo pelo qual uma proteína assume sua forma funcional), modelagens financeira e
climática, simulações complexas em geral, etc.
Em geral, estes problemas caracterizam-se por serem grandes demais para serem
processados por um único Cluster ou supercomputador. De certa forma, neste tipo de
problema é possível obter uma vazão de dados e processamento muito maior através da
utilização de um sistema em Grid do que utilizando um supercomputador de capacidade de
processamento semelhante.
3.8.2 Vantagens de Computação em Grid
Com relação aos benefícios que o Grid pode trazer, pode-se citar, segundo (BERSTIS,
2003), os seguintes:
• Explorar recursos subutilizados e recursos adicionais: A princípio, uma aplicação
pode ser executada em qualquer máquina que faça parte de um Grid, desde que esta
possua acesso a determinados recursos solicitados pela aplicação. Pode-se escolher
esta máquina utilizando-se diversos parâmetros, como por exemplo: a que estiver
com menor carga de processamento, a que possuir disponível certo tipo de
dispositivo ou determinados dados;
• Capacidade de processamento paralelo: Outra característica interessante é a
possibilidade de melhor utilizar o processamento paralelo através de Grids. Em
alguns tipos de aplicações tais como científicas, financeiras, processamento de
imagens e simulações, a utilização de processamento paralelo pode trazer bastante
ganhos com relação ao desempenho. Uma aplicação que faça uso de algoritmos e
técnicas de programação paralela pode ser dividida em partes menores e estas podem
ser separadas e processadas independentemente. Cada uma destas partes de código
pode ser executada em uma máquina distinta no Grid, melhorando o desempenho;
• Dispositivos e Organizações Virtuais: A colaboração entre os mais diversos tipos de
usuários e aplicações é outra capacidade que pode ser desenvolvida com o advento
58
dos Grids. Recursos e máquinas podem ser agrupados e trabalharem juntos formando
o que pode ser chamado de uma Organização Virtual;
• Confiabilidade: Existem diversas maneiras de aumentar a confiabilidade em um
sistema computacional. Processadores e discos são duplicados, de modo que caso um
falhe o outro assuma seu lugar, fontes de energia e circuitos redundantes, geradores
elétricos, entre outros. Todas estas formas comprovadamente aumentam a
disponibilidade e a confiança em um sistema, mas seus custos podem torná-las
impraticáveis. Utilizando-se uma abordagem baseada em Grids, com máquinas
espalhadas em diversos lugares diferentes, quando uma falha atinge uma parte do
Grid as demais podem continuar sua operação normalmente. Sistemas de
gerenciamento podem executar novamente processos importantes caso seja detectada
alguma falha ou estes podem ser executados redundantemente para garantir sua
consistência.
3.8.3 Deficiência
Uma deficiência com relação à computação em Grid está relacionada a redes de
computadores com baixa taxa de transmissão de dados. Isso constitui uma espécie de gargalo
com relação àquelas aplicações que necessitam transferir grandes quantidades de dados.
Assim, a multiplicidade das velocidades das diversas redes de computadores implica em
alguns pontos de gargalo, o que acaba comprometendo o desempenho do supercomputador
virtual.
3.8.4 Algumas Comparações
3.8.4.1 Grid x Cluster
Uma das controvérsias existentes em torno dos sistemas em Grid deve-se ao fato destes
serem comumente confundidos com Clusters. Porém, antes de definir as diferenças entre um
Cluster e um Grid é preciso conhecer a definição de um Cluster e como este trabalha. A
definição de (BUYYA, 2002) para Cluster é a seguinte:
59
“Um conjunto de múltiplos nós interconectados que trabalham cooperativamente juntos
como um único recurso”.
Ao contrário dos Grids, os recursos de um Cluster são pertencentes a uma única
organização e eles são gerenciamentos por um recurso de gerenciamento e escalonamento
centralizado. Isto significa que os usuários de um Cluster têm que passar por um sistema
centralizado que gerencia a alocação de recursos para os trabalhos das aplicações.
Através dessa definição podem-se afirmar quais são os pontos chaves nos quais os
Clusters se diferem dos Grids (BUYYA, 2002):
• Os Clusters são fisicamente centralizados, isto é, os membros (nós) de um Cluster
encontram-se dispersos sobre uma mesma área física (um prédio, sala, datacenter
etc.);
• Os recursos (poder de processamento, memória etc.) de um Cluster são
administrados pela organização responsável pelo Cluster. Em um Grid, a
administração deste recurso cabe a cada um dos responsáveis pelos nós do Grid.
Além disso, é possível identificar alguns dos outros aspectos que definem a diferença
entre ambos (BUYYA, 2002):
• Os Grids, devido a sua estrutura descentralizada, têm uma disposição de recursos
computacionais muito mais heterogênea do que um Cluster. Ou seja, a variação do
poder de processamento, memória, disco, etc dos membros de um Grid é muito
maior do que aquela encontrada nos membros de um Cluster (onde o que se deseja
geralmente é o contrário, caso contrário, poderia configurar-se como um gargalo);
• Os membros (nós) de um Grid não precisam estar permanentemente interconectados;
• Clusters tendem a serem utilizados para solução de problemas lineares, ao passo que
Grids devem ser utilizados para sistemas capazes de serem processados em paralelo.
Por fim, é importante ressaltar que é possível criar Grids utilizando Clusters como
membros, entretanto o contrário não é possível.
60
3.8.4.2 Grid x Peer To Peer (P2P)
Segundo (LEDLIE, 2003), tanto sistemas Peer to Peer quanto sistemas em Grid
compartilham de um conjunto de problemas em comum, no que diz respeito à computação
distribuída, com foco em compartilhamento de recursos em larga-escala. A definição mais
formal de sistemas Peer To Peer encontrada em (THEOTOKIS; SPINELLIS, 2004) é:
“Sistemas distribuídos que consistem de nodos interconectados, com capacidade de se
auto-organizarem em topologias de rede, com o objetivo de compartilhar recursos como
ciclos de CPU, armazenamento e bandwidth, capazes de se adaptar a falhas e acomodar
populações transientes de nodos, enquanto mantém conectividade e performance aceitáveis,
sem depender da intermediação ou suporte de uma autoridade (servidor) central.”
Ou seja, sistemas Peer To Peer, apresentam soluções que não buscam padrões para
protocolos e infra-estrutura, para prover interoperabilidade, enquanto Grid está baseado em
infra-estrutura de serviços padronizados.
Contudo, à medida a tecnologia de Grid torna-se difundida ela necessita de soluções
para prover auto-organizaçao, tolerância à falhas, escalabilidade, etc. O resultado será uma
nova classe de tecnologias combinando elementos de ambas: Escalabilidade, auto-adaptação,
recuperação diante de falhas e infra-estrutura persistente e padronizada para
interoperabilidade (FOSTER; IAMNITCHI, 2003).
3.8.4.3 Grid x Supercomputadores
Supercomputador é um termo, de uso amplo, utilizado para definir recursos
computacionais de altíssimo desempenho. Independente da sua estrutura física e lógica, este
termo é utilizado para definir recursos computacionais como: Clusters, Grids etc.
Supercomputadores, do ponto de vista de uma estrutura física e computacional única,
também podem fazer parte de um Grid.
61
3.8.5 Ferramentas de Desenvolvimento
Existem algumas ferramentas disponíveis que habilitam o desenvolvimento de
aplicativos que fazem uso da arquitetura de Grids. Dentre elas podemos destacar: OurGrid
(CIRNE, 2005), Condor (THAIN et al., 2004) e Globus Toolkit (GLOBUS, 2004). Dessas, a
que tem alcançado grande popularidade, principalmente por ser desenvolvida a partir de
padrões abertos e mantida por comunidades de programadores, é o Globus Toolkit, que é
resumido a seguir.
3.8.5.1 Globus Toolkit
O Globus Toolkit é um conjunto de ferramentas e bibliotecas de software que dão
suporte à arquitetura e às aplicações em Grid. É um projeto desenvolvido pelo Argnone
National Laboratory (ANL) e pela University of Southern California. É mantido por uma
comunidade de programadores, The Globus Alliance (GLOBUS, 2004), e é baseada em
arquiteturas e códigos abertos. Com ele é possível implementar segurança, busca de
informações, gerenciamento de recursos e de dados, comunicação, detecção de falhas e
portabilidade (DANTAS; ALLEMAND; PASSOS, 2003). Segundo (FOSTER;
KESSELMAN, 1997), os serviços no Globus são baseados em um modelo conhecido como
Hourglass (Ampulheta). Nesta analogia, os serviços locais encontram-se na parte inferior da
ampulheta, enquanto que os serviços globais estão na parte superior. Os serviços fornecidos
pelo Globus ficam localizados no gargalo da ampulheta. Os componentes do conjunto de
ferramentas Globus podem ser usados tanto independentemente quanto em conjunto no
desenvolvimento de aplicações e de ferramentas de programação em Grid. Para cada
componente existe uma API em linguagem C ou Java definida para facilitar o uso pelos
desenvolvedores. A Figura 22 demonstra a estrutura do Globus Toolkit.
62
Figura 22. Uma visão geral do sistema Globus Toolkit (FERREIRA et al., 2002).
As versões mais atuais do Globus Toolkit (GT) (versão 3 em diante) são baseadas no
conceito de Grid Services, uma expansão do conceito de Web Services. Os principais
conceitos e padrões nos quais está baseado o GT3, versão usada neste trabalho, serão
discutidos a seguir.
• OGSA (Open Grid Services Architecture): A utilização de padrões é uma das
principais necessidades para que os sistemas em Grid sejam amplamente utilizados.
A arquitetura da computação em Grid é definida pela OGSA, desenvolvida pelo
Global Grid Forum (GGF) (GLOBAL. . . , 2004). OGSA define uma arquitetura
aberta, padrão e comum para aplicações baseadas em Grid. A sua principal meta é
padronizar aqueles serviços relacionados com aplicações Grid, tais como: serviços de
gerenciamento de trabalho, serviços de gerenciamento de recursos, serviços de
segurança etc.;
• OGSI (Open Grid Services Infrastructure): É a especificação concreta da arquitetura
OGSA. É baseado nas tecnologias de Grids e Web Services, chamados Grid Services,
e define como construir, gerenciar e expandir um serviço;
63
• Web Services: São a base para o conceito de Grid Services e, por sua vez, a base para
o OGSI, OGSA e o GT3. Web Services é uma tecnologia de computação distribuída
que permite a criação de aplicações cliente/servidor usando como plataforma de
comunicação protocolos abertos e amplamente conhecidos como o HTTP e o XML.
Desta forma, pode-se executar um serviço através de uma Intranet ou mesmo
Internet, ocultando do cliente detalhes relativos a implementação do serviço e
plataforma operacional. Essas características fazem com que os clientes e servidores
sejam fracamente acoplados, tornando Web Services a escolha natural para a
construção de aplicações baseadas em Grid. Contudo, uma das desvantagens de Web
Services é o overhead, pois a transmissão de dados é feita usando XML que é,
obviamente, menos eficiente do que usar um código binário proprietário. Este
overhead é usualmente aceitável para a maioria das aplicações. Contudo, será difícil
encontrar aplicações críticas de tempo real que usam Web Services (SOTOMAYOR,
2003). Uma outra desvantagem é que Web Services não são muito versáteis, desde
que eles não ofereçam suporte para serviços de persistência, notificação,
gerenciamento de ciclo de vida, transações etc. Para contornar essas limitações,
surgiram os Grid Services, que são basicamente Web Services com características e
serviços melhorados;
• Grid Services: São baseados no conceito de Web Services com algumas
particularidades e mecanismos definidos pelo OGSI. As principais melhorias
introduzidas pelos Grid Services são:
� Factory: usam uma abordagem de Factory para a criação de instâncias de
serviços. Ao contrário de ter um serviço compartilhado por todos os usuários,
tem-se uma fábrica central responsável por criar instâncias desse serviço sob
demanda. Assim, quando um cliente quer efetuar uma operação deste serviço, ele
se comunica com a sua instância do serviço. Quando um cliente necessita de uma
nova instância, ou de destruir uma, ele requisita à fábrica.
� Naming: associa um Grid Service Handle (GSH) a um único Grid Service. O GSH
é o único modo de identificar um Grid Service, porém ele não fornece
informações detalhadas sobre o serviço. Para conhecer os detalhes e requisitos de
comunicação com o serviço, uma GSH é mapeada a um Grid Service Reference
64
(GSR). Em resumo, um GSH aponta para um Grid Service e o GSR especifica
como deve ser a comunicação com este serviço;
� Data Service: uma instância de um Grid Service pode possuir uma coleção de
dados estruturados associados a ela e que podem ser acessados pelos usuários do
serviço. Estes dados, chamados de Service Data Elements (SDE), podem ser
pesquisados e alterados pelos usuários. A especificação OGSI define alguns tipos
padrões de SDE que podem ser usados pelos Grid Services, sendo que um Grid
Service geralmente possui alguns destes SDEs quando é instanciado.
� Notification: o mecanismo de notificação permite que um serviço seja uma fonte
de notificação, e que este envie mensagens para aqueles clientes interessados na
ocorrência de determinado evento;
� Lifecycle Management: a especificação OGSI define o ciclo de vida de um serviço
como o tempo desde a criação de uma instância até a sua destruição. A criação da
instância pode ser realizada pelo cliente ao requisitar ao mecanismo Factory. O
processo de destruição pode ser feito ao invocar o método da instância
responsável por esta tarefa. Outra forma do ciclo de vida é quando o cliente
instancia o serviço por um tempo determinado. Quando este período expira, se o
cliente não reafirmar o interesse pela utilização, a instância do serviço é destruída;
• WSRF/GT4. Com a evolução da arquitetura de Web Services, e tendo em vista que
toda a base de Grid Services tem origem nas tecnologias para Web Services, foi
preciso ocorrer um refinamento em alguns aspectos da especificação OGSI (CIRNE;
NETO, 2005). A principal crítica estava relacionada aos mecanismos de
endereçamento para os serviços, por exemplo: Grid Service Handler e Grid Service
Reference. Objetivando fornecer um mecanismo de endereçamento independente da
camada de transporte, surgiu o WS-Addressing (CZAJKOWSKI et al., 2004). Além
dessa, outras características da especificação OGSI necessitavam ser alteradas para
poder acompanhar a evolução da tecnologia Web Service. Nesse sentido, é criado o
WSRF (Web Service Resource Framework), que é basicamente o resultado do
refinamento de OGSI objetivando aproveitar a existência dos novos padrões que
surgiram para Web Services (e.g. WS-Addressing, WS-Notification) e assimilar a
demanda da comunidade Web Services. Uma outra medida importante diz respeito a
65
recuperação da compatibilidade com as ferramentas existentes para XML e Web
Services, já que OGSI usa GWSDL, o qual provê acréscimos se compadaro ao
WSDL 1.1. Contudo, estes acréscimos estarão disponíveis nas versões WSDL
1.2/2.0. Ao contrário de OGSI, ao invés de estender a definição de portType WSDL
1.1, ou mesmo esperar pelo portType da nova versão WSDL 2.0, WS-Resource
Framework utiliza puramente WSDL 1.1, o que garante compatibilidade com as
ferramentas existentes para Web Services. Alguns entusiastas da área de Web
Services, em geral, argumentam que Web Services não devem manter estado ou ter
instâncias. Ou seja, atualmente, OGSI modela um recurso que mantém estado como
um Web Service que encapsula o estado do recurso. WS-Resource Framework
modifica esse modelo para criar uma distinção explícita entre serviço e entidades que
mantém estado e são manipuladas através do serviço. Esta composição é denominada
WS-Resource pelo padrão WSRF, que introduz a idéia de recursos que mantém
estados e podem ser acessados através de Web Services via o uso convencional de
WS-Addressing. Em linhas gerais, a evolução de OGSI se deu em três fases:
introdução do conceito de WS-Resource; divisão de funcionalidades em várias
especificações melhorando a compatibilidade com ferramentas usadas para Web
Service; e finalmente, uma melhoria nos mecanismos de notificação. O padrão
WSRF deve se materializar, de forma estável, através do lançamento do Globus
Toolkit 4.
A Figura 23 exemplifica como os conceitos OGSA, OGSI, Web Service e a ferramenta
Globus Toolkit interagem para a criação de um Grid Service.
Uma apresentação mais detalhada da arquitetura do Globus Toolkit, suas características,
serviços disponibilizados e conceitos que foram utilizados neste trabalho podem ser
encontrados de forma mais detalhada em (BIANCARDI, 2005).
O próximo capítulo apresenta a especificação funcional da Máquina de Execução de
Consultas Distribuída do CoDIMS, descrevendo os requisitos necessários para que ela atenda
às necessidades de paralelismo e distribuição do CoDIMS.
66
Figura 23. Interação entre as partes componentes (SOTOMAYOR, 2003).
67
4 Especificação Funcional
4.1 Introdução
Neste capítulo, primeiramente, será descrita a atual sistemática de execução de
consultas do CoDIMS e apontadas suas restrições, deficiências e problemas. Logo após serão
propostas soluções com o intuito de aprimorar tal sistemática. Finalmente, serão detalhados os
novos componentes incorporados ao CoDIMS para dar suporte às soluções propostas.
4.2 Atual Sistemática
A arquitetura atual do CoDIMS (Figura 24) (BIANCARDI, 2005) é dividida em quatro
camadas: Apresentação, Integração, Wrapper-Grid e Fontes de Dados.
Figura 24. Arquitetura de Camadas (BIANCARDI, 2005).
68
As consultas são enviadas por um Cliente para o CoDIMS, através da camada de
Apresentação chegando até o componente Controle, já na Camada de Integração. O Controle
identifica o escalonamento a partir do workflow da operação de consulta submetida e o envia
ao Componente Processamento de Consulta para que as operações sejam executadas. Na
forma mais geral, o escalonamento contém as seguintes operações a serem executadas:
Análise: O Analisador acessa o componente Metadados para verificar se a consulta está
sintaticamente e semanticamente correta, gerando um PEC (Plano de Execução de Consulta)
inicial. No CoDIMS, o PEC é descrito através de um documento XML (PINHEIRO, 2004),
representando uma árvore, onde cada folha é uma fonte de dados que deve ser acessada e os
nós internos representam as operações que devem ser executadas sobre os sub-resultados. Um
exemplo de PEC é apresentado na Figura 25.
Figura 25. Um exemplo de PEC.
Re-escrita: O Re-escritor refaz o PEC de forma a gerar apenas uma sub-consulta para
cada fonte de dados envolvida na consulta global. Para isso, também acessa o componente
Metadados para obter os mapeamentos entre os metadados globais e os metadados locais de
cada fonte de dados. As sub-consultas são representadas segundo um padrão estabelecido em
(PINHEIRO, 2004). Cada sub-consulta é encapsulada em um objeto Sub-Consulta que
contém as seguintes informações: Identificador da Consulta; Identificador da sub-consulta,
algumas informações da fonte de dados (necessárias para o wrapper) e a sub-consulta
propriamente dita.
69
Otimização: O Otimizador de consultas (GOMES, 2005) gera um PEC otimizado para
a execução das sub-consultas e integração dos sub-resultados.
Execução: A MEC recebe e executa o PEC otimizado, gerencia a execução de cada
sub-consulta, e por fim, gera o resultado final a partir da composição dos sub-resutados.
Para cada sub-consulta a ser executada é realizada uma comunicação com o componente
Acesso a Dados e, uma a uma, elas são enviadas de forma assíncrona. Ao serem recebidas,
cada objeto Sub-Consulta é inserido no final da fila de execução de sub-consultas. Sempre
que uma inserção é realizada nessa fila, uma notificação é feita ao seu observador, indicando
que existe uma nova sub-consulta que deve ser executada. O observador recupera os dados do
objeto Sub-Consulta a ser executado seguindo a ordem imposta pela fila.
Para proceder a execução, o Componente Acesso a Dados envia esses dados para a
camada de Wrapper-Grid, formada pelos Componentes Wrapper Grid (WGCs) que
encapsulam as funcionalidades básicas de um Wrapper Service (WS) (BIANCARDI;
SILVESTRE; BARBOSA, 2005a).
Para a utilização de um WGC, é necessário instalá-lo em um Nó do Grid, e em cada
WGC existem Wrapper Services para todas as fontes de dados envolvidas na configuração do
CoDIMS (Figura 26).
Nó
WGC
wrapper1 wrapper2
wrapper3 wrappern
Nó 2
WGC
wrapper1 wrapper2
wrapper3 wrappern
Nó n
WGC
wrapper1 wrapper2
wrapper3 wrappern
...
Figura 26. Wrappers em todos os WGC's.
Antes de enviar uma sub-consulta para um WCG o componente Acesso aos Dados deve
determinar em qual Nó do Grid ela será executada, levando-se em consideração a capacidade
de processamento, memória, capacidade de armazenamento, largura de banda da rede,
comunicação entre as máquinas etc.
70
O problema é que esse processo pode envolver outros fatores específicos do ambiente
de Grid utilizado (Globus, MyGrid, Condor, etc.), tal como a comunicação com algum
componente do Grid que forneça informações sobre as características dos Nós. Sendo assim, a
decisão de qual o Nó do Grid mais apropriado para execução de uma sub-consulta deve ser
abstraída do componente Acesso a Dados, para que no caso de uma alteração nas interfaces
do ambiente de Grid, ou até mesmo a sua substituição, não sejam necessárias modificações no
Componente Acesso a Dados.
No Nó do Grid selecionado pelo Acesso a Dados, o WGC inicia a execução do
wrapper, que realiza as seguintes tarefas: tradução da sub-consulta do modelo global para o
modelo de dados nativo da fonte; comunicação com a fonte de dados e encaminhamento da
sub-consulta para a fonte. Na fonte de dados a sub-consulta é processada e, ao seu término, o
conjunto resultado é transmitido para a camada de Wrapper-Grid, mais precisamente para o
Nó no qual o wrapper responsável pela sub-consulta está localizado. O conjunto-resultado é
então convertido do modelo nativo da fonte para o modelo de dados global, e, logo após, é
disparada uma notificação ao componente Acesso aos Dados, para que este possa indicar o
término da execução da sub-consulta à MEC. A fim de diminuir o tempo de comunicação
entre os componentes do CoDIMS, como não é feito nenhum processamento com a
notificação no componente Acesso a Dados, os wrappers poderiam enviar diretamente para a
MEC a indicação de conclusão de uma sub-consulta.
A MEC, ao receber a notificação de finalização da última sub-consulta, inicia a
composição dos sub-resultados para gerar o resultado final. As operações de composição
definidas no PEC são executadas de maneira centralizada e seqüencial, e os resultados
parciais gerados são todos armazenados no próprio servidor da MEC. Essa abordagem
prejudica a execução independente e paralela das operações do PEC, o que diminui a
agilidade no processamento do PEC. A distribuição dos dados nos Nós do Grid não é
aproveitada para o processamento distribuído das operações, tal como nos sistemas de BDDs
(ÖZSU; VALDURIEZ, 2001).
Em resumo, a atual sistemática de execução de consultas do CoDIMS definidas em
(BIANCARDI, 2005) possui algumas restrições:
71
• É o componente Acesso a Dados que determina qual o Nó mais apropriado para a
execução de uma sub-consulta. Essa escolha pode ser muito complexa, tornando-se
mais vantajoso a utilização de componentes específicos para esse fim;
• Ao final da execução de uma sub-consulta os wrappers devem notificar o
Componente Acesso a Dados para este informar à MEC. A comunicação entre
componentes remotos pode gerar atrasos no tempo de execução de uma consulta;
• A MEC realiza composição dos sub-resultados e execução dos operadores de
maneira centralizada e seqüencial. O processamento centralizado da MEC pode gerar
sobrecarga no seu servidor, comprometendo o tempo de execução das consultas.
• A MEC espera até que todas as sub-consultas tenham sido finalizadas para buscar os
sub-resultados gerados e iniciar o processamento sobre eles. Considerando que uma
sub-consulta pode demorar mais tempo que as outras, o tempo total de execução da
consulta submetida ao CoDIMS seria prejudicado.
Como forma resolver os problemas encontrados e otimizar a execução de consultas no
CoDIMS, torna-se necessária a alteração de algumas características a incorporação de novas
funcionalidades ao processo de execução de consultas.
4.3 Soluções propostas
1. Abstração, por parte do Componente Acesso a Dados, das características do
ambiente, das configurações dos Nós, da forma de comunicação e envio de serviços
para o Grid. Para isso foi incorporado ao CoDIMS o Componente Access Grid
(Figura 27), que disponibiliza um Web Service para que o Componente Acesso a
Dados envie as solicitações de execução de wrappers no Grid. O Componente
Access Grid determina qual o Nó mais apropriado para a execução da sub-consulta
e para ele é enviados a sub-consulta para ser executados.
72
Figura 27. Componente Access Grid.
2. Comunicação direta do wrapper com a MEC para enviar a notificação de final da
execução de uma sub-consulta. Nessa notificação são enviadas as seguintes
informações: identificador da consulta, identificador da sub-consulta, tamanho do
conjunto resultado e localização (endereço do Nó e link para o arquivo).
3. Distribuição não somente das sub-consultas, mas de toda a execução do PEC,
utilizando o ambiente de Grid. A MEC processa o PEC, executando as operações de
forma paralela. Ela envia os operadores para o Componente Access Grid, e este,
após determinar qual o Nó mais apropriado para a execução, inicia o processamento
da operação no Nó selecionado. No caso do PEC da Figura 25, as operações (join)
sobre os sub-resultados A-B e C-D podem ser executadas ao mesmo tempo, em Nós
distintos.
4. Execução independente das operações sobre sub-resultados relacionados. Ou seja,
para a execução de um operador será necessário apenas que os sub-resultados dos
seus operadores produtores tenham sido gerados. Além disso, as operações podem
ser executadas em Nós que já contenham sub-resultados, objetivando diminuir o
tempo na transferência de dados entre os Nós do Grid. Considerando ainda o PEC
da Figura 25, a operação de join pode ser executada sobre os sub-resultados
provenientes das fontes A e B, mesmo que as sub-consultas das fontes C e D ainda
não tenham sido finalizadas.
Para implementar as soluções descritas, algumas alterações devem ser realizadas na
atual arquitetura do CoDIMS:
73
• A MEC centralizada do CoDIMS deve ser substituída por uma Máquina de Execução
de Consultas Distribuída (MECD), que permita a composição do resultado final de
forma distribuída e paralela;
• Incorporação do Componente Access Grid que tem por finalidade: i) receber
solicitações de execução de sub-consultas do Componente Acesso a Dados; ii)
receber solicitações de execução de operações da MECD; iii) determinar qual o Nó
mais apropriado para a execução de sub-consultas e operações; iv) repassar as
solicitações para serem executados nos Nós selecionados.
• A atual Camada Wrapper-Grid deve ser estendida de modo a oferecer serviços para
execução não somente de wrappers, mas também de operadores do PEC, que serão
enviados para a geração do resultado final da consulta. Sendo assim, a partir deste
trabalho ela será denominada Camada MEC-Grid.
Com a incorporação da MECD, da camada MEC-Grid, do Componente Access Grid e
do MECGC, a nova arquitetura do CoDIMS é apresentada na Figura 28:
GRID
CoDIMS
Controle
Metadados
Acesso
a
Dados
Processamento
de Consultas
FD 1 FD nFD 2
MECD
Access Grid
...
Aplicações
Camada
de
Integração
Camada
MEC-Grid
Camada de
Apresentação
Camada de
Fontes de Dados
wrappers operadores
Figura 28. MECD, Camada MEC-Grid e Componente Access Grid.
74
4.4 MECD
A Máquina de Execução de Consultas Distribuída (Figura 29) inserida no CoDIMS foi
baseada no framework QEEF (Query Execution Engine Framework) (AYRES, 2003). Por ser
um framework (FAYAD; SCHMIDT; JOHSON, 1999), possui partes fixas (frozen-spots), que
devem existir em todas as instâncias da MECD, e partes que serão instanciadas dependendo
do cenário em que o CoDIMS seja utilizado (hot-spots).
Figura 29. MECD do CoDIMS
As partes fixas criam uma infra-estrutura básica para a execução das consultas. Essas
partes são: a interface da MEC; o processamento do PEC; a estrutura básica dos operadores e
do conjunto resultado.
As partes a serem instanciadas, responsáveis pela adaptação do CoDIMS a cada cenário,
são compostas pelos operadores algébricos e pelo conjunto resultado de cada modelo de
dados.
A MECD no CoDIMS foi implementada como um componente remoto (separada do
Processamento de Consulta). Essa escolha se deve a dois fatores. Primeiro, situando a MECD
em um componente remoto se torna mais simples criá-la em um formato que a mesma possa
ser substituída sem que seja necessário alterar a implementação de algum outro componente.
E segundo, caso algum outro projeto futuro crie um componente de Processamento de
Consulta que seja capaz de lidar com várias MECDs em paralelo, a distribuição delas se torna
mais simples.
75
Uma parte importante na construção de uma MECD são os operadores que ela é capaz
de executar. Através deles a MECD possui a capacidade de executar diversos tipos de
operações algébricas. Os operadores possuem uma interface comum: assim, através dela, é
possível implementar um conjunto de operações sem que a MECD tenha que conhecer a
fundo cada operador.
4.4.1 Processamento do PEC
O primeiro estágio do processamento do PEC no CoDIMS é a criação do plano dentro
da MECD. A criação do plano significa a tradução do documento XML que descreve o PEC
para uma árvore de objetos (meta-operadores). Cada meta-operadores do PEC corresponde a
um operador que será executado em um Nó do Grid.
Após a criação de todos os meta-operadores, a MECD determina quais são os
produtores e os consumidores de cada meta-operador. Existem dois tipos de meta-operadores:
• meta-operadores folhas: não possuem operadores produtores. Devem buscar dados
das fontes através de uma sub-consulta executada por um wrapper. Ex:
ScanRelacional;
• meta-operadores não folhas: geralmente possuem dois meta-operadores produtores
que geram tuplas necessárias para o seu processamento. Ex: LoopNestedJoin.
Ao iniciar a execução do plano, a MECD identifica o meta-operador raiz da árvore e
executa o seu método abrir(). O meta-operador raiz executa o método abrir() dos seus meta-
operadores produtores que, sucessivamente, também executam o método abrir() dos seus
produtores. Ou seja, cada meta-operador inicializa os seus produtores. Uma vez que todos os
meta-operadores estejam preparados, é executado o método obterProximo() do meta-operador
raiz. O meta-operador raiz também invocará os métodos obterProximo() dos seus produtores.
Cada meta-operador da árvore executa os métodos obterProximo() dos seus produtores
de forma assíncrona, através da criação de Threads. Após isso, cada meta-operador espera até
que os seus produtores gerem conjuntos-resultados para prosseguir a sua execução. Essa
sistemática é necessária para que as operações possam ser executadas de forma independente,
paralela e distribuída. Para ilustrar esse procedimento, considere a árvore de meta-operadores
da Figura 30. O Meta-Operador 1 inicia a execução do seu método obterProximo()
76
executando os métodos obterProximo() dos seus produtores (Meta-Operador 2 e Meta-
Operador 3) de forma assíncrona. Após isso, o método obterProximo() do Meta-Operador 1
espera até que as Threads criadas finalizem suas execuções e retornem as informações dos
conjuntos-resultados gerados (nome do arquivo, localização e tamanho). Logo após, o método
obterProximo() do Meta-Operador 1 aciona a execução do seu respectivo Operador, e ao final
da execução, retorna a informação do conjunto-resultado gerado. Esses procedimentos são
executados até que o meta-operador raiz da árvore finalize o método obterProximo() e retorne
o conjunto-resultado final.
Figura 30. Execução assíncrona de operadores.
4.4.2 Execução remota das sub-consultas
Ao iniciar a execução do método obterProximo, um meta-operador folha da árvore, que
representa o operador ScanRelacional, deverá enviar uma solicitação de execução da sua sub-
consulta para o Componente Acesso a Dados com os seguintes dados: identificador da
consulta; identificador da sub-consulta; sub-consulta propriamente dita. O Componente
Acesso a Dados recebe a solicitação, identifica qual a fonte de dados responsável pela sub-
consulta e envia a solicitação para o Componente Access Grid com as informações recebidas
da MECD e também com informações da fonte de dados (localização, tipo e forma de acesso).
O Componente Access Grid determina qual o Nó mais apropriado para a execução da sub-
consulta e envia as informações recebidas para o MECGC Nó selecionado, de modo que a
sub-consulta seja executada.
O MECGC inicia a execução da sub-consulta selecionando o wrapper responsável pela
consulta. O wrapper realiza as seguintes atividades: traduz a consulta para o modelo nativo da
77
fonte; realiza a comunicação com a fonte; recebe o resultado gerado; traduz o resultado para o
modelo interno do CoDIMS. Ao final do processamento e geração de um novo conjunto-
resultado o wrapper deverá armazená-lo no mesmo Nó do Grid onde ele se encontra e
retornar as informações do conjunto-resultado gerado (nome do arquivo, localização e
tamanho) para o meta-operador ScanRelacional que enviou a solicitação ao Componente
Acesso a Dados. Este, por sua vez, retorna os resultados para o seu meta-operador consumidor
que executou a chamada assíncrona.
4.4.3 Execução remota das operações
Um meta-operador não folha da árvore, ou seja, que possui produtores, após executar os
métodos obterProximo() dos seu produtores de forma assíncrona e receber o retorno com as
informações dos conjuntos-resultados, inicia a execução do seu respectivo operador que será
realizada em um Nó do Grid. Ele envia para o Componente Access Grid as seguintes
informações: identificador da consulta, identificador da operação, nome do operador, nomes
dos arquivos que contém os conjuntos-resultados, localizações dos conjuntos-resultados. O
Componente Access Grid determina qual o Nó mais apropriado para a execução da operação e
envia as informações recebidas para MECGC o Nó selecionado, de modo que a operação ela
seja executada.
O MECGC inicia a execução do Operador, que deverá buscar os sub-resultados que
estão localizados em outros nós do Grid para então serem processados. Para isso ele utiliza as
informações de localização dos conjuntos-resultados recebidas do Componente Access Grid.
Ao final do processamento e geração de um novo conjunto-resultado o Operador deverá
armazená-lo no Nó do Grid e retornar as informações do conjunto-resultado gerado (nome do
arquivo, localização e tamanho) para o meta-operador que enviou a solicitação ao
Componente Access Grid.
Caso o meta-operador seja o raiz da árvore, as informações do resultado final são
retornadas para a aplicação que enviou a consulta ao CoDIMS. Caso contrário, as informações
do conjunto-resultado serão retornadas para o meta-operador consumidor que executou a
chamada assíncrona. Ele seguirá os mesmos passos do meta-operador anterior, e as execuções
dos meta-operadores continuarão se propagando pela árvore até que a execução do meta-
operador raiz seja finalizada.
78
4.5 Camada MEC-Grid
A Camada MEC-Grid, é uma extensão da Camada Wrapper-Grid (BIANCARDI, 2005),
oferecendo suporte também às operações necessárias pela MECD para a execução do PEC de
forma distribuída. Ela é composta pelo Componente Access Grid e pelos componentes
MECGC, que possibilitam a utilização do ambiente de Grid no CoDIMS.
4.5.1 Componente Access Grid
O Acces Grid (Figura 31) é um componente que visa auxiliar no processo de integração
de dados heterogêneos e distribuídos. Ele funciona como uma ponte entre as Camadas de
Integração e MEC-Grid, sendo que seu principal objetivo é abstrair da Camada de Integração
os requisitos necessários para a execução de serviços no Grid, da Camada MEC-Grid. A
MECD e o Componente Acesso a Dados não precisam conhecer os detalhes necessários para
comunicação e envio de solicitações para o Grid. Cada um deles deve apenas invocar um Web
Service do Componente Access Grid específico para que estes serviços sejam executados.
Figura 31. Access Grid, MECD e Acesso a Dados.
Esta característica de abstração favorece a mudança de um ambiente de Grid para outro
sem que as camadas superiores do CoDIMS sejam modificadas.
Mesmo que neste trabalho esteja sendo utilizada uma configuração do CoDIMS com o
componente MECGC que tem como base o Globus Toolkit 3.2 (GLOBUS, 2004), em
configurações que utilizem outros ambientes de Grid, seria necessário apenas alterações nos
componentes da camada MEC-Grid (Figura 32).
79
Figura 32. Configurações com ambientes de Grid diferentes.
Um outro objetivo muito importante do Access Grid é determinar qual o melhor Nó do
Grid para a execução dos wrappers e operadores. Para isso ele poderá utilizar algum serviço
do próprio ambiente de Grid que forneça informações sobre os Nós: capacidade de
processamento, disponibilidade de memória, capacidade de armazenamento, largura de banda
da rede, comunicação entre as máquinas etc. Entretanto, no processo de integração de dados
heterogêneos e distribuídos alguns fatores específicos também devem ser considerados:
• Na execução dos wrappers é interessante que as sub-consultas sejam processadas em
máquinas próximas às fontes de dados, ou na própria fonte, objetivando um menor
tráfego na rede;
• Na composição dos conjuntos-resultado, é uma boa estratégia enviar um Operador
para o Nó que já contém um conjunto-resultado, e que ele seja o maior entre os que
estão envolvidos na operação, para diminuir o tempo na transferência de informações
entre os Nós.
• Algumas estatísticas de serviços executados anteriormente devem ser consideradas
para a escolha do Nó: tempo médio de acesso a uma fonte de dado por Nó; tempo
médio de processamento de um Operador por Nó e complexidade de tradução do
sub-resultado para o modelo global.
80
Sendo assim, para determinar qual o melhor Nó para execução de um serviço, o Access
Grid deverá ponderar as características de máquinas e rede, coletadas no próprio ambiente de
Grid, com as características inerentes a integração de dados heterogêneos e distribuídos.
Em resumo, os principais objetivos do componente Access Grid são:
• Publicar Web Services para a camada de Integração;
• Abstrair o ambiente de Grid das camadas de Integração e Apresentação;
• Receber do componente Acesso a Dados a solicitação de execução de um wrapper
no Grid;
• Receber da MECD a solicitação de execução de um operador no Grid;
• Buscar informações de configuração das máquinas e rede do ambiente;
• Determinar qual o melhor Nó do Grid para a execução do serviço;
• Enviar o serviço para ser executado no Nó selecionado.
4.5.2 Componente MECGC
O Componente MEC-Grid (MECGC) permite que sejam enviadas e executadas nos Nós
do Grid não somente sub-consultas, mas também operações sobre os sub-resultados. Na base
do MECGC é usado o Globus Toolkit 3.2 (GLOBUS, 2004), que é uma implementação de
referência OGSA (FOSTER; GANNON, 2003).
MECGC
Globus
Toolkit
Operators Services
Wrappers Services
Grid Services
Figura 33. Componente MECGC.
81
Para utilização do MECGC é necessária a sua instalação nos Nós do Grid. É necessário
que ele já contenha todos os serviços (operadores e wrappers) que serão utilizados em uma
instância do CoDIMS. O MECGC publica serviços para receber solicitações de execução de
wrappers e operadores algébricos provenientes do Componente Access Grid.
4.6 A nova sistemática de execução de consultas
Para resumir a especificação funcional do CoDIMS, a Figura 34 ilustra todo o fluxo de
execução de uma consulta. Alguns detalhes como, mensagens das filas, foram omitidos por
questão de espaço. Na figura existe uma enumeração dos passos para a execução completa de
uma consulta.
1. A aplicação Cliente submete a consulta ao CoDIMS através da Camada de
Apresentação. Na camada de Integração o Componente Controle recebe a consulta e
a encaminha para o Componente Processamento de Consulta;
2. O Componente Processamento de Consulta, Analisa, Re-escreve e Otimiza;
3. A MECD inicia a execução do PEC gerado pelo Otimizador e envia as informações
das sub-consultas para o Componente Acesso a Dados;
4. O Componente Acesso a Dados busca informações referentes à fonte de dados
relacionada a cada sub-consulta. Ele as envia, juntamente das informações recebidas
da MECD, para o Componente Access Grid;
5. O Componente Access Grid recebe a solicitação de execução de uma sub-consulta,
determina qual o melhor Nó para esse serviço e envia as informações recebidas para
o componente MECGC do Nó selecionado;
6. O MECGC instancia o wrapper responsável pela consulta na fonte de dados e o
executa. O wrapper traduz a consulta do modelo global para o modelo local e a sub-
consulta para a fonte de dados (6.1). Ao final o wrapper traduz o sub-resultado do
modelo local para o modelo global; armazena o conjunto-resultado no Nó do Grid e
envia retorna para a MECD as informações do conjunto-resultado gerado;
82
Figura 34. Exemplo de execução de uma Consulta.
7. A MECD recebe o retorno de finalização de uma sub-consulta e executa as
operações sobre os sub-resultados gerados;
7.1 Se todos os sub-resultados para a execução da próxima operação já foram
gerados, a MECD envia solicitação para o Componente Access Grid, com as
seguintes informações: identificador da consulta, identificador da operação,
nome do operador e informações para acesso aos sub-resultados. Caso contrário
83
ela espera até que todos os sub-resultados necessários para a operação sejam
gerados;
8. O Componente Access Grid recebe a solicitação de execução de uma operação,
determina qual o melhor Nó para esse serviço e envia as informações recebidas da
MECD para o componente MECGC do Nó selecionado;
9. O MECGC seleciona o Operador responsável pela operações e a sua execução. Ele
busca os conjuntos-resultados dos Nós remotos e executa a operação sobre eles. O
novo sub-resultado gerado é armazenado no Nó e as suas informações são
retornadas para a MECD;
10. A MECD recebe o retorno de finalização da operação e continua o processamento
do PEC. Caso ainda existam operações a serem processadas ela volta a executar os
passos a partir do item 9.1. Caso contrário ela envia os dados (nome do arquivo e
localização) do resultado final para o componente controle para o Componente
Controle;
11. O Componente Controle recebe os dados do resultado final e os envia para a
Aplicação Cliente;
12. A Aplicação Cliente recebe as informações do resultado final e busca o resultado no
Nó do Grid especificado.
No capítulo seguinte será apresentada modelagem necessária para a implementação
deste trabalho. A modelagem inclui Diagrama de Componentes, de Classes e de Seqüência.
84
5 Modelagem
5.1 Componentes do CoDIMS
O principal objetivo do CoDIMS é oferecer uma abordagem para a construção de
sistemas de integração de dados, através da seleção, customização e integração de um
conjunto adequado de componentes, baseados nos serviços de gerência de banco de dados. A
Figura 35 apresenta o Diagrama de Componentes do CoDIMS na sua forma original.
Processamento
de Consultas
Gerência de
Metadados
Acesso a
Dados
Gerência de
Transação
Controle de
Concorrência
Gerência de
Regras
Controle
Figura 35. Diagrama de Componentes do CoDIMS (BARBOSA, 2001).
Cada componente do CoDIMS possui uma fachada, através da qual são disponibilizados
seus métodos para outros componentes do CoDIMS ou para interação com o usuário (no caso
do componente Controle). Assim, toda e qualquer chamada às operações dos componentes é
realizada sempre via fachada, o que isola as funcionalidades internas dos componentes,
facilitando a troca destes por outros, que possuam a mesma interface. A Figura 36 mostra as
fachadas definidas inicialmente para o CoDIMS (BARBOSA, 2001).
85
Figura 36. As Fachadas do Componente do CoDIMS (Barbosa, 2001).
Além disso, todos os componentes do CoDIMS são frameworks, o que faz com que o
ambiente como um todo tenha essa característica. Framework é uma arquitetura semi-
completa que pode ser instanciada para produzir aplicações customizadas, permitindo o reuso
de análise, de projeto e de código (FAYAD; SCHMIDT; JOHSON, 1999). Segundo (PREE,
1995), um framework é composto por frozen spots, que são aquelas partes presentes em
qualquer instância do framework; e por hot spots, que são partes específicas para cada
sistema, de acordo com as necessidades de cada aplicação.
Em todos os diagramas de classes deste capítulo, os componentes serão representados
através de uma extensão da UML para representar frameworks (FONTOURA, 1999;
FONTOURA; PREE; RUMPE, 2000). Cada estereótipo que contido nos diagramas é descrito
a seguir:
Facade. O pattern Facade fornece, para um conjunto de interfaces de um sub-sistema
(componente), uma interface unificada de alto nível que facilita o uso do sub-sistema
(GAMMA et al., 1995). A estruturação de um sistema em sub-sistemas auxilia a redução da
complexidade. Como um dos objetivos de um projeto é minimizar a comunicação e
86
dependências entre os sub-sistemas, a introdução de Facade fornece uma interface única e
simplificada para uma maior facilidade de comunicação com o sub-sistema;
Extensible. Aplica-se quando a interface da classe depende da instanciação: novos
métodos podem ser definidos para estender a funcionalidade da classe;
Static. Aplica-se a hot-spot de interface, método de variação e classe de extensão. O
hot-spot não precisa ser reconfigurado em tempo de execução. Hot-spots de interface são
interfaces ou classes abstratas que permitem a criação de sub-classes concretas durante a
instanciação do framework, métodos de variação são métodos que têm assinatura bem
definida, mas sua implementação pode variar dependendo da instanciação do sistema e classes
de extensão são classes que podem ter suas interfaces estendidas durante o processo de
instanciação do framework;
Incomplete. Aplica-se a generalização. Novas sub-classes podem ser adicionadas
durante a instanciação do framework;
Disjoint. Aplica-se a generalização. Apenas uma das sub-classes pode estar presente na
instanciação do framework.
Na versão original do CoDIMS (BARBOSA, 2001), os seus componentes se
comunicavam através do componente Controle, usando RMI (Remote Method Invocation). A
partir de (TREVISOL, 2004), os componentes do CoDIMS passaram a ser disponibilizados
como Web Services, havendo também a possibilidade de se comunicarem diretamente (Figura
37). A adoção de tecnologia de Web Services gerou um alto grau de interoperabilidade entre
os componentes, possibilitando que eles se tornassem independente de plataformas,
tecnologias de redes, aplicações e linguagens de programação. Já a desburocratização do
componente controle, tirando o seu papel de broker do ambiente, aumentou o dinamismo na
comunicação entre os componentes, diminuindo o tempo na troca de mensagens.
87
Figura 37. Evolução arquitetura de comunicação entre os componentes.
Como o objetivo principal deste trabalho é desenvolver uma máquina de execução de
consultas distribuída, foi realizada uma reformulação na sistemática de processamento de
consultas, o que gerou a necessidade extensão de alguns componentes e a criação de outros.
Assim, a seguir são apresentados os diagramas de pacotes e de classes dos componentes
envolvidos neste trabalho que, de alguma maneira, foram afetados pela nova sistemática de
execução de consultas incorporada ao CoDIMS.
A arquitetura independente de comunicação entre os componentes, implantada em
(TREVISOL, 2004), possibilitou que este trabalho se focasse somente nos componentes
envolvidos diretamente no processamento das consultas. Dessa forma, os componentes
Controle e Metadados não sofreram nenhum impacto com as alterações realizadas neste
trabalho.
5.2 Diagramas de Pacotes e de Classes
A Figura 38 mostra o diagrama de pacotes dos componentes MECD, Acesso a Dados,
Access Grid e MECGC e a dependência entre eles.
88
MECD
Access Grid
Acesso a
Dados
MECGC
Figura 38. Dependência entre Pacotes.
As dependências entre os componentes existem, pois a MECD necessita de elementos
definidos no Pacote Acesso a Dados para execução das sub-consultas. Ela também precisa
conhecer as interfaces de acesso do Pacote Access Grid para o processamento dos operadores.
O Pacote Acesso a Dados, por sua vez, deve enviar os wrappers e sub-consultas para o Pacote
Access Grid. O Pacote Access Grid deve interagir com o Pacote MECGC para envio dos
wrappers e operadores. Finalmente, o Pacote MECGC interage com o Pacote MECD para
envio da notificação de finalização do processamento de sub-consultas e operadores.
5.2.1 Classes do Pacote MECD
A Figura 39 mostra as classes do Pacote MECD e como elas se relacionam.
89
Figura 39. Diagrama de classes do Pacote MECD.
A seguir são detalhados os métodos e atributos de cada classe do Pacote MECD.
5.2.1.1 Classe FachadaMECD
A classe FachadaMECD é a classe principal do componente MECD. Seus métodos são:
• FachadaMECD: Construtor da classe;
90
• executarPEC: Método publicado como um Web Service que é invocado remotamente
pela FachadaProcessamentoDeConsultas. Tem a função de executar um PEC passado
como argumento;
• enviaSubConsulta: Método responsável por enviar um objeto SubConsulta para o
componente Acesso a Dados;
5.2.1.2 Classe SubConsulta
A classe SubConsulta contém as informações de uma sub-consulta. Seus atributos são:
• idConsulta: Contém o identificador da consulta;
• idSubConsulta: Contém o identificador da sub-consulta;
• subConsulta: Texto da sub-consulta propriamente dita.
Os métodos são os getters e setters dos atributos e o Construtor da classe.
5.2.1.3 Classe SubResultado
Classe abstrata que possui os atributos e operações básicas de um sub-resultado. É
herdada pelas classes SubResultadoWrapper e SubResultadoOperador. Seus atributos são:
• host: Nó que contém o sub-resultado;
• idConsulta: Contém o identificador da consulta;
• linkSubResultado: Referência para o sub-resultado;
• tamanho: Tamanho do sub-resultado.
Os métodos são os getters e setters dos atributos.
91
5.2.1.4 Classe SubResultadoWrapper
Classe que contém as informações do sub-resultado gerado por uma sub-consulta. Ela
herda os métodos e atributos da classe SubResultado. Seu único atributo é:
• idSubConsulta: Contém o identificador da sub-consulta.
Os métodos são: get e set do atributo e o Construtor da classe.
5.2.1.5 Classe SubResultadoOperador
Classe que contém as informações do sub-resultado gerado por uma operação. Ela herda
os métodos e atributos da classe SubResultado. Seu único atributo é:
• idOperacao: Contém o identificador da operação.
Os métodos são: get e set do atributo e o Construtor da classe.
5.2.1.6 Classe MetaOperador
A classe abstrata MetaOperador é a classe pai de todos os meta-operadores disponíveis
para a MECD. Ela possui os métodos básicos de todos os meta-operadores e sua principal
função é permitir que a classe FachadaMECD se abstraia dos detalhes das classes filhas. A
classe MetaOperador utiliza a classe abstrata FabricaMetaOperador para criar os meta-
operadores. No entanto, não é necessária a criação de um objeto dessa classe, uma vez que o
método criarMetaOperador é definido como método de classe.
Os operadores que realmente executarão as operações nos Nós do Grid serão
apresentados e descritos no pacote MECGC.
Seus métodos são:
• new: Cria um meta-operador com base no seu nome. Este método executa o método
criarMetaOperador da classe FabricaMetaOperador;
• open: Prepara o meta-operador para execução;
92
• next: Produz dados para o meta-operador consumidor. É implementado por cada
meta-operador independentemente;
• close: finaliza a execução de um meta-operador.
5.2.1.7 Classe MetaLoopNestedJoin
A classe MetaLoopNestedJoin herda os métodos da classe MetaOperador. Ela é
responsável por gerenciar a execução de Threads para execução dos meta-operadores
produtores e iniciar a execução do seu respectivo operador no Grid. Seus métodos são:
• MetaLoopNestedJoin: Construtor da classe;
• obterProximo: Este método é responsável por gerenciar a execução Threads para
execução dos meta-operadores produtores, disparar a execução do seu respectivo
operador no Nó do Grid e retornar para o seu meta-operador consumidor o nome e
localização do arquivo gerado com o resultado.
5.2.1.8 Classe MetaScanRelacional
A classe MetaScanRelacional herda os métodos da classe MetaOperador. Ela é
responsável por disparar a execução de uma sub-consulta no Grid. Seus métodos são:
• MetaScanRelacional: Construtor da classe;
• obterProximo: Este método é responsável por disparar a execução de uma sub-
consulta no Nó do Grid e retornar para o seu meta-operador consumidor o nome e
localização do arquivo gerado com o resultado.
5.2.1.9 Classe MetaProject
A classe MetaProject herda os métodos da classe MetaOperador. Ela é responsável por
simular a execução do seu respectivo operador que será executado nos Nós do Grid. Seu
único método é:
• MetaProject: Construtor da classe.
93
5.2.1.10 Classe FabricaMetaOperador
A classe abstrata FabricaMetaOperador conhece todos os meta-operadores envolvidos
em uma configuração do CoDIMS. Assim, dado o nome do MetaOperador e os seus
argumentos, ela é capaz de criar os objetos que os representam. Essa metodologia é baseada
no padrão de projeto Abstract Factory (GAMMA, 1995). Seu único método é:
• criarMetaOperador: Cria um meta-operador com base no seu nome.
5.2.2 Classes do Pacote Acesso a Dados
A Figura 40 mostra as classes do Pacote Acesso a Dados e como elas se relacionam.
Figura 40. Diagrama de classes do Pacote Acesso a Dados.
A seguir são detalhados os métodos e atributos de cada classe do Pacote Acesso a
Dados.
94
5.2.2.1 Classe FachadaAcessoDados
A classe FachadaAcessoDados é responsável por publicar seus serviços para o
componente MECD, receber solicitação de execução de uma sub-consulta e enviá-las para o
componente Access Grid. Seus métodos são:
• FachadaAcessoDados: Construtor da classe;
• executarSubConsulta: Método publicado como Web Service que é invocado pelo
componente MECD para execução de uma sub-consulta.
5.2.2.2 Classe DadosFonte
Classe responsável por manter os dados de uma fonte de dados que faz parte de uma
determinada instância do CoDIMS. Seus atributos são:
• nomeFonte: Nome da Fonte de Dados;
• tipoFonte: Tipo da Fonte de Dados;
• stringConexao: String de conexão utilizada para acesso à Fonte de Dados.
Os métodos são: getters e setters dos atributos e o Construtor da classe.
5.2.3 Classes do Pacote Access Grid
A Figura 41 mostra as classes do Pacote Access Grid e como elas se relacionam.
95
Figura 41. Diagrama de classes do Pacote Access Grid.
A seguir são detalhados os métodos e atributos de cada classe do Pacote Access Grid.
5.2.3.1 Classe FachadaAccessGrid
A classe FachadaAccessGrid é responsável por publicar serviços para os componentes
MECD e Acesso a Dados. Também tem por finalidade realizar a comunicação com o
ambiente de Grid, através da classe abstrata ComunicacaoGrid, para buscar informações dos
Nós do Grid, e enviar solicitações para execução de sub-consultas e operações nos Nós do
Grid. Seu único atributo é:
• comunicacaoGrid. Objeto de alguma das classes filhas da classe ComunicacaoGrid.
Seus métodos são:
• FachadaAccessGrid. Construtor da classe. Seu único argumento é o arquivo de
configuração que determina qual o ambiente de utilizado na instância do CoDIMS;
• executarSubConsulta: Método publicado como um Web Service que é invocado pela
classe FachadaAcessoDados para executar uma sub-consulta;
96
• executarOperacao: Método publicado como um Web Service que é invocado pela
classe FachadaMECD para executar uma operação;
• obterConjuntoResultado: Método publicado como um Web Service que é invocado
pela classe FachadaMECD. Obtém os dados de um conjunto resultado que está
localizado em algum Nó do Grid. Para isso, executa o método
obterConjuntoResultado do atributo comunicacaoGrid. Recebe o nome do arquivo e
sua localização. Retorna os dados do arquivo;
• selecionarNoOperacao: Para um determinado operador, seleciona o melhor Nó do
Grid para a sua execução. Para isso, executa o método buscarDadosNo do atributo
comunicacaoGrid. São enviadas as informações dos sub-resultados relacionados;
• selecionarNoSubConsulta: Para um determinado wrapper, seleciona o melhor Nó do
Grid para a sua execução. Para isso, executa o método buscarDadosNo do atributo
comunicacaoGrid.
5.2.3.2 Classe DadosNo
A classe DadosNo contém as informações de um determinado Nó do Grid. Seus
atributos são:
• host: Identificador do Host cujo Nó está localizado;
• cpu: Capacidade de CPU do Nó;
• memoriaTotal: Capacidade de total de memória do Nó;
• memoriaDisponivel: Capacidade de memória disponível do Nó;
• discoDisponivel: Capacidade de disco disponível.
Seus métodos são os getters e setters dos atributos e o construtor da classe.
97
5.2.3.3 Classe ComunicacaoGrid
A classe abstrata ComunicaçãoGrid tem por finalidade fornecer uma definição dos
métodos necessários para a comunicação com o ambiente de Grid utilizado na instancia do
CoDIMS. As classes filhas devem implementar as operações específicas para a comunicação
com o seu respectivo ambiente de Grid. É importante notar (Figura 41) que o estereótipo de
disjoint no relacionamento de herança se deve ao fato de que uma instância do CoDIMS
utiliza somente um ambiente de Grid. Seus métodos são:
• executarSubConsulta: Envia uma sub-consulta para ser executada no Grid. A classe
filha deverá implementar este método para enviar as informações necessárias para a
execução da sub-consulta para o seu respectivo ambiente de Grid;
• executarOperacao: Envia uma operação para ser executada no Grid. A classe filha
deverá implementar este método para enviar o os dados necessários para a execução
da operação para o seu respectivo ambiente de Grid;
• obterConjuntoResultado: Obtém os dados de um conjunto resultado que está
localizado em algum Nó do Grid. Recebe o nome do arquivo e sua localização.
Retorna os dados do arquivo.
• buscarDadosNo: Busca os dados dos Nós do Grid e retorna um array de objetos
DadosNo. Cada classe filha deverá implementar este método para se comunicar com
o respectivo ambiente de Grid e para coletar as informações dos Nós. Para cada Nó
será criado um objeto DadosNo.
5.2.4 Classes do Pacote MECGC
A Figura 42 mostra as classes do Pacote MECGC e como elas se relacionam.
98
Figura 42. Diagrama de classes do Pacote MECGC.
A seguir são detalhados os métodos e atributos de cada classe do Pacote MECGC.
5.2.4.1 MECGCImpl
Esta classe implementa um serviço Grid e publica seus métodos para serem utilizados
como Grid Services. Ela herda suas funcionalidades da classe GridServiceImpl que faz parte
do conjunto de bibliotecas do Globus Toolkit. A classe MECGCImpl também implementa a
interface MECGCPortType que é gerada automaticamente no momento da compilação do
Grid Service. A interface MECGCPortType herda suas assinaturas de métodos da interface
GridService que também faz parte do conjunto de bibliotecas do Globus Toolkit. Os métodos
da classe MECGCImpl são:
99
• MECGCImpl: Construtor da classe;
• executarSubConsulta: Método publicado como um Grid Service para ser invocado
pela classe ComunicacaoGrid do Pacote Access Grid. Este método seleciona o
wrapper responsável pela execução da sub-consulta e executa seu método
executarSubConsulta. Retorna a localização e nome do arquivo gerado com o sub-
resultado;
• executarOperacao: Método publicado como um Grid Service para ser invocado pela
classe ComunicacaoGrid do Pacote Access Grid. Este método seleciona o operador
responsável pela execução da operação e executa seu método executarOperacao. É
retornado a localização e nome do arquivo gerado com o conjunto-resultado;
• obterConjuntoResultado: Método publicado como um Grid Service para ser invocado
pela classe ComunicacaoGrid do Pacote Access Grid. Recebe o nome do arquivo e
sua localização. Retorno os dados do arquivo.
5.2.4.2 Classe Operador
A classe abstrata Operador é a classe pai de todos os operadores que a MECD é capaz
de executar. Ela possui os métodos básicos de todos os operadores e sua principal função é
permitir que a classe MECGCImpl se abstraia dos detalhes das classes filhas. A classe
Operador utiliza a classe abstrata FabricaOperador para criar os operadores. No entanto, não é
necessária a criação de um objeto dessa classe, uma vez que o método criarOperador é
definido como método de classe. Seus métodos são:
• new: Cria um operador com base no seu nome. Este método executa o método
criarOperador da classe FabricaOperador;
• executarOperacao: Executa a operação que é implementada pelo Operador.
100
5.2.4.3 Classe LoopNestedJoin
A classe LoopNestedJoin herda os métodos da classe Operador que possui funções
básicas para a execução dos operadores. Ela é responsável pela implementação da operação
algébrica de seleção do conjunto resultado a partir das fontes. Seus métodos são:
• LoopNestedJoin: Construtor da classe;
• juntarTuplas: Este método realiza a junção de dois conjuntos-resultado.
5.2.4.4 Classe Project
A classe Project herda os métodos da classe Operador que possui funções básicas para a
execução dos operadores. Ela é responsável pela implementação da operação algébrica de
projeção dos conjuntos-resultado. Seus métodos são:
• Project: Construtor da classe;
• eliminarColunas: Eliminas colunas do conjunto resultado.
5.2.4.5 Classe FabricaOperador
A classe abstrata FabricaOperador conhece todos os operadores envolvidos em uma
configuração do CoDIMS. Assim, dado o nome do Operador e os seus argumentos, ela é
capaz de criar os objetos que os representam. Seu único método é:
• criarOperador: Cria um Operador com base no seu nome.
5.2.4.6 Classe Wrapper
A classe abstrata Wrapper é a classe pai de todos os wrappers do CoDIMS. Ela possui
os métodos básicos de todos os wrappers e sua principal função é permitir que a classe
FachadaAcessoDados se abstraia dos detalhes das classes filhas. A classe Wrapper utiliza a
classe abstrata FabricaWrapper para criar os wrappers. No entanto, não é necessária a criação
101
de um objeto dessa classe, uma vez que o método criarWrapper é definido como método de
classe. Seu único atributo é:
• subConsulta: Sub-consulta que deverá ser executada pelo wrapper.
Seus métodos são:
• executarSubConsulta: Método principal do wrapper, responsável por executar a sub-
consulta associada. Cria um arquivo contendo os dados do sub-resultado gerado.
Retorna a localização do arquivo e seu nome;
• traduzirSubConsulta: Traduz a sub-consulta do modelo interno do CoDIMS para o
modelo nativo da fonte relacionada ao wrapper;
• traduzirSubResultado:Traduz o sub-resultado do modelo nativo da fonte relacionada
ao wrapper para o modelo interno do CoDIMS;.
Os demais métodos são os getters e setters dos atributos.
5.2.4.7 Classe FabricaWrapper
A classe abstrata FabricaWrapper conhece todos os wrappers envolvidos em uma
configuração do CoDIMS. Assim, dado o nome do wrapper e os seus argumentos, ela é capaz
de criar os objetos que os representam. Seu único método é:
• criarWrapper: Cria um wrapper com base no seu nome.
Uma especificação completa das classes que herdam as funcionalidades da classe
Wrapper pode ser encontrada em (CÔCO, 2005).
5.2.4.8 Classe MECGCServiceLocator
A classe MECGCServiceLocator herda as funcionalidades da classe Service que faz
parte do conjunto de bibliotecas do Globus Toolkit. Ela também implementa a interface
MECGCService que é criada automaticamente no momento da compilação do Grid Service.
102
A classe MECGCServiceLocator e a classe MECGCPortType é utilizada pela classe
ComunicacaoGridGlobus do pacote Access Grid para acesso aos serviços publicados pela
classe MECGCImpl.
5.3 Diagramas de Seqüência
O objetivo destes diagramas é descrever as comunicações necessárias entre os
componentes para a execução de uma sub-consulta e execução de uma operação sobre dois
sub-resultados localizados em Nós distintos. Assim, neste diagrama é feito, ao longo de uma
linha de tempo, a seqüência de comunicações entre os componentes envolvidos na execução
de uma consulta.
Na Figura 43, a MECD inicia o processo enviando uma solicitação para o Componente
Acesso a Dados. Este, após buscar informações da fonte de dados a ser consultada, chama o
Componente Access Grid. O Componente Access Grid determina qual o Nó mais apropriado
para executar a sub-consulta envia a solicitação para o MECGC do Nó selecionado. No
MECGC o wrapper responsável executa a sub-consulta e, ao final do processamento, as
informações do resultado gerado são retornados até a MECD.
Figura 43. Diagrama de Seqüência do método executarSubConsulta.
103
Na Figura 44, a MECD inicia a execução de uma operação invocando o método
executarOperação() do Componente Access Grid. Este determina qual o Nó mais apropriado
para a execução da operação e envia a solicitação para o MECGC do Nó selecionado
(MECGC Nó1). No MECGC o operador responsável pela execução da operação deve buscar
o conjunto resultado localizado no outro Nó do Grid. Para isso ele se comunica com o
MECGC deste Nó (MECGC Nó 2). Ao final do processamento da operação as informações
do sub-resultado gerado são retornadas até a MECD.
Figura 44. Diagrama de Seqüência do método executarOperação.
104
6 Estudo de Caso
6.1 Introdução
Neste capítulo é apresentado um exemplo de uso da MECD através de uma aplicação
hipotética no contexto do projeto Telecardio (ANDREAO, 2006). O objetivo é avaliar e
validar a sistemática proposta comparando-a com as já implementadas anteriormente no
CoDIMS, apresentadas em (BARBOSA, 2001; BIANCARDI, 2005). São então apresentadas:
a descrição da aplicação, os cenários de testes e os resultados alcançados.
6.2 Descrição da Aplicação
O Telecardio, Telecardiologia a Serviço do Paciente em Ambientes Hospitalares e
Residenciais (TELECARDIO, 2005), é um projeto de pesquisa de iniciativa dos Programas de
Pós-Graduação em Engenharia Elétrica e em Informática do Centro Tecnológico da UFES. O
projeto propõe o desenvolvimento integrado (hardware e software) de um sistema de
Telecardiologia voltado para o acompanhamento remoto da atividade elétrica do coração em
pacientes crônicos. Os motivos que viabilizam o monitoramento remoto podem ser: estado de
saúde do paciente, sendo mais indicado a permanência em sua própria casa; estado financeiro
do paciente que não possui condição de pagar por uma internação; falta de leitos nos
hospitais; distância de sua residência até o hospital mais próximo que tenha especialidade no
tratamento de sua doença, etc. Para os casos em que os pacientes estão localizados em locais
distantes dos hospitais é interessante que eles possuam, em sua própria residência, aparelhos
que monitoram seu estado de saúde e enviam as informações para os centros médicos
especializados.
Sendo assim, nesta aplicação, é necessário conhecer quais os atendimentos médicos que
são realizados em pacientes que residem em cidades diferentes da cidade do hospital do
atendimento. Supondo que não exista uma base de dados central que possua todas as
105
informações necessárias para a consulta a aplicação precisará acessar fontes de dados que
estão distribuídas. A Tabela 2 apresenta as localizações e tipos das fontes de dados que serão
envolvidas na consulta.
Fonte de Dados Nome Localização Tipo Registros Atendimentos Atendimentos Setor Financeiro do SUS XML Registros de Pacientes Pacientes Setor de Cadastramento do SUS XML Registros de Hospitais Hospitais Setor Convênios do SUS XML Registros de Cidades Cidades IBGE XML
Tabela 2. Dados das fontes envolvidas na consulta.
As informações de Atendimentos médicos são de responsabilidade do setor Financeiro
do SUS. Cada atendimento possui o código do Cartão Nacional de Saúde do paciente (CNS) e
também o CNPJ do Hospital. Já as informações dos pacientes estão localizadas no setor de
Cadastramento do SUS, e em cada registro de paciente existe o código do seu CNS. Os dados
de todos os Hospitais conveniados estão localizados no setor de Convênios do SUS, e as
informações de todas as cidades do Brasil são armazenadas no sistema do IBGE. No registro
de paciente existe o código da cidade de residência, já no registro de hospital existe o código
da cidade onde o hospital está localizado.
A Figura 45 apresenta os DTDs das fontes de dados Atendimentos, Cidades, Pacientes e
Hospitais.
<DOCTYPE Atendimentos> <!ELEMENT Atendimento > <!ATTLIST Atendimento codigo #REQUIRED cns CDATA cnpj_hosp CDATA dt_inic CDATA dt_fim CDATA diagnostico CDATA >
<DOCTYPE Cidades> <!ELEMENT Cidade> <!ATTLIST Cidade codigo #REQUIRED nome CDATA uf CDATA >
<DOCTYPE Pacientes> <!ELEMENT Paciente> <!ATTLIST Paciente cns #REQUIRED nome CDATA cod_cidade CDATA dt_nasc CDATA >
<DOCTYPE Hospitais> <!ELEMENT Hospital> <!ATTLIST Hospital cnpj #REQUIRED razao_social CDATA cod_cidade CDATA >
Figura 45. DTDs das fontes de dados Atendimentos, Pacientes, Hospitais e Cidades.
106
6.3 Configuração do ambiente de testes
Para execução da consulta e comparações dos resultados, foram criadas três instâncias
do CoDIMS, descritas na seção 6.4 deste capítulo. O modelo integrador utilizado em todas
elas será o relacional e, neste caso, foi necessária a conversão dos modelos nativos das fontes
de dados, em XML, para o esquema global, Relacional, definido segundo Tabela 3, Tabela 4,
Tabela 5 e Tabela 6 a seguir.
Atendimento
Atributo Tipo Modificador codigo Varchar(10) Primary Key cns Number(20) Foreign Key (Paciente) cnpj_hosp Number(20) Foreign Key (Hospital) dt_inic Date Null dt_fim Date Null diagnostico Varchar(500) Null
Tabela 3. Esquema global. Tabela de Atendimentos.
Cidades
Atributo Tipo Modificador codigo Varchar(10) Primary Key nome Varchar(100) Not null uf Varchar(2) Not null
Tabela 4. Esquema global. Tabela de Cidades
Pacientes
Atributo Tipo Modificador cns Number(20) Primary Key nome Varchar(50) Not null cod_cidade Varchar(10) Foreign Key (Cidade) dt_nasc Date Null
Tabela 5. Esquema global. Tabela de Pacientes.
Hospital
Atributo Tipo Modificador cnpj Number(20) Primary Key razao_social Varchar(100) Not null cod_cidade Varchar(10) Foreign Key (Cidade)
Tabela 6. Esquema global. Tabela de Hospitais.
Configurado o esquema global, a seguinte consulta (Figura 46), escrita em SQL, foi
submetida ao CoDIMS com o objetivo de buscar todos registros de atendimentos médicos que
107
tenham sido realizados em pacientes cuja cidade de residência é diferente da localização do
hospital que realizou o atendimento.
select paciente.nome, paciente.cns, atendimento.diagnostico,
atendimento.dt_inic, atendimento.dt_fim,
hospital.razao_social, cidade.nome, cidade.uf
from paciente, atendimento, hospital, cidade
where hospital.cnpj = atendimento.cnpj_hosp and
paciente.cod_cidade = cidade.codigo and
paciente.cns = atendimento.cns and
paciente.cod_cidade <> hospital.cod_cidade
Figura 46. Consulta enviada ao CoDIMS, em linguagem SQL.
Após a execução das tarefas de análise, reescrita e otimização, é gerado um plano de
execução de consulta (PEC) (Figura 47) otimizado que foi enviado à MEC para ser executado.
Para melhor visualização do PEC, ele é apresentado em forma de árvore na Figura 48. Os
índices nos operadores identificam a sua ordem de execução no PEC.
<meta-plano>
<operador ordem-execucao="1">
<scan-relacional tabela="Atendimento">
<coluna nome="cns" tabela-origem="Atendimento"/>
<coluna nome="cnpj_hosp" tabela-origem="Atendimento"/>
<coluna nome="dt_inic" tabela-origem="Atendimento "/>
<coluna nome="dt_fim" tabela-origem="Atendimento "/>
<coluna nome="diagnostico" tabela-origem="Atendimento "/>
</scan-relacional>
<consumidor op-consumidor="3"/>
</operador>
<operador ordem-execucao="2">
<scan-relacional tabela="Hospital">
<coluna nome="cnpj" tabela-origem="Hospital "/>
<coluna nome="razao_social" tabela-origem="Hospital"/>
<coluna nome="cod_cidade" tabela-origem="Hospital"/>
</scan-relacional>
<consumidor op-consumidor="3"/>
</operador>
<operador ordem-execucao="3">
<join-nested-loop-relacional tabela-esquerda="Atendimento" tabela-direita="Hospital">
<condicao argumento-esquerdo="Atendimento.cnpj_hosp" operacao="igual"
argumento-direito="Hospital.cnpj" />
</join-nested-loop-relacional>
<produtor op-produtor="1"/> <produtor op-produtor="2"/>
<consumidor op-consumidor="4"/>
</operador>
<operador ordem-execucao="4">
<project-relacional>
<coluna nome="cns" tabela-origem="Atendimento"/>
<coluna nome="dt_inic" tabela-origem="Atendimento"/>
<coluna nome="dt_fim" tabela-origem="Atendimento"/>
<coluna nome="dianostico" tabela-origem="Atendimento"/>
<coluna nome="razão_social" tabela-origem="Hospital"/>
</project-relacional>
<produtor op-produtor="3"/>
</operador>
<operador ordem-execucao="5">
<scan-relacional tabela="Paciente">
<coluna nome="cns" tabela-origem="Paciente"/>
<coluna nome="nome" tabela-origem="Paciente"/>
<coluna nome="cod_cidade" tabela-origem="Paciente"/>
</scan-relacional>
<consumidor op-consumidor="7"/>
</operador>
<operador ordem-execucao="6">
<scan-relacional tabela="Cidade">
108
<coluna nome="codigo" tabela-origem="Cidade"/>
<coluna nome="nome" tabela-origem="Cidade"/>
<coluna nome="uf" tabela-origem="Cidade"/>
</scan-relacional>
<consumidor op-consumidor="7"/>
</operador>
<operador ordem-execucao="7"> <join-nested-loop-relacional tabela-esquerda="Paciente" tabela-direita="Cidade">
<condicao argumento-esquerdo="Paciente.cod_cidade" operacao="igual"
argumento-direito="Cidade.codigo" />
</join-nested-loop-relacional>
<produtor op-produtor="5"/> <produtor op-produtor="6"/>
<consumidor op-consumidor="8"/>
</operador>
<operador ordem-execucao="8">
<project-relacional>
<coluna nome="cns" tabela-origem="Paciente"/>
<coluna nome="nome" tabela-origem="Paciente"/>
<coluna nome="cod_cidade" tabela-origem="Paciente"/>
<coluna nome="nome" tabela-origem="Cidade"/>
<coluna nome="uf" tabela-origem="Cidade"/>
</project-relacional>
<produtor op-produtor="7"/>
</operador>
<operador ordem-execucao="9">
<join-nested-loop-relacional tabela-esquerda="Paciente" tabela-direita="Atendimento">
<condicao argumento-esquerdo="Paciente.cns" operacao="igual"
argumento-direito="Atenidmento.cns" />
</join-nested-loop-relacional>
<join-nested-loop-relacional tabela-esquerda="Paciente" tabela-direita="Hospital">
<condicao argumento-esquerdo="Hospital.cod_cidade" operacao="diferente"
argumento-direito="Paciente.cod_cidade" />
</join-nested-loop-relacional>
<produtor op-produtor="4"/> <produtor op-produtor="8"/>
<consumidor op-consumidor="10"/>
</operador>
<operador ordem-execucao="10">
<project-relacional>
<coluna nome="nome" tabela-origem="Paciente"/>
<coluna nome="cns" tabela-origem="Paciente"/>
<coluna nome="dt_inic" tabela-origem="Atendimento"/>
<coluna nome="dt_fim" tabela-origem="Atendimento"/>
<coluna nome="diagnostico" tabela-origem="Atendimento"/>
<coluna nome="razao_social" tabela-origem="Hospital"/>
<coluna nome="nome" tabela-origem="Cidade"/>
<coluna nome="uf" tabela-origem="Cidade"/>
</project-relacional>
<produtor op-produtor="9"/>
</operador>
</meta-plano>
Figura 47. PEC otimizado da consulta submetida.
O PEC descreve as sub-consultas a serem processadas e também as operações a serem
aplicadas sobre os sub-resultados gerados durante a sua execução.
109
Atendimentos Hospitais Pacientes Cidades
1 2 5 6
3 7
4 8
9
10
Atendimento
|X|
Hospital
Paciente
|X|
Cidade
|X|
(cns = cns) ^ (codigo = cod_cidade)
π π
scan scan scan scan
π
Figura 48. PEC da consulta em forma de árvore.
A MEC interpreta o PEC recebido e gera uma sub-consulta para cada fonte de dados
envolvida na consulta (Figura 49, Figura 50, Figura 51 e Figura 52). Como o modelo de dados
integrador é relacional, as sub-consultas são geradas no formato relacional, encapsuladas em
XML segundo o padrão definido em (PINHEIRO, 2004).
Tanto a MEC Centralizada (PINHEIRO, 2004) como a MECD são implementadas sobre
o framework QEEF (AYRES, 2003), o que faz com que as funcionalidades de interpretação
do PEC e geração das sub-consultas sejam herdadas do framekork, não havendo então,
diferenças entre elas nestes serviços.
<local-plano>
<coluna ordem="0" nome="cns" tabela="Atendimento" />
<coluna ordem="1" nome="cnpj_hosp" tabela="Atendimento" />
<coluna ordem="2" nome="dt_inic" tabela="Atendimento" />
<coluna ordem="3" nome="dt_fim" tabela="Atendimento" />
<coluna ordem="4" nome="diagnostico" tabela="Atendimento" />
<tabela nome="Atendimento" />
</local-plano>
Figura 49. Sub-Consulta para a fonte Atendimentos.
<local-plano>
<coluna ordem="0" nome="cns " tabela="Paciente" />
<coluna ordem="1" nome="nome" tabela="Paciente" />
<coluna ordem="2" nome="cod_cidade" tabela="Paciente" />
<tabela nome="Paciente" />
</local-plano>
Figura 50. Sub-Consulta para a fonte Pacientes.
110
<local-plano>
<coluna ordem="0" nome="codigo" tabela="Cidade" />
<coluna ordem="1" nome="nome" tabela="Cidade" />
<coluna ordem="2" nome="uf" tabela="Cidade" />
<tabela nome="Cidade" />
</local-plano>
Figura 51. Sub-Consulta para a fonte Cidades.
<local-plano>
<coluna ordem="0" nome="cnpj" tabela="Hospital" />
<coluna ordem="1" nome="razao_social" tabela="Hospital" />
<coluna ordem="2" nome="cod_cidade" tabela="Hospital" />
<tabela nome="Hospital" />
</local-plano>
Figura 52. Sub-Consulta para a fonte Hospitais.
Dependendo de cada implementação da MEC, centralizada ou distribuída, as sub-
consultas serão enviadas e integradas de uma determinada forma. Entretanto, independente da
implementação da MEC, os wrappers executarão os mesmos procedimentos para geração dos
sub-resultados.
Como as fontes de dados não possuem capacidade de processamento de consulta, por
serem arquivos XML, os wrappers interpretam as sub-consultas buscando os atributos,
recuperam todos os dados da fonte e geram os sub-resultados no modelo relacional,
encapsulados em um padrão XML.
6.4 Cenários de Teste
Objetivando comparar as possíveis formas de execução de consultas já implementadas
no CoDIMS, foram criados três cenários de testes:
Cenário 1: Processamento das sub-consultas de forma distribuída em máquinas da rede.
Porém, as sub-consultas foram enviadas e executadas seqüencialmente de forma síncrona,
uma após a outra. Já a composição dos sub-resultados foi realizada de maneira centralizada
pela MEC, implementada em (PINHEIRO, 2004).
Cenário 2: Neste cenário foi instanciada uma configuração do CoDIMS utilizando a
camada Wrapper-Grid (BIANCARDI, 2005). O processamento das sub-consultas foi
realizado de maneira distribuída e paralela, utilizando o ambiente de Grid. Já a composição
dos sub-resultados foi realizada de maneira centralizada pela MEC, tal como no cenário 1.
111
Cenário 3: Para a execução de consultas, neste cenário foi criada uma configuração do
CoDIMS que utiliza a MECD, componente Access Grid, camada MEC-Grid e o componente
MECGC. O envio e processamento das sub-consultas segue a sistemática do Cenário 2. Para a
composição do resultado final, a MECD utilizou a camada MEC-Grid, composta pelos
componentes MECGC, para distribuir e paralelizar a execução das operações sobre os
conjuntos-resultado. Ou seja, o processamento do PEC foi realizado totalmente de forma
distribuída no ambiente de Grid.
Em todos os cenários foi utilizada a infra-estrutura do Laboratório de Pesquisa em
Redes e Multimídia (LPRM) do Departamento de Informática da UFES. As máquinas e suas
configurações são apresentadas na Tabela 7.
Nome Sistema Operacional Configuração Camburi Suse 9.0 Pentium 3 1133MHz, 17.6 GB, 512 MB Costa Suse 10 Pentium 4 2.4GHz, 40GB, 1GB Setiba Suse 10 Pentium 4 2.4GHz, 40GB, 1GB Carapebus Suse 9.1 Celeron 1.8GHz, 17.6GB, 256 MB Pontal Suse 10 Pentium 4 3 GHz, 40 GB, 512 MB Switch - 10/100 Mbps
Tabela 7. Configuração da Infra-estrutura utilizada.
As fontes de dados Hospitais, Atendimentos, Pacientes e Cidades foram instaladas nas
máquinas Camburi, Costa, Carapebus e Pontal, respectivamente. A MEC de cada cenário,
distribuída ou centralizada, foi implantada na máquina Setiba (Figura 53).
Figura 53. Ambiente de testes.
112
A seguir, o processamento da consulta submetida será detalhado em cada um dos
cenários de testes descritos anteriormente.
6.4.1 Cenário 1
Os wrappers foram implantados nas máquinas Camburi, Costa, Carapebus e Pontal,
acessando as fontes de dados Hospitais, Atendimentos, Pacientes e Cidades, respectivamente.
Em cada máquina seus serviços foram publicados como Web Services, utilizando o Apache
Tomcat 5.0 como servidor Web e Apache SOAP para comunicação via Web Services.
A MEC, após interpretar o PEC e gerar as sub-consultas, como descrito no item
anterior, iniciou o processamento de cada uma delas de forma seqüencial. Após o
processamento de cada sub-consulta, o respectivo wrapper gerou um arquivo contendo o sub-
resultado e retornou para MEC o nome e localização do arquivo.
Ao final do processamento de todas as sub-consultas, a MEC transferiu cada arquivo de
sub-resultado para o seu servidor e prosseguiu a execução do PEC de maneira centralizada na
máquina Setiba, até a geração do resultado final, que foi então retornado para a aplicação
cliente que submeteu a consulta.
6.4.2 Cenário 2
A configuração das máquinas e fontes de dados é a mesma do cenário 1. Contudo, neste
cenário, as máquinas Camburi, Costa, Carapebus e Pontal fazem parte da Camada Wrapper-
Grid e os serviços dos wrappers são publicados como Grid Services (Figura 54) no
middleware Globus Toolkit 3.2 (SOTOMAYOR, 2003) que foi instalado nessas máquinas.
113
Figura 54. Arquitetura de testes. Camada Wrapper-Grid.
Neste cenário, as sub-consultas foram enviadas pela MEC para o ambiente de Grid
assincronamente. Para isso, foi criada uma Thread para cada sub-consulta. Após o envio das
sub-consultas a MECD esperou até que o resultado de todas elas tenha sido retornado pelos
wrappers.
Ao final do processamento de todas as sub-consultas, a MEC transferiu cada arquivo de
sub-resultado para o seu servidor, na máquina Setiba, e prosseguiu a execução do PEC de
maneira centralizada, até que o resultado final da consulta fosse gerado e retornado para a
aplicação cliente.
6.4.3 Cenário 3
O terceiro cenário está relacionado ao processamento to PEC totalmente de forma
distribuída e paralela, utilizando a MECD, que acessa os Grid Services publicados pelos
componentes MECGC da camada MEC-Grid.
A configuração das máquinas e localização das fontes de dados é a mesma do cenário 1.
Em cada Nó do Grid foi instalado um componente MECGC e em todos eles existem todos os
wrappers e operadores algébricos necessários para a configuração do CoDIMS deste cenário.
A MECD iniciou o processamento das sub-consultas enviando-as para o componente
Access Grid, assincronamente. O componente Access Grid enviou cada sub-consulta para ser
114
processada no Nó cuja respectiva fonte de dados estava localizada. Isso fez com que não
houvesse transferências de informações entre as máquinas.
Sempre que dois sub-resultados a serem integrados eram gerados pelos wrappers, a
MECD disparava a execução das operações sobre eles nos Nós do Grid. Ela submetia a
solicitação para o componente Access Grid que determinava qual o Nó apropriado para
execução da operação.
Uma vez que ainda não existe um escalonador para definir, em tempo de execução, qual
o melhor Nó para a execução de uma operação, a escolha foi feita baseando-se na localização
e no tamanho dos sub-resultados. No caso a operação de ordem de execução 3 (Atendimento
|X| Hospital) e 4 (π) (Figura 48) o componente Access Grid selecionou a máquina Costa para
ser o Nó a executar a operação (Figura 53). Esta escolha se deve ao fato de o conjunto
resultado da fonte Atendimentos estar localizado neste Nó e, nos testes realizados, o tamanho
do sub-resultado da fonte Hospitais ser menor. Essa escolha objetivou diminuir o tempo na
transferência dos sub-resultados de um Nó para outro. Já a operação de ordem de execução 7
(Paciente |X| Cidade) e 8 (π) foi executada na máquina Carapebus, já que o sub-resultado da
fonte Pacientes estava localizado neste Nó e o tamanho do conjunto resultado da fonte
Cidades ser menor que o da fonte Pacientes.
A MECD esperou até que os dois sub-resultados fossem gerados pelos operadores
algébricos nos Nós do Grid, para então prosseguir a execução do PEC.
Ao receber a notificação de finalização das duas operações que ocorriam em paralelo, a
MECD submeteu uma solicitação para o componente Access Grid para esse iniciar a execução
da última operação em um Nó do Grid. Ele selecionou a máquina Carapebus para ser o Nó de
execução da operação de ordem de execução 9 (|X| (cns = cns) ^ (codigo = cod_cidade)) e 10
(π), já que o sub-resultado localizado nesta máquina era maior comparado ao sub-resultado da
máquina Costa. Ao final da operação o sub-resultado final ficou localizado na máquina
Carapebus. Sua localização e nome do arquivo contendo os dados foram retornados para a
MECD, que, por sua vez, retornou-os para a aplicação cliente. A Figura 55 apresenta as
transferências de sub-resultados e localização de execução das operações.
115
PontalCosta
Carapebus
Camburi
Hospitais
Operação 3
Atendimento |X| Hopital
Operação 7
Paciente |X| Cidade
Operação 9
|X|
(cns = cns) ^ (codigo = cod_cidade)
Cidades
Resultado
Operação 3
Localização
Resultado
Cliente
1
1 2
3
Figura 55. Transferência dos sub-resultados e execução das operações.
6.5 Resultados Alcançados
A sistemática para execução dos testes foi a seguinte: Para cada cenário executou-se a
consulta diversas vezes utilizando-se fontes de dados com a mesma quantidade de registros,
calculando-se o tempo médio de execução. Em seguida, aumentou-se a quantidade de
registros nas fontes de dados, repetindo-se os testes diversas vezes em cada cenário.
É importante ressaltar que não foi utilizada uma infra-estrutura dedicada de rede e de
máquinas, ou seja, os demais usuários do LPRM, onde os testes foram realizados, poderiam
estar utilizando as máquinas no momento em que os testes estivessem sendo executados.
O objetivo foi avaliar e comparar o comportamento de cada cenário no que se refere ao
tempo médio de execução das consultas com diferentes tamanhos das fontes de dados
envolvidas.
116
Os resultados obtidos a partir dos testes feitos podem ser visualizados nos gráficos das
da Figura 56 e Figura 57.
0,00
0,20
0,40
0,60
0,80
1,00
1,20
1,40
10 20 30 40 50 60 70 80 90
Quantidade de registros
Tem
po
de e
xecu
ção
(s)
Cenário 1
Cenário 2
Cenário 3
Figura 56. Gráfico de comparação entre as três abordagens com pequena quantidade de registros (< 100).
Observando o gráfico da Figura 56 pode-se concluir que, para pequenos conjuntos de
dados (até 20 registros) a serem processados, a abordagem do cenário 1, sub-consultas
seqüenciais com composição centralizada, torna-se a mais eficiente. A partir deste ponto e até
65 linhas a abordagem de execução do cenário 2, sub-consultas de forma paralela com
composição centralizada, é a mais vantajosa. Isso porque para pequenas quantidades de
registros a execução seqüencial de sub-consultas e composição centralizada compensam o
overhead causado pela criação de Threads e comunicação com o Globus Toolkit do cenário 2.
Pelo gráfico, nota-se também que a partir de cerca de 30 registros, o tempo de execução
do cenário 1 ultrapassa o do cenário 3, tornando-se o menos indicado. Isso mostra que mesmo
tendo que gerenciar uma grande quantidade de Threads e realizar diversas comunicações com
o ambiente de Grid, o cenário 3, que utiliza a MECD, consegue processar as sub-consultas
mais rapidamente, em comparação com o cenário 1.
Acima de 65 registros o cenário 3, com execução do PEC totalmente de forma
distribuída utilizando a MECD, torna-se o mais eficiente, sendo ultrapassado pelo cenário 2
no que se refere ao tempo de execução da consulta. A explicação para isso é que a
117
composição centralizada dos sub-resultados demanda um alto tempo de processamento, sendo
mais indicado que ela seja realizada de maneira distribuída e paralela no ambiente de Grid,
mesmo que se tenha a necessidade um maior controle no gerenciamento das Threads e sejam
realizadas muitas mais comunicações com o Globus Toolkit.
0,00
10,00
20,00
30,00
40,00
50,00
60,00
70,00
80,00
90,00
100,00
110,00
120,00
130,00
140,00
150,00
160,00
170,00
180,00
50 100 200 300 400 500 600 700 800 900 1000
Quantidade de registros
Tem
po
de e
xecu
ção
(s)
Cenário 1
Cenário 2
Cenário 3
Figura 57. Gráfico de comparação entre as três abordagens com grande quantidade de registros (> 100).
Já pelo gráfico da Figura 57 fica claro que, à medida que se aumenta a quantidade de
registros, o tempo médio de execução das consultas cresce de maneira exponencial, porém,
com fatores diferentes em cada cenário.
O tempo de execução no cenário 1 cresce mais que os outros dois cenários à medida que
se aumenta a quantidade de registros. No cenário 2, o crescimento não é tão acentuado visto
que existe paralelismo na execução das sub-consultas. Já no cenário 3, que utiliza a MECD, o
crescimento é o menor, já que existe paralelismo na execução das sub-consultas e na
composição dos sub-resultados, sendo ainda mais vantajoso a sua utilização quando é
necessário realizar a integração de grandes quantidades de registros.
6.6 Decompondo o tempo total de execução
O tempo de total execução da consulta submetida é composto, principalmente, pelos
seguintes fatores:
118
1. Execução das sub-consultas (s);
2. Transferência de sub-resultados das sub-consultas (t);
3. Composição de sub-resultados (c);
4. Transferência de sub-resultados das operações (o).
A Figura 58 apresenta os fatores que compõem o tempo total de execução, considerando
o estudo de caso descrito neste capítulo.
s1 s2 s3 s4
t1 t2 t3 t4
c1 c2
c3
o1 o2
Figura 58. Fatores que compõem o tempo total de execução.
A Tabela 8 apresenta as funções de tempo f(s,t,c,o) de cada cenário, considerando esses
4 fatores, de acordo com a Figura 58.
Cenário 1
T = Σsi + Σti + Σci
Cenário 2
T = Max(si) + Σti + Σci Cenário 3
T ≤ Max(si) + Max(Min(t1, t2), Min(t3, t4)) + Max(c1, c2) + Min(o1, o2) + c3
Tabela 8. Funções de tempos de execução.
Nos cenários 1 e 2 o fator (o) não é considerado, pois as operações de composição de
sub-resultados são executadas de maneira centralizada no servidor da MEC. Ou seja, os sub-
resultados gerados por tais operações não precisam ser transferidos.
119
6.6.1 Cenário 1
No cenário 1, onde as sub-consultas e operações de composição são executadas
sequencialmente, o tempo total de execução da consulta é dado pela soma dos seguintes
termos:
1. Σsi: somatório dos tempos de execução de cada uma das sub-consultas;
2. Σti: somatório dos tempos de cada transferência dos sub-resultados das sub-
consultas para a MEC;
3. Σci: somatório dos tempos de execução de cada operação de composição dos sub-
resultados.
6.6.2 Cenário 2
No cenário 2 as sub-consultas são processadas paralelamente e as operações de
composição executadas sequencialmente. Neste caso, comparando com o cenário 1, a
diferença está apenas no primeiro termo, que passa a ser:
1. Max(si): o maior entre os tempos de execução das sub-consultas.
Essa diferença ocorre porque as sub-consultas são executadas em paralelo e, neste caso
quanto maior for o tempo individual de execução de cada sub-consulta mais se diminui o
tempo total de execução da consulta, em comparação com o cenário 1.
6.6.3 Cenário 3
No cenário 3, onde tanto as sub-consultas como as operações de composição são
executadas paralelamente, o tempo total de execução é menor ou igual à somatória dos
seguintes termos:
1. Max(si): o maior entre os tempos de execução das sub-consultas (tal como no
cenário 2);
120
2. Max(Min(t1, t2), Min(t3, t4)): o maior entre os menores tempos de transferência de
dois sub-resultados relacionados a uma mesma operação. Os termos Min(t1, t2) e
Min(t3, t4) refletem o algoritmo utilizado pela MECD que prioriza a transferência
do menor sub-resultado dentre os dois que são necessários para uma operação de
composição. Cabe ressaltar que as duas transferências (t1 ou t2) e (t3 ou t4) são
realizadas em paralelo;
3. Max(c1, c2): o maior entre os tempos de execução das operações de composição c1
e c2 que são executadas em paralelo;
4. Min(o1, o2): o menor entre os tempos de transferência dos sub-resultados gerados
pelas operações c1 e c2. Tal como no termo 2 será priorizada a transferência do
menor sub-resultado;
5. c3: tempo de execução da operação c3.
É importante notar que o tempo total de execução neste cenário é representado por uma
inequação. Isso porque existe, por exemplo, a seguinte possibilidade: a operação representada
por c1 possuir um tempo de execução maior que c2, e c1 ser iniciada antes de c2. Neste caso,
o fator 3 será menor que Max(c1, c2).
Comparando com o cenário 2, o tempo gasto com fator (t) diminui já que o número de
transferências é menor ((t1 ou t2) e (t3 ou t4)), transfere-se o menor sub-resultado e as duas
transferências necessárias são realizadas em paralelo. Além disso, o gasto com o fator (c)
também é menor já que as composições são também executadas em paralelo. A transferência
final (Min(o1, o2)) compensa as outras duas transferências evitadas, considerando que,
geralmente, nas transferências finais os sub-resultados são menores que as transferências
iniciais/intermediárias.
121
7 Conclusões
7.1 Conclusões Gerais
Os sistemas de integração de dados têm por objetivo fornecer aos usuários uma
interface uniforme e transparente para as diversas fontes de dados, possivelmente autônomas,
heterogêneas e distribuídas (ÖZSU; VALDURIEZ, 2001). Ou seja, o objetivo é liberar o
usuário de ter que localizar as fontes de dados, interagir com cada uma isoladamente e
combinar manualmente dados vindos dessas múltiplas fontes (HALEVY, 2003).
Uma grande quantidade de informações e serviços, heterogêneos e distribuídos (por
exemplo, home pages, bibliotecas digitais online, catálogos de produtos, etc.), está
prontamente disponível (BOUGUETTAYA et al., 2000), e os usuários, cada vez mais,
necessitam de uma visão integrada dos dados disponíveis a partir dessas fontes de dados
(HAKIMPOUR; GEPPERT, 2001).
Como forma de aprimorar os serviços para processamento de consultas em sistemas de
integração de dados heterogêneos e distribuídos o uso de um ambiente distribuído têm se
tornado uma solução promissora. Apesar de a infra-estrutura necessária já estar disponível,
ainda não existe uma solução completa para o problema (KOSSMANN, 2000; CARVALHO
et al., 2006). Recentemente, computação em Grid vem sendo disseminada e usada em uma
grande variedade de aplicações. Ela provê acesso transparente a recursos distribuídos como
processamento e armazenamento de dados. Essencialmente, os usuários enxergam o Grid
como um único e grande computador, desconhecendo o fato de os recursos estarem
geograficamente distribuídos e serem conectados por uma rede de computador. Sendo assim,
um ambiente de computação em Grid apresenta-se como uma boa opção para aprimorar o
processamento das consultas em sistemas de integração de dados, considerando os seguintes
fatores: i) distribuição das fontes de dados; ii) quantidade de dados envolvidos em algumas
aplicações; iii) existência de uma demanda acentuada por recursos distribuídos para
transformação entre modelos de dados e os processos de integração propriamente ditos.
122
Nesse contexto, vem sendo desenvolvido o CoDIMS (Configurable Data Integration
Middleware System). O CoDIMS é um middleware para integração de dados heterogêneos e
distribuídos, onde as consultas submetidas são decompostas em sub-consultas para cada fonte
de dados integrante do sistema. As sub-consultas são enviadas pela MEC para o Componente
de Acesso aos Dados que se utiliza de wrappers para acessar as diversas fontes integradas
pelo sistema.
A incorporação da camada Wrapper-Grid (BIANCARDI; SILVESTRE; BARBOSA,
2005b), criou uma infra-estrutura de Grid, utilizando o Globus Toolkit 3.2, onde a execução
das sub-consultas passou a ser realizada de forma distribuída e paralela. Os sub-resultados
gerados pelos wrappers foram distribuídos nos Nós do Grid. Assim, a camada Wrapper-Grid,
possibilitou uma condição inicial para que a execução das operações de composição dos sub-
resultados também ocorresse de maneira paralela nos Nós do Grid. Sendo assim, o objetivo
deste trabalho é a especificação e implementação de uma Máquina de Execução de Consultas
Distribuída (MECD) em ambiente de Grid para o CoDIMS.
Contudo, para dar suporte às necessidades da MECD, a camada Wrapper-Grid foi
estendida, dando origem à camada MEC-Grid, que além das funcionalidades disponíveis na
camada Wrapper-Grid, fornece serviços para: i) comunicação entre os Nós do Grid; ii)
transferência de sub-resultados entre os Nós do Grid; iii) execução das operações de maneira
distribuída e paralela. Os serviços são disponibilizados como Grid Services através do
componente MECGC, que estende as funcionalidades do componente WGC. O MECGC é
implantado em cada Nó pertencente ao Grid e, além de todos os wrappers necessários em
uma instancia do CoDIMS, o MECGC contém todos os operadores algébricos que são
responsáveis por implementar as operações executadas sobre os sub-resultados na composição
do resultado final de uma consulta.
Como objetivo secundário, este trabalho incorporou ao CoDIMS um novo componente
denominado Access Grid. Ele visa auxiliar no processo de integração de dados heterogêneos e
distribuídos, fazendo a ligação entre as camadas de Integração e MEC-Grid, sendo que seu
principal objetivo é abstrair da camada de Integração os requisitos necessários para a
execução de serviços no Grid, da camada MEC-Grid.
Para validação da sistemática proposta, foram criados três cenários de testes:
123
1. Execução distribuída das sub-consultas, sendo elas processadas sequencialmente,
uma após a outra. Execução centralizada das operações sobre os sub-resultados para
composição do resultado final;
2. Execução distribuída e paralela das sub-consultas. Execução centralizada das
operações sobre os sub-resultados para composição do resultado final;
3. Execução distribuída e paralela das sub-consultas. Processamento das operações
também de maneira distribuída e paralela, utilizando a MECD proposta neste
trabalho.
Os resultados obtidos mostram que, para aquelas aplicações nas quais os sub-resultados
provenientes das fontes de dados são pequenos, a utilização do cenário 1 mostra-se mais
eficiente. Os testes realizados mostram também que à medida que se aumenta a quantidade de
dados retornados pelas fontes e também quando se aumenta a quantidade de fontes de dados a
serem integradas em uma consulta, os cenários 2 e 3, onde existem distribuição e paralelismo
de tarefas, tornam-se mais satisfatórios. Entretanto, para consultas nas quais as fontes de
dados são razoavelmente grandes, a nova abordagem de execução de consultas do CoDIMS
apresentada neste trabalho é mais interessante, pois o tempo de resposta é consideravelmente
menor. Assim, quanto maior a quantidade de dados a serem integrados, mais significativa é a
diferença entre a abordagem que utiliza a MECD (cenário 3) e os demais cenários testados, no
que diz respeito ao tempo de execução da consulta.
7.2 Contribuições
De uma maneira geral, as contribuições deste trabalho, para a integração de dados, são:
• Execução em paralelo das operações realizadas sobre os sub-resultados;
• Independência na execução das operações;
• Disponibilização do resultado gerado pela execução de um operador em um Nó do
Grid para ser utilizado por outros operadores, de acordo com a hierarquia da árvore
que descreve o PEC;
Com relação ao projeto CoDIMS, as principais contribuições estão relacionadas a:
124
• Especificação e incorporação da MECD;
• Especificação e incorporação da camada MEC-Grid e dos seus componentes
MECGC;
• Especificação e incorporação do componente Access Grid;
• Redução da carga do servidor da MEC com a distribuição do processamento;
• Implementação de um protótipo com relação ao estudo de caso;
• Redução do tempo de execução de consultas que integram grandes fontes de dados;
• Publicação do artigo “A proposal for Distributed Query Execution Engine in a Grid
Environment to CoDIMS”. Proceedings of the IV Workshop on Computational Grids
and Applications (WCGA 2006) (TREVISOL; BARBOSA, 2006).
7.3 Trabalhos futuros
No decorrer do desenvolvimento, surgiram alguns assuntos que não haviam sidos
discutidos e pensados anteriormente, mas que agora devem ser melhor explorados. Estes
assuntos estão relacionados tanto com o aperfeiçoamento deste trabalho como com melhorias
que devem ser feitas no CoDIMS.
• Estudar e verificar a eficácia da utilização de outras ferramentas de desenvolvimento
em Grid ao CoDIMS comparando com o Globus Toolkit;
• Incorporação de um otimizador para consultas distribuídas. O otimizador para
consultas distribuídas, no momento da geração do PEC otimizado, deve considerar a
sistemática de execução distribuída das operações envolvidas na execução de uma
consulta. Um PEC otimizado para consultas centralizadas geralmente não é o mais
eficiente se for aplicado a consultas cujas operações são executadas de forma
distribuída. Isso se deve ao fato de que em processamento centralizado não há
paralelismo de tarefas, sendo mais eficiente e utilização de PECs com topologias
lineares, enquanto que na execução paralela das operações é mais indicado o uso de
PECs com topologias ramificadas.
125
• Incorporar um escalonador dinâmico ao Componente Access Grid para auxiliar no
processo de seleção do melhor Nó para execução de uma sub-consulta e de uma
operação;
• Efetuar testes mais elaborados envolvendo: diferentes PECs que possuam topologias
diferentes (Lineares e Ramificadas); mais fontes de dados; diferentes tipo de fontes
de dados, como por exemplo - orientada a objetos, planilhas, páginas Web, dados
geográficos etc.; fontes com uma grande quantidade de dados; utilização de um
número maior de máquinas com mais recursos; implantação dos serviços
desenvolvidos em diferentes nós de um Grid pertencentes a outras instituições, de
forma que se possa ter uma Organização Virtual em escala global e com recursos
mais poderosos.
• Implementação do CoDIMS multi-usuário. Isso é possível pois, com a camada MEC-
Grid, diferentes instâncias dos componentes MECGC podem ser criadas para
diferentes usuários, o que possibilita uma independência em suas execuções. Assim,
diferentes usuários podem executar diferentes consultas ao mesmo tempo;
• Realocação de instâncias. Devido à necessidade de realizar uma realocação de
instâncias MECGC em tempo de execução, torna-se interessante que o componente
Access Grid possua a função de monitorar a vazão de cada sub-consulta. Quando
identificada uma sobrecarga de um Nó, uma nova instância será criada para ser
executada em um outro Nó do Grid. Contudo, a instância antiga poderá continuar
executando, pois para fontes com grande capacidade de processamento, pode
acontecer de, apesar de a nova instância estar executando em um Nó menos
sobrecarregado, a instância antiga finalizar a sua execução antes da nova. Nesse
sentido, é necessário abortar a execução de uma instância caso o resultado já tenha
sido gerado por outra. Dessa forma, o Nó que gerar primeiro o resultado deverá
notificar o componente Access Grid para que ele possa abortar a execução da tarefa
ainda não finalizada.
126
Referências
ABITEBOUL, S. et al. The lowell database research self assessment. May 2003. Disponível em: <http://research.microsoft.com/~Gray/lowell/>. Acesso em: 07 de novembro de 2006.
ALPDEMIR, N. et al. OGSA-DQP: A service-based distributed query processor for the grid. In: UK e-Science All Hands Meeting Nottingham. EPSRC, 2003. Disponível em: <http://twiki.mygrid.org.uk/twiki/pub/Mygrid/AllHands2003Local/114.pdf>. Acesso em: 06 de novembro de 2006.
ALPDEMIR, N. et al. Service-based distributed querying on the grid. In: 1st International Conference on Service Oriented Computing (ISOC). [S.l.]: Springer Verlag, 2003. p. 467-482.
ANDRADE, H.; KURC, T.; SUSSMANY, A.; SALTZ, J. Active Proxy-G: Optimizing the Query Execution Process in the Grid. Conference on High Performance Networking and Computing, 2002. Proceedings of the 2002 ACM/IEEE conference on Supercomputing. Disponível em: <http://www.supercomp.org/sc2002/paperpdfs/pap.pap219.pdf>. Acesso em: 06 novembro 2006.
ANDREAO, R. V.; PEREIRA FILHO, J. G.; CALVI, C. Z. TeleCardio: Telecardiologia a Serviço de Pacientes Hospitalizados em Domicílio. In: Congresso da Sociedade Brasileira de Informática em Saúde, 2006, Florianópolis. Anais do XX CBIS, 2006. Disponível em <http://www.sbis.org.br/cbis/arquivos/906.pdf>. Acesso em: 15/11/2006.
ATKINSON, M. SPECIAL THEME: Grids The Next Generation. October 2004. ERCIM - The European Research Consortium for Informatics and Mathematics. Disponível em: <http://www.globus.org/alliance/publications/papers.php>. Acesso em: 06 novembro 2006.
ATKINSON, M.; BAXTER, R.; HONG, N. Grid Data Access and Integration in OGSA. 2002. EPCC, University of Edinburgh. Disponível em: <http://www.cs.man.ac.uk/griddb/ papers/OGSA-DAI-spec-1.2.pdf>. Acesso em: 06 de novembro de 2006.
AVNUR, R.; HELLERSTEIN, J. M. Eddies: continuously adaptive query processing. SIGMOD Record 2000, 29(2): p. 261-272.
AYRES, F. V. M. QEEF: Uma máquina de execução de consultas extensível. Tese (Doutorado) - PUC-Rio, Brasil, 2003.
BARBOSA, A. C. P. Middleware para Integração de Dados Heterogêneos Baseado em Composição de Frameworks. Tese (Doutorado) - PUC-Rio, Brasil, Maio 2001.
BARBOSA, A. C. P.; PORTO, F.; MELO, R. N. Configurable data integration middleware system. J. Braz. Comp. Soc., v. 8, n. 2, p. 12-19, 2002.
BERCKEN, J. et al. XXL - A Library Aproach to Supporting Efficient Implementations of Advanced Database Queries. In: International Conference On Very Large Databases (VLDB). 2001, Roma, Italy. Proceedings... 2001.
127
BERSTIS, V. Fundamentals of Grid Computing. Dec 2003. Redbooks. Disponível em: <http://www.redbooks.ibm.com/redpapers/pdfs/redp3613.pdf>. Acesso em: 07 de novembro de 2006.
BIANCARDI, C. Distribuição e execução de wrappers em ambiente de Grid para o CoDIMS. Dissertação (Mestrado) – UFES, 2005. Disponível em: <http://codims.lprm.inf.ufes.br/publicacoes.html>. Acesso em: 07 de novembro de 2006.
BIANCARDI, C.; SILVESTRE, L. J.; BARBOSA, A. C. P. Integração de dados heterogêneos em ambiente web. In: Escola Regional de Informática - ERI. RJ/ES, 2004. Disponível em: <http://codims.lprm.inf.ufes.br/publicacoes.html>. Acesso em: 07 de novembro de 2006.
BIANCARDI, C.; SILVESTRE, L. J.; BARBOSA, A. C. P. A CoDIMS based proposal for distribution and execution of wrappers in a grid environment. In: Proceedings of the III Workshop on Computational Grids and Applications (WCGA 2005). Disponível em: <http://codims.lprm.inf.ufes.br/publicacoes.html>. Acesso em: 07 de novembro de 2006.
BIANCARDI, C.; SILVESTRE, L. J.; BARBOSA, A. C. P. Uma abordagem de grid para a integração de dados. Proceedings of XXVI Iberian Latin-American Congress on Computational Methods in Engineering (CILAMCE 2005). Disponível em: <http://codims.lprm.inf.ufes.br/publicacoes.html>. Acesso em 07 de novembro de 2006.
BOUGUETTAYA, A. et al. Supporting dynamic interactions among web-based information sources. IEEE Transactions on Knowledge and Data Engineering, 12(5): p. 779–801.
BUYYA, R. Grid Computing Info Centre (GRID Infoware). 2002. Disponível em: <http://www.gridcomputing.com/>. Acesso em: 07 de novembro de 2006.
CARVALHO, A. C. P. L. et al. Grandes Desafios da Pesquisa em Computação no Brasil. 2006 – 2016. Relatório sobre o Seminário realizado em 8 e 9 de maio de 2006. p. 7–9. Disponível em: <http://www.sbc.org.br/index.php?language=1&subject=8&content=downloads&id=231>. Acesso em: 15 de novembro de 2006.
CIRNE, W.; NETO, E. S. Grids Computacionais: Da Computação de Alto Desempenho a Serviços sob Demanda. 2005. Minicursos - Simpósio Brasileiro de Redes de Computadores (SBRC). Disponível em: <http://walfredo.dsc.ufcg.edu.br/papers/SBRC.2005.v18.pdf>. Acesso em: 15 de novembro de 2006.
CIRNE, W. The OurGrid Project. Disponível em <http://www.rnp.br/_arquivo/wrnp/2005/OurGrid.pdf>. Acesso em 06 de novembro de 2006.
CÔCO, T. Implementando wrappers xml e relacional parao codims. Monografia de Conclusão de Curso – UFES, 2005. Disponível em: <http://codims.lprm.inf.ufes.br/publicacoes.html>. Acesso em: 07 de novembro de 2006.
CONRAD, S. et al. Research issues in federated database systems: report of efdbs '97 workshop. SIGMOD Rec., ACM Press, v. 26, n. 4, p. 54-56, 1997.
128
CZAJKOWSKI, K. et al. From Open Grid Services Infrastructure to WS-Resource Framework: Refactoring & evolution. 2004. Global Grid Forum Draft Recommendation. Disponível em: <http://www.globus.org/alliance/publications/papers.php>. Acesso em: 07 de novembro de 2006.
DANTAS, M. A. R.; ALLEMAND, J. N. C.; PASSOS, L. B. C. An evaluation of globus and legion software environments. In: International Conference on Computational Science. [S.l.: s.n.], 2003. p. 963-970.
DATE, J. Introdução a Sistemas de Banco de Dados. Editora Elsevier Ltda, Ed. 8, 2004.
FAYAD, M.; SCHMIDT, D.; JOHNSON, R. Building Application Frameworks – Object-Oriented Foundations of Frameworks. John Wiley & Sons, Inc. 1999.
FERREIRA, L. et al. Introduction to Grid Computing with Globus. 2002. Redbook. Disponível em: <www.redbooks.ibm.com/redbooks/pdfs/sg246895.pdf>. Acesso em: 07 de novembro de 2006.
FONTES, V. et al. CoDIMS-G: A data and program integration service for the Grid. In: Proceedings of the 2nd workshop on Middleware for grid computing. [S.l.]: ACM Press, 2004. p. 29-34.
FONTOURA, M.F.M.C. Uma Abordagem Sistemática para o Desenvolvimento de Frameworks. Tese (Doutorado) - PUC-Rio, Brasil, 1999.
FONTOURA, M.F.; PREE, W.; RUMPE, B. UML-F: A Modeling Language for Object-Oriented Frameworks. 14th European Conference on Object Oriented Programming (ECOOP 2000). p. 63-82, Cannes, France, 2000.
FOSTER, I. What is the Grid? A Three Point Checklist. 2002. Disponível em: <http://www-fp.mcs.anl.gov/foster/Articles/WhatIsTheGrid.pdf>. Acesso em: 07 de novembro de 2006.
FOSTER, I.; GANNON, D. The Open Grid Services Architecture Platform. 2003. Disponível em: < http://www.ggf.org/Meetings/ggf7/drafts/draft-ggf-ogsa-platform-2.pdf >. Acesso em: 07 de novembro de 2005.
FOSTER, I.; KESSELMAN, C. Globus: A metacomputing infrastructure toolkit. The International Journal of Supercomputer Applications and High Performance Computing, v. 11, n. 2, p. 115-128, Summer 1997.
FOSTER, I.; KESSELMAN, C. The grid: Blueprint for a new computing infrastructure. In: San Francisco, CA, USA: MORGAN-KAUFMANN, 1999. cap. 11, p. 259-278.
FOSTER, I. et al. The physiology of the grid: An open grid services architecture for distributed system integration. Open Grid Service Infrastructure WG, Global Grid Forum, june 2002. Disponível em: <www.globus.org/research/papers/ogsa.pdf>. Acesso em: 07 de novembro de 2006.
FOSTER, I.; KESSELMAN, C.; TUECKE, S. The anatomy of the Grid: Enabling scalable virtual organizations. Lecture Notes in Computer Science, v. 2150, 2001. Disponível em: <www.globus.org/research/papers/anatomy.pdf>. Acesso em: 07 de novembro de 2006.
129
FOSTER, I., IAMNITCHI, A. On death, taxes, and the convergence of peer-to-peer and grid computing. In Proceedings of 2nd International Workshop on Peer-to-Peer Systems
(IPTS’02), 2003. Berkeley, CA.
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design Patterns – Elements of Reusable Object-Oriented Software. Addison-Wesley professional computing series, 1995.
GARCIA-MOLINA,H.; ULLMAN,J.; WIDOM,J. Database System Implementation. Prentice Hall Pub., 2000.
GIRALDI, G. A.; PORTO, F.; SCHULZE, B.; FONTES, V.; DUTRA, M. L. Data Integration Middleware System for Scientific Visualization, 2005. Technical Report. Disponível em: <http://virtual01.lncc.br/~giraldi/TechReport/Grid-Vis2005.pdf >. Acesso em: 06 de novembro de 2006.
GLOBAL Grid Forum. 2004. Disponível em: <http://www.gridforum.org/>. Acesso em: 06 de novembro de 2006.
GLOBUS. The Globus Toolkit. 2006. Disponível em: <www.globus.org>. Acesso em: 06 novembro 2006.
GOBLE, C.; ROURE, D. D. The Grid: an application of the semantic web. SIGMOD Rec., ACM Press, v. 31, n. 4, p. 65-70, 2002.
GOMES, F. R. Um otimizador de consulta para o codims. Monografia de Conclusão de Curso – UFES, 2005. Disponível em: <http://codims.lprm.inf.ufes.br/publicacoes.html>. Acesso em: 07 de novembro de 2006.
GORLA, N. Features to Consider in a Data Warehousing System, Communications of the ACM, 46(11), November, 2003, p. 111-115.
GRAEFE, G.; MCKENNA, W. The Volcano Optimizer Generator: Extensibility and Efficient Search. In: International Conference On Data Engineering (ICDE). 1993, Vienna. Proceedings... 1993, p209.
HAAS, L. M.; MILLER, R. J.; AL., B. N. et. Transforming Heterogeneous Data with Database Middleware: Beyond Integration. 1999. Disponível em: <http://www.almaden.ibm.com/projects/data/debull99.ps>. Acesso em: 16 de novembro de 2006.
HAKIMPOUR, F.; GEPPERT, A. Resolving semantic heterogeneity in schema integration: an ontology based approach. In: Proceedings of the international conference on Formal Ontology in Information Systems. USA: [s.n.], 2001. v. 2001, p. 297-308.
HALEVY, A. Y. Data integration: A status report. In: Proceedings of 10th Conference on Database Systems for Business Technology and the Web (BTW 2003). Germany: [s.n.], 2003. p. 24-29.
JABLONSKI, S.; BUSSLER, C. “Workflow Management – Modeling Concepts, Architecture and Implementation”. International Thomson Computer Press, 1996.
130
KIM, W. (Ed.). Modern database systems: the object model, interoperability, and beyond. New York, NY, USA: ACM Press/Addison-Wesley Publishing Co., 1995.
KIM, W.; SEO, J. Classifying schematic and data heterogeneity in multidatabase systems. Computer, IEEE Computer Society Press, v. 24, n. 12, p. 12-18, 1991. ISSN 0018-9162.
KOBIELUS, J.G. Workflow Strategies. IDG Books Worldwide,1997. Publisher: John Wiley & Sons Inc (Computers)
KOSSMANN, D. The State of the Art in Distributed Query Processing. ACM Computing Survey, v32, n4, Dec, 2000.
LAQUINE, C. E. Envio de código dos Wrappers em ambiente de Grid para o CoDIMS. Monografia de Conclusão de Curso – UFES, 2006. Disponível em: <http://codims.lprm.inf.ufes.br/publicacoes.html>. Acesso em: 07 de novembro de 2006.
LAWRENCE, P. Workflow Handbook. J Wiley & Sons, 1997.
LEDLIE, J.; SHNEIDMAN, J.; SELTZER, M.; HUTH, J. – Scooped Again. 2nd International Workshop on Peer-to-Peer Systems (IPTPS '03). Disponível em <http://iptps03.cs.berkeley.edu/final-papers/scooped.pdf>. Acesso em: 06 de novembro de 2006.
LITWIN, W.; MARK, L.; ROUSSOPOULOS, N. Interoperability of multiple autonomous databases. ACM Comput. Surv., ACM Press, v. 22, n. 3, p. 267-293, 1990.
MALAIKA, S.; EISENBERG, A.; MELTON, J. Standards for databases on the Grid. SIGMOD Rec., ACM Press, v. 32, n. 3, p. 92-100, 2003.
MATTOSO, M. et al. Middleware para processamento paralelo de consultas OLAP em clusters de banco de dados. In Simpósio Brasileiro de Banco de Dados, 2005. ACM Press. Uberlândia, MG.
MIDDLEWARE Based On a Code SHipping Architecture (MOCHA). 2000. Disponível em: <http://www.cs.umd.edu/projects/mocha/>. Acesso em: 07 de novembro de 2006.
MILLER, R. J. et al. The clio project: Managing heterogeneity. v. 30, n. 1, p. 78-83, March 2001. Disponível em: <citeseer.ist.psu.edu/miller01clio.html>. Acesso em: 07 de novembro de 2006.
MILOJICIC, D. S. et al.; Peer-to-Peer Computing, 2003. Technical Report. Disponível em <http://www.hpl.hp.com/techreports/2002/HPL-2002-57R1.pdf >. Acesso em: 16 de novembro de 2006.
MUNRO, C. Developing a C Client Toolkit for OGSA-DAI. Dissertação (Mestrado) - University of Edinburgh, 2004. Disponível em: < http://www.epcc.ed.ac.uk/msc/dissertations/dissertations-0304/>. Acesso em: 06 de novembro de 2006.
OPEN Grid Services Architecture - Data Access and Integration - OGSA-DAI. 2004. Disponível em: <http://www.ogsadai.org.uk>. Acesso em: 16 de novembro de 2006.
131
OPEN Grid Services Architecture - Distributed Query Processor - OGSA-DQP. 2004. Disponível em: <http://www.ogsadai.org.uk/dqp/>. Acesso em: 06 de novembro de 2006.
PEREIRA FILHO, J. G. et al. Infraware: Um Midlleware de Suporte a Aplicações Móveis Context-Aware. In: SBRC – Simpósio Brasileiro de Redes de Computadores, 2006, Curitiba. SBRC 2006.
PINHEIRO, F. S. Incorporando uma máquina de execução de consultas ao CoDIMS. Dec 2004. Monografia de Conclusão de Curso, Universidade Federal do Espírito Santo - UFES. Disponível em <http://codims.lprm.inf.ufes.br/publicacoes.html>. Acesso em: 07 de novembro de 2006.
PITOURA, E.; BUKHRES, O.; ELMAGARMID, A. Object orientation in multidatabase systems. ACM Comput. Surv., ACM Press, v. 27, n. 2, p. 141-195, 1995.
PORTO, F. et al. CoDIMS: An adaptable middleware system for scientific visualization in Grids. Journal Concurrency and Computation: Practice and Experience, v. 16, n. 5, p. 515-522, 2004.
POSTGRESQL, PostgreSQL v.8.0, 2005. Disponível em: http://www.postgresql.org/download/, Acesso em: 06 de novembro de 2006.
PREE, W. “Design Patterns for Object-Oriented Software Development”. Addison-Wesley, 1995.
QI, K. Data integration scenarios in OGSA-DAI. Dissertação (Mestrado) - University of Edinburgh, 2004. Disponível em: <http://www.epcc.ed.ac.uk/msc/dissertations/dissertations-0304/>. Acesso em: 06 de novembro de 2006.
RAHM, E.; BERNSTEIN, P. A. A survey of approaches to automatic schema matching. VLDB Journal: Very Large Data Bases, v. 10, n. 4, p. 334-350, December 2001. Disponível em: <citeseer.ist.psu.edu/rahm01survey.html>. Acesso em: 06 de novembro de 2006.
RODRIGUEZ-MARTINEZ, M.; ROUSSOPOULOS, N. Mocha: a self-extensible database middleware system for distributed data sources. In: Proceedings of the 2000 ACM SIGMOD international conference on Management of data. [S.l.]: ACM Press, 2000. p. 213-224.
RODRIGUEZ-MARTINEZ, M. et al. Mocha: A database middleware system featuring automatic deployment of application-specific functionality. In: CHEN, W.; NAUGHTON, J. F.; BERNSTEIN, P. A. (Ed.). Proceedings of the 2000 ACM SIGMOD International Conference on Management of Data, May 16-18, 2000, Dallas, Texas, USA. [S.l.]: ACM, 2000. p. 594.
SELINGER, P. et al. Access path selection in a relational data base management system, In: International Conference On Management Of Data (SIGMOD). 1979, Boston, USA. Proceedings... 1979.
SHETH, A. P.; LARSON, J. A. Federated database systems for managing distributed, heterogeneous, and autonomous databases. ACM Comput. Surv., ACM Press, v. 22, n. 3, p. 183-236, 1990.
132
SILBERSCHATZ, A.; KORTH, H.; SUDARSHAN, S. Sistema de banco de dados. Editora Elsevier Ltda, Ed 5, 2006.
SILBERSCHATZ, A.; ZDONIK, S. Database systems-breaking out of the box. SIGMOD Rec., ACM Press, v. 26, n. 3, p. 36-50, 1997.
SILVA, V. F. V; DUTRA, M. L.; PORTO, F.; SCHULZE B.; BARBOSA, A. C., OLIVEIRA, J. C. An Adaptive Parallel Query Processing Middleware for the Grid. Concurrency and Computation: Practice and Experience, v. 18, n. 6, p. 621-634, 2006.
SILVESTRE, L. J.; BIANCARDI, C.; BARBOSA, A. C. P. Sistemas para Integração de Dados Heterogêneos. 2004. Disponível em: <http://codims.lprm.inf.ufes.br/publicacoes.html>. Acesso em: 07 de novembro de 2006.
SOTOMAYOR, B. The Globus Toolkit 3 Programmer's Tutorial. Dez 2003. Tutorial. Disponível em: <http://gdp.globus.org/gt3-tutorial/>. Acesso em: 07 de novembro de 2006.
TELECARDIO. Telecardiologia a Serviço do Paciente em Ambientes Hospitalares e Residenciais, 2005. Projeto DI/DEL/UFES, Financiamento: FAPES.
THAIN, D.; TANNENBAUM, T.; LIVNY, M. Condor and the Grid. Grid Computing – Making the Global Infrastructure a Reality. 2003. p. 299-335. Disponível em <http://media.wiley.com/product_data/excerpt/90/04708531/0470853190.pdf>. Acesso em: 06 de novembro de 2006.
THEOTOKIS, S.A.; SPINELLIS, D. ACM Computing Surveys, Vol. 36, No., December 2004, p. 335-371.
THOMAS, G. et al. Heterogeneous distributed database systems for production use. ACM Comput. Surv., ACM Press, v. 22, n. 3, p. 237-266, 1990.
TPC (2003), TPC BenchmarkTM H – Revision 2.1.0, Disponível em: http://www.tpc.org. Acesso em: 06 de novembro de 2006.
TREVISOL, G. G. CoDIMS: Incorporando Nova Abordagem na Comunicação entre seus Componentes. June 2004. Monografia de Conclusão de Curso, Universidade Federal do Espírito Santo - UFES. Disponível em: <http://codims.lprm.inf.ufes.br/publicacoes.html>. Acesso em: 07 de novembro de 2006.
TREVISOL, G. G.; BARBOSA, A. C. P. A proposal for Distributed Query Execution Engine in a Grid Environment to CoDIMS. In: Proceedings of the IV Workshop on Computational Grids and Applications (WCGA 2006). Disponível em: <http://codims.lprm.inf.ufes.br/publicacoes.html>. Acesso em: 07 de novembro de 2006.
WAAS, F. Handling Non-Deterministic Data Availability in Parallel Query Execution. In: International. Workshop On Parallel And Distributed Databases (PADD). 1999, Florence, Italy. Proceedings... 1999, p. 61-65.
WIEDERHOLD, G. Value-added Middleware: Mediators. 1998. Disponível em: <http://www-db.stanford.edu/pub/gio/1998/dbpd.html>. Acesso em: 07 de novembro de 2006.
133
WIEDERHOLD, G.; GENESERETH, M. The conceptual basis for mediation services. IEEE Expert, v. 12, n. 5, p. 38-47, Sep/Oct 1997.
ZIEGLER, P.; DITTRICH, K. R. Three decades of data integration - all problems solved? In: JACQUART, R. (Ed.). 18th IFIP World Computer Congress (WCC 2004), Volume 12, Building the Information Society. Toulouse, France, August 22-27: Kluwer, 2004. (IFIP International Federation for Information Processing, v. 156), p. 3-12.
ÖZSU, M. T.; VALDURIEZ, P. Princípios de Sistemas de Banco de Dados Distribuídos. Rio de Janeiro - RJ: Editora Campus, Ed 2, 2001.
Livros Grátis( http://www.livrosgratis.com.br )
Milhares de Livros para Download: Baixar livros de AdministraçãoBaixar livros de AgronomiaBaixar livros de ArquiteturaBaixar livros de ArtesBaixar livros de AstronomiaBaixar livros de Biologia GeralBaixar livros de Ciência da ComputaçãoBaixar livros de Ciência da InformaçãoBaixar livros de Ciência PolíticaBaixar livros de Ciências da SaúdeBaixar livros de ComunicaçãoBaixar livros do Conselho Nacional de Educação - CNEBaixar livros de Defesa civilBaixar livros de DireitoBaixar livros de Direitos humanosBaixar livros de EconomiaBaixar livros de Economia DomésticaBaixar livros de EducaçãoBaixar livros de Educação - TrânsitoBaixar livros de Educação FísicaBaixar livros de Engenharia AeroespacialBaixar livros de FarmáciaBaixar livros de FilosofiaBaixar livros de FísicaBaixar livros de GeociênciasBaixar livros de GeografiaBaixar livros de HistóriaBaixar livros de Línguas
Baixar livros de LiteraturaBaixar livros de Literatura de CordelBaixar livros de Literatura InfantilBaixar livros de MatemáticaBaixar livros de MedicinaBaixar livros de Medicina VeterináriaBaixar livros de Meio AmbienteBaixar livros de MeteorologiaBaixar Monografias e TCCBaixar livros MultidisciplinarBaixar livros de MúsicaBaixar livros de PsicologiaBaixar livros de QuímicaBaixar livros de Saúde ColetivaBaixar livros de Serviço SocialBaixar livros de SociologiaBaixar livros de TeologiaBaixar livros de TrabalhoBaixar livros de Turismo
