Escolar Documentos
Profissional Documentos
Cultura Documentos
Banco de Dados
I. INTRODUO
1
Heliomar Q. Lordo (heliomar_loredo@hotmail.com), Lindemberg N.
Ferreira
(lnaffah@dcc.ufmg.br)
e
Guilherme
T.
de
Assis
(gtassis@dcc.ufmg.br) so, respectivamente, aluno, professor e coordenador
do curso de ps-graduao em banco de dados do do Centro Universitrio de
Belo Horizonte - UNI-BH, Belo Horizonte, Minas Gerais, 30180-111.
53
Banco de Dados
observar se os pontos de acesso a dados realizam apenas
consultas ou se realizam consultas e atualizaes, se as
operaes poderiam ser realizadas off-line e sincronizadas
posteriormente e se esse procedimento provocaria excessivas
situaes de conflito.
Deve-se avaliar, tambm, a necessidade de autonomia de
acesso aos dados para os bancos que estariam envolvidos na
soluo, qual a quantidade de transaes presentes nas
operaes de atualizao e se essas transaes envolveriam
mais de um fragmento de dados.
Outro aspecto importante o custo de implementao do
ambiente BDD com replicao assncrona, se comparado a
uma soluo centralizada. Em algumas propostas de
implementao de BDD, os custos envolvidos com aquisio
de SGBD e softwares de controle de replicao podem ser
determinantes para a rejeio da proposta.
Aplicaes que dependem de grande desempenho,
autonomia, flexibilidade e escalabilidade, que so executadas
em computadores pessoais e que apresentam algum grau
independncia de acesso a dados so grandes candidatas ao
uso de BDD com replicao assncrona.
A fim de ilustrar o processo de definio e escolha das
tcnicas de BDD para uma aplicao, considere o cenrio da
Figura 1. Essa uma aplicao projetada com base na
arquitetura de trs camadas, com uso de banco de dados
centralizado e com estaes clientes que possuem apenas um
navegador (browser) e que no dispem de bancos de dados
locais, servidores de aplicao ou regras de negcio.
Considere a necessidade de maior desempenho nas operaes
de consulta e atualizao realizadas nas estaes clientes, a
disperso geogrfica entre as mquinas e uma estreita relao
entre a localizao geogrfica das estaes e os dados
acessados por elas. Nesse cenrio, na maioria das vezes, os
dados so de interesse particular de cada estao cliente.
Porm, eventualmente, alguma estao poderia consultar ou
atualizar um dado de interesse comum a outras estaes.
Considere, ainda, que algumas operaes so implementadas
por transaes. A Figura 1 mostra tambm a heterogeneidade
de tecnologia de interligao utilizada nessa aplicao, que
tira proveito da Internet.
.
Cons ultas /
atuali zaes
SGBD
propriet rio
Conexo dedicada
512 K
Dial 56K
Navegador
Servidor
de
Apli cao
Satlite 128K
Navegador
54
Banco de Dados
Dada a escolha do modelo de replicao assncrona, devese considerar a possibilidade de conflitos e a dificuldade de
manuteno da semntica transacional. De acordo com o
cenrio descrito nesta seo, as estaes clientes, futuros sites
no modelo de BDD, podem realizar atualizaes nos dados.
Segundo BURETTA [4], as propriedades ACID de uma
transao no so garantidas quando se implementa replicao
assncrona com possibilidade de atualizaes em qualquer
site. De fato, quando considerado o aspecto global do sistema,
podem ocorrer conflitos que ferem as propriedades ACID.
Portanto, a semntica transacional de uma operao s pode
ser mantida quando considerada sua execuo local. No
momento de sua propagao, os conflitos devem ser
detectados e tratados a nvel global.
Segundo KEMME & ALONSO [6], freqente deixar a
cargo da aplicao usuria a tarefa de manter a consistncia,
procedimento adotado no cenrio em questo.
BURETTA [4] apresenta opes de atualizaes
completas, incrementais ou por propagao delta de eventos
para a implementao da replicao assncrona. No cenrio da
Figura 1, mencionou-se que algumas operaes so
implementadas por transaes. Desta forma, a opo mais
adequada seria a propagao delta de eventos, pois, segundo a
referida autora, essa a estratgia de replicao capaz de
preservar as fronteiras de uma transao ou conjunto de
transaes.
No modelo de BDD, cada estao cliente presente no
modelo de trs camadas descrito em nosso cenrio, seria,
resumidamente, um site com software local e um banco de
dados com suporte ao processamento de transaes. Percebese aqui a necessidade de se determinar qual SGBD seria
utilizado para gerenciar os bancos presentes em cada site.
Diz-se que feita replicao entre bancos de dados
homogneos quando todos os sites participantes possuem o
mesmo SGBD. Porm, com o intuito de no deixar a aplicao
dependente de um nico fornecedor, trabalhar com mais de
uma opo de suporte, ganhar em flexibilidade e
portabilidade, algumas implementaes lidam com replicao
entre bancos de dados heterogneos, em que os SGBD so
diferentes entre os sites.
No cenrio proposto, optar-se- pelo uso de replicao
entre bancos de dados heterogneos. Note que, no exemplo, o
servidor central usa SGBD proprietrio. Destacou-se, no
incio dessa seo, o risco de que os custos envolvidos com
aquisio de SGBD e softwares de controle de replicao
proprietrios inviabilizassem o uso de BDD. Uma opo
vivel para no enfrentar problemas relacionados ao custo,
seria, no cenrio apresentado, manter o SGBD proprietrio j
existente no servidor central e utilizar um SGBD gratuito entre
os demais sites.
Optou-se, ainda, por replicao procedural, propagando-se
os procedimentos a serem executados no lugar de propagar
dados.
De forma resumida, a arquitetura de BDD seria
implementada, nesse exemplo, a partir de replicao parcial,
assncrona, com propagao delta de eventos, procedural,
55
Banco de Dados
BANCO DE DADOS LOCAL: banco de dados onde so
armazenados os dados do negcio. Pode haver um ou mais em
cada site presente na aplicao.
CAPTURA: componente responsvel por capturar as
transaes provenientes da aplicao, aplicar no banco local e,
caso seja uma operao que deve ser replicada, armazenar na
fila de transaes mantendo a ordem original de sua execuo.
CATLOGO DE REPLICAO: banco de dados,
presente apenas no servidor mestre, que contm os dados
sobre a replicao. Armazena quais so os sites envolvidos,
quais as rplicas presentes em cada um dos sites, o histrico
de falhas e sucessos durante a distribuio de dados, qual o
atraso de propagao configurado para cada site, quais aes
devem ser tomadas em caso de falha, etc.
ESCALONA PROPAGAES: componente responsvel
por popular a tabela denominada agenda. A partir de consultas
ao catlogo de replicao, com o conhecimento da distribuio
das rplicas dos fragmentos pelos sites e a partir do uso de
triggers, grava na agenda a indicao dos sites que devem
receber as transaes no momento em que se conectarem para
sincronizar os dados.
EXECUTA SNAPSHOT: componente executado quando
um site escravo no sincroniza os dados com o mestre por
tempo muito superior ao configurado; busca, no banco de
dados local do mestre, os valores atuais de todos os
fragmentos que devem ser replicados para o escravo que est
realizando a sincronizao em momento indevido; utilizado,
tambm, no momento em que um novo site escravo ingressa
no esquema de replicao, promovendo a primeira carga de
dados desse novo site.
FILA DE TRANSAES - FT: tabela que armazena as
transaes que sero replicadas para outros sites.
FILA DE TRANSAES REPLICADAS - FTR: tabela
que armazena as transaes originadas de outros sites e que
devero ser aplicadas localmente.
PROPAGA: componente responsvel por transferir o
contedo da FT do site onde o dado foi atualizado para a FTR
dos sites escravos que recebero a sua rplica. Tambm
transfere o contedo da FT dos sites escravos para a FT do
site mestre.
Os componentes e as tabelas de dados apresentadas
anteriormente esto organizados, no processo de replicao de
dados, conforme a Figura 2.
SIT EMEST RE
SIT E ESCRAVO
PROPAGA
APLICA O
TRANSAES
CAPTURA
FILA DE
TRANSAES
REPLICADAS - FTR
ESCALONA
PROPAGA ES
AGENDA
CATLOGO DE
REPLICAO
FILA DE
TRANSAES - FT
FILA DE
TRANSAES - FT
ATUALIZA
MESTRE
PROPAGA
BANCO DE DADOS
LOCAL - Livre
EXE CUTA
SNAPSHOT
BANCO DE DADOS
LOCAL - Proprietrio
56
Banco de Dados
cinco e seis. Na prxima vez em que este mesmo site iniciar
um processo de sincronizao, desde que dentro do prazo
configurado para que ocorra a replicao, todos os passos
sero executados.
IV. RESULTADOS
Este artigo no apresenta medidas de desempenho da
soluo implementada. Contudo, foi possvel acompanhar
empiricamente o comportamento de uma aplicao comercial
que emprega a arquitetura proposta, utilizada em uma empresa
cuja identidade no ser revelada, a pedido da mesma.
O cenrio da empresa em questo era muito parecido com o
da Figura 1: banco de dados central, estaes clientes que
acessavam a aplicao com o uso de um navegador (browser)
e se conectavam ao servidor por intermdio da Internet.
As estaes clientes da referida empresa estavam
localizadas em cidades do Rio Grande do Sul, So Paulo,
Minas Gerais e Rio de Janeiro. Havia 47 estaes conectadas
a um servidor localizado em So Paulo. Havia variaes entre
as configuraes de hardware das estaes, mas em geral, os
computadores eram compostos de processadores Intel Pentium
II, com 128 Megabytes de memria RAM, adaptadores de
modem, rede, som e vdeo off-board. O sistema operacional
dessas estaes era o Windows 98 Segunda Edio. A
conexo com a Internet dependia da tecnologia encontrada em
cada um dos locais onde as mquinas estavam instaladas. A
grande maioria delas se conectava a partir de conexo dial-up,
mas algumas se valiam de conexo ADSL.
O servidor central de banco de dados da empresa em exame
estava localizado em So Paulo, ligado Internet via conexo
dedicada, com taxa de transferncia de 512 Kbps (quilobits
por segundo). O SGBD utilizado nesse servidor era o
SQLServer 2000.
Estudou-se detalhadamente a aplicao da empresa sub
examine, a fim de avaliar se o uso de replicao assncrona
seria realmente indicado. As condies do negcio da empresa
favoreciam o teste. Ademais,
a direo da referida
organizao determinou sua equipe de engenheiros de
software que buscasse uma nova tcnica que garantisse maior
desempenho, disponibilidade e diminusse os custos
relacionados s conexes discadas. Por conseguinte, optou-se
por migrar o banco de dados centralizado para um banco
distribudo, com o uso de replicao assncrona, desde que
fossem garantidos a diminuio de custos, a melhoria do
desempenho e um rpido retorno ao sistema centralizado, caso
a migrao no fosse bem sucedida.
Optou-se pelo uso de MySQL nos sites escravos e
manteve-se o SQLServer 2000 no site mestre.
Implementado o ambiente descrito na Seo III,
acompanhou-se o desempenho dos sites escravos e do
servidor, observando-se que os primeiros se comportaram bem
no que diz respeito ao desempenho e autonomia adquirida
com o modelo implementado.
O principal problema observado nos sites escravos dizia
respeito conexo. Freqentemente a conexo era
interrompida enquanto estava ocorrendo o processo de
57
Banco de Dados
resultados apresentados tm sido satisfatrios, principalmente
em relao queda nos custos de telecomunicaes, tendo em
vista que, anteriormente, as estaes clientes eram mantidas
conectadas durante todo o tempo. Ademais, a execuo da
aplicao no cliente resultou em desempenho superior
aplicao centralizada.
V. CONCLUSO
Neste trabalho apresentou-se uma proposta para
implementao de replicao assncrona entre bancos de
dados heterogneos. Foram comentados alguns dos trabalhos
relacionados ao tema, os quais foram comparados
abordagem que se pretendia defender.
No foram exibidos resultados experimentais tangveis,
contendo medidas obtidas a partir de experimentos efetuados
em ambiente controlado. Contudo, foi discutido um exemplo
real de implementao da proposta, que permite afirmar, a
partir dos resultados obtidos, que a proposta vivel, do ponto
de vista funcional e quanto ao desempenho. Mais que isso,
possvel dizer que a abordagem sugerida
garante
expansibilidade, portabilidade, baixo custo e ainda possibilita
o uso conjunto de sistemas de gerncia de banco de dados
livres e proprietrios, sem a necessidade do uso de gateways
ou features que viabilizem essa operao.
Algumas possveis linhas de investigao futura seriam: a)
realizao de experimentos com variveis controladas, a fim
de mensurar o desempenho e a expansibilidade da replicao,
quando implementada conforme sugesto contida neste
trabalho; b) utilizao de replicao de dados em lugar da
replicao procedural, o que permitiria a incluso de recursos
para deteco e tratamento de conflitos na soluo proposta;
c) incorporao de um tradutor de dialetos SQL na arquitetura
de replicao sugerida neste artigo.
VI. REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
Replication
in
MySQL
http://www.mysql.com/doc/en/Replication.html
MySQL
Transactions
Overview
http://www.informit.com/isapi/product_id~%7B056A857F-D4E54FAD-9AB5-1E97E2DD1C72%7D/content/index.asp
VALDURIEZ P.; ZSU M. Principles of Distributed Database Systems.
Nova Jersey: Prentice-Hall, 1999. 666p.
58