Um Middleware para o Gerenciamento de Clusters de

UIVERSIDADE ESTADUAL DO CEARÁ – UECE
Centro de Ciências Tecnológicas - CCT
ISTITUTO FEDERAL DE EDUCAÇÃO, CIÊCIA
E TECOLOGIA DO CEARÁ - IFCE
Diretoria de Ensino – DIRE
MESTRADO PROFISSIOAL EM COMPUTAÇÃO APLICADA – MPCOMP
CICERO TADEU PEREIRA LIMA FRAÇA
Um Middleware para o Gerenciamento de Clusters
de SGBDs Heterogêneos
FORTALEZA – CEARÁ
Setembro de 2010
CICERO TADEU PEREIRA LIMA FRAÇA
Um Middleware para o Gerenciamento de Clusters
de SGBDs Heterogêneos
Dissertação apresentada ao Curso de Mestrado
Profissional em Computação Aplicada da Universidade
Estadual do Ceará e Instituto Federal de Educação,
Ciência e Tecnologia do Ceará como requisito parcial
necessário para obtenção do grau de Mestre em
Computação Aplicada, área de concentração: Redes de
Computadores
Orientador: Prof. Dr. Cidcley Teixeira de Souza
FORTALEZA – CE
Setembro de 2010
F814m
França, Cicero Tadeu Pereira Lima
Um Middleware para o Gerenciamento de Clusters de SGBDs
Distribuídos / Cícero Tadeu Pereira Lima França - Fortaleza,
2010.
114 p.
Orientador: Prof. Dr. Cidcley Teixeira de Souza
Dissertação do Curso de Mestrado Profissional em
Computação Aplicada (MPCOMP) - Universidade Estadual do
Ceará e Instituto Federal de Educação, Ciência e Tecnologia do
Ceará.
1. Banco de Dados 2. SGBDD 3. Cluster
4.
Middleware.
Universidade
Estadual
do
Ceará,
Centro de Ciências e Tecnologia.
CDD: 001.6
Título do trabalho: Um Middleware para o Gerenciamento de Clusters de SGBDs
Distribuídos
Autor: Cicero Tadeu Pereira Lima França
Defesa em: 01/09/2010
Banca Examinadora
Cidcley Teixeira de Souza, DSc (IFCE)
Presidente (Orientador)
Verônica Lima Pimentel de Sousa, DSc (IFCE)
Membro Interno
José Maria da Silva Monteiro Filho, DSc (UFC)
Membro Externo
À minha esposa Ylane, e aos meus filhos Lucas Gabriel e Cibelle.
Agradecimentos
À DEUS, que sempre mostra o caminho correto em momentos incertos.
À minha esposa Ylane pelo apoio irrestrito em todos os momentos, sempre elevando
minha auto-estima nas horas difíceis.
Ao meu filho Lucas Gabriel que, mesmo com três anos de idade, aceitava as
ausências do pai durante este mestrado.
À minha filha Cibelle, que nasceu no mesmo período da defesa desta dissertação.
À minha mãe Terezinha, por sempre ter ensinado aos filhos que o estudo é
importante na vida das pessoas.
À minha tia-madrinha Cicera, pelo acolhimento e carinho que sempre me foi dado.
À minha já falecida avó materna Quitéria, pelo exemplo de bondade e serenidade.
Ao meu orientador Prof. Cidcley Teixeira de Souza, pelo tempo dedicado no
direcionamento e incentivo, sempre apoiando nos momentos mais difíceis.
Ao MPCOMP, aos que representam a coordenação, Prof. Marcos Negreiros, Profa.
Verônica Pimentel, Prof. Klécius, e aos secretários Ton e Érika, meus sinceros
agradecimentos pelo apoio institucional no final desta caminhada.
Ao IFCE – Campus Juazeiro do Norte, por proporcionar as condições de trabalho na
fase final deste trabalho.
Resumo
Este trabalho apresenta um middleware para ser utilizado com SGBDRs (Sistemas
de Gerenciamento de Bancos de Dados Relacional) que usam a arquitetura cliente-servidor
de duas camadas. O middleware tem a finalidade de aumentar a eficiência dos SGBDRs em
relação a escalabilidade, através do gerencia de um cluster de SGBDRs.
Os SGBDRs com arquitetura cliente-servidor de duas camadas têm como
desvantagem a baixa escalabilidade. A única maneira de aumentar a escalabilidade de um
SGBDR nesse tipo de arquitetura é trocando o servidor de dados por outro com poder
computacional maior. O middleware apresentado neste trabalho aumenta a escalabilidade
dos SGBDRs citados, gerenciando a distribuição horizontal dos dados e mantendo o
balanceamento de carga dentro do cluster de SGBDRs.
Palavras-chave: Banco de Dados, SGBDR, Cluster, Middleware, Distribuição de
Dados, Balanceamento de Carga.
Abstract
This project shows a middleware to be used with RDBMS (Relational Database
Management System) that use the client-server architecture of two tier. The middleware has
a the objective to increase the efficiencies of the RDBMS in order to a relation with scales,
through a RDBMS cluster management.
The RDBMS with client-server architecture of two tier has as an disadvantage the
low scales. The only way to increase the scale of a RDBMS n this type of architecture is
changing the data servers by another one with a bigger computer power. The middleware
shown in this project increases the scales of the mentioned RDBMS, managing the
horizontal data distribution and keeping the balance inside the cluster of RDBMS.
Keywords: Database, RDBMS, Cluster, Middleware, Data Distribution, Load
Balancing.
Lista de Figuras
Figura 1.1 – Arquitetura cliente-servidor de duas camadas
Figura 2.1 – A arquitetura física centralizada
Figura 2.2 – A arquitetura física cliente/servidor de duas camadas
Figura 2.3 – A arquitetura lógica cliente/servidor de três camadas
Figura 2.4 – Um elemento XML complexo chamado <projetos>
Figura 3.1 – Arquitetura física Real Application Clusters
Figura 3.2 – Sistema de balanceamento de carga
Figura 3.3 – Sistema de alta disponibilidade
Figura 3.4 – Replicação em Cascata
Figura 3.5 – Replicação continua após uma falha
Figura 3.6 – Arquitetura do ParGRES
Figura 3.7 – Arquitetura do modelo de mediador proposto por Tercilio Junior
Figura 3.8 – Exemplo de RAIDb-0
Figura 3.9 – Exemplo de RAIDb-1
Figura 3.10 – Exemplo de RAIDb-2
Figura 3.11 – Exemplo de RAIDb-1-0
Figura 3.12 – Exemplo de RAIDb-0-1
Figura 4.1 – Middleware proposto
Figura 4.2 – Diagrama de caso de uso sintético
Figura 4.3 – Diagrama de caso de uso básico
Figura 4.4 – Exemplo de arquivo XML gerado pelo middleware
Figura 4.5 – Diagrama de classe do LUCAS
Figura 4.6 – Diagrama de classe do GABRIEL
Figura 4.7 – Diagrama de Seqüência – Incluir registro independente
Figura 4.8 – Diagrama de Seqüência – Incluir registro dependente
Figura 4.9 – Fluxograma para inclusão de dados
Figura 4.10 – Diagrama de Seqüência – Alterar registro
Figura 4.11 – Fluxograma para alteração de dados
Figura 4.12 – Diagrama de Seqüência – Excluir registro
Figura 4.13 – Fluxograma para exclusão de dados
Figura 4.14 – Diagrama de Seqüência – Consultar via SetConsultar
Figura 4.15 – Fluxograma para consultar dados via SetConsultar
Figura 4.16 – Diagrama de Seqüência – Consultar via SetConsultarSQL
Figura 5.1 – Aplicativo GABRIEL
Figura 5.2 – Aplicativo Cliente
Figura 5.3 – Aplicativo Configura Cliente
Figura 5.4 – Gráfico do percentual médio de desempenho da CPU na inclusão de dados
Figura 5.5 – Gráfico do percentual médio da utilização da rede na inclusão de dados
Figura 5.6 – Gráfico do percentual médio de desempenho da CPU na alteração de dados
Figura 5.7 – Gráfico do percentual médio da utilização da rede na alteração de dados
Figura 5.8 – Gráfico do percentual médio de desempenho da CPU na consulta de dados
Figura 5.9 – Gráfico do percentual médio da utilização da rede na consulta de dados
Lista de Tabelas
Tabela 2.1 – Exemplo de fragmentação de uma relação inteira
Tabela 2.2 – Exemplo de fragmentação horizontal
Tabela 2.3 – Exemplo de fragmentação vertical
Tabela 4.1 – Incluir registro independente
Tabela 4.2 – Incluir registro dependente
Tabela 4.3 – Alterar registro
Tabela 5.1 – Percentual médio de desempenho da CPU no processo de inclusão de dados
Tabela 5.2 – Percentual médio da utilização da rede no processo de inclusão de dados
Tabela 5.3 – Tabelas dos SGBDRs após o processo de inclusão de dados
Tabela 5.4 – Percentual médio de desempenho da CPU no processo de alteração de dados
Tabela 5.5 – Percentual médio da utilização da rede no processo de alteração de dados
Tabela 5.6 – Percentual médio de desempenho da CPU no processo de consulta de dados
Tabela 5.7 – Percentual médio da utilização da rede no processo de consulta de dados
Tabela A.1 – Atributos da classe LUCAS
Tabela A.2 – Métodos da classe LUCAS
Tabela B.1 – Atributos da classe ClientSocket
Tabela B.2 – Métodos da classe ClientSocket
Tabela C.1 – Atributos da classe GABRIEL
Tabela C.2 – Métodos da classe GABRIEL
Tabela D.1 – Atributos da classe ServerSocket
Tabela D.2 – Métodos da classe ServerSocket
Tabela E.1 – Atributos da classe SQLConnect
Tabela E.2 – Métodos da classe SQLConnect
Tabela G.1 – Chamadas aos métodos da classe LUCAS
Tabela G.2 – Métodos auxiliares utilizados na sobrecarga
Tabela G.3 – Resumo das configurações dos computadores usados no teste
Lista de Abreviaturas
ANSI
American National Standards Institute
API
Application Program Interface
BDD
Banco de Dados Distribuído
CQP
Cluster Query Processor
CRM
Customer Relationship Management
DBA
Database Administrator
DCL
Data Control Language
DDL
Data Definition Language
DML
Data Manipulation Language
DQL
Data Query Language
DTL
Data Transaction Language
ERP
Enterprise Resource Planning
ISO
International Organization for Standardization
JDBC
Java Database Connectivity
JDK
Java Development Kit
JVM
Java Virtual Machine
LAN
Local Area Network
NQP
Node Query Processor
ODBC
Open Data Base Connectivity
POO
Programação Orientada a Objeto
RAC
Real Application Cluster
RAID
Redundant Array of Inexpensive Drives
RAIDb
Redundant Array of Inexpensive Databases
SEQUEL
Structured English Query Language
SGBD
Sistema Gerenciador de Banco de Dados
SGBDD
Sistema Gerenciador de Banco de Dados Distribuído
SGBDOR Sistema de Gerenciamento de Bancos de Dados Objeto-Relacional
SGBDR
Sistema Gerenciador de Bancos de Dados Relacional
SOA
Service Oriented Architecture
SQL
Structured Query Language
UML
Unified Modeling Language
XML
eXtensible Markup Language
W3C
World Wide Web Consortium
WAN
Wide Area Network
WWW
World Wide Web
Sumário
Capítulo 1 ................................................................................................................................ 1
Introdução ............................................................................................................................... 1
1.1. Motivação ................................................................................................................ 1
1.2. Descrição do Problema ........................................................................................... 2
1.3. Solução Proposta ..................................................................................................... 3
1.4. Organização da Dissertação ................................................................................... 4
Capítulo 2 ................................................................................................................................ 5
Fundamentação Teórica .......................................................................................................... 5
2.1. Computação Distribuída.......................................................................................... 5
2.1.1. Comunicação entre Processos .............................................................................. 5
2.1.1.1. Comunicação Síncrona e Assíncrona ................................................................ 6
2.1.1.2. Troca de Mensagens .......................................................................................... 6
2.1.1.3. Falhas de Comunicação .................................................................................... 7
2.1.1.4. Transmissão de Mensagens por Sockets ............................................................ 7
2.1.2. Cluster ................................................................................................................... 8
2.1.3. Grid Computing .................................................................................................... 9
2.1.3.1. Diferenças entre Cluster e Grid Computing .................................................... 10
2.1.4.Middleware .......................................................................................................... 10
2.2. Banco de Dados ..................................................................................................... 11
2.2.1. Banco de Dados e Sistema Gerenciador de Banco de Dados ............................ 11
2.2.2. Modelos de Bancos de Dados ............................................................................. 12
2.2.3. Arquiteturas de Banco de Dados ........................................................................ 13
2.2.3.1. Arquitetura Centralizada ................................................................................. 13
2.2.3.2. Arquitetura Cliente-Servidor de Duas Camadas ............................................. 13
2.2.3.3. Arquitetura Cliente-Servidor de Três Camadas .............................................. 14
2.2.3.4. Arquitetura Distribuída ................................................................................... 15
2.2.3.4.1. Vantagens...................................................................................................... 16
2.2.3.4.2. Desvantagens ................................................................................................ 16
2.2.3.4.3. Fragmentação de Dados ............................................................................... 16
2.2.3.4.4. Replicação de Dados .................................................................................... 18
2.2.4. SQL ..................................................................................................................... 19
2.2.5. XML .................................................................................................................... 20
2.3. Conclusão .............................................................................................................. 21
Capítulo 3 .............................................................................................................................. 23
Trabalhos Relacionados ........................................................................................................ 23
3.1. Oracle 10g ............................................................................................................. 23
3.1.1. Real Application Cluster ..................................................................................... 23
3.1.1.1. Arquitetura do Real Application Cluster ......................................................... 24
3.1.2. Oracle Clusterware............................................................................................. 24
3.1.3. Escalabilidade .................................................................................................... 25
3.1.4. Pontos Fracos na Solução da Oracle 10g .......................................................... 25
3.2. PostgreSQL ............................................................................................................ 25
3.2.1. PGCluster ........................................................................................................... 25
3.2.2. PGPool................................................................................................................ 27
3.2.3. Slony-I ................................................................................................................. 27
3.2.4. ParGRES ............................................................................................................. 29
3.2.4.1. Arquitetura ....................................................................................................... 30
3.2.4.2. Cluster Query Processor ................................................................................. 30
3.2.5. Pontos Fracos nas Soluções do PostgreSQL ...................................................... 30
3.3. Modelo para o Compartilhamento de Bases de Dados Distribuídas e
Heterogêneas ................................................................................................................ 30
3.3.1. Atores .................................................................................................................. 31
3.3.2. Classes ................................................................................................................ 32
3.3.3. Pontos Fracos do Middleware ............................................................................ 33
3.4. Sequoia................................................................................................................... 33
3.4.1. Arquitetura .......................................................................................................... 33
3.4.2. RAIDb ................................................................................................................. 33
3.4.2.1. RAIDb-0 ........................................................................................................... 34
3.4.2.2. RAIDb-1 ........................................................................................................... 34
3.4.2.3. RAIDb-2 ........................................................................................................... 35
3.4.2.4. Aninhamento de RAIDb ................................................................................... 35
3.4.3. Pontos Fracos do Sequoia .................................................................................. 35
3.5. Conclusão .............................................................................................................. 36
Capítulo 4 .............................................................................................................................. 38
O Middleware LUCAS-GABRIEL ...................................................................................... 38
4.1. Introdução .............................................................................................................. 38
4.2. Diagrama de caso de uso....................................................................................... 39
4.3. Diagrama de classe ............................................................................................... 42
4.3.1. LUCAS ................................................................................................................ 42
4.3.2. GABRIEL ............................................................................................................ 44
4.4. Diagrama de seqüência ......................................................................................... 45
4.4.1. Incluir.................................................................................................................. 45
4.4.1.1. Incluir registro independente........................................................................... 45
4.4.1.2. Incluir registro dependente .............................................................................. 49
4.4.2. Alterar ................................................................................................................. 53
4.4.3. Excluir ................................................................................................................. 55
4.4.4. Consultar ............................................................................................................ 57
4.4.4.1. SetConsultar..................................................................................................... 57
4.4.4.2. SetConsultarSQL ............................................................................................. 58
4.5. Fluxos alternativos e Funcionalidade ................................................................... 59
4.6. Conclusão .............................................................................................................. 60
Capítulo 5 .............................................................................................................................. 62
Validação .............................................................................................................................. 62
5.1. DLL “LUCAS” ...................................................................................................... 62
5.2. Aplicativo “GABRIEL” ......................................................................................... 62
5.3. Aplicativo “Cliente” .............................................................................................. 63
5.4. Aplicativo “Configura Cliente”............................................................................. 64
5.5. Cenário .................................................................................................................. 64
5.6. Casos de Validação ............................................................................................... 65
5.6.1. Incluir Dados ...................................................................................................... 66
5.6.2. Alterar Dados ..................................................................................................... 70
5.6.3. Consultar Dados ................................................................................................. 71
5.7. Análise da validação .............................................................................................. 73
5.8. Conclusão .............................................................................................................. 74
Capítulo 6 .............................................................................................................................. 75
Conclusão e Trabalhos Futuros............................................................................................. 75
6.1. Síntese da Dissertação ........................................................................................... 75
6.2. Conclusão .............................................................................................................. 75
6.2.1. Vantagens do Middleware .................................................................................. 76
6.2.2. Limitações do Middleware.................................................................................. 77
6.3. Dificuldades Encontradas...................................................................................... 77
6.4. Trabalhos Futuros ................................................................................................. 78
Apêndice A ........................................................................................................................... 80
Apêndice B ........................................................................................................................... 84
Apêndice C ........................................................................................................................... 86
Apêndice D ........................................................................................................................... 90
Apêndice E ............................................................................................................................ 91
Apêndice F ............................................................................................................................ 93
Apêndice G ........................................................................................................................... 95
Referências ............................................................................................................................ 98
1
Capítulo 1
Introdução
Nos tempos atuais a informação é um bem imprescindível. Contudo deve-se unir a
isso a necessidade de obtê-las de maneira eficiente e rápida. Este cenário leva ao
nascimento de muitas idéias com o intuito de aperfeiçoar (i) o armazenamento de dados e
(ii) a busca por um processo eficiente para fazer o armazenamento de dados.
1.1. Motivação
Com o fim da reserva de mercado para produtos de informática – Lei Federal
nº 8.248/91 – o parque computacional empresarial no Brasil começou a “existir”. Até então
raras empresas tinham um ou mais computadores.
Levando este cenário para o lado das redes de computadores a situação se agravava.
Se empresas com um computador era fato raro e com mais de um computador fato
raríssimo, o que falar das empresas que tinham mais de um computador e que os ligavam
em rede? Hoje é inimaginável uma empresa não interligar seus computadores numa rede de
computadores, mas no início da década de 1990 isso era muitas vezes tratado com descaso.
A quase inexistência de redes computacionais vinha de vários fatores. Um dos
fatores mais importante eram os softwares, uma vez que os mesmos eram criados para
automatizar processos, mas esses processos automatizados não eram integrados. Cada setor
tinha seu próprio software que armazenava suas próprias informações e essas informações
não eram compartilhadas por outros setores da mesma empresa.
Quase duas décadas depois este cenário mudou consideravelmente. Nos dias atuais
raramente encontra-se uma empresa no Brasil que não tenha um ou mais computadores. As
informações são compartilhadas entre os vários setores da empresa, o que elevou as redes
de computadores para o nível de tecnologia essencial no mundo empresarial.
Por outro lado, as empresas sabem que os dados armazenados podem e devem ser
convertidos em dividendos. Manter os dados em locais seguros é visto por alguns como
uma estratégia de mercado, mas não basta apenas mantê-los seguros, a empresa tem que ser
capaz de acessar esses dados.
2
A busca e cruzamento dos dados armazenados podem gerar novas oportunidades de
negócios. Por este motivo, todo esforço físico imposto no armazenamento de dados de nada
servirá, caso o empresário não tenha como obter esses dados de maneira fácil e rápida.
A agilidade na obtenção dos dados pode ser afetada pela tecnologia e arquitetura de
armazenamento de dados utilizada. Os SGBDRs com arquitetura cliente-servidor de duas
camadas são amplamente usados na atualidade, mas esses tipos de SGBDs têm como
desvantagem baixa escalabilidade.
As soluções existentes, para resolver a baixa escalabilidade dos SGBDRs com
arquitetura cliente-servidor de duas camadas. Essas soluções são onerosas, pois requerem a
aquisição de licenças caras de SGBD, ou a alteração dos sistemas já implantados na
empresa, ou ainda a criação de uma estrutura de hardware. As empresas de pequeno e
médio porte não têm o aporte financeiro necessário para adotarem as soluções existentes.
Este trabalho propõe uma solução, para resolver o problema de escalabilidade, menos
onerosa que as soluções existentes.
1.2. Descrição do Problema
Com o aumento da necessidade de armazenamento de grandes volumes de dados,
problemas e soluções foram surgindo. Um deles está relacionado com sistemas
centralizados de Maiframe e com hardwares capazes de armazenar e processar grandes
volumes de dados.
A criação de softwares capazes de manter grandes volumes de dados seguros e
disponíveis, também passou a ser uma necessidade, pois a perda de dados poderia ocasionar
danos, dependendo do domínio onde os dados estavam sendo usados.
Para ilustrar este cenário, idealize uma pane no armazenamento de dados da bolsa
de valores de Nova York, onde os valores das ações negociadas desaparecessem, e a sua
recuperação não fosse possível. A desordem se instalaria no sistema financeiro mundial.
Constatou-se que o armazenamento de dados mais comum, entre as pequenas e
médias empresas, utiliza o modelo de bancos de dados relacional com arquitetura
cliente-servidor de duas camadas. Nessa arquitetura, vários clientes ficam conectados em
um único servidor (figura 1.1). A grande vantagem dessa arquitetura é a facilidade do
gerenciamento centralizado dos dados, mas, em contrapartida, o servidor é responsável por
armazenar todos os dados num único ponto.
3
Cliente
Cliente
Cliente
Cliente
Cliente
Memória
Servidor
Figura 1.1 – Arquitetura cliente-servidor de duas camadas
A falta de escalabilidade é um problema que impacta diretamente sobre a rotina
diária das empresas. Com o constante aumento no volume de dados e na quantidade de
clientes conectados no servidor, as solicitações de manipulação e consultas dos dados
passam a sofre degradação no seu processamento.
As grandes empresas conseguem resolver o problema de escalabilidade com
investimentos financeiros altos, adquirindo licenças de softwares ou infra-estrutura de
hardware. As pequenas e médias empresas não têm como investir valores elevados para
reverter esse problema. Mas independente do tamanho da empresa, a escalabilidade é um
problema presente e sua solução merece atenção, pois a agilidade na obtenção dos dados é
tão importante para a tomada de decisão quanto a disponibilidade dos dados.
1.3. Solução Proposta
O middleware proposto nesta dissertação tem como foco principal a escalabilidade
associada a independência do SGBDR. Ele soluciona o problema de escalabilidade numa
estrutura de armazenamento de dados que pode ser tanto homogênea quanto heterogênea. O
problema de escalabilidade é resolvido através da distribuição dos dados horizontalmente
entre várias instâncias de SGBDRs sem interferir, contudo, na maneira como os dados são
gerenciados nesses servidores.
O middleware trata o problema de escalabilidade dos SGBDRs com arquitetura
cliente-servido de duas camadas. Para isso o middleware fornecerá um ambiente de
distribuição de dados, possibilitará um acesso simplificado aos dados distribuídos e tornará
4
a distribuição destes dados transparentes aos outros sistemas. O middleware simplificará as
solicitações, proporcionando a interação entre os sistemas clientes e os dados distribuídos
de maneira transparente.
1.4. Organização da Dissertação
No capítulo 2 são apresentados fundamentos teóricos, tais como os conceitos de
comunicação entre processos, troca de mensagem, transações concorrentes e uma visão
geral sobre cluster e grid computing. Banco de dados e suas principais características,
alguns modelos de banco de dados e as arquiteturas de banco de dados mais comuns,
também estão contidos no capítulo 2.
A arquitetura do banco de dados Oracle 10g com a tecnologia baseada em grid
computing, desenvolvida para dar suporte aos componentes que oferecem alta
disponibilidade, escalabilidade, e proteção contra falhas é apresentada no capítulo 3. Este
capítulo discute ainda o banco de dados PostgreSQL com suas soluções para os mesmos
problemas, assim como o middleware Sequoia e um modelo para o compartilhamento de
bases de dados distribuídas.
O middleware proposto é apresentado no capítulo 4. Sua validação, a descrição do
ambiente de teste, os casos de teste e os resultados são mostrados no capítulo 5.
No último capítulo são apresentados algumas considerações finais, além das
conclusões obtidas, dificuldade encontradas e os trabalhos futuros a serem realizados.
5
Capítulo 2
Fundamentação Teórica
Antes de apresentar o middleware proposto, se torna necessário esclarecer alguns
conceitos básicos que levaram a concepção desta proposta. Como o middleware proposto
tem a finalidade de gerenciar a distribuição do armazenamento de dados entre banco de
dados homogêneos e/ou heterogêneos, duas áreas do conhecimento – Computação
Distribuída e Banco de Dados – devem ser apresentadas para o melhor entendimento da
solução proposta.
2.1. Computação Distribuída
Nesta seção são discutidos alguns conceitos sobre sistemas distribuídos. Não é
pretensão desta seção exaurir o tema, uma vez que alguns dos tópicos apresentados têm
informações e contestações suficientes para justificar a quantidade de livros, artigos, entre
outras publicações acadêmicas.
2.1.1. Comunicação entre Processos
Processos que rodam em vários sistemas finais podem comunicar-se. Segundo
[KUROSE, 2006] “Um processo pode ser imaginado como um programa que está rodando
dentro de um sistema final.”. Quando os processos estão rodando no mesmo sistema final é
usada a comunicação interprocessos que é resolvida pelo sistema operacional final que
define suas regras com base na proposta do seu projeto de criação e desenvolvimento.
“Co contexto de uma sessão de comunicação entre um par de processos,
o processo que inicia a comunicação (isto é, o primeiro a contatar o
outro no início da sessão) é rotulado como cliente. O processo que
espera ser contatado para iniciar a sessão é o servidor.”
[KUROSE, 2006].
6
2.1.1.1. Comunicação Síncrona e Assíncrona
Nas comunicações síncronas quando o processo a envia (send) a mensagem o
mesmo fica bloqueado até receber (receive) a mensagem de resposta do processo b. Nesse
caso o send e receive causam bloqueio no processo.
Nesse tipo de comunicação (i) o processo remetente envia uma mensagem de
requisição pedindo autorização para iniciar a transmissão; (ii) recebendo a autorização o
processo remetente inicia o envio (send) da mensagem; (iii) o envio (send) só é concluído
após a recepção (receive) confirmando o recebimento; (iv) após concluir o processo os
buffers e estruturas de dados são liberados.
Necessitando-se de um processo que após o envio da mensagem (send) não fique
bloqueado pela recepção (receive), deve-se utilizar a comunicação assíncrona. Nesse caso a
operação send é não bloqueante. Enquanto o receive pode tanto ser bloqueante quanto não
bloqueante.
No receive bloqueante o send é liberado após a mensagem ter sido copiada para um
buffer local. Em seguida, o processo remetente pode reutilizar o seu buffer, mas não tendo
como garantia o sucesso da transmissão anterior. O receive da comunicação assíncrona
bloqueante assemelha-se com o receive da comunicação síncrona.
“Ca variante não bloqueante, o processo destino prossegue sua
execução após ter realizado a operação receive, a qual fornece um
buffer para ser preenchido em background. Ceste caso, o processo deve
receber separadamente uma notificação de que seu buffer possui dados a
serem lidos, isso pode ser feito baseado em polling ou em interrupção.”
[COULOURIS, 2007].
2.1.1.2. Troca de Mensagens
Quando se deseja criar uma comunicação entre um processo cliente e servidor
pode-se usar a troca de mensagem. Essas mensagens trocadas devem ter um protocolo de
comunicação, uma vez que, para obter o resultado esperado, esse processo requer uma
compreensão e cooperação entre o processo cliente e servidor.
Segundo [TANENBAUM, 2003] “Este método de comunicação interprocessos usa
duas primitivas, send e receive.”. O processo remetente envia uma solicitação ao processo
destino via mensagem. Ao receber a mensagem o processo servidor avalia para iniciar o
7
atendimento a solicitação ou, caso a mensagem seja inconsistente, retorna uma mensagem
de erro ao processo cliente.
2.1.1.3. Falhas de Comunicação
Um problema que deve ser levado em consideração nos sistemas que usam troca de
mensagem é a possibilidade de perdas de mensagens, “especialmente se os processos
comunicantes
estiverem
em
máquinas
diferentes
conectadas
por
uma
rede.”
[TANENBAUM, 2003].
O modelo de falha apresentado por [COULOURIS, 2007] classifica as falhas a
seguir:
• Falhas por Omissão: Falhas provenientes de problemas na execução em um
canal de comunicação ou processo.
• Falhas Arbitrárias: A falha no (i) processo acontece quando passos do
processo são omitidos ou são efetuados processamentos indesejados. A falha
no (ii) canal de comunicação aparece quando uma mensagem é corrompida,
mensagens inexistentes são enviadas ou mensagens reais são entregues mais
de uma vez.
• Falhas de Temporização: Só existem nos sistemas síncronos que precisam
da garantia de temporização.
• Mascaramento de Falhas: Falhas conhecidas de um componente do sistema,
ocultadas ou convertidas num tipo de falha aceitável através do
mascaramento.
• Confiabilidade da Comunicação de Um para Um: Falhas na validação e
integridade das mensagens.
2.1.1.4. Transmissão de Mensagens por Sockets
Quando o processo emissor está fisicamente separado do processo receptor, essa
comunicação pode fazer uso de socket sobre uma rede com protocolo TCP/IP, pois o
mesmo combina o endereço de IP, o protocolo de comunicação e a porta que será usada.
“Um processo envia mensagens para a rede e recebe mensagens dela através de um socket.”
[KUROSE, 2006].
Os três tipos de sockets mais comuns são:
8
1. Fluxo confiável de bytes orientado a conexão;
2. Fluxo confiável de pacotes orientado a conexão;
3. Transmissão não confiável de pacotes.
No primeiro tipo de socket os bytes são enviados do emissor para o receptor de
maneira continua, e garante que todos os bytes enviados vão ser recebidos na ordem em que
foram enviados.
O segundo tipo de socket é semelhante ao primeiro, mas neste caso os bytes não
serão transmitidos de uma única vez, e sim em pacotes com tamanhos bem definidos.
O terceiro tipo de socket é muito usado em aplicativos de tempo real ou em sistema
com tratamento de erro implementado no seu projeto. Nesse tipo de socket não existe a
garantia de ordem nem a garantia de entrega dos pacotes, sendo indicado para os
aplicativos onde a exigência de desempenho sobrepõe a confiabilidade dos bytes enviados e
recebidos.
2.1.2. Cluster
Cluster, ou aglomerado de computadores, pode ser definido como um grupo de
computadores que trabalham de maneira que aparentam ser uma única máquina. Para isto,
deve ser utilizado um sistema operacional distribuído. O sistema operacional distribuído “é
aquele que parece aos olhos dos usuários um sistema operacional tradicional de processador
único...” [TANENBAUM, 2003].
Outra definição de cluster, sob a ótica de redes de computadores, é apresentada por
[COULOURIS, 2007].
“Um agrupamento, ou aglomerado, é um conjunto de computadores
convencionais... interligado por uma rede de comunicação de alta
velocidade... comutada. Os computadores individuais podem ser PCs,
estações de trabalho padrão, placas de processador montadas sobre um
rack; eles ainda podem ser monoprocessadores ou multiprocessadores.
Uma aplicação de clusters é o fornecimento de serviços de alta
disponibilidade
e
flexíveis...
pela
replicação
ou
divisão
do
processamento e do estado do servidor em todos processadores do
cluster... também são usados para executar programas paralelos”
[COULOURIS, 2007].
9
A evolução das redes de computadores, capacitando ligar vários computadores em
uma rede e permitindo-os que desempenhem uma mesma tarefa, impulsionou o uso e
evolução do cluster ao estágio atual, onde o cluster se tornou uma opção interessante nos
departamentos de tecnologia das corporações.
2.1.3. Grid Computing
A idéia de um modelo capaz de lidar com uma taxa de processamento elevada e ao
mesmo tempo dividir esse processamento entre máquinas formando uma única máquina
virtual, podendo ser acessada por uma LAN (Local Area Cetwork – Rede de Área Local) ou
WAN (Wide Area Cetwork – Rede de Longa Distância), foi introduzida nos anos 90 com o
grid computing.
A analogia com as redes elétricas (power grids) é citada sempre que se deseja falar
sobre grid computing. No caso das redes elétricas, quando se tem um equipamento que
necessita de energia elétrica, basicamente, basta conectar na rede elétrica e a mesma
proverá a energia necessária para o funcionamento do equipamento. Não é preciso saber de
onde vem, em que momento foi gerada ou como foi transportada. A única coisa que
interessa é que tenha o que se deseja – energia elétrica – no momento que se precisa.
Da mesma maneira deve ser o grid computing, quando se precisar armazenar ou
recuperar informações, processar uma quantidade relativamente grande de dados entre
outros tantos recursos computacionais, basta conectar a máquina no grid computing e o
mesmo proverá o que se deseja no momento que se precisa.
“O termo grade (grid) é usado para se referir ao middleware que é
projeto para permitir o compartilhamento de recursos como arquivos,
computadores, software, dados e sensores em uma escala muito grande.
Cormalmente, os recursos são compartilhados por grupos de usuários
em diferentes organizações, os quais estão colaborando na solução de
problemas que exigem grandes números de computadores para resolvêlos, ou pelo compartilhamento de dados ou pelo compartilhamento do
poder de computação. Esses recursos são necessariamente suportados
por hardware, sistemas operacionais, linguagens de programação e
aplicações heterogêneas. É necessário gerenciamento para coordenar o
uso de recursos para garantir que os clientes obtenham o que precisam e
10
que os serviços possam fornecê-los. Em alguns casos, são exigidas
técnicas de segurança sofisticadas para garantir o uso correto dos
recursos nesse tipo de ambiente.” [COULOURIS, 2007].
2.1.3.1. Diferenças entre Cluster e Grid Computing
Embora possam parecer iguais à primeira vista, cluster e grid computing são
diferentes na sua essência.
Quanto ao gerenciamento de recurso:
• Cluster – Gerenciamento centralizado, tendo todos os nós trabalhando em
conjunto buscando um objetivo comum.
• Grid Computing – Gerenciamento descentralizado, onde cada nó pode adotar
políticas de alocação e uso de recursos, independente das políticas adotada
por outros nós.
Quanto à especificação do hardware e software:
• Cluster – Têm que ser homogêneos.
• Grid Computing – Têm que ser heterogêneos.
Quanto à conexão:
• Cluster – Requer tecnologia de redes de computadores de alto-desempenho
(“system bus”, iSCSI, Fibre Channel).
• Grid Computing – Permite redes convencionais de internet.
2.1.4.Middleware
Um middleware é um software que pode gerar a troca de informações entre
programas com diferentes (i) protocolos de comunicação, (ii) sistemas operacionais e (iii)
plataformas. O middleware também fornece uma estrutura de programação mais rica e
produtiva, facilitando (i) o desenvolvimento de aplicações distribuídas e a (ii) integração de
sistemas legados.
O middleware, geralmente, contém módulos com APIs (Application Program
Interface – Interface de Programação de Aplicativo) de alto nível para facilitar a integração
entre os aplicativos, mantendo uma interface de baixo nível para comportar a
independência de dispositivo.
11
Embora alguns middleware só suportem uma linguagem de programação,
comumente, o middleware é uma camada de software que oferece abstração de
programação.
“O middleware foi definido... como uma camada de software cujo o
objetivo é mascarar a heterogeneidade e fornecer um modelo de
programação conveniente para os programadores de aplicativos... Em
particular, ele simplifica as atividades de comunicação de programas
aplicativos por meio do suporte de abstração como a invocação a
métodos remotos, a comunicação entre um grupo de processos, a
notificação
de
eventos,
o
particionamento,
posicionamento
e
recuperação de objetos de dados compartilhado entre computadores, a
replicação de objetos de dados compartilhados e a transmissão de dados
multimídia em tempo real.” [COULOURIS, 2007].
2.2. Banco de Dados
Esta seção apresenta alguns tópicos sobre banco de dados que devem ser
conhecidos, uma vez que a arquitetura proposta foi criada para distribuir de maneira
balanceada os dados armazenados.
2.2.1. Banco de Dados e Sistema Gerenciador de Banco de Dados
A diferença entre banco de dados e Sistema Gerenciador de Banco de Dados
(SGBD) deve ficar bem clara para entender os conceitos que se seguem.
Um banco de dados deve ser projetado para o armazenamento de fatos que possuem
um significado implícito, representando aspectos do mundo real. O conjunto de
informações (dados) armazenado deve ter um significado efetivo que atende um propósito
específico.
“... um banco de dados possui algumas fontes das quais os dados são
derivados, alguns níveis de interação com os eventos do mundo real e um
publico efetivamente interessado em seus conteúdos.” [CAVATHE,
2005].
Um SGBD é um conjunto de programas que permite a criação e manipulação do
banco de dados, facilitando os processos de definição, construção, manipulação e
compartilhamento dos dados.
12
De uma maneira simplista, um banco de dados especifica os dados, as estruturas e
as restrições enquanto o SGBD gerencia a manipulação desses dados facilitando o acesso
aos mesmos, extraindo essas responsabilidades dos usuários e aplicativos.
2.2.2. Modelos de Bancos de Dados
À medida que aumentava o uso de banco de dados, foram surgindo necessidades
que antes não eram vislumbradas, com isso antigos modelos de banco de dados foram
cedendo espaços para novos modelos, causando uma evolução nos bancos de dados. Na
seqüência são mostrados alguns modelos de banco de dados e suas características
principais:
• Banco de Dados Hierárquico: Esse modelo foi muito utilizado nas primeiras
aplicações de banco de dados; ele conecta registros numa estrutura de árvore
de dados através de um relacionamento do tipo um-para-muitos.
• Banco de Dados em Rede: Semelhante ao anterior, mas nesse caso o
relacionamento é do tipo muitos-para-muitos.
• Banco de Dados Relacional: Concebido inicialmente para separar o modelo
físico do conceitual, além de prover uma fundamentação matemática; sendo
um modelo baseado na lógica e na teoria de conjuntos tornou-se o primeiro
modelo de banco de dados formal; esse modelo é uma abstração que define o
armazenamento, manipulação e recuperação dos dados estruturados na forma
de tabelas; sendo largamente utilizado nos dias atuais.
• Banco de Dados Orientado a Objeto: Esse modelo foi criado pensando na
necessidade
do
armazenamento
e
consulta
de
dados
complexos,
incorporando paradigmas já conhecidos da programação orientada a objeto
(POO), tais como a abstração de dados, encapsulamento, herança e
identificação de objetos.
• Banco de Dados Objeto-Relacional: Esse modelo é semelhante ao modelo
relacional, mas alguns conceitos do modelo orientado a objeto foram
incorporados; os esquemas do banco de dados dão suporte à criação e
consulta de objetos, classes e herança.
13
2.2.3. Arquiteturas de Banco de Dados
Assim como os modelos, no decorrer do tempo foram propostas varias arquiteturas.
As principais arquiteturas que foram propostas e ainda são usadas são apresentadas nesta
subseção.
2.2.3.1. Arquitetura Centralizada
As arquiteturas dos bancos de dados centralizados (figura 2.1) utilizavam o conceito
de concentrar nos mainframes o processamento das funções do sistema, programas de
aplicação, programas de interface entre outras funcionalidades do SGBD.
Figura 2.1 – A arquitetura física centralizada – Fonte: [AVATHE, 2005]
Os usuários acessavam os sistemas via terminais de computadores que apenas
exibiam resultados, mas não tinham poder computacional de processamento. Os processos
em si eram executados remotamente no mainframe, que após processar o solicitado,
enviava ao terminal as informações de exibição e os controles.
2.2.3.2. Arquitetura Cliente-Servidor de Duas Camadas
Essa arquitetura (figura 2.2) é uma evolução da arquitetura centralizada, pois graças
à troca dos antigos terminais cliente por PCs e workstations o poder computacional do lado
cliente aumentou, possibilitando passar parte do processamento para os mesmos e
14
“desafogando” os servidores. Os programas de interface com o usuário e os de aplicação
foram transpostos para o lado cliente.
Figura 2.2 – A arquitetura física cliente/servidor de duas camadas – Fonte: [AVATHE, 2005]
Um cliente é geralmente uma máquina de usuário com poder computacional e com
funcionalidade de interfaces, mas sempre que precisar acessar o banco de dados conecta-se
com o servidor que viabiliza o acesso aos dados. Geralmente têm-se máquinas com
software cliente e outras com software servidor, mas pode-se ter máquinas com ambos.
Na arquitetura cliente-servidor o programa cliente estabelece uma conexão com o
programa servidor para comunicar-se com o SGBD. Após estarem conectados, os sistemas
cliente enviam solicitações de manipulação e consulta dos dados, as mesmas são
processadas pelo servidor e enviadas de volta para o programa cliente, que processa e
apresenta o resultado de acordo com a necessidade.
2.2.3.3. Arquitetura Cliente-Servidor de Três Camadas
Com o crescimento da WWW (World Wide Web – Rede de Alcance Mundial – ou
simplesmente Web) os papéis na arquitetura cliente-servidor de duas camadas sofreram
mudanças que levaram a arquitetura cliente-servidor de duas camadas para a arquitetura
cliente-servidor de três camadas (figura 2.3), ou arquitetura de três camadas. Na arquitetura
de três camadas foi colocada uma camada intermediaria entre a máquina cliente e o
15
servidor de banco de dados. Essa camada do meio passou a chamar-se de servidor de
aplicação ou servidor Web, dependendo do contexto onde o aplicativo está inserido.
Figura 2.3 – A arquitetura lógica cliente/servidor de três camadas – Fonte: [AVATHE, 2005]
“Esse servidor desempenha um papel intermediário armazenando as regras de
negócio... que são usadas para acessar os dados do servidor de banco de dados.”
[NAVATHE, 2005]. Checar as credenciais do cliente antes de aceitar a solicitação do
mesmo também pode ser incrementado nesse servidor, deixando por sua conta a segurança
do banco de dados, desafogando o servidor de banco de dados desse processo.
A arquitetura em três camadas pode parecer igual a arquitetura em duas camadas,
mas ao retirar do servidor de dados regras de negócios e de segurança, deixa-se o servidor
menos sobrecarregado, pois fica responsável por gerenciar apenas os dados.
2.2.3.4. Arquitetura Distribuída
Um BDD (Banco de Dados Distribuído) é um conjunto de banco de dados
distribuídos por uma rede de computadores, mas logicamente inter-relacionados, enquanto
o SGBDD (Sistema Gerenciador de Banco de dados Distribuído) não apenas gerencia o
BDD, mas também torna a distribuição e transações transparentes para o usuário.
Existem dois tipos de banco de dados distribuídos, os (i) homogêneos que são
compostos por um único tipo de banco de dados e os (ii) heterogêneos que são compostos
por mais de um tipo de banco de dados.
16
Num banco de dados distribuído, os dados podem estar replicados ou fragmentados.
Na replicação, é criada uma cópia de cada dado em bases diferentes, deixando as bases com
os dados iguais. Na fragmentação, os dados são divididos entre bases diferentes.
2.2.3.4.1. Vantagens
Alguns dos motivos que levaram ao desenvolvimento dessa arquitetura foram a (i)
descentralização dos dados, aumentando o poder computacional de processamento; a (ii)
fragmentação dos dados levando em consideração a estrutura organizacional, persistindo os
dados no local desejado (Ex.: Departamento de Compras) aumentando a autonomia local; a
(iii) melhoria no desempenho devido a proximidade dos dados, paralelismo e
balanceamento entre os servidores de dados; (iv) tolerância a falhas aumentando a
disponibilidade dos dados; (v) economia na aquisição de servidores menores a medida que
o poder computacional exigido for aumentado; (vi) facilidade de acrescentar ou remover
novos servidores.
2.2.3.4.2. Desvantagens
O uso do banco de dados distribuído não só tem vantagens, mas traz consigo
algumas desvantagens como (i) complexidade exigida para garantir a distribuição de forma
transparente para o usuário; (ii) custo maior de implementação devido ao trabalho extra
exigido; (iii) planejamento mais difícil devido a fragmentação, alocação e, algumas vezes, a
replicação dos dados; (iv) integridade do banco exige alto recurso de rede; (v) exigência de
maior segurança tanto nos servidores quanto na infra-estrutura; (vi) inexistência de um
padrão que auxilie a conversão dos bancos de dados centralizados para os banco de dados
distribuídos; (vii) poucos casos práticos disponíveis para serem analisados.
2.2.3.4.3. Fragmentação de Dados
O tipo de fragmentação de banco de dados é a fragmentação de uma relação inteira,
ou seja, os dados de uma tabela inteira são colocados num único servidor do BDD. Dessa
maneira sempre que se precisar de alguma informação da tabela, o SGBDD irá busca essa
informação no servidor que a mantém. Para exemplificar suponha que um BDD tenha cinco
servidores de dados e que as tabelas do BDD estão espalhadas como mostrado na
tabela 2.1.
17
Tabela 2.1 – Exemplo de fragmentação de uma relação inteira
Servidor
Tabela
# Registros
S01
Cliente
10000
S02
Fornecedor
S03
PDV
1000000
S04
PDV_Item
4000000
S05
Estoque
1000
10000
Neste exemplo o servidor S02 vai precisar de um poder computacional bem menor
que o servidor S04 para atender as solicitações feitas, uma vez que o número de registros do
servidor S02 é bem menor que do servidor S04, causando um desbalanceamento de carga
entre os servidores.
Na fragmentação horizontal, as tuplas (registros) são divididas horizontalmente
entre os vários servidores. Esse tipo de fragmentação diminui o problema do
desbalanceamento de carga entre os servidores como pode ser visto na tabela 2.2. Com a
fragmentação horizontal cada registro da tabela fica em um servidor, junto com todos os
seus atributos (colunas).
Tabela 2.2 – Exemplo de fragmentação horizontal
Tabela: Cliente
Servidor
ID_Cliente
ome_Cliente
Cidade_Cliente
S01
1
Roberto
Juazeiro do Norte
S02
2
Helena
Fortaleza
S03
3
Francisco
Crato
S01
4
Lucas
Barbalha
S02
5
Ylane
Juazeiro do Norte
S03
6
Eduardo
Barbalha
S01
7
Carlos
Fortaleza
S02
8
Vitor
Fortaleza
S03
9
Maria
Crato
18
A fragmentação vertical divide as tuplas e seus atributos (tabela 2.3), o problema
nesse tipo de fragmentação está na obrigatoriedade de incluir a chave primária ou chave
candidata em cada parte da fragmentação, para que esses valores possam ser resgatados e
unidos quando necessário.
Existe ainda a possibilidade de combinar a fragmentação horizontal com a
fragmentação vertical gerando uma fragmentação mista ou híbrida.
2.2.3.4.4. Replicação de Dados
A replicação ou redundância de dados é usada para melhorar a disponibilidade dos
dados, pois através dela obtém-se um sistema de alta disponibilidade, mantendo o sistema
sempre disponível, mesmo em casos de falhas de componentes ou sobrecargas do sistema.
Embora a replicação de dados melhore a disponibilidade e o desempenho do banco
de dados, a mesma reduz a velocidade das operações de atualização, uma vez que cada
atualização deverá ser replicada em todas as cópias existentes para manter a consistência
dos dados redundantes.
Tabela 2.3 – Exemplo de fragmentação vertical
Tabela: Cliente
Servidor
ID_Cliente
S01
1
S02
ome_Cliente
Servidor
ID_Cliente
Cidade_Cliente
Roberto
S04
1
Juazeiro do Norte
2
Helena
S05
2
Fortaleza
S03
3
Francisco
S06
3
Crato
S01
4
Lucas
S05
4
Barbalha
S02
5
Ylane
S04
5
Juazeiro do Norte
S03
6
Eduardo
S06
6
Barbalha
S01
7
Carlos
S06
7
Fortaleza
S02
8
Vitor
S04
8
Fortaleza
S03
9
Maria
S05
9
Crato
19
2.2.4. SQL
A SQL (Structured Query Language – Linguagem Estruturada de Consulta)
permitiu padronizar a construção e acesso a SGBDR (Sistema de Gerenciamento de Bancos
de Dados Relacional) de diferentes tipos e em diferentes plataformas de software e
hardware.
Essa padronização impulsionou não apenas a disseminação dos SGBDR, mas
também a própria SQL. Para entender a importância da SQL são mostrados nesta subseção
todos os pontos que levaram os DBAs (Database Administrator – Administrador de Banco
de Dados) a ter na SQL um aliado importante.
No final da década de 1960 o matemático Edgar Frank Codd apresentou as
primeiras idéias sobre banco de dados relacional. Em junho de 1970 publicou o artigo “A
relational model of data for large shared data banks – Um modelo relacional de dados para
grandes bancos de dados compartilhados”, o que lhe rendeu em 1981 o prêmio ACM
TURING AWARD2.1.
Em 1973 a IBM criou o seu primeiro gerenciador de dados relacional, o SYSTEM R
que utilizava a linguagem de consulta SEQUEL (Structured English Query Language –
Linguagem Inglesa Estruturada de Consulta). Por motivos legais, a sigla foi alterada para
SQL, mas o primeiro SGBDR disponível comercialmente foi o ORACLE em 1979.
A primeira versão padronizada da SQL ocorreu em 1986, ficando conhecida como
SQL-86.
Esse padrão foi inicialmente desenvolvido no âmbito da ANSI (American
Cational Standards Institute – Instituto Nacional Americano de Padrões) sendo aprovado
pela ISO (International Organization for Standardization – Organização Internacional para
Padronização) em 1987.
Em 1989 foi publicada uma extensão do padrão SQL-86 chamada de SQL-89. A
SQL-92, também chamada de SQL2, foi publicado em 1992 e aprovado pela ISO. Essa
versão da SQL foi dividida tem três partes:
1. Entry Level (Nível de Entrada) – Nesse nível foi definido um conjunto
mínimo de comando para ser considerado padrão SQL
2. Intermediate level (Nível Intermediário)
2.1
O prêmio ACM TURING AWARD é conferido a uma pessoa que tenha dado contribuições de natureza
técnica a comunidade computacional
20
3. Full (Completo)
A SQL-99 ou SQL3 foi aprovado pela ISO no final de 1999. Nela foi definido o
uso de triggers, stored procedures, consultas recursivas entre outros. Esse padrão também
definiu regras para os SGBDOR (Sistema de Gerenciamento de Bancos de Dados ObjetoRelacional), implementando assim o suporte ao tratamento de objetos. No ano de 2003 foi
lançado o SQL-2003, introduzindo características relacionadas ao XML, seqüências
padronizadas e colunas com valores de auto-generalização.
A SQL é uma linguagem padronizada, mas cada SGBDR apresenta dialeto próprio,
com extensões diferentes entre cada fabricante de SGBD.
Os comandos da SQL são separados em grupos:
• DDL (Data Definition Language – Linguagem de Definição de Dados):
Subconjunto utilizado para criar, alterar e excluir tabelas e elementos
associados; esse é o grupo que mais muda de um fabricante para outro.
• DCL (Data Control Language – Linguagem de Controle de Dados):
Subconjunto de comandos que controla o acesso dos usuários aos dados.
• DTL (Data Transaction Language - Linguagem de Transação de Dados):
Subconjuntos de comandos usados para iniciar e finalizar transações.
• DML (Data Manipulation Language – Linguagem de Manipulação de
Dados): Subconjunto dos comandos usado para inserir, atualizar e apagar
dados.
• DQL (Data Query Language – Linguagem de Consulta de Dados): Com
apenas um único comando – select – e suas várias cláusulas e opções – nem
sempre obrigatórias – permite recuperar os dados de uma ou mais tabelas
através de consultas elaboradas como uma descrição do resultado desejado.
Além desses grupos de comandos a SQL tem operadores lógicos, operadores
relacionais e funções de agregação que, assim como na DDL, pode mudar de um fabricante
para outro.
2.2.5. XML
XML (Extensible Markup Language – Linguagem de Marcação Extensiva) é uma
linguagem universal usada para troca de informações entre organizações, empresas,
21
departamentos e banco de dados – entre outros – de uma forma transparente e organizada,
permitindo ao desenvolvedor criar as marcações (tags) mais adequadas para cada situação.
O XML passou a ser recomendada como padrão pelo W3C (World Wide Web
Consortium – Consórcio da World Wide Web) depois de estudos – feito em meados da
década de 1990 – que tinham o intuito de combinar a flexibilidade do SGML2.2 (Standard
Generalized Markup Language – Linguagem Padronizada de Marcação Genérica) com a
simplicidade do HTML (HyperText Markup Language – Linguagem de Marcação de
Hipertexto).
Com a combinação do SGML com o HTML pretendia-se criar uma linguagem que
oferecesse a capacidade de leitura via software e fosse facilmente integrada com outras
linguagens. Conforme [FARIA, 2005], essa capacidade promoveu comunicação entre
fornecedores e clientes, agilizando e reduzindo custos de processos.
Essa troca de informação barrava geralmente na incompatibilidade das tecnologias
utilizadas pelos dois lados, deixando o processo mais complicado. Esse ambiente abriu as
portas para o padrão XML, que passou a ser considerada a principal maneira para realizar
intercâmbio de dados entre tecnologias distintas, uma vez que combinava dois modelos
conceituais – (i) modelos empregados nos sistemas de documento e (ii) modelos de banco
de dados.
No XML os dados são organizados usando estruturas de árvores hierárquicas, e são
representados como elementos que podem ficar aninhados, permitindo a criação de
estruturas hierárquicas complexas. A figura 2.4 mostra um exemplo de um elemento XML
complexo.
2.3. Conclusão
O conhecimento sobre computação distribuída é importante para esta dissertação,
pois ela propõe um middleware para a distribuição dos dados armazenados. Conhecido os
processos de comunicação entre os sistemas distribuídos, torna-se mais claras as estratégias
adotada no projeto do middleware proposto neste trabalho.
2.2
“SGML... foi uma linguagem criada... com o objetivo de construir um sistema portável... com o qual
pudéssemos compartilhar e processar documentos.” [FARIA, 2005]
22
Figura 2.4 – Um elemento XML complexo chamado <projetos> – Fonte: [AVATHE, 2005]
A abordagem sobre cluster e grid computing foi incluída para que ficasses claro que
na elaboração do middleware, elas foram descartadas propositalmente e não por
desconhecimento do autor.
As arquiteturas de banco de dados contribuirão na delimitação do problema, ou seja,
o middleware foi elaborado para aumentar o desempenho de SGBDRs sobre a arquitetura
cliente-servidor de duas camadas. O aumento de desempenho foi feito utilizando
fragmentação horizontal dos dados.
A SQL é fundamental a dissertação, uma vez que o middleware trabalha com
SGBDRs. Já o conhecimento de XML é importante, uma vez que o middleware utiliza
desse padrão para gerar as respostas das consultas feitas pelo sistema cliente.
23
Capítulo 3
Trabalhos Relacionados
Neste capítulo é apresentada uma visão geral sobre as soluções adotadas pelos
SGBDs Oracle 10g e PostgreSQL para fornecer suporte a distribuição dos dados, com o
intuito de fornecer alta disponibilidade, tolerância a falhas, replicação, balanceamento de
carga, alto desempenho e escalabilidade. Também é apresentado o middleware Sequoia e
um modelo para o compartilhamento de bases de dados distribuídas.
3.1. Oracle 10g
O Oracle 10g foi o primeiro banco de dados destinado a grid computing. Melhorias
foram implementadas e lançadas na versão do Oracle 11g, contudo a estrutura básica do
Oracle 10g foi mantida.
No Oracle 10g, o banco de dados se acomoda no grid computing através da
clusterização de servidores, do armazenamento auto-gerenciado e dos mecanismos de autogerenciamento e auto-ajuste. Nesse cenário, a inclusão de novos recursos ou exclusão de
recursos existentes pode ser feito sem a necessidade de parar o banco de dados e seus
aplicativos.
“Esta arquitetura baseia-se em servidores de custo relativamente baixo,
mas
constantemente
atualizados.
Os
servidores
devem
estar
interconectados em uma estrutura de cluster. O Oracle Application
Server 10g e o Oracle Database 10g foram concebidos para serem
executados em clusters e poderem alocar dinamicamente os recursos de
acordo com a necessidade do grid.” [OLIVEIRA, 2004].
3.1.1. Real Application Cluster
O RAC (Real Application Cluster) é o principal componente do Oracle 10g, pois
através dele o Oracle 10g oferece alta disponibilidade, escalabilidade, proteção contra
falhas de hardware e software. O RAC permite que o banco de dados execute aplicações em
conjunto com servidores em cluster.
24
3.1.1.1. Arquitetura do Real Application Cluster
A arquitetura física do RAC (figura 3.1) é dividida em camadas, onde na interface
de acesso tem-se os usuários que têm acesso a rede pública; a infra-estrutura de rede
mantém duas redes com papeis bem definidos, a rede pública que estabelece a conexão com
os aplicativos clientes e a rede privada, que estabelece a conexão de alta velocidade para
garantir a troca de mensagens reservadas ao funcionamento do cluster; a camada de cluster
de servidores, que mantêm as instâncias do banco de dados, fica responsável pelo
gerenciamento da carga de trabalhado e o compartilhamento da memória; a camada de
armazenamento compartilhado que mantém os arquivos do banco de dados que são
armazenados “numa localização independente e cujos métodos de acesso configurados
permitem que os seus conteúdos sejam compartilhados, de modo concorrente.”
[NOGUEIRA, 2008].
Figura 3.1 – Arquitetura física Real Application Clusters – Fonte: [OGUEIRA, 2008]
3.1.2. Oracle Clusterware
O RAC deve ser colocado sobre um cluster já montado. Ainda que o RAC possa
trabalhar sobre um cluster de terceiros certificado pela Oracle, ela desenvolveu o Oracle
Clusterware que é uma solução especifica para seu banco de dados.
25
O Oracle Clusterware monitora e gerencia o RAC, dessa maneira se houver uma
falha o Oracle Clusterware irá reiniciar automaticamente a instância sem que o
administrador perceba a falha. Se um novo nó for adicionado ao cluster, o Oracle
Clusterware se responsabiliza por inicializar todas as instâncias e serviços do nó
automaticamente.
3.1.3. Escalabilidade
Na arquitetura cliente-servidor de duas camadas, quando um servidor de dados está
sobrecarregado ele é substituído por outro servidor com poder computacional maior e,
conseqüentemente, mais caro.
O RAC permite planejar um crescimento gradativo e com custo menor que o de
troca de servidores. A adição de novos servidores no cluster aumenta o poder
computacional ao mesmo tempo em que não exige uma paralisação do banco de dados.
3.1.4. Pontos Fracos na Solução da Oracle 10g
Embora o RAC proporcione escalabilidade, ele só pode ser aplicado sobre uma base
de dados Oracle, mais especificamente a partir da do Oracle 10g. Outro empecilho do RAC
está na estrutura necessária que precisa ser montada para que ele possa ser executado.
3.2. PostgreSQL
Ao contrário do Oracle 10g, o PostgreSQL não implementa nativamente o grid
computing, assim como não tem recursos para gerenciamento de cluster. Contudo tem
soluções, de terceiros, projetadas para atender essas necessidades.
O PostgreSQL também não possui implementações nativas para replicação e nem
balanceamento, porem existem soluções de terceiros criadas para replicar e balancear os
dados no PostgreSQL.
3.2.1. PGCluster
O PGCluster é um sistema de replicação síncrona composto por vários servidores,
tendo como principais características o balanceamento de carga e a alta disponibilidade.
O PGCluster é composto por três tipos de máquinas:
26
• Servidor de Balanceamento (Load Balancer): Recebe consultas e as
encaminha para os nós de armazenamento. As consultas são distribuídas de
acordo com a carga de cada nó. Podem existir mais de um balanceador de
carga.
• Servidor de Armazenamento (Cluster DB): Máquina que recebe e armazena
as consultas em bancos de dados.
• Servidor de Replicação (Replicator): Cuida de manter os dados
sincronizados entre os servidores. Mais de um servidor pode ser utilizado,
neste caso, outro servidor só assume se o servidor de replicação principal
falhar.
No balanceamento de carga (figura 3.2) são combinados servidores de
armazenamento e servidores de replicação, criando um sistema em cluster. O PGCluster
distribui a carga de acesso, redirecionando consultas para máquinas com menor carga.
Figura 3.2 – Sistema de balanceamento de carga – Fonte: [GOVEROELETROICO, 2008]
No caso da alta disponibilidade (figura 3.3) é utilizando um servidor responsável
por distribuir a carga de acesso no cluster. Caso um servidor de armazenamento falhe o
mesmo é separado pelo servidor de replicação. Quando a falha do servidor for contornada,
ou for incluído um novo servidor, os dados são copiados para o mesmo automaticamente.
27
Figura 3.3 – Sistema de alta disponibilidade – Fonte: [GOVEROELETROICO, 2008]
3.2.2. PGPool
O PGPool é uma solução que fica numa camada entre o cliente e servidor de dados
com a finalidade de prover alta disponibilidade, replicação e balanceamento de carga.
“Como sistema de replicação de dados, PGPool permite backup em
tempo real de bancos de dados, enviando as mesmas declarações SQL
para ambos os servidores, podendo ser considerado um sistema de
replicação síncrona... Se algum problema torna um dos servidores
PostgreSQL indisponível, o PGPool tenta continuar o serviço com o
servidor ainda ativo.” [GOVERCOELETROCICO, 2008].
As consultas são distribuídas de maneira aleatória entre os nós para obter um ganho
de desempenho, balanceando a carga entre esses nós. Utilizando o PGPool como
middleware os aplicativos que utilizam o PostgreSQL não precisam ser modificados. Já o
número de conexões com o PostgreSQL pode ser configuráveis.
O PGPool-II é uma evolução do PGPool, que suporta até 128 nós, com poder de
processamento paralelo nos nós.
3.2.3. Slony-I
O Slony-I é um sistema de replicação que segue o modelo Master to Multiple Slaves
apoiado no cascateamento de slaves e failover. Com essa estrutura é possível garantir que
um Slave assuma a posição de Master caso um Master venha a falhar.
O Slony-I também se responsabiliza em usar rotas alternativas sempre que um Slave
responsável pela transmissão dos dados falhe. O tipo de replicação de banco de dados
adotado pelo Slony-I foi a replicação assíncrona em cascata (figura 3.4).
28
Figura 3.4 – Replicação em Cascata – Fonte: [SLOY, Introducing, 2008]
Segundo [SLONY, 2008], Slony-I é um sistema replicador Master-Slave que inclui
todos os recursos e capacidades necessárias para replicar grandes bancos de dados para um
número razoavelmente limitado de sistemas Slaves. O Slony-I foi projetado para ser usado
em data centers e sites de backup.
No caso de falha de um Slave que fornece dados para outros Slaves, os Slaves
podem continuar a replicação através de outro Slave ou diretamente para o Master. No caso
do Master falhar (figura 3.5), um Slave pode receber uma promoção para se tornar um
Master, os outros Slaves passam a replicar o novo Master. O modelo assíncrono, adotado
pelo Slony-I, mantém réplicas em estados diferentes – mais ou menos atualizadas – por este
motivo, quando um Slave se torna um Master, ele próprio sincroniza com o estado mais
recente entre os Slaves ativos.
Figura 3.5 – Replicação continua após uma falha – Fonte: [SLOY, Introducing, 2008]
29
3.2.4. ParGRES
O ParGRES é um middleware projetado com o objetivo de ser capaz de processar
consultas pesadas com grandes quantidades de dados. Porém para que ele possa ser
utilizado o PostgreSQL deve estar sobre um cluster de PCs. O processamento da consulta
usa o paralelismo intra-consultas3.1 e inter-consultas3.2.
O ParGRES consiste em uma camada intermediária de software que gerencia
instâncias de SGBDs executados em diferentes nós de um cluster, implementando técnicas
de processamento paralelo. Segundo [MATTOSO, 2009] “seus componentes se encontram
distribuídos entre os nós do cluster”. Dessa maneira o ParGRES possui uma arquitetura
descentralizada como mostrado na figura 3.6.
Figura 3.6 – Arquitetura do ParGRES – Fonte: [MATTOSO, 2009]
“ParGRES está sendo desenvolvido em Java, e os testes estão sendo
executados em um cluster de PCs seguindo arquitetura de memória
distribuída. Pela sua arquitetura, o ParGRES não necessita em absoluto
de hardware específico de clusters... Ca implementação atual do
ParGRES está sendo utilizado o SGBD PostgreSQL versão 8.0 em cada
3.1
“Significa decompor consultas complexas em sub-consultas que serão executadas em paralelo, cada subconsulta em um fragmento de dados diferente. Dessa forma, cada sub-consulta poderá então ser enviada para
o nó que possui o respectivo fragmento dos dados. Assim, cada sub-consulta é enviada para um nó diferente e
executada em paralelo com as demais” [MATTOSO, 2009].
3.2
“Consultas distintas são executadas de forma concorrente no cluster de banco de dados, uma em cada nó do
cluster” [MATTOSO, 2009].
30
nó do cluster. A comunicação entre o ParGRES e cada nó do cluster é
realizada através de JDBC.” [MATTOSO, 2009].
3.2.4.1. Arquitetura
Na arquitetura do ParGRES existem componentes globais e locais. As tarefas que
envolvem vários nós do cluster são executadas pelos componentes globais, enquanto as
tarefas que são realizadas em apenas um nó são executadas pelos componentes locais.
Os componentes locais são os NQP (Code Query Processor – Processador de
Consultas de Nó) e o PostgreSQL, enquanto os componentes globais são o Intermediador e
o CQP (Cluster Query Processor – Processador de Consultas de Cluster).
O Intermediador repassa as requisições das aplicações para o CQP, e do CQP para
as aplicações. Dessa maneira o Intermediador provê maior flexibilidade na alocação física
do CQP, aumentando o grau de tolerância a falhas do ParGRES.
3.2.4.2. Cluster Query Processor
O CQP é o componente mais importante do ParGRES, ele age como gerenciador
dos outros componentes, sendo responsável por controlar a execução de requisições do
ParGRES.
As informações presentes no Catálogo do ParGRES são utilizadas pelo CQP para
analisar as consultas e definir que tipo de paralelismo deverá ser usado. O Catálogo
armazena informações necessárias para a fragmentação virtual adaptativa, não precisando
de informações específicas do SGBD.
3.2.5. Pontos Fracos nas Soluções do PostgreSQL
As soluções do PostgreSQL têm como foco a replicação dos dados. Nenhuma das
soluções trata a escalabilidade como foco primordial. Em alguns a escalabilidade é tratada
como um problema secundário. Em outros nem isso é apresentado. Além disso, todas são
soluções direcionadas ao PostgreSQL.
3.3. Modelo para o Compartilhamento de Bases de Dados Distribuídas
e Heterogêneas
No seu trabalho apresentado por [JUNIOR, 2005] é proposto um modelo para
viabilizar o “Compartilhamento de Bases de Dados Distribuídas e Heterogêneas”
31
A figura 3.7 mostra a arquitetura do middleware proposto. Ele é formado por
artefatos denominados Agentes, que desempenham a função de relacionar-se com o
aplicativo e de relacionar-se com os outros Agentes.
O Agente utiliza socket para comunicar-se com outros Agentes. O reconhecimento
de outros Agentes e seus serviços é feito através do Diretório de Agentes.
Os Agentes Servidores se registram no Catálogo de Serviços, esse catálogo informa
aos Agentes Clientes os Agentes Servidores disponíveis e seus endereços, esse catálogo não
é persistido.
Após a identificação dos Agentes Servidores, o Agente Cliente passa a interagir
diretamente com os mesmos, não precisando mais do auxilio do Mediador.
O Agente de Gerenciamento tem a função de (i) permitir a manutenção do Diretório
de Agentes e (ii) proporcionar a situação de atividade dos Agentes em seus Catálogos de
Serviços ativos e Log de Transação gerado pelos Agentes.
Figura 3.7 – Arquitetura do modelo de mediador proposto por Tercilio Junior – Fonte: [JUIOR, 2005]
3.3.1. Atores
Os atores são definidos por [JUNIOR, 2005] da seguinte maneira:
• Agente Cliente – Aplicativo: Sistema ou software que faz o tratamento de
informações das bases de dados através do Agente Cliente.
32
• Agente Servidor – Base de Dados: Qualquer fonte de informação disponível
em ambiente computacional ou em interfaces. Os Agentes Servidores podem
ser criados para tratar informações de sistemas de arquivos, banco de dados,
informações de estado de sistemas operacionais, sensores, etc.
• Administrador do Sistema: Usa o Agente de Gerenciamento para inserir
novos agentes no Diretório de Agente e fazer o acompanhamento do
funcionamento dos serviços através do Log de Transação e da atividade dos
agentes através do Catálogo de Serviços.
3.3.2. Classes
A descrição das classes do middleware, assim como suas características e
funcionalidade é apresentado resumidamente na seqüência:
• Diretório de Agentes: Classe de entidade persistente responsável por
catalogar todos os Agentes e seus serviços, podendo ser replicado para vários
pontos da sub-rede.
• Catálogo de Serviços: Classe de entidade não persistente responsável por
catalogar os serviços ativos, sendo utilizado pelos Agentes Servidor para
poder registrar os serviços e pelos Agentes Cliente para identificar os
Agentes Servidor em atividade.
• Log de Transações: Classe de entidade persistente responsável por registrar
as atividades dos agentes, permitindo o acesso do Agente de Gerenciamento
para fornecer dados ao Administrador do Sistema.
• Agente de Gerenciamento: Classe de fronteira que consente a manutenção
do Diretório de Agentes, apresentando o estado dos serviços do Catálogo de
Agentes e Log de Transações.
• Agente Cliente: Componente do serviço de solicitação, sendo parte
integrante do aplicativo e suprindo este aplicativo com dados por meio do
mediador.
• Agente Servidor: Componente do serviço responsável por responder as
solicitações do Agente Cliente, interagindo com uma base de dados para
disponibilizar os serviços da mesma.
33
3.3.3. Pontos Fracos do Middleware
A implementação do middleware proposto em [JUNIOR, 2005] se caracterizou por
Independência de Ambiente Operacional (Portabilidade), Independência física de dados,
Transparência de Localização, Redundância dos Serviços e Gerenciamento do Ambiente.
Mas na proposta, [JUNIOR, 2005] não apresenta uma estrutura para distribuição e
balanceamento de dados, de forma transparente ao sistema cliente.
3.4. Sequoia
O Sequoia é um middleware de código aberto desenvolvido para deixar
transparente, a aplicativos JAVA, o acesso a um cluster de banco de dados pelo meio do
JDBC (Java Database Connectivity). Com esse middleware os aplicativos clientes,
aplicativos servidores e servidores de banco de dados não sofrem alterações, bastando o
Sequoia ter acesso aos bancos de dados.
O uso do Sequoia necessita de uma aplicação cliente que utilize o JDBC, uma JVM (Java
Virtual Machine – Máquina Virtual Java) compilada para JDK (Java Development Kit – Kit
de Desenvolvimento Java) 1.4 ou superior, um banco de dados com driver JDBC ou ODBC
(Open Data Base Connectivity – Conectividade com Base de Dados Aberta), comunicação
entre o nós do cluster via TCP/IP.
3.4.1. Arquitetura
A arquitetura flexível provida pelo Sequoia permite escalabilidade, alta
disponibilidade e tolerância a falhas por meio do conceito de RAIDb (Redundant Array of
Inexpensive Databases – Conjunto Redundante de Base de Dados Econômicos), onde o
banco de dados é distribuído e replicado entre diversos nós, ficando o Sequoia responsável
por distribuir a carga das consultas entre eles.
3.4.2. RAIDb
O RAIDb é o equivalente do RAID (Redundant Array of Inexpensive Drives –
Conjunto Redundante de Discos Econômicos) só que no contexto de banco de dados. No
RAID vários discos rígidos são combinados em um array, obtendo melhor desempenho,
capacidade e confiabilidade. Já o RAIDb propõe obter melhor desempenho e tolerância a
falhas combinando várias instâncias de banco de dados em um array de banco de dados.
34
3.4.2.1. RAIDb-0
Nesse nível do RAIDb (figura 3.8) os dados são particionados, distribuindo suas
tabelas entre as máquinas que hospedam o banco de dados. Tabelas diferentes podem estar
em nós distintos, mas uma mesma tabela não pode estar em mais de um nó. O RAIDb-0
particiona o banco de dados, mas a tolerância a falha não é oferecida.
Figura 3.8 – Exemplo de RAIDb-0 – Fonte: [GOVEROELETROICO, 2008]
3.4.2.2. RAIDb-1
Nesse nível de RAIDb (figura 3.9) é disponibilizado o espelhamento integral,
replicando totalmente os dados entre as máquinas que hospedam o banco de dados,
permitindo total tolerância a falhas. A escrita no banco de dados – update, insert, delete –
se torna mais onerosa, pois as requisições devem ser enviadas para todos os nós.
Figura 3.9 – Exemplo de RAIDb-1 – Fonte: [GOVEROELETROICO, 2008]
35
3.4.2.3. RAIDb-2
A combinação de RAIDb-0 com RAIDb-1 cria o RAIDb-2 (figura 3.10). Nesse
nível o RAIDb provê replicação parcial, melhorando o desempenho em comparação ao
RAIDb-1. Cada tabela tem que estar em pelo menos dois nós, mas é necessário no mínimo
quatro nós para este nível de RAIDb.
Figura 3.10 – Exemplo de RAIDb-2 – Fonte: [GOVEROELETROICO, 2008]
3.4.2.4. Aninhamento de RAIDb
A utilização de vários níveis de RAIDb simultaneamente é possível. Com apenas
um controlador RAIDb é possível escala um número limitado de bancos de dados, mas
pode-se usar vários controladores em cascata para disponibilizar, teoricamente, um número
ilimitado de banco de dados.
No RAIDb-1-0 (figura 3.11) um controlador RAIDb-1 fica no nível mais alto,
enquanto no RAIDb-0-1 (figura 3.12) o nível mais alto fica um controlador RAIDb-0.
3.4.3. Pontos Fracos do Sequoia
O Sequoia proporciona escalabilidade, alta disponibilidade e tolerância a falhas,
mas só é possível ser usado por aplicativos JAVA.
Embora seja um consenso, entre os profissionais da área de programação, que o
JAVA estar entre as linguagens mais populares, uma quantidade grande de aplicativos não
pode usufruir do Sequoia, pois foram desenvolvidos em outras linguagens.
36
3.5. Conclusão
Embora o Oracle e o PostgreSQL apresentem soluções para resolver o problema de
escalabilidade, todas elas são para banco de dados homogêneos. O middleware proposto
nesta dissertação foi construído para resolver o problema de escalabilidade em banco de
dados heterogêneos.
Figura 3.11 – Exemplo de RAIDb-1-0 – Fonte: [GOVEROELETROICO, 2008]
Figura 3.12 – Exemplo de RAIDb-0-1 – Fonte: [GOVEROELETROICO, 2008]
A proposta apresentada em [JUNIOR, 2005] não aborda a distribuição e
balanceamento dos dados de maneira transparente ao sistema cliente. O seu trabalho ficou
limitado a uma solução para o compartilhamento de bases de dados distribuídas e
37
heterogêneas. O middleware apresentado nesta dissertação vai mais além da proposta de
[JUNIOR, 2005]. Além do compartilhamento de dados distribuídos em bases heterogêneas,
também apresenta uma solução para a distribuição e balanceamento de dados heterogêneos.
Na solução do Sequoia foi levado em consideração apenas aplicativos
desenvolvidos em JAVA. No middleware proposto nesta dissertação, a heterogeneidade da
linguagem de programação é tão importante quanto a heterogeneidade dos dados
armazenados.
38
Capítulo 4
O Middleware LUCAS-GABRIEL
Este capítulo apresenta o middleware proposto nesta dissertação, o qual foi
denominado LUCAS-GABRIEL. Ele tem a finalidade de aumentar a escalabilidade
associada a independência dos SGBDRs com arquitetura cliente-servidor de duas camadas.
O LUCAS-GABRIEL distribui os dados entre os SGBDRs, gerenciando o
balanceamento entre os mesmos. Depois, quando recebe solicitações de atualização de
dados, o LUCAS-GABRIEL redireciona a solicitação de maneira correta aos SGBDRs.
Também é de responsabilidade do LUCAS-GABRIEL receber as solicitações de consulta,
redirecionar aos SGBDRs, consolidar os resultados dos SGBDRs e enviar a consolidação
para sistema que solicitou a consulta.
4.1. Introdução
A arquitetura do LUCAS-GABRIEL é mostrada na figura 4.1, nesta arquitetura os
dados são distribui horizontal (Leia 2.2.3.4.3. Fragmentação de Dados) entre SGBDRs. O
LUCAS-GABRIEL não irá interferir diretamente no funcionamento dos SGBDRs.
O software cliente se comunica com o módulo LUCAS (Lançador Uniforme de
Consultas Acessado por Software), que é uma classe encapsulada dentro de uma DLL, com
isso, a máquina onde está o software fica livre de qualquer tipo de instalação cliente de
SGBD.
Numa camada intermediária fica o módulo GABRIEL (Gerenciador de Acesso a
Banco Receptor de Invocações Enviadas do LUCAS). Esta camada é responsável por
distribuir horizontalmente os dados entre os SGBDs registrados.
O GABRIEL recebe as solicitações de modificação de estados dos dados emitidas
pelo software cliente via LUCAS. Na seqüência, o GABRIEL processa e distribui as
solicitações entre os servidores balanceando a carga entre os mesmos.
O GABRIEL também se responsabiliza pelo gerenciamento das solicitações de
dados, repassando as mesmas para os servidores, em seguida, faz a consolidação das
respostas e as envia para o software cliente via LUCAS.
39
Cliente
Cliente
Cliente
Cliente
Cliente
LUCAS
LUCAS
LUCAS
LUCAS
LUCAS
GABRIEL
Memória
Memória
Memória
Servidor
Servidor
Servidor
Firebird
PostgreSQL
MySQL
Figura 4.1 – Middleware proposto
Esta arquitetura deixa o gerenciamento dos dados mais complexo, porém, em
contra-partida ganha nas consulta de dados, uma vez que os mesmos são processados em
locais distintos. Outra vantagem da arquitetura é a heterogeneidade dos SGBDRs e a
possibilidade de inclusão de novos servidores para aumentar a escalabilidade.
4.2. Diagrama de caso de uso
O middleware é dividido em duas partes, o LUCAS e o GABRIEL (figura 4.2). O
LUCAS fica do lado cliente, isto quer dizer que cada cliente deve ter o LUCAS instalado
localmente. Entre o LUCAS e os SGBDs tem-se o GABRIEL, que é o núcleo do
middleware. O middleware não terá nada instalado do lado do SGBDR, para o SGBDR o
GABRIEL é um cliente.
A figura 4.3 ilustra o diagrama da figura 4.2 mais detalhadamente. Na figura 4.3 são
apresentados os casos de uso básicos, nesta figura é possível ver que todo serviço existente
no LUCAS precisa, para sua conclusão, de um outro serviço que está no GABRIEL.
40
Figura 4.2 – Diagrama de caso de uso sintético
Figura 4.3 – Diagrama de caso de uso básico
Os diagramas de caso de uso não são aprofundados, pois a usabilidade do
middleware será detalhada no transcorrer deste capítulo.
A troca de mensagens entre LUCAS e GABRIEL é realizada via socket. Nas
consultas de dados, o GABRIEL consolida os dados num arquivo XML e envia ao LUCAS
via socket. A escolha do socket foi devido a simplicidade das mensagens e dos dados
trocados. Já o XML foi escolhido devido já ser um padrão amplamente usado e conhecido.
Um exemplo de um arquivo XML gerado pelo GABRIEL e enviado ao LUCAS pode ser
visto na figura 4.4.
41
<?xml version="1.0" encoding="ISO-8859-1"?>
<dados>
<registro>
<NOME>SAULA SAMPAIO BRINGEL IZIDORO</NOME>
<ENDER>RUA PADRE CICERO</ENDER>
<BAIRRO>MATRIZ</BAIRRO>
<CEP>63.000.000</CEP>
<CIDADE>JUAZEIRO DO NORTE</CIDADE>
<UF>CE</UF>
</registro>
<registro>
<NOME>TADEU PEREIRA LIMA FRANCA</NOME>
<ENDER>RUA PADRE CICERO</ENDER>
<BAIRRO>MATRIZ</BAIRRO>
<CEP>63.000.000</CEP>
<CIDADE>JUAZEIRO DO NORTE</CIDADE>
<UF>CE</UF>
</registro>
</dados>
Figura 4.4 – Exemplo de arquivo XML gerado pelo middleware
O esquema do arquivo XML gerado está diretamente relacionado com o metadado
da origem dos dados, mas três tags são comuns a todos os arquivos XML gerados:
• <?xml version="1.0" encoding="ISO-8859-1"?>
Esta tag especial define a versão do documento XML através do
atributo version, enquanto o atributo encoding define a tabela
caracteres que será usada no arquivo. Esta tag deve aparecer apenas
uma vez no arquivo XML
• <dados>
Local onde os registros ficam armazenados. Esta tag deve aparecer
apenas uma vez no arquivo XML.
• <registro>
Define uma tupla e os valores armazenados em seus atributos. Esta
tag pode aparecer uma vez, várias vezes ou nenhuma vez no arquivo
XML, o que define a quantidade de vezes é o resultado gerado pela
consulta.
Ainda analisando o exemplo apresentado na figura 4.4 tem-se as tags <COME>,
<ECDER>, <BAIRRO>, <CEP>, <CIDADE> e <UF> dentro da tag <registro>. Os
42
nomes destas tags são iguais aos nomes dos atributos da tupla retornada pela consulta, e no
seu conteúdo estão os valores dos atributos da tupla.
4.3. Diagrama de classe
Nesta seção é apresentado o diagrama de classes do middleware, além do
detalhamento dos seus atributos e métodos.
4.3.1. LUCAS
A figura 4.5(a) apresenta o LUCAS detalhado em um diagrama de classe, nesta
figura é possível ver todos os atributos e métodos da classe.
Figura 4.5(a) – Diagrama de classe do LUCAS
Detalhamento da classe LUCAS
Na figura 4.5(b) pode-se ver o relacionamento do LUCAS com a classe
ClientSocket, o tipo enumerado Tipo_Solicitacao e as exceções que podem ser geradas. Na
mesma figura também pode-se ver detalhada a classe ClientSocket e o relacionamento da
mesma com o tipo enumerado Tipo_Status.
43
Figura 4.5(b) – Diagrama de classe do LUCAS
Detalhamento da (i) classe ClientSocket, do (ii) tipo enumerado Tipo_Solicitacao e
das (iii) exceções e como os mesmos se relacionam com a classe LUCAS
A classe ClientSocket é responsável por abrir a conexão, via socket, com a classe
ServerSocket e envia solicitações à mesma.
O detalhamento dos atributos e métodos do LUCAS pode ser visto nas tabelas do
Apêndice A. Os atributos e métodos da classe ClientSocket, da qual o atributo
SoqueteCliente do LUCAS descende, estão nas tabelas do Apêndice B.
Existem sete exceções criadas pelo LUCAS. A exceção ExceptionAguardando
acontece quando o Status do atributo SoqueteCliente está diferente de zero (Aguardando), a
exceção ExceptionBaixando acontece quando existe uma falha na transferência do arquivo
de
retorno
da
consulta.
As
exceções
ExceptionIncluindo,
ExceptionAlterando,
ExceptionExcluindo e ExceptionConsultando são executadas quando um dos SGBDRs
retornarem um erro, neste caso a mensagem é repassada do SGBDR para o sistema cliente.
A última exceção é a ExceptionMensagem que acontece sempre que um erro não esperado
ocorrer no GABRIEL.
44
4.3.2. GABRIEL
Na figura 4.6(a) o diagrama de classe do GABRIEL é apresentado. Na figura 4.6(b)
pode-se ver o relacionamento do GABRIEL com as classes ServerSocket e SQLConnect.
Figura 4.6(a) – Diagrama de classe do GABRIEL
Detalhamento da classe GABRIEL
Figura 4.6(b) – Diagrama de classe do GABRIEL
Detalhamento das classes (i) ServerSocket e (ii) SQLConnect e
como as mesmas se relacionam com a classe GABRIEL
45
A classe ServerSocket é responsável por gerenciar as conexões e solicitações
enviadas pela classe ClientSocket, enquanto a classe SQLConnect gerencia a conexão e as
transações feitas ao SGBDR.
Pode-se ver nas tabelas do Apêndice C o detalhamento dos atributos e métodos do
GABRIEL. Nas tabelas do Apêndice D tem-se o equivalente para a classe ServerSocket,
enquanto as tabelas do Apêndice E se referem a classe SQLConnect.
4.4. Diagrama de seqüência
Os diagramas de seqüências da inclusão, alteração, exclusão e consultas são
apresentados nesta seção.
4.4.1. Incluir
4.4.1.1. Incluir registro independente
As figuras 4.7(a) à 4.7(f) mostram o diagrama de seqüência para incluir um registro
numa tabela sem chave estrangeira. O digrama foi desmembrado em sete partes para
permitir a visualizar.
No caso de uma inclusão independente o Sistema Cliente deve invocar os métodos
Clear e SetTabela da classe LUCAS, em seguida, para cada campo e valor que se deseja
incluir no novo registro o método SetDados deve ser invocado.
Para entender melhor, imagine que se deseja incluir um registro na tabela Cliente
com os dados da tabela 4.1.
Tabela 4.1 – Incluir registro independente
Tabela: Cliente
Campo
Valor
Nome
José da Silva
Endereco Rua Todos os Santos
Cidade
Juazeiro do Norte
UF
CE
O Sistema Cliente deve executar o código semelhante ao mostrado:
46
LUCAS.Clear;
LUCAS.SetTabela(‘Cliente’);
LUCAS.SetDados(‘Nome’, ‘José da Silva’);
LUCAS.SetDados(‘Endereco’, ‘Rua Todos os Santos’);
LUCAS.SetDados(‘Cidade’, ‘Juazeiro do Norte’);
LUCAS.SetDados(‘UF’, ‘CE’);
LUCAS.SetIncluir(True);
O comando SQL gerado pelo método SetRequisitar (Leia Apêndice F) do LUCAS e
enviado ao GABRIEL fica como mostrado:
insert into Cliente (Nome, Endereco, Cidade, UF)
values (‘José da Silva’, ‘Rua Todos os Santos’,
‘Juazeiro do Norte’, ‘CE’);
Quando recebe a solicitação, o GABRIEL, por meio do seu atributo ServidorTabela,
seleciona o servidor que tem menos registro na tabela informada. Por fim, redireciona o
comando para o servidor escolhido. Logo, o balanceamento entre os SGBDs são garantidos
pelo GABRIEL através do atributo ServidorTabela.
Figura 4.7(a) – Diagrama de Seqüência – Incluir registro independente
Mensagens trocadas entre o Sistema Cliente e a classe LUCAS
47
Figura 4.7(b) – Diagrama de Seqüência – Incluir registro independente
Mensagens trocadas entre as classes LUCAS e ClientSocket
Figura 4.7(c) – Diagrama de Seqüência – Incluir registro independente
Mensagens trocadas entre as classes ClientSocket e ServerSocket
48
Figura 4.7(d) – Diagrama de Seqüência – Incluir registro independente
Mensagens trocadas entre as classes ServerSocket e GABRIEL
Figura 4.7(e) – Diagrama de Seqüência – Incluir registro independente
Mensagens trocadas entre as classes GABRIEL e SQLConnect
Figura 4.7(f) – Diagrama de Seqüência – Incluir registro independente
Mensagens trocadas entre a classe SQLConnect e os SGBDs
49
4.4.1.2. Incluir registro dependente
A inclusão de um registro que possua chave estrangeira, e onde esta chave
estrangeira deve ser igual a chave primária de uma inclusão anterior, mas ainda
desconhecida, deve seguir o diagrama de seqüência mostrado nas figuras 4.8(a) e 4.8(b), a
partir do ClientSocket o diagrama de seqüência é semelhante ao mostrado nas figuras 4.7(c)
à 4.7(f).
Figura 4.8(a) – Diagrama de Seqüência – Incluir registro dependente
Mensagens trocadas entre o Sistema Cliente e a classe LUCAS
50
Figura 4.8(b) – Diagrama de Seqüência – Incluir registro dependente
Mensagens trocadas entre as classes LUCAS e ClientSocket
Uma venda via pedido é um cenário onde se inclui registros dependentes. A chave
primária do pedido é chave estrangeira para seus itens, mas a chave primária só será
conhecida no momento da inclusão.
51
O desconhecimento da chave primária do pedido pode causar inconsistência nos
dados, uma vez que se forem incluídos dois ou mais pedidos num mesmo instante, não tem
como saber qual a chave primária que os itens lançados nesses pedidos distintos devem
obter, uma vez que um pedido pode ser persistido (i) antes de todos, (ii) após todos ou (iii)
entre lançamentos.
Para simplificar, é mostrado como incluir dados em casos semelhantes, conforme
tabela 4.2.
Tabela 4.2 – Incluir registro dependente
Tabela: Pedido
Campo
Valor
DtPedido
01/01/2009
ID_Vend
10
ID_Cliente
153
Tabela: Pedido_Item
Campo
Valor
ID_Pedido
???????
ID_Produto 1234567890
Quant
2
Tabela: Pedido_Item
Campo
Valor
ID_Pedido
???????
ID_Produto 0987654321
Quant
5
O código que deve ser executado pelo Sistema Cliente fica semelhante ao mostrado:
LUCAS.Clear;
LUCAS.SetTabela(‘Pedido’);
LUCAS.SetDados(‘DtPedido’, ‘01/01/2009’);
LUCAS.SetDados(‘ID_Vend’, ‘10’);
LUCAS.SetDados(‘ID_Cliente’, ‘153’);
52
LUCAS.SetIncluir(False);
LUCAS.SetTabela(‘Pedido_Item');
LUCAS.SetChaveEstrangeira(‘Pedido’, 'ID_Pedido');
LUCAS.SetDados(‘ID_Produto’, ‘1234567890’);
LUCAS.SetDados(‘Quant’, ‘2’);
LUCAS.SetIncluir(False);
LUCAS.SetDados(‘ID_Produto’, ‘0987654321’);
LUCAS.SetDados(‘Quant’, ‘5’);
LUCAS.SetIncluir(False);
LUCAS.SetRequisitar;
Note que só foi preciso configurar o nome da tabela e a chave estrangeira
(SetTabela e SetChaveEstrangeira) no primeiro item. Uma vez que o parâmetro do método
SetIncluir do LUCAS recebeu o valor falso, o mesmo se encarrega de configurar estes
valores (SetTabela e SetChaveEstrangeira) automaticamente, ficando por conta do Sistema
Cliente informar apenas os campos e seus valores através do método SetDados.
O comando gerado pelo método SetRequisitar (Leia Apêndice F) do LUCAS e
enviado ao GABRIEL fica igual ao mostrado a seguir:
insert into Pedido (DtPedido, ID_Vend, ID_Cliente)
values (‘01/01/2009’, ‘10’, ‘153’);
insert into Pedido_Item (ID_Produto, Quant)
values (‘1234567890’, ‘2’), ‘Pedido’, ‘ID_Pedido’;
insert into Pedido_Item (ID_Produto, Quant)
values (‘0987654321’, ‘5’), ‘Pedido’, ‘ID_Pedido’;
Ao receber esta solicitação de inclusão, o GABRIEL executa o processo a seguir:
Pedido.Gerador_ID := Pedido.Gerador_ID + 1;
insert into Pedido (ID, DtPedido, ID_Vend, ID_Cliente)
values (Pedido.Gerador_ID, ‘01/01/2009’, ‘10’, ‘153’);
insert into Pedido_Item (ID_Pedido, ID_Produto, Quant)
53
values (Pedido.Gerador_ID, ‘1234567890’, ‘2’);
insert into Pedido_Item (ID_Pedido, ID_Produto, Quant)
values (Pedido.Gerador_ID, ‘0987654321’, ‘5’);
A figura 4.9 mostra o fluxograma para inclusão de dados.
Inicio
Clear
SetTabela
[SetChaveEstrangeira]
Fim
Não
Nova
Tabela
Sim
SetRequisitar
SetDados
Não
Sim
Novos
Dados
Requisitar
Sim
Não
SetIncluir
Figura 4.9 – Fluxograma para inclusão de dados
4.4.2. Alterar
A alteração de dados se assemelha com a inclusão de dados. A diferença básica está
no tocante ao método SetChaveEstrangeira, que neste caso é desprezado pelo método
SetRequisitar, uma vez que, em uma alteração, a chave estrangeira já é conhecida.
O algoritmo usado pelo GABRIEL replica a solicitação enviada pelo LUCAS em
todos os servidores. A desvantagem dessa escolha é a perda de desempenho da rede, pois a
mesma solicitação é enviada ao vários servidores. A vantagem é o ganho de desempenho
dos servidores, devido cada servidor ter que processar uma quantidade menor de dados.
O diagrama de seqüência da alteração de dados é mostrado na figura 4.10, a
continuação desse diagrama é semelhante ao mostrado nas figuras 4.7(b) à 4.7(f).
54
Figura 4.10 – Diagrama de Seqüência – Alterar registro
Mensagens trocadas entre o Sistema Cliente e a classe LUCAS
Tendo como base os dados da tabela 4.3, é mostrado a seguir como o Sistema
Cliente deve efetuar a alteração neste registro.
Tabela 4.3 – Alterar registro
Tabela: Cliente
Campo
Valor Atual
ID
150
Nome
José da Silva
Endereco Rua Todos os Santos
Cidade
Juazeiro do Norte
UF
CE
ovo Valor
Rua Padre Cícero
O código que deverá ser executado:
LUCAS.Clear;
LUCAS.SetTabela(‘Cliente’);
LUCAS.SetDados(‘Endereco’, ‘Rua Padre Cicero’);
LUCAS.SetAlterar(‘ID = 150’, True);
O comando SQL gerado (Leia Apêndice F):
update Cliente
55
set Endereço = ‘Rua Padre Cicero’
where ID = 150;
O fluxograma para alteração de dados é mostrado na figura 4.11.
Inicio
Clear
SetTabela
Fim
Não
Nova
Tabela
Sim
SetRequisitar
SetDados
Não
Sim
Novos
Dados
Requisitar
Sim
Não
SetAlterar
Figura 4.11 – Fluxograma para alteração de dados
4.4.3. Excluir
O processo de excluir dados é o mais simples, pois neste caso são usados apenas os
métodos Clear, SetTabela e SetExcluir, os métodos SetDados e SetChaveEstrangeira são
desprezados. A figura 4.12 mostra o diagrama de seqüência da exclusão de dados até o
LUCAS, a partir do LUCAS o diagrama é semelhante ao mostrado nas figuras 4.7(b) à
4.7(f).
Figura 4.12(a) – Diagrama de Seqüência – Excluir registro
Mensagens trocadas entre o Sistema Cliente e a classe LUCAS
56
O código executado pelo Sistema Cliente deve ficar semelhante ao mostrado a
seguir:
LUCAS.Clear;
LUCAS.SetTabela(‘Cliente’);
LUCAS.SetExcluir(‘ID = 150’, True);
O comando SQL gerado (Leia Apêndice F):
delete from Cliente
where ID = 150;
O algoritmo usado pelo GABRIEL para excluir dados é semelhante ao da alteração
de dados, uma vez que o GABRIEL replica a solicitação enviada pelo LUCAS em todos os
servidores. Na figura 4.13 tem-se o fluxograma para exclusão de dados.
Inicio
Clear
SetTabela
Fim
Não
Nova
Tabela
Não
Sim
SetRequisitar
Requisitar
SetExcluir
Figura 4.13 – Fluxograma para exclusão de dados
Sim
57
4.4.4. Consultar
Para consulta existem dois caminhos possíveis, (i) usando o método SetConsultar
ou (ii) usando o método SetConsultarSQL, mas nos dois casos, o GABRIEL replica a
consulta em todos os servidores.
No primeiro caso os métodos Clear, SetTabela e SetDados são usados em conjunto
com o método SetConsultar, sendo que o método SetDados tem o seu segundo parâmetro
(Valor) desconsiderado.
Para a segunda opção todos os outros métodos são desprezados (Clear, SetTabela,
SetChaveEstrangeira, SetDados) uma vez que neste caso o Sistema Cliente deve passar o
comando de consulta já formatado de acordo com os requisitos da SQL.
Para fazer uma consulta através do método SetConsultar, o LUCAS verifica se
existem solicitações pendentes. Caso existam, ele manda para o GABRIEL todas essas
solicitações para serem atendidas, só então a solicitação de consulta é enviada. Desta
maneira LUCAS fica livre para esperar o arquivo XML de retorno, gerado no GABRIEL,
com os dados consolidados da consulta feita nos SGBDs e unificados neste arquivo.
4.4.4.1. SetConsultar
A figura 4.14 mostra o diagrama de seqüência até o LUCAS, quando o Sistema
Cliente usa o método SetConsultar. A continuação do diagrama é idêntico aos das figuras
4.7(b) à 4.7(f).
Figura 4.14 – Diagrama de Seqüência – Consultar via SetConsultar
Mensagens trocadas entre o Sistema Cliente e a classe LUCAS
58
O Sistema Cliente deve ficar com o código semelhante ao mostrado:
LUCAS_Clear;
LUCAS_SetTabela(‘Cliente’);
LUCAS_SetDados(‘ID’, ‘’);
LUCAS_SetDados(‘Nome’, ‘’);
LUCAS_SetDados(‘Endereco’, ‘’);
LUCAS_SetDados(‘Cidade’, ‘’);
LUCAS_SetDados(‘UF’, ‘’);
LUCAS_SetConsultar(‘ID between 100 and 1000’);
Comando SQL gerado (Leia Apêndice F):
select ID, Nome, Endereco, Cidade, UF from Cliente
where ID between 100 and 1000;
Na figura 4.15 é mostrado o fluxograma para se efetuar este mesmo procedimento.
Inicio
Clear
SetTabela
Fim
SetRequisitar
SetConsultar
SetDados
Sim
Novos
Dados
Não
Figura 4.15 – Fluxograma para consultar dados via SetConsultar
4.4.4.2. SetConsultarSQL
O fluxograma deste método é mais simples que o anterior, pois ele permite uma
consulta otimizada. Contudo, se o implementador do Sistema Cliente não tiver experiência
com SQL este método se torna mais difícil de ser usado. O diagrama de seqüência com
59
este método está nas figuras 4.16(a) e 4.16(b). A continuação do diagrama assemelha-se aos
das figuras 4.7(c) à 4.7(f).
Figura 4.16(a) – Diagrama de Seqüência – Consultar via SetConsultarSQL
Mensagens trocadas entre o Sistema Cliente e a classe LUCAS
Figura 4.16(b) – Diagrama de Seqüência – Consultar via SetConsultarSQL
Mensagens trocadas entre as classes LUCAS e ClientSocket
Código do Sistema Cliente:
SetConsultarSQL(‘select ID, Nome, Endereco, Cidade, UF ’
‘from Cliente where ID between 100 and 1000’);
Comando SQL gerado:
select ID, Nome, Endereco, Cidade, UF from Cliente
where ID between 100 and 1000;
4.5. Fluxos alternativos e Funcionalidade
As solicitações de inclusão, alteração e exclusão podem ficar pendentes no LUCAS,
bastando para isso informar como falso o parâmetro Requisitar dos métodos SetIncluir,
SetAlterar e SetExcluir.
60
Para enviar as pendências ao GABRIEL o método SetRequisitar deve ser invocado
de maneira direta ou indireta. No primeiro caso o Sistema Cliente deve incorporar no seu
código a chamada ao método SetRequisitar. No outro caso basta informar o parâmetro
Requisitar da última solicitação como verdadeiro, pois uma vez que os métodos SetIncluir,
SetAlterar e SetExcluir invocam o método SetSolicitar e, ao passar o parâmetro Requisitar
como verdadeiro, o mesmo invoca o método SetRequisitar (veja figuras 4.7, 4.10 e 4.12),
todas a pendências do LUCAS são enviadas para o GABRIEL.
O método SetChaveEstrangeira só é utilizado pelo LUCAS em conjunto com o
método SetIncluir. Nos outros métodos (SetAlterar, SetExcluir e SetConsultar) ele é
desprezado.
O segundo parâmetro do método SetDados (Valor) não é utilizado quando o método
é usado em conjunto com o método SetConsultar.
O método SetRequisitar processa todas as solicitações pendentes e as repassa para o
método EnviarMensagem. Em seguida invoca o método Clear para apagar todas as
solicitações enviadas.
4.6. Conclusão
Neste capítulo foi apresentado o middleware LUCAS-GABRIEL. Este middleware
propõe uma arquitetura de armazenamento de dados distribuído para SGBDRs com
arquitetura cliente-servidor de duas camadas. Com essa distribuição, o LUCAS-GABRIEL
aumenta a escalabilidade dos SGBDRs com arquitetura cliente-servidor de duas camadas.
O LUCAS-GABRIEL efetua a distribuição horizontal dos dados entre instâncias
distintas de SGBDRs, mas sem interferir diretamente sobre o processamento dos SGBDRs.
Ele atua numa camada intermediária entre o sistema cliente e os SGBDRs. Com esta
camada intermediária o processo de comunicação entre o sistema cliente e SGBDR muda.
Este novo processo é mostrado na seqüência:
1. O sistema cliente manda a solicitação ao LUCAS (Lançador Uniforme de
Consultas Acessado por Software);
2. O LUCAS recebe as solicitações do sistema cliente, organiza estas
solicitações e as envias ao GABRIEL (Gerenciador de Acesso a Banco
Receptor de Invocações Enviadas do LUCAS);
61
3. O GABRIEL recebe as solicitações e processa as mesmas, agindo de
maneira distinta para cada tipo de solicitação:
a. Inclusão: É feita a distribuição de maneira a manter os SGBDRs
balanceados.
b. Alterações/Exclusões: A solicitação é replicada entre os SGBDRs
para que a solicitação seja executada.
c. Consultas: A solicitação é repassada para os SGBDRs, o retorno da
consulta é consolidado num arquivo XML.
4. O Gabriel envia uma resposta ao LUCAS;
5. O LUCAS repassa a resposta ao sistema cliente.
Desta maneira o sistema cliente não se comunica diretamente com o SGBDR,
apenas através do LUCAS-GABRIEL. Em contrapartida, o LUCAS-GABRIEL deixa
transparente ao sistema cliente a estrutura física dos dados persistidos. Também é possível
incluir novas instâncias de SGBDRs na estrutura computacional sem que o sistema cliente
perceba tal ação.
62
Capítulo 5
Validação
Para
testar
a
arquitetura
proposta
foi
efetuada
a
implementação
do
LUCAS-GABRIEL, além de programa auxiliares. As implementações foram feitas no
Delphi 5.0.
Embora a proposta do LUCAS-GABRIEL seja independência de SGBD, os testes
foram feitos apenas com o Firebird 2.0 instanciado em todos os servidores. Esta
homogeneidade de SGBD na validação permite apresentar resultados mais confiáveis de
desempenho.
Já o sistema operacional usado foi o Windows XP Professional Service Pack 3
rodando em hardwares com configurações idênticas. Assim como no SGBD, este ambiente
de hardware e software homogêneo proporcionou uma validação mais confiável.
Neste capítulo é descrito o ambiente de teste e casos para validação da arquitetura.
5.1. DLL “LUCAS”
A classe LUCAS foi criada seguindo todas as normas da arquitetura proposta. Nesta
primeira versão, a classe foi incorporada numa DLL (LUCAS.DLL) que passou a
disponibilizar os métodos do objeto LUCAS_DLL – instância da classe LUCAS – através
de chamada a DLL.
A escolha por criar a DLL, nesta versão, foi a opção que melhor se encaixou na
reutilização da classe por qualquer linguagem de programação que tenha suporte ao uso de
DLL. Embora muitas linguagens de programação tenham suporte ao uso de DLL, ficou
para estudos futuros a busca de uma solução que deixe o LUCAS ainda mais heterogêneo
quanto a linguagem de programação do sistema cliente.
A tabela G.1 do Apêndice G mostra os métodos disponibilizados e como efetuar sua
chamada via DLL.
5.2. Aplicativo “GABRIEL”
Foi criado um aplicativo responsável por instanciar a classe GABRIEL, o aplicativo
acessa os métodos da instância do GABRIEL. Os servidores configurados ficam visíveis
63
constantemente. As tabelas, seus campos chaves, seus geradores e valores dos mesmos são
atualizados constantemente. A figura 5.1 mostra o aplicativo GABRIEL em execução.
Figura 5.1 – Aplicativo GABRIEL
5.3. Aplicativo “Cliente”
O aplicativo Cliente simula um sistema cliente com a função de incluir, alterar,
excluir ou consultar registros nas tabelas, mas quando informada a tabela “PDV” para
inclusão, o aplicativo insere registros nas tabelas “PDV” e “PDV_Item”. As ações de
incluir, alterar, excluir ou consultar podem ser feitas diretamente no SGBD ou através do
GABRIEL.
Neste aplicativo é instanciado um objeto do tipo ServerSocket para servir de elo de
comunicação entre ele o aplicativo Configura Cliente (Leia 5.4. Aplicativo Configura
Cliente). Quando o objeto do tipo ServerSocket do aplicativo Cliente recebe uma
mensagem do aplicativo Configura Cliente é iniciado o processo de configuração da DLL
“LUCAS” e sincronizada a hora do computador local com a do computador onde está o
aplicativo Cliente.
64
Figura 5.2 – Aplicativo Cliente
A tabela G.2 do Apêndice G mostra os métodos criados para auxiliar a sobrecarga.
5.4. Aplicativo “Configura Cliente”
A tabela a ser usada, ação a ser efetuada, período inicial e quantidade de vezes que a
ação será executada são configurados através deste aplicativo (figura 5.3). O aplicativo
Configura Cliente também informa se as ações acontecerão (i) diretamente no SGBD, para
verificar o desempenho do SGBD sem uso do LUCAS-GABRIEL, ou (ii) através do
GABRIEL, para verificar o desempenho dos SGBDs gerenciados pelo GABRIEL. Este
aplicativo também tem uma instância de um objeto do tipo ClientSocket, através do qual
são enviadas as configurações para as instâncias do aplicativo Cliente que serão utilizadas
no caso de validação. Os itens da interface do aplicativo são explicados na seqüência. As
caixas de edições são usadas para configurar tanto dados individuais das instâncias do
aplicativo Cliente quanto dados comuns a todas as instâncias do aplicativo Cliente.
5.5. Cenário
As CPUs usados nos testes eram iguais devido serem de um mesmo lote de compra
(tabela G.3 do Apêndice G). Foram utilizados dezessete CPUs, das quais seis ampararam as
instâncias do Firebird 2.0 e o GABRIEL. As outras onze mantiveram o aplicativo Cliente
divididas da seguinte maneira:
‒ Quatro CPUs efetuavam mil ações sobre a tabela Cliente;
‒ Uma CPU efetuava mil ações sobre a tabela Funcion;
‒ Uma CPU efetuava mil ações sobre a tabela Produto;
‒ Cinco CPUs efetuavam mil ações sobre a tabela PDV.
65
As ações dependiam do processo que estava sendo executado durante o caso de
validação.
Figura 5.3 – Aplicativo Configura Cliente
5.6. Casos de Validação
A validação foi feita através de três processos distintos descritos na seqüência:
1. Incluir Dados: Todos os aplicativos que usavam o LUCAS efetuavam
inclusões de dados.
2. Alterar Dados: Todos os aplicativos que usavam o LUCAS efetuavam
alterações de dados.
3. Consultar Dados: Todos os aplicativos que usavam o LUCAS efetuavam
consultas de dados.
Cada processo passou por seis casos de validações com as seguintes características:
‒ Caso de Validação 1: Neste caso de validação os aplicativos de Cliente não
usaram o GABRIEL, a sobrecarga foi feita em um único SGBD.
‒ Caso de Validação 2: Neste caso de validação os aplicativos de Cliente
usaram o GABRIEL, mas o GABRIEL estava gerenciando o acesso a apenas
um único SGBD.
‒ Caso de Validação 3: Neste caso de validação os aplicativos de Cliente
usaram o GABRIEL gerenciando o acesso a dois SGBDs.
66
‒ Caso de Validação 4: Neste caso de validação os aplicativos de Cliente
usaram o GABRIEL gerenciando o acesso a três SGBDs.
‒ Caso de Validação 5: Neste caso de validação os aplicativos de Cliente
usaram o GABRIEL gerenciando o acesso a quatro SGBDs.
‒ Caso de Validação 6: Neste caso de validação os aplicativos de Cliente
usaram o GABRIEL gerenciando o acesso a cinco SGBDs.
O processo de “Incluir Dados” foi executado em todos os casos de validação
descritos, ou seja, do “Caso de Validação 1” até o “Caso de Validação 6”. Em seguida foi
executado o processo de “Alterar Dados” da mesma maneira, e assim sucessivamente.
Deste modo todos os processos de “Incluir Dados” foram executados em um momento
cronológico anterior aos processos subseqüentes.
No “Caso de Validação 1” o servidor S1 manteve o SGBD na arquitetura ClienteServidor tradicional, ou seja, com os dados centralizados em um único servidor de dados. O
GABRIEL não estava instanciado e os servidores S2, S3, S4, S5, S6 não entram no teste.
No “Caso de Validação 2” o servidor S1 manteve a instância do GABRIEL,
enquanto o servidor S2 mantinha uma instância do SGBD. Os servidores S3, S4, S5, S6 não
entram no teste.
No “Caso de Validação 3” o servidor S1 manteve a instância do GABRIEL,
enquanto os servidores S2 e S3 mantinham instâncias do SGBD, uma instância para cada
servidor. Os servidores S4, S5, S6 não entram no teste.
Para cada novo caso de validação, um novo servidor se unia aos servidores S2 e S3.
Os resultados apresentados nas próximas subseções tiveram como referencia o valor
relativo do servidor S1 no “Caso de Validação 1”, logo os valores percentuais estão
diretamente proporcionais ao mesmo. Desta maneira, o caso de validação que apresentar
valor acima de 100% implica em desempenho pior que o “Caso de Validação 1”.
Conseqüentemente, sempre que o valor estiver abaixo de 100% implica em desempenho
melhor que o “Caso de Validação 1”.
5.6.1. Incluir Dados
Neste processo as bases de dados, de cada caso de validação, estavam inicialmente
limpas. A tabela 5.1 mostra os resultados percentuais médio de desempenho da CPU.
67
Na coluna Servidor desta tabela são mostrados os servidores. Na coluna Caso 1 é
apresentado o resultado do servidor S1 no “Caso de Validação 1”. O valor apresentado
para o servidor S1 no “Caso de Validação 1” é tomado com referencia para os servidores
ativos nos casos de validações posteriores.
A coluna Caso 2 apresenta os resultados dos servidores S1 e S2 no “Caso de
Validação 1”. A coluna Caso 3 apresenta o resultados dos servidores S1, S2 e S3 no “Caso
de Validação 3”. As outras colunas têm suas explicações semelhantes as já apresentadas.
A figura 5.4 mostra o gráfico de desempenho das CPUs baseado na tabela 5.1.
Tabela 5.1 – Percentual médio de desempenho da CPU no processo de inclusão de dados
Servidor Caso 1
S1
100%
S2
S3
S4
S5
S6
Caso 2
122%
28%
Caso 3
94%
11%
Caso 4
83%
6%
Caso 5
72%
6%
Caso 6
72%
6%
A tabela 5.2 mostra os resultados percentuais médio da utilização da rede, sua
explicação é análoga a da tabela 5.1. A figura 5.5 mostra o gráfico de desempenho da rede
fundamentado na tabela 5.2.
Tabela 5.2 – Percentual médio da utilização da rede no processo de inclusão de dados
Servidor Caso 1
S1
100%
S2
S3
S4
S5
S6
Caso 2
100%
74%
Caso 3
100%
33%
Caso 4
100%
20%
Caso 5
100%
18%
Caso 6
100%
13%
68
Figura 5.4 – Gráfico do percentual médio de desempenho da CPU na inclusão de dados
Figura 5.5 – Gráfico do percentual médio da utilização da rede na inclusão de dados
A tabela 5.3 mostra como as tabelas dos SGBDRs ficaram povoadas após as
inclusões. Na coluna Servidor foram colocados os servidores. Na coluna Tabela foram
colocas as tabelas que estavam em cada servidor. Todos os servidores continham as
mesmas tabelas.
Na coluna Caso 1 é apresentado o total de registros em cada tabela do servidor S1
após a conclusão do “Caso de Validação 1”. O mesmo acontece na coluna Caso 2 onde é
69
mostrado o total de registros nas tabelas do servidor S2 após a conclusão do “Caso de
Validação 2”.
A coluna Caso 3 apresenta o total de registros nas tabelas dos servidores S2 e S3
após o “Caso de Validação 3”. As colunas Caso 4, Caso 5 e Caso 6 mostram o equivalente
dos “Caso de Validação 4” à “Caso de Validação 6”.
Tabela 5.3 – Tabelas dos SGBDRs após o processo de inclusão de dados
Servidor
S1
S2
S3
S4
S5
S6
Tabela
Cliente
Funcion
PDV
PDV_Item
Produto
Cliente
Funcion
PDV
PDV_Item
Produto
Cliente
Funcion
PDV
PDV_Item
Produto
Cliente
Funcion
PDV
PDV_Item
Produto
Cliente
Funcion
PDV
PDV_Item
Produto
Cliente
Funcion
PDV
PDV_Item
Produto
Caso 1
4000
1000
5000
15000
1000
Caso 2
Caso 3
Caso 4
Caso 5
Caso 6
4000
1000
5000
15000
1000
2000
500
2500
7500
500
2000
500
2500
7500
500
1334
334
1666
5000
333
1333
333
1667
5000
334
1333
333
1667
5000
333
1000
250
1250
3750
250
1000
250
1250
3750
250
1000
250
1250
3750
250
1000
250
1250
3750
250
800
200
1000
3000
200
800
200
1000
3000
200
800
200
1000
3000
200
800
200
1000
3000
200
800
200
1000
3000
200
70
5.6.2. Alterar Dados
Neste processo as bases de dados, de cada caso de validação, estavam com os dados
incluídos nos processos de inclusão de dados dos seus respectivos caso de validação. A
tabela 5.4 e a figura 5.6 mostram os resultados percentuais médio de desempenho da CPU,
enquanto a tabela 5.5 e a figura 5.7 mostram os resultados percentuais médio da utilização
da rede.
As explicações para as tabelas 5.4 e 5.5 são análogas as das tabelas 5.1 e 5.2,
respectivamente.
Tabela 5.4 – Percentual médio de desempenho da CPU no processo de alteração de dados
Servidor Caso 1
S1
100%
S2
S3
S4
S5
S6
Caso 2
138%
25%
Caso 3
127%
25%
Caso 4
127%
25%
Caso 5
138%
13%
Caso 6
138%
13%
Figura 5.6 – Gráfico do percentual médio de desempenho da CPU na alteração de dados
71
Tabela 5.5 – Percentual médio da utilização da rede no processo de alteração de dados
Servidor Caso 1
S1
100%
S2
S3
S4
S5
S6
Caso 2
168%
37%
Caso 3
210%
37%
Caso 4
247%
37%
Caso 5
263%
37%
Caso 6
263%
37%
Figura 5.7 – Gráfico do percentual médio da utilização da rede na alteração de dados
5.6.3. Consultar Dados
Neste processo as bases de dados, de cada caso de validação, estavam com os dados
alterados nos processos de alteração de dados dos seus respectivos caso de validação. A
tabela 5.6 e a figura 5.8 mostram os resultados percentuais médio de desempenho da CPU,
enquanto a tabela 5.7 e figura 5.9 mostram os resultados percentuais médio da utilização da
rede.
As explicações para as tabelas 5.6 e 5.7 também são análogas as das tabelas 5.1 e
5.2, respectivamente.
72
Tabela 5.6 – Percentual médio de desempenho da CPU no processo de consulta de dados
Servidor Caso 1
S1
100%
S2
S3
S4
S5
S6
Caso 2
107%
59%
Caso 3
118%
33%
Caso 4
111%
29%
Caso 5
93%
15%
Caso 6
81%
11%
Figura 5.8 – Gráfico do percentual médio de desempenho da CPU na consulta de dados
Tabela 5.7 – Percentual médio da utilização da rede no processo de consulta de dados
Servidor Caso 1
S1
100%
S2
S3
S4
S5
S6
Caso 2
417%
117%
Caso 3
300%
67%
Caso 4
250%
42%
Caso 5
233%
25%
Caso 6
217%
17%
73
Figura 5.9 – Gráfico do percentual médio da utilização da rede na consulta de dados
5.7. Análise da validação
A implementação e validação do middleware chegou aos seguintes resultados:
1. Incluir Dados: Neste processo o middleware mostrou-se parcialmente viável
quando usado no “Caso de Validação 2”, uma vez que o servidor
mantenedor do GABRIEL sofreu uma sobrecarga na CPU maior que no
“Caso de Validação 1” quando mantinha apenas o SGBD. Mas no “Caso de
Validação 2” o servidor que mantinha a instância do SGBD obteve um
ganho significativo se comparando com o caso de validação anterior. Do
“Caso de Validação 3” à “Caso de Validação 6” tanto o servidor
mantenedor do GABRIEL quanto os que mantinham o SGBD obtiveram
ganhos de uso da CPU se comparados ao “Caso de Validação 1”. A
utilização da rede por parte do servidor S1 manteve-se estável em todos os
casos de validação, quanto aos servidores S2 à S6, à medida que um novo
servidor era incluído na arquitetura, a utilização da rede obtinha ganho de
desempenho.
2. Alterar Dados: Neste processo o middleware mostrou-se parcialmente
viável, uma vez que o servidor S1 obteve desempenho pior com o uso do
GABRIEL. Já os servidores S2 à S6 sempre tiveram desempenho melhor que
74
o servidor S1 no “Caso de Validação 1”. Esta mesma situação foi verificada
no requisito utilização da rede.
3. Consultar Dados: Neste processo o servidor S1 só obteve melhor
desempenho de uso da CPU nos “Caso de Validação 5” e “Caso de
Validação 6”, em contra-partida, a cada novo servidor colocado na
arquitetura, o desempenho das CPUs foram melhoradas consideravelmente.
Os piores desempenhos da utilização da rede ocorreram neste processo, o
servidor S1 sempre obteve resultados piores quando utilizava o middleware
proposto, enquanto o servidor S2 só obteve desempenho melhor de
utilização de rede a partir do “Caso de Validação 3”, já os servidores S3 à
S6 sempre obtiveram um desempenho melhor de utilização da rede. No
“Caso de Validação 6” os servidores S2 à S6 obtiveram desempenho de
utilização de rede semelhante ao do servidor S1 quando aplicado o “Caso de
Validação 1” no processo de inclusão de dados.
5.8. Conclusão
O middleware proposto efetuou a distribuição horizontal dos dados entre os
SGBDRs instanciados, garantindo escalabilidade maior que a arquitetura cliente-servidor
de duas camadas.
Quando o LUCAS-GABRIEL foi utilizado, os servidores com as instâncias dos
SGBDRs sempre obtiveram resultados melhores, mesmo quando o servidor com a instância
do GABRIEL mostrou desempenho inferior ao valor de referencia.
Para o sistema cliente passar a usar o middleware proposto, bastou substituir os
comandos SQL pelas chamadas aos métodos da classe LUCAS via DLL. Desta maneira
softwares projetados para arquitetura cliente-servidor de duas camadas podem migrar para
uma arquitetura de escalabilidade maior com poucas alterações na sua implementação.
Para o LUCAS-GABRIEL ser utilizado não foi preciso a existência de cluster ou
grid computing. Para cada nova instância de SGBDR incluído no middleware proposto, foi
necessário apenas informar ao GABRIEL o endereço do novo banco de dados.
Estes motivos comprovam que o middleware LUCAS-GABRIEL é viável.
75
Capítulo 6
Conclusão e Trabalhos Futuros
Este capítulo apresenta comentários conclusivos sobre a dissertação. Na seqüência é
apresentada a conclusão e as dificuldades encontradas, além dos trabalhos futuros.
6.1. Síntese da Dissertação
O aumento do armazenamento de dados trouxe consigo problemas, um deles foi a
necessidade de softwares capazes de manter grandes volumes e dados seguros e
disponíveis. Técnicas de distribuição e replicação de dados foram aplicadas para garantir a
recuperação dos dados, mas tais técnicas não resolvem problemas de disponibilidade e
escalabilidade.
O banco de dados Oracle 10g impulsionou a integração de técnicas de maneira
nativa com a finalidade de fornecer alta disponibilidade, tolerância a falhas, replicação,
balanceamento de carga, alto desempenho e escalabilidade. Outro banco com estudos na
área é o PostgreSQL, mas as soluções desenvolvidas para o PostgreSQL não são
implementações nativas.
A arquitetura apresentada nesta dissertação não é direcionada a um único banco de
dados, mas para uma estrutura de armazenamento de dados homogênea ou heterogênea.
Esta arquitetura é montada sobre o middleware LUCAS-GABRIEL, o middleware se
responsabiliza em distribuir os dados horizontalmente entre os SGBDs, mas sem interferir
nos processos internos dos SGBDs.
No middleware LUCAS-GABRIEL, o sistema cliente envia suas solicitações ao
LUCAS que organiza as mesmas e as envias ao GABRIEL. O GABRIEL, por sua vez,
gerencia as solicitações junto aos SGBDRs e envia uma resposta para o LUCAS que a
repassa esta resposta para o sistema cliente.
6.2. Conclusão
Os resultados das validações demonstraram que o middleware LUCAS-GABRIEL é
viável, pois os SGBDRs sempre ganharam desempenho. O bom resultado nos SGBDRs foi
conseguido graças ao processo de distribuição dos dados executado pelo middleware.
76
As validações também demonstraram que a proposta inicial de aumentar a
escalabilidade dos SGBDRs com arquitetura cliente-servidor de duas camadas foi
alcançada.
A comunicação via socket, entre o sistema cliente e o middleware proposto,
permitiu montar uma estrutura de acesso a dados para sistemas implementados em qualquer
linguagem de programação que suporte o uso de socket.
Os requisitos que o middleware LUCAS-GABRIEL se propôs a resolver foram
conseguidos e provados na validação.
6.2.1. Vantagens do Middleware
Embora existam outras propostas de distribuição de dados (Leia Capítulo 3), o
middleware LUCAS-GABRIEL apresenta um conjunto de benefícios não igualados pelas
outras propostas estudadas:
• Heterogeneidade da linguagem de programação do sistema cliente;
• Independência de SGBDR;
• Estrutura distribuída de armazenamento de dados;
• Balanceamento dos dados armazenados entre os SGBDRs;
• Transparência na distribuição dos dados;
• Escalabilidade.
A heterogeneidade da linguagem de programação para o sistema cliente é um ponto
forte do middleware, pois beneficiar sistemas legados.
Com a independência de SGBDR, as regras de acesso ao banco de dados, mantidas
no sistema cliente, não precisam mudar quando o SGBDR for mudado.
A estrutura distribuída de armazenamento de dados aumenta o poder computacional
de processamento, melhorando o desempenho quando comparado com uma estrutura
centralizada (Leia 2.2.3.4. Arquitetura Distribuída).
O balanceamento dos dados entre os SGBDRs aumento o desempenho das
solicitações feitas pelo sistema cliente. Uma vez que cada SGBDR tem apenas parte dos
dados, o processamento das solicitações nesses dados exige um poder computacional
menor.
77
O sistema cliente não precisa ficar preocupado em gerenciar os dados distribuídos, o
middleware LUCAS-GABRIEL faz isso de maneira transparente.
Problemas de escalabilidade podem ser contornados incluindo novos servidores de
dados na estrutura gerenciada pelo middleware LUCAS-GABRIEL.
6.2.2. Limitações do Middleware
As validações apontaram que a centralização das solicitações no GABRIEL –
localizado em único nó – causou perda de desempenho do GABRIEL em situações
especifica, tanto no desempenho médio da CPU, quanto no desempenho médio da
utilização da rede.
Devido o GABRIEL não manter um esquema para o gerenciamento dos dados
armazenados junto aos SGBDRs, o uso de junções em consultas SQL se torna inviável no
middleware. A falta de esquema também impossibilitou a implementação da replicação dos
dados em um ou mais servidores de dados.
6.3. Dificuldades Encontradas
Uma pesquisa sobre o banco de dados Oracle 10g foi o passo inicial para ter em
mente a estratégia utilizada pela Oracle para resolver problemas de alta disponibilidade,
tolerância a falhas, replicação, balanceamento de carga, alto desempenho e escalabilidade.
Embora a documentação sobre o Oracle 10g seja vasta, o detalhamento técnico da sua
arquitetura não é tão fácil de encontrar.
O passo seguinte foi analisar como o PostgreSQL resolveu os mesmo problemas
citados para o Oracle 10g. Assim como no caso do Oracle 10g, a documentação também é
ampla, mas neste caso a dificuldade em localizar o detalhamento técnico de suas soluções
foi bem menor. Devido o PostgreSQL ser um banco de dados open source existem várias
soluções, mas muitas estão sem implementação; direcionando os estudos para um novo
levantamento com o intuito de saber quais soluções implementadas são mais utilizadas
pelos usuários do PostgreSQL.
Na seqüência foram pesquisadas propostas independentes de banco de dados, e
assim como no PostgreSQL, a documentação é vasta, mas a grande maioria se limitou
apenas em documentar, não levando adiante a implementação e os testes para validação.
78
Com a pesquisa feita, foi iniciado o desenho da arquitetura, tendo como foco os
diagramas de classes e de seqüências. Tais diagramas foram refinados muitas vezes até
chegar à versão apresentada neste documento.
Com os diagramas prontos foi iniciado a implementação do middleware, exigindo
maiores esforços nos tópicos de identificação do IP, criação e tratamento de mensagens e
seu envio e recebimento via sockets, além da criação, tratamento, envio e recebimento de
arquivos XML.
Por fim, foi necessário conseguir um laboratório para que os testes de validação
fossem feito, sendo necessário instalar o middleware além do Firebird 2.0, todos
instanciados sobre o sistema operacional Windows XP Professional Service Pack 3 (Leia
5.5. Cenário).
6.4. Trabalhos Futuros
Ao incorporar a classe LUCAS numa DLL, o middleware ficou heterogêneo quanto
a linguagem de programação do sistema cliente, porém limitou seu uso as linguagens de
programação que tem suporte a DLL. Deixar o LUCAS ainda mais heterogêneo deve ser
revisto em estudos futuros.
A perda de desempenho do GABRIEL é um ponto que merece ser alvo de estudos
futuros, para transformar o mesmo em um aplicativo distribuído. Estes estudos devem
tentar remover o ponto de sobrecarga detectado nos testes de validação e o ponto de falha
no caso de queda do GABRIEL.
O uso de esquemas pelo GABRIEL para gerenciar os dados e as instâncias dos
SGBDRs por si só já é uma questão que deve ser levantada para estudos futuros, mas a
criação de esquemas pode levar a outros estudos futuros como os mostrados na seqüência:
‒ Fragmentação vertical dos dados: O uso de esquemas permitiria ao
middleware evoluir para a fragmentação vertical dos dados;
‒ Alta disponibilidade dos dados: Com o uso de esquemas pode ser
implementado a redundância dos dados em instâncias distintas do SGBDs
aumentando a disponibilidade dos dados;
‒ Balanceamento automático de carga: Sempre que um novo servidor
ingressasse na arquitetura, o middleware se encarregaria de refazer o
79
balanceamento entre as instâncias do SGBDs, aumentando o desempenho do
sistema como um todo.
Um estudo futuro com esquema importante que deve ser considerado é a
fragmentação de relação inteira, onde todos os dados de uma tabela são mantidos num
único servidor. Desta maneira sistemas ERP (Enterprise Resource Planning – Sistemas
Integrados de Gestão Empresarial) e CRM (Customer Relationship Management - Gestão
de Relacionamento com o Cliente) poderiam se beneficiar do middleware, pois estes
sistemas veriam o middleware como um SGBD único, se preocupando apenas em solicitar
os serviços ao GABRIEL, implementando SOA (Service Oriented Architecture –
Arquitetura Orientada a Serviços) na arquitetura de distribuição de dados do middleware.
Independente do uso de esquema para fragmentação de dados, o middleware pode
ser usado como SOA em consultas entre empresas do mesmo grupo que retornem, por
exemplo, o histórico de compras e pagamentos de um determinado cliente, conjuntura
comum em empresas que tenham uma ou mais filiais, e que são obrigadas a utilizar
soluções nem sempre práticas (consulta via telefone entre a matriz e as filiais, troca de
mensagens instantâneas, etc.) para obter tais informações.
80
Apêndice A
Detalhamento dos atributos e métodos da classe LUCAS.
Tabela A.1 – Atributos da classe LUCAS
Atributo
Conteúdo
Porta_Endereco
- Porta que será usada na conexão;
- Endereço do GABRIEL;
- Endereço onde será colocado o arquivo XML retornado
pelo GABRIEL
Tabela
- ID da solicitação;
- Tabela que será usada na solicitação;
- Tipo de Solicitação (tipo enumerado Tipo_Solicitacao);
- Condição (quando houver) que deve ser atendida na solicitação
ChaveEstrangeira
- ID da solicitação;
- Tabela estrangeira;
- Campo da tabela local que receberá o valor da chave primária da
tabela estrangeira
Dados
- ID da solicitação;
- Campo da tabela local;
- Valor que será atribuído ao campo da tabela local
ID_Solicitacao
- ID de solicitação atual
SoqueteCliente
- socket cliente descendente da classe ClientSocket
Tabela A.2 – Métodos da classe LUCAS
Método
Parâmetro
Descrição
EnviarMensagem
Mensagem
Envia o conteúdo do parâmetro ao
método SetMensagem do SoqueteCliente
SalvarXML
NomeAtributo
Persiste, em um arquivo XML, o atributo
de configuração passado
81
SetSolicitar
- Solicitar
- Configura tipo de solicitação que será
executada (ver atributo Tabela);
- Condicao
- Condição que deve ser atendida
(ver atributo Tabela);
- Requisitar
- Quando verdadeiro chama o método
SetRequisitar
Método relacionado:
- SetRequisitar
- SetTabela
- SetChaveEstrangeira
Construir
SetPorta
Construtor da classe
Porta
Configura porta de conexão com o
GABRIEL (ver atributo Porta_Endereco)
SetMediador
Endereco
Configura endereço do GABRIEL
(ver atributo Porta_Endereco)
SetResposta
Endereco
Configura endereço do arquivo XML de
retorno (ver atributo Porta_Endereco)
SetConfiguracao
- Porta
- Envia o conteúdo do parâmetro ao
método SetPorta
- EnderecoMediador
- Envia o conteúdo do parâmetro ao
método SetMediador
- EnderecoResposta
- Envia o conteúdo do parâmetro ao
método SetResposta
SetTabela
Tabela
Configura tabela que será usada na
solicitação (ver atributo Tabela)
SetChaveEstrangeira
- Tabela
- Configura tabela estrangeira
(ver atributo ChaveEstrangeira)
- Campo
- Configura campo da tabela local
(ver atributo ChaveEstrangeira)
82
SetDados
- Campo
- Configura campo da tabela local
(ver atributo Dados)
- Valor
- Configura valor que será atribuído ao
campo (ver atributo Dados)
Clear
Limpa todas as solicitações pendentes
ClearChaveEstrangeira
Limpa todas as chaves estrangeiras das
solicitações pendentes
ClearChaveEstrangeira
- Tabela
Limpa a chave estrangeira da solicitação
atual com tabela estrangeira e campo
- Campo
local iguais aos passados pelos
parâmetros
ClearDados
Limpa todos os dados das solicitações
pendentes
ClearDados
Campo
Limpa todos os dados da solicitação
atual com campo igual ao passado pelo
parâmetro
GetPorta
Captura porta de conexão com o
GABRIEL (ver atributo Porta_Endereco)
GetMediador
Captura endereço do GABRIEL
(ver atributo Porta_Endereco)
GetResposta
Captura endereço do arquivo XML de
retorno (ver atributo Porta_Endereco)
GetTabela
Captura IDs, tabelas, tipos de
solicitações e condições das solicitações
pendentes (ver atributo Tabela)
GetChaveEstrangeira
Captura IDs, tabelas estrangeiras e
campos da tabelas locais das solicitações
pendentes
(ver atributo ChaveEstrangeira)
83
GetDados
Captura IDs, campos e valores dos dados
das solicitações pendentes
(ver atributo Dados)
GetPendente
Captura o número de solicitações
pendentes
SetIncluir
Requisitar
Envia o parâmetro Requisitar ao método
SetSolicitar, informando que a pendência
atual se refere a uma inclusão
SetAlterar
- Condicao
Envia os parâmetros Condicao e
Requisitar ao método SetSolicitar,
- Requisitar
informando que a pendência atual se
refere a uma alteração
SetExcluir
- Condicao
Envia os parâmetros Condicao e
Requisitar ao método SetSolicitar,
- Requisitar
informando que a pendência atual se
refere a uma exclusão
SetConsultar
- Condição
Envia os parâmetros Condicao ao
método SetSolicitar, informando que a
pendência atual se refere a uma consulta
SetConsultarSQL
ComandoSelect
Envia o conteúdo do parâmetro (deve ser
um comando select) ao método
EnviarMensagem
SetRequisitar
Gera os comandos SQL das solicitações
pendentes e os passa ao método
EnviarMensagem
Método relacionado:
- EnviarMensagem
- Clear
84
Apêndice B
Detalhamento dos atributos e métodos da classe ClientSocket.
Tabela B.1 – Atributos da classe ClientSocket
Atributo
Conteúdo
Status
Status atual do socket cliente (tipo enumerado Tipo_Status)
Porta
Porta que será usada na conexão
Conectado
Status da conexão
Tabela B.2 – Métodos da classe ClientSocket
Método
Parâmetro
Construir
Descrição
Construtor da classe
SetStatus
Status
Configura o atributo Status
SetPorta
Porta
Configura o atributo Porta
SetConectado
Conectado
Configura o atributo Conectado
GetStatus
Captura o atributo Status
- Aguardando = 0;
- Processando = 1;
- Baixando = 2
GetStatus
Status
Captura o atributo Status, além de
retorna, através do parâmetro passado
por referencia, o valor de enumeração
Tipo_Status
GetPorta
Captura o atributo Porta
GetConectado
Captura o atributo Conectado
SoqueteClienteLocalizar
Localizador do socket servidor
SetMensagem
Mensagem
Envia conteúdo do parâmetro para o
socket servidor
85
GetMensagem
Captura mensagem enviada pelo socket
servidor
GetErro
Captura erros que possam ocorrer entre
a conexão cliente e servidor
86
Apêndice C
Detalhamento dos atributos e métodos da classe GABRIEL.
Tabela C.1 – Atributos da classe GABRIEL
Atributo
Conteúdo
Porta_Relembrar
- Porta que será usada na conexão;
- Flag que indica se será efetuada uma contagem de registros nas
tabelas sempre que for efetuar uma inclusão
Servidor
- Nome do servidor
- Endereço do banco de dados no servidor
Tabela
- Nome das tabelas que serão gerenciadas pelo GABRIEL
- Nome do campo indicado como chave primária
- Último número gerado para a chave primaria
ServidorTabela
- Nome do servidor
- Nome da tabela
- Quantidade de registros da tabela no servidor
Este atributo é o responsável por manter os SGBDs balanceados,
através da quantidade de registros que uma tabela tem em cada um
dos SGBDs
SoqueteServidor
- Socket servidor descendente da classe ServerSocket
ConexaoSQL
- Vetor descendente da classe SQLConnect
Tabela C.2 – Métodos da classe GABRIEL
Método
Parâmetro
ConstruirConexaoSGBD Servidor
Descrição
Construtor da conexão do GABRIEL
com o SGBD
DestruirConexaoSGBD
Servidor
Destruidor da conexão do GABRIEL
com o SGBD
87
ExecutarSQL
- Mensagem
- Comando(s) SQL
- Origem
- Origem do solicitante
- Controle
- Número controle do solicitante
Envia o(s) comando(s) SQL (insert,
update, delete, select) do parâmetro
Mensagem para o método
ExecutarComandoSQL do
ConexaoSQL; caso o parâmetro
Mensagem contenha uma consulta
(select), os registros de retorno do
SGBDs são colocados em um arquivo
XML, onde sua identificação é feita
através dos parâmetros Origem e
Controle
SalvarXML
NomeAtributo
Persiste, em um arquivo XML, o
atributo de configuração passado
SetServidorTabela
Atualiza o atributo ServidorTabela
sempre que houve uma atualização nos
atributos Servidor ou Tabela
EraseServidorTabela
- Nome
- Nome do servidor ou tabela
- Servidor
- Flag que indica se o nome é de um
servidor ou de uma tabela
Exclui todos os itens do atributo
ServidorTabela que coincidam com os
parâmetros passados
Construir
SetPorta
Construtor da classe
Porta
Configura porta de conexão
(ver atributo Porta_Relembrar)
88
SetTabelaRelembrar
TabelaRelembrar
Configura flag de contagem de registros
(ver atributo Porta_Relembrar)
SetServidor
- Nome
Configura atributo Servidor
- Endereco
(ver atributo Servidor)
Métodos relacionados:
- ConstruirConexaoSGBD
- SetServidorTabela
SetConfiguracao
- Porta
- Envia o conteúdo do parâmetro ao
método SetPorta
- ServidorNome
- ServidorEndereco
- TabelaRelembrar
- Envia o conteúdo dos parâmetros ao
método SetServidor
- Envia o conteúdo do parâmetro ao
método SetTabelaRelembrar
SetTabela
- Tabela
Configura atributo Tabela
- Chave
(ver atributo Tabela)
- Gerador
Método Relacionado:
- SetServidorTabela
EraseServidor
Nome
Exclui o item do atributo Servidor que
coincide com o parâmetro
Métodos relacionados:
- DestruirConexaoSGBD
- EraseServidorTabela
89
EraseTabela
Tabela
Exclui o item do atributo Tabela que
coincide com o parâmetro
Método relacionado:
- EraseServidorTabela
GetPorta
Captura porta de conexão
(ver atributo Porta_Relembrar)
GetTabelaRelembrar
Captura flag de contagem de registros
(ver atributo Porta_Relembrar)
GetServidor
Captura atributo Servidor
(ver atributo Servidor)
GetTabela
Captura atributo Tabela
(ver atributo Tabela)
90
Apêndice D
Detalhamento dos atributos e métodos da classe ServerSocket.
Tabela D.1 – Atributos da classe ServerSocket
Atributo
Conteúdo
Porta
Porta que será usada na conexão
Conectado
Status da conexão
Tabela D.2 – Métodos da classe ServerSocket
Método
Parâmetro
Construir
Descrição
Construtor da classe
SetPorta
Porta
Configura o atributo Porta
SetConectado
Conectado
Configura o atributo Conectado
GetPorta
Captura o atributo Porta
GetConectado
Captura o atributo Conectado
SetMensagem
Mensagem
Envia conteúdo do parâmetro para o
socket cliente
GetMensagem
Captura mensagem enviada pelo socket
cliente
GetErro
Captura erros que possam ocorrer entre a
conexão cliente e servidor
91
Apêndice E
Detalhamento dos atributos e métodos da classe SQLConnect.
Tabela E.1 – Atributos da classe SQLConnect
Atributo
Conteúdo
BaseDados
Endereço da base de dados
DialetoSQL
Dialeto SQL usado pelo SGBD
SolicitarLogin*
Flag usado para informar se deverá ser pedido usuário e senha toda
vez que o banco de dados for conectado
Usuario*
Usuário que está se conectando com o banco de dados
Senha*
Senha do usuário
Ativo
Status da conexão
ComandoSQL
Comando SQL que deverá ser executado
*Os atributos Usuario e Senha só serão usados no momento da conexão com o SGBD se o atributo SolicitarLogin não estiver habilitado.
Tabela E.2 – Métodos da classe SQLConnect
Método
Parâmetro
Construir
Descrição
Construtor da classe
SetBaseDados
BaseDados
Configura o atributo BaseDados
SetDialetoSQL
DialetoSQL
Configura o atributo DialetoSQL
SetSolicitarLogin
SolicitarLogin
Configura o atributo SolicitarLogin
SetUsuario
Usuario
Configura o atributo Usuario
SetSenha
Senha
Configura o atributo Senha
SetAtivo
Ativo
Configura o atributo Ativo
SetComandoSQL
ComandoSQL
Configura o atributo ComandoSQL
GetBaseDados
Captura o atributo BaseDados
GetDialetoSQL
Captura o atributo DialetoSQL
GetSolicitarLogin
Captura o atributo SolicitarLogin
GetUsuario
Captura o atributo Usuário
GetSenha
Captura o atributo Senha
92
GetAtivo
Captura o atributo Ativo
GetComandoSQL
Captura o atributo ComandoSQL
ExecutarComandoSQL
Executa o comando SQL que está no
atributo ComandoSQL retornando,
quando for uma consulta (select), os
registros
93
Apêndice F
Algoritmo do método SetRequisitar da classe LUCAS:
// Tabela, Dados, ChaveEstrangeira: Atributos da classe LUCAS
//
do tipo HashMAP.
Variáveis Locais
SQL: String;
ReqDados: String;
ReqDadosValor: String;
ReqChaveEstrangeira: String;
Inicio
SQL.Limpar;
Tabela.Primeiro;
Enquanto (não for o fim de Tabela) Faça
Inicio
// Preparação do atributo Dados para todas as solicitações
ReqDados.Limpar;
Dados.Filtro =
“ID_Solicitacao = ” + Tabela[“ID_Solicitacao”];
Dados.Primeiro;
// Solicitação de inclusão
Se (Tabela[“Solicitacao”] == “Incluir”) Então
Inicio
ReqDadosValor.Limpar;
Enquanto (não for o fim de Dados) Faça
Inicio
Se (ReqDados <> “”) Então
Inicio
ReqDados = ReqDados + “, ”;
ReqDadosValor = ReqDadosValor + “, ”;
Fim;
ReqDados = ReqDados + Dados[“Campo”];
ReqDadosValor = ReqDadosValor + “'” +
Dados[“Valor”] + “'”;
Dados.Próximo;
Fim;
ReqChaveEstrangeira.Limpar;
ChaveEstrangeira.Filtro = “ID_Solicitacao = ” +
Tabela[“ID_Solicitacao”];
ChaveEstrangeira.Primeiro;
Enquanto (não for o fim de ChaveEstrangeira) Faça
Inicio
ReqChaveEstrangeira = ReqChaveEstrangeira +
ChaveEstrangeira[“Tabela”] + “, ” +
ChaveEstrangeira[“Campo”] +
Char(27) + Char(10) + Char(13);
ChaveEstrangeira.Próximo;
Fim;
Se ( ReqChaveEstrangeira <> “” ) Então
Inicio
ReqChaveEstrangeira =
Char(27) + Char(10) + Char(13) +
ReqChaveEstrangeira;
94
Fim;
Se (ReqDados <> “” ) E (ReqDadosValor <> “”) Então
Inicio
SQL = SQL + “insert into ” + Tabela[“Tabela”] +
“ (” + ReqDados + “) values (” + ReqDadosValor +
“)” + ReqChaveEstrangeira + “;”;
Fim;
Fim
SeNão Se (Tabela[“Solicitacao”] == “Alterar” ) Então
Inicio
Enquanto (não for o fim de Dados) Faça
Inicio
Se (ReqDados <> “”) Então
Inicio
ReqDados = ReqDados + “, ”;
Fim;
ReqDados = ReqDados + Dados[“Campo”] + “ = '” +
Dados[“Valor”] + “'”;
Dados.Próximo;
Fim;
Se (ReqDados <> “”) Então
Inicio
SQL = SQL + “update ” + Tabela[“Tabela”] + “ set ” +
ReqDados + “ where ” + Tabela[“Condicao”] + “;”;
Fim;
Fim
SeNão Se (Tabela[“Solicitacao”] == “Excluir” ) Então
Inicio
SQL = SQL + “delete from ” + Tabela[“Tabela”] +
“ where ” + Tabela[“Condicao”] + “;”;
Fim
SeNão Se (Tabela[“Solicitacao”] == “Consultar” ) Então
Inicio
Enquanto (não for o fim de Dados) Faça
Inicio
Se (ReqDados <> “”) Então
Inicio
ReqDados = ReqDados + “, ”;
Fim;
ReqDados = ReqDados + Dados[“Campo”];
Dados.Próximo;
Fim;
Se (ReqDados <> “”) Então
Inicio
SQL := SQL + “select ” + ReqDados + “ from ” +
Tabela[“Tabela”] + “ where ” +
Tabela[“Condicao”] + “;”;
Fim;
Fim;
Tabela.Próximo;
end;
EnviarMensagem(SQL);
Fim;
95
Apêndice G
Tabela G.1 – Chamadas aos métodos da classe LUCAS
Método da classe LUCAS
Chama via DLL
LUCAS_DLL.SetAtivarSoquete
LUCAS_SetAtivarSoquete
LUCAS_DLL.SetPorta
LUCAS_SetPorta
LUCAS_DLL.SetMediador
LUCAS_SetMediador
LUCAS_DLL.SetResposta
LUCAS_SetResposta
LUCAS_DLL.SetConfiguracao
LUCAS_SetConfiguracao
LUCAS_DLL.SetTabela
LUCAS_SetTabela
LUCAS_DLL.SetChaveEstrangeira
LUCAS_SetChaveEstrangeira
LUCAS_DLL.SetDados
LUCAS_SetDados
LUCAS_DLL.Clear
LUCAS_Clear
LUCAS_DLL.ClearChaveEstrangeira
LUCAS_ClearChaveEstrangeiraTudo
LUCAS_DLL.ClearChaveEstrangeira
LUCAS_ClearChaveEstrangeira
LUCAS_DLL.ClearDados
LUCAS_ClearDadosTudo
LUCAS_DLL.ClearDados
LUCAS_ClearDados
LUCAS_DLL.GetSoqueteAtivo
LUCAS_GetSoqueteAtivo
LUCAS_DLL.GetSoqueteAtivar
LUCAS_GetSoqueteAtivar
LUCAS_DLL.GetPorta
LUCAS_GetPorta
LUCAS_DLL.GetMediador
LUCAS_GetMediador
LUCAS_DLL.GetResposta
LUCAS_GetResposta
LUCAS_DLL.GetTabela
LUCAS_GetTabela
LUCAS_DLL.GetChaveEstrangeira
LUCAS_GetChaveEstrangeira
LUCAS_DLL.GetDados
LUCAS_GetDados
LUCAS_DLL.GetPendente
LUCAS_GetPendente
LUCAS_DLL.GetStatus
LUCAS_GetStatus
LUCAS_DLL.GetStatus
LUCAS_GetStatusDescr
LUCAS_DLL.SetIncluir
LUCAS_SetIncluir
LUCAS_DLL.SetAlterar
LUCAS_SetAlterar
96
LUCAS_DLL.SetExcluir
LUCAS_SetExcluir
LUCAS_DLL.SetConsultar
LUCAS_SetConsultar
LUCAS_DLL.SetConsultarSQL
LUCAS_SetConsultarSQL
LUCAS_DLL.SetRequisitar
LUCAS_SetRequisitar
Tabela G.2 – Métodos auxiliares utilizados na sobrecarga
Método
Descrição
Tabela
GerarNome
Cria um conjunto de nomes e sobrenomes para
- Cliente
as inclusões
- Funcion
Cria endereços para as inclusões e alterações
- Cliente
GerarEnder
- Funcion
GerarBairro
Cria bairros para as inclusões, alterações e
- Cliente
consultas
- Funcion
GerarDescr
Cria descrições para as inclusões e consultas
- Produto
GerarValor
Cria valores monetários para as inclusões,
- Produto
alterações e consultas
GerarComiss
Cria valores em percentuais para as inclusões e
- Produto
consultas
GerarPDV_ID
Captura o valor que será usado no campo ID das - PDV
inclusões
MaiorID(Tabela: string)
Captura o maior valor já incluído no campo ID
- Cliente
- Funcion
- Produto
- PDV
- PDV_Item
97
Tabela G.3 – Resumo das configurações dos computadores usados no teste
Sistema Operacional
Processador
HD
Placa Mãe
Memória
Windows XP Professional Service Pack 3 (build 2600)
3,00 gigahertz Intel Pentium D
16 kilobyte primary memory cache
2048 kilobyte secondary memory cache
64-bit ready
Multi-core (2 total)
Not hyper-threaded
WDC WD800BB-63JKC0 [Hard drive] (80,03 GB) -- drive 0, s/n
WD-WCAMDA734570, rev 05.01C05, SMART Status: Healthy
Board: Gigabyte Technology Co., Ltd. VM900M
Bus Clock: 200 megahertz
BIOS: Award Software International, Inc. FC 08/14/2007
448 Megabytes Usable Installed Memory
98
Referências
AULT, Mike; TUMMA, Madh. Oracle 10g Grid & Real Application Clusters:
Oracle10g Grid Computing with RAC. 2004. Kittrell, North Carolina, USA: Rampant
TechPress. 680 p.
CENTER, Next Generation. Grid Computing. http://www.nextgenerationcenter.
com/v3/web/download.php?curso_id=58. 10 de Dezembro de 2008.
COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim. Sistemas
Distribuídos: Conceitos e Projetos. Tradução: João Tortello. 4. ed. Porto Alegre:
Bookman, 2007. 784 p.
FARIA, Rogério Amorim de. Treinamento Avançado em XML. São Paulo:
Digerati Books, 2005. 126 p.
FERREIRA, E. C.; SANTOS, A. F. P. dos; SCHULZE, B. Distribuição de
Processos em Ambiente de Grid. http://arquivosweb.lncc .br/pdfs/relatorio-31-03.pdf. 03
de Dezembro de 2008.
Guia de Estrutura e Administração do Ambiente de Cluster e Grid.
http://guialivre.governoeletronico.gov.br/guiaonline/downloads/guiacluster.pdf.
30
de
Dezembro de 2008.
JUNIOR, Tercilio Stedile. Um Modelo para Compartilhamento de Bases de
Dados Distribuídas e Heterogêneas. http://www.tede.ufsc.br/teses/ PGCC0679 .pdf. 13 de
Dezembro de 2008.
KUROSE, James F; ROSS, Keith W. Redes de Computadores e a Internet: Uma
abordagem top-down. Tradução: Arlete Simille Marques. 3. ed. São Paulo: Pearson
Addison Wesley, 2006. 634 p.
MATTOSO, Marta; ZIMBRÃO, Geraldo; LIMA, Alexandre A. B.; BAIÃO,
Fernanda; BRAGANHOLO, Vanessa P.; AVELEDA, Albino A.; MIRANDA, Bernardo;
ALMENTERO, Bruno Kinder; COSTA, Marcelo Nunes. ParGRES: Middleware para
Processamento Paralelo de Consultas OLAP em Clusters de Banco de Dados.
http://www.dcc.ufrj.br/~braganholo/artigos/mattoso2005-sbbd-demos.pdf. 16 de Dezembro
de 2009.
99
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de Banco de Dados. 4. ed.
São Paulo, Pearson Addison Wesley, 2005. 724 p.
NOGUEIRA, Rui Miguel Silvestre Matos. Viabilidade RAC Oracle10g + Linux /
Benchmarking Linux VS Windows 2003. http://www.di.fc.ul.pt/disciplinas/pei/pei0506/
conteudo/documentos/rels_finais/0506rfinal_23052.pdf. 30 de Novembro de 2008.
OLIVEIRA, C. H. P. de. Tecnologia de Grid Computing utilizando Banco de
Dados Oracle. http://www.niee.ufrgs.br/eventos/CBCOMP/2004/mini_curso/MiniCurso
%2005.pdf. 28 de Novembro de 2008.
RAMAKRISHNAN, Raghu; GEHRKE, Johannes. Sistemas de Banco de Dados.
Tradução: Acauan Pereira Fernandes, Celia Taniwaki, João Tortello. 2. ed. São Paulo:
McGraw-Hill, 2008. 884 p.
SLONY. Slony-I. http://www.slony.info/. 30 de Dezembro de 2008.
SLONY. Introducing Slony. http://onlamp.com/pub/ a/onlamp/2004/11/18/
slony.html. 30 de Dezembro de 2008.
TANENBAUM, Andrew S. Sistemas Operacionais Modernos. Tradução: Ronaldo
A. L. Gonçalves, Luís A. Consularo. 2. ed. São Paulo: Pearson Prentice Hall, 2003. 695 p.