1. Projeto de Banco de Dados Distribuído

Trabalho de Banco de Dados
Distribuído
Tópico: Banco de Dados Ingres
Grupo
Antonio Chiacchio Petruccelli
Denis Calixto
Eric Sander
1
ÍNDICE
Página
1.
Projeto de Banco de Dados Distribuído .................................................................................................. 3
a) Suporte a Fragmentação (Horizontal, Vertical, Híbrida) ........................................................................ 3
b) Mecanismos de Replicação .................................................................................................................... 3
Vantagens de se utilizar o Ingres/Replicator : ............................................................................................ 4
Tipos de Réplica ......................................................................................................................................... 4
Diferenças entre o Ingres/Replicator e o Ingres/Star. ................................................................................. 5
Resumo de Replicação ............................................................................................................................... 6
2.
Controle de Ambiente Distribuído.......................................................................................................... 9
a) Gerenciamento de View ......................................................................................................................... 9
b) Controle de Segurança ........................................................................................................................... 9
c) Controle de Integridade .........................................................................................................................10
3.
Transparência ........................................................................................................................................11
a) Distribuição ...........................................................................................................................................11
b) Replicação .............................................................................................................................................11
c) Fragmentação ........................................................................................................................................11
4.
Processamento Distribuído de Consulta ................................................................................................12
a) Suporte ao Processamento Distribuído de Consulta ..............................................................................12
b)Tipo de Otimizador de Consulta Utilizado .............................................................................................12
c) Mecanismos de Otimização de Consulta Distribuída ............................................................................12
2
1. Projeto de Banco de Dados Distribuído
a) Suporte a Fragmentação (Horizontal, Vertical, Híbrida)
O Banco de Dados Distribuído Ingres não suporta as fragmentações. A sua
unidade de distribuição é a relação. Não há uma fragmentação, já que os dados podem ser
encontrados em vários servidores remotos. Consideramos isso uma replicação
fragmentada dos dados.
O gráfico abaixo demonstra isso graficamente:
Iremos ver com mais detalhes nos mecanismos de replicação o conceitos de
organização de dados replicados utilizando o Ingres/Replicator que são: Consistent
Distributed Data Set (CDDS) - Consistência de conjunto de dados distribuídos.
b) Mecanismos de Replicação
O Ingres possui o Ingres/Replicator. É um componente utilizado para fazer a
réplica assíncrona dos dados por transação. O Ingres/Replicator é transparente para o
usuário já que ele está entre o banco de dados e a aplicação. A integridade dos dados é
reforçada pelo protocolo Two-Phase Commit. Os dados de uma transação só estão
disponíveis para uma replicação após a transação ser comitada localmente. Isso garante a
integridade dos dados no caso de uma falha em algum ponto do sistema distribuído.
O Ingres/Replicator permite que o usuário atualize o banco de dados local em um
modo assíncrono, tornando-o transparente para o usuário local. O Ingre/Replicator
3
percorre cada réplica a ser feita e utilizando o protocolo Two-Phase Commit direciona
essa transação para o banco de dados a ser replicado. O protocolo Two-Phase Commit
garante que todas as réplicas serão feitas. Caso haja algum problema durante o TwoPhase Commit, essa solicitação será refeita. Caso algum dos bancos de dados a ser
replicado caia, todas as réplicas que seriam feitas nesse banco serão mantidas em espera e
enviadas na ordem correta assim que o banco estiver no ar.
Vantagens de se utilizar o Ingres/Replicator :

Melhora na performance
Reduz o tráfego de rede e evita o acúmulo de solicitações a um determinado banco de
dados (evitando o gargalo).

Tolerância a Falhas
Caso algum servidor saia do ar, o dados poderá estar disponível em outro servidor. Caso
dois banco de dados se tornem inconsistentes, o Ingres/Replicator tem recursos de
reconciliá-los que funciona em conjunto com o procedimento de recuperação. Já que os
dados estão localizados em mais de um local, a perda de dados em uma máquina não é
catastrófica.

Flexibilidade
Com as constantes anterações nos ambientes de bancos de dados, o Ingres/Replicator
oferce soluções de conectividade. Se o seu sistema opera sobre diferentes bancos de
dados, você pode usar o Ingres/Replicator para conectá-los. O Ingres/Replicator opera
com banco de dados que não são Ingres utilizando o produto que fornece um gateway
entre os diferentes bancos; o Ingres/Enterprise Access. Você poderá manter os seus
sistemas legados ou usar o Ingres/Replicator para fazer um controle completo de
migração para um sistema de banco de dados Ingres. Os usuários dos sistemas legados
poderão ter acesso à dados criados em outros ambientes heterogênios.
Tipos de Réplica
O Ingres/Replicator fornece um controle significativo sobre o fluxo de dados.
Você pode configurar o Ingres/Replicator para satisfazer suas necessidades utilizando o
Consistent Distributed Data Set (CDDS) - Consistência de conjunto de dados
distribuídos.
O CDDS é um conjunto de daods que é mantida consistente (idêntica) em dois ou
mais bancos de dados. O CDDS provê um método de definição e agrupamento de dados,
de modo que um banco inteiro ou partes de bancos de dados possam ser replicados para
diferentes sites. (vide gráfico reproduzido no ítem 1a.)
O CDDS fornece ao banco de dados distribuído a disponibilidade de fazer a
réplica de dados de acordo com as necessidades do negócio (empresa).
O CDDS consiste de :
a) Qual dado a ser replicado
4
Pode-se replicar qualquer tipo de combinação abaixo:
– Todo o Banco
– Conjunto de tabelas
– Conjunto de Colunas (particionamento vertical)
– Conjunto de linhas (particionamento horizontal baseado em um valor
específico )
b) Para aonde a réplica vai
Pode-se configurar o Ingres/Replicator para que o dado seja replicado:
– Em uma direção com um alvo específico (Central-to-Backup : Mater Slave)
– Em uma direção com alvos variados
– Em duas direções entre dois bancos de dados (Peer-to-Peer)
– Em várias direções em alguns bancos de dados (Central-to-Branch)
– Uma combinação dessas opções
c) Por qual caminho a réplica é feita
Deve-se especificar o caminho (rota) que o dado replicado deve fazer para chegar
ao seu alvo.
d) Quando o dado será replicado
Pode-se especificar quando o Ingres/Replicator deve propagar os dados ;
Continuamente, Um vez ao dia ou sobre demanda.
e) Que tipo de banco pode ser usado
Pode-se usar o banco de dados Ingres de qualquer forma utilizando o
Ingres/Replicator. Alguns bancos de dados Ingres/ Enterprise Access (gateways)
podem ser usados tanto como fonte quanto quanto alvo; outros, entretanto,
podem ser usados somente como banco de dados alvo com a capacidade de readonly.
Diferenças entre o Ingres/Replicator e o Ingres/Star.
Tanto o Ingres/Replicator quanto o Ingres/Star mantêm os dados entre dois ou
mais bancos de dados distribuídos. No Ingres/Star usa o protocolo Two-Phase Commit
entre o banco local e o remoto. Durante a atualização de um usuário local, o Ingres/Star
bloqueia os dados no banco de dados local e remoto e não libera esse bloqueio enquanto
o protocolo de Two-Phase Commit for completado com sucesso. Esse bloqueio pode
gerar atrasos para o usuário local.
Já o Ingres/Replicator atualiza os dados do banco de dados local de um modo
assíncrono, a aí faz o bloqueio em cada banco de dados remoto utilizando o protocolo
5
Two-Phase Commit. Portanto resultará em um ganho significante de performance
utilizando o Ingres/Replicator ao invés do Ingres/Star.
Com o Ingres/Replicator pode-se customizar o ambiente de replica que não
acontece no Ingres/Star. Como o Ingres/Star, um transação é completada em todos os
bancos de dados ou em nenhum. Já com o Ingres/Replicator dois usuários poderão
atualizar o mesmo dado em diferentes bancos de dados replicados, podendo causar assim
um problema de colisão.
Resumo de Replicação
Cada vez que uma tabela registrada no banco de dados para replicação for
manipulada, a replicação desta tabela será executada seguindo os passos abaixo:
1. O usuário atualiza o banco no servidor local.
2. O Change Recorder atualiza a tabela shadow.
3. O Change Recorder atualiza a tabela archive.
4. O Change Recorder aiciona uma linha ao input queue.
5. Depois de ser comitada, as threads de distribuição lêem o input queue e a
tabela de caminhos de popagação (propagation paths table) para determinar como
e onde o dados devem ser replicados.
6. As threads de distribuição atualizam o distribution queue com a replicação e a
informação do destino.
7. As threads de distrubuição deletam a replicação do input queue.
8. As threads de distribiução alertam um servidor de Réplica.
9. O Servidor de Réplica (Replicator server) lê o distribution queue.
10. O Servidor de Réplica atualiza o banco de dados remoto utilizando SQL
remoto ou porcedures de banco de dados.
11. Se o servidor remoto for full peer ou protected read-only target, o Replicator
server atualiza a tabela shadow correspondente.
12 Se o servidor remoto for full peer target, o Replicator atualiza a tabela archive
correspondente.
13. Se o servidor remoto for full per target, uma linha é adicionada no input
queue remoto.
14. A linha é deletada do distribution queue do banco de dados local.
O Replicator server apaga a linha correspondente do distribution queue local.
15. As alterações no banco de dados remoto e local são serguradas utilizando o
two-phase commit.
O gráfico abaixo ilusta cada um desse passos:
6
Base Table
The base table is the table manipulated by the
user.
Shadow Table
The shadow table maintains a history of previous
transactions. It contains a row for each row in the
base table that has been manipulated. Shadow
table rows include the system-generated replicated
transaction key for that manipulation, plus the
previous replicated transaction key, along with the
base table’s designated unique key.
Note: Shadow tables are used only in full peer or
protected read-only targets.
7
Archive Table
The archive table contains the “before-images” of
rows that have been updated or deleted. Archive
table rows include all the replicated columns of
the base table, along with the replication key of
the manipulation that altered that row. Each row
in the archive table corresponds to a row in the
shadow table.
Note: Archive tables are used only in full peer
targets.
Input Queue Table
The input queue table contains a transient entry
for each row manipulated in a replicated table.
Distribution Queue Table
The distribution queue table contains a transient
entry for each replicated row that is to be
transmitted to another database. It contains the
identifier of the target database.
8
2. Controle de Ambiente Distribuído
Um Banco de Dados distribuído pode ser composto por tabelas, visões,
procedures e índices no banco de dados Ingres local, banco de dados Ingres remoto e
banco de dados que não sejam Ingres que podem ser acessados pelos produtos de
Entreprise Access.
O Ingres/Star permite o acesso à bancos de dados diversos simultaneamente. O
usuário não precisa saber onde o dado está localizado. Combinando o Ingres/Star com o
Ingres/Net permite à usuários o acesso a banco d dados locais quanto remotos, não
importanto onde eles estão localizados na rede. Você pode efetuar operações complexas
como joins e subselects entre DB2 e IMS, o que seria muito difícil sem a utilização do
Ingres/Star.
Quando o banco de dados distribuído é criado, o Star cria o Star Catalog que é o
catálogo responsávbel pela coordenação de acesso à todos os dados. O Star Catalog é
uma coleção de tabelas que guardam informações sobre o banco de dados distribuído. Ele
descreve cada banco de dados local que faz parte do banco de dados distribuído quanto os
objetos do banco de dados distribuído.
Combinando o Ingres/Star, Net e o Enterprise Access o acesso à banco de dados
que não são Ingres será possível simultaneamente em qualquer ponto da rede. O ambiente
distribuído heterogêneo será explicado posteiormente.
a) Gerenciamento de View
As views também são objetos registrados no banco de dados distribuídos.
Portanto elas também estarão registradas no Star Catalog. A utilização da view no Ingres
é semelhante à utilizada em outros sistema distribuídos. No Ingres, não é aconselhado a
utilização de views para atualizar as tabelas às quais ela referencia. OBS: Essa é uma
particularização da utilização de views no Ingres
b) Controle de Segurança
9
Os usuários do Star devem estar autorizados no banco local quanto no remoto
que eles querem acessar. Os componentes Netutil e o Ingnet podem também fornecer essa
autorização. Use o Netutil (Network Autorization and Connection Information) ou o
Ingnet no servidor local para definir o login de autorização para sua conta em um
servidor remoto.
Os usuários devem definir sua senha de acesso local e a senha de acesso remoto
somente uma vez. Essa autorização será mantida até o momento que os usuários decidam
apagá-la.
Além da utilização do Netutil e Ingnet, pode-se haver uma outra estratégia de
segurança quando utilizamos o Ingres/Net. Nesse caso o usuário deverá ter acesso à rede
pela qual ele deve trafegar para chegar ao servidor remoto, além do acesso no banco de
dados.
A segurança que já existe no banco de dados é considerada da mesma forma no
sistema distribuído utilizando a idéia de grupos e regras.
c) Controle de Integridade
O Ingres/Star não implementa integridade. No caso do dado estar localizado em
múltiplas localizações, o particionamento por essas várias localidades é controlado pelo
banco de dados local. Se for preciso uma obter algum dado de integridade de um objeto
registrado, faça um direct connect para o banco de dados local apropriado e faça uma
query no catálogo padrão.
Quando utilizamos o Ingres/Replicator o controle de integridade é feito através
de um mecanismo de detecção de colisões. Mas podem existir situações que no caso de se
estar utilizando integridade referencial de constraints, pode criar conflitos que não
poderão ser resolvidos.
Por exemplo se um registro de consumidor for deletado em um banco de dados
,mas no mesmo momento um novo pedido é registrado para aquele determinado
consumidor em outro banco de dados. Se existir integridade referencial por constraints
referenciando o consumidor, vai então haver um problema quando o dado for replicado
para outro banco de dados.
A melhor maneira de se evitar a colisão e a prevenção. Projete o seu sistema de
réplica com o objetivo de reduzir a probabilidade de colisão. Mesmo em sistemas de
banco de dados bem projetados pode existir colisões durante um erro no sistema quando
se é necessário toca entre bases replicadas. Por essa razão , deve-se planejar como se
tratar colisões em um sistema de replicação.
10
3. Transparência
a) Distribuição
O Ingres possibilita o usuário a ver todos os sites como apenas um data source
lógico, eliminando a necessidade de saber onde está o dado. Como funciona: cria-se um
banco de dados virtual composto por todos os data sources ligados a todos os sites onde
pelos quais o banco está distribuído. Assim, todos os data sources aparecem copmo se
fossem apenas um banco gigantesco. Dessa forma, os desenvolvedores de aplicações e
usuários em geral podem executar suas consultas sem saber onde estão localizados os
dados. O componente encarregado disso é o Star, que coordena o banco de dados
distribuído. Todavia, essa transparência só é visualizada pelo usuário final.
Desenvolvedores de aplicação em geral precisa, através de linha de código, se conectar
ao bando de dados onde estão as informações com as quais ele quer trabalhar.
b) Replicação
O Ingres implementa transparência de replicação através do Ingres/Replicator,
um componente que faz parte do SGBD que cuida de tudo relacionado a replicação. O
Ingres/Replicator se porta como uma camada entre o banco de dados e a aplicação, sendo
transparente ao usuário. Quando um usuário faz uma consulta ou atualiza uma tabela, o
Ingres/Replicator cuida para que esse usuário não precise atualizar cada réplica existente
desse banco, bem como não mostra ao usuário se o conjunto resposta veio de uma réplica
ou do banco original.
c) Fragmentação
Não foi encontrado nenhum documento falando sobre transparência de
fragmentação no Ingres, a não ser durante a otimizaçao de uma consulta, quando a
consulta é quebrada em fragmentos (não visíveis ao usuário, que acha que a consulta está
sendo executada localmente) e cada fragmento é resolvido por um site responsável, sendo
coordenados pelo site de onde partiu a consulta.
11
4. Processamento Distribuído de Consulta
a) Suporte ao Processamento Distribuído de Consulta
Star tem suporte para otimização distribuída de consulta, escolhendo o mais
eficiente acesso ou plano de consulta entre os diferentes bases de dados e diferentes nós
da rede. Enquanto o plano de consulta está sendo desenvolvido, o Star tem a habilidade
de mover tuplas de dados de um site para outro com o intuito de maximizar os recursos
do processamento ao mesmo tempo que minimiza a movimentação de dados. O Star é
capaz de analizar variações nos fatores de custo de transmissão entre nós da rede e tempo
de processamento da CPU, bem como escolher quando e para onde (ou de onde)
transferir dados em busca de uma performance ótima.
b)Tipo de Otimizador de Consulta Utilizado
Heurística. O Ingres possui um componente chamado Ingres Query Optimizer
(que no caso do banco de dados distribuído é utilizado pelo do Star), que se utiliza de
informações básicas tais como tamanho da tabela, número de tuplas, chaves primárias e
índices definidos, mas também se utiliza de informações mais específicas como
quantidade de dados duplicados (recuperados através de estatísticas geradas) em uma
coluna e tráfego de rede (através do componente Ingres/Net).
c) Mecanismos de Otimização de Consulta Distribuída
O Star mantem dados estatísticos em um catálogo chamado iistatistics e dados a
respeito do banco distribuição em uma tabela chamada iihistograms. Quando o Query
Optimizer avalia uma query, ele gera um QEP (Query Execution Plan) mostrando como a
query será executada. Uma vez que o QEP foi gerado, ele pode ser usado uma ou mais
vezes para executar a mesma query. Como geralmente existem outras maneiras de se
otimizar uma query, escolher o melhor QEP causa um dano à performance. Por isso, o
Star te possibilita visualizar um gráfico desse QEP, sendo assim possível detectar um
problema na performance. Agora, dependendo da própria query, o Query Optimizer pode
gerar mais de um QEP. Queries contendo subqueries, Union, Group By e/ou Views que
precisam ser montadas são os casos. O site de onde parte a consulta determina como será
feita a consulta. Logo, é híbrido.
12
5. Processamento Distribuído de Transação
Two-Phase Commit
Fase 1
Se alguma parte da fase 1 falhar, por exemplo, se o Star perder a conexão com
um nó antes de todos os bancos de dados estarem preparados para comitar, o Star
dá um roll back sobre a transação em todos os sites, inclusive naqueles que já
estão prontos para comitar.
Fase 2
Se a conexão a um banco de dados local for perdida entre o tempo que o Star
decide comitar e o tempo que o banco de dados local de fato acata aquela
instrução, Star continua tentando completar a transação até a conexão ser
restaurada e o commit efetuado. Star não retorna o controle ao usuário final até
que todos os nós tenham comitado. Se alguma parte da fase 2 falhar, o Star ainda
assim comita a transação.
Quando O Two-Phase Commit Não É Usado
Nem todas as transações distribuídas requerem o two-phase commit. Por exemplo, uma
transação que não atualiza, ou que atualiza apenas um banco de dados, não requer coordenador
entre os bancos de dados. Neste caso, Star usa o single-phase commit que consiste no envio de
mensagens de commit para cada banco de dados.
As vezes uma transação distribuída não pode usar o protocolo de two-phase commit pelo
fato de um dos bancos de dados não envolvidos não suportá-lo.
Tais bancos de dados ainda podem participar em uma transação distribuída se seus dados
não são atualizados, ou se os bancos de dados estão no único site que está sendo atualizado em
uma transação. Se um único site não capaz do two-phase commit estiver envolvido em uma
atualização de múltiplos sites, o Star simulará o two-phase commit.
Simulação do Two-Phase Commit
No caso onde uma atualização é realizada para um site que não é capaz do two-phase
commit e onde uma transação de atualização em múltiplos sites é requerida, o Star simula o twophase commit. Ele faz isso primeito enviando um prepare-to-commit para todos os sites que são
capazes desse protocolo, então enviando um commit para o site individual que não é capaz do
two-phase commit, e finalmente enviando commits para todos os outros sites preparados. Note
que o Star apenas suporta a simulação do two-phase commit quando um site individual não capaz
do two-phase commit está envolvido numa atualização de sites múltiplos. Se mais de um site não
é capaz do two-phase commit é atualizado, o Star se recusa a atender a atualização.
Utilitário StarView
13
O Star tem um utilitário gerenciador de banco de dados distribuído chamado StarView, o
qual permite ao administrador de banco de dados do Star:



Obter informação sobre os nós, bancos de dados e tabelas que constituem um banco de dados
distribuído.
Testar as conexões de rede entre os nós no banco de dados distribuído.
Registrar tabelas locais num banco de dados distribuído e remover estes registros.
6. Suporte a acesso a dados de SBBD Heterogêneos
O Ingres dá suporte a cesso a dados de banco de dados que não sejam Ingres atra’ves
dos compenentes Ingres/Star, Ingres/Net e Enterprise Access. No final desse
documento consta um apêndice dando mais detalhes sobre o funcionamento de cada
um desses componentes.
Bancos de Dados que Acessa:





Oracle
Sybase
Sql Server
Informix
DB2
Apêndice: Ingres/Star (Gateway)
É um gerenciador de dados que adiciona ao Ingres a capacidade de um sistema de banco
de dados relacional distribuído, o qual inclui acesso, armazenamento e processamento distribuído.
Ele faz com que se combine um número de bancos de dados separados para criar uma simples
view de seus dados, que é acessada como se fosse um simples banco de dados local.
Qual produto do Ingres deve ser usado:

Para acesso local aos dados
Apenas o Ingres

Para acesso remoto aos dados
Quando seu computador faz parte de uma rede, Net permite acessar um simples banco de
dados armazenado em um outro computador pelo seu computador local.

Para acesso a dados heterogêneos
O Enterprise Access permite acessar dados armazenados em bancos de dados nãoIngres.
14

Para acesso a dados distribuídos
Star dá acesso a múltiplos bancos de dados simultaneamente. Não é preciso saber onde os
dados requisitados estão. Os outros bancos de dados e suas configurações são invisíveis.
Trabalha transparentemente com o banco de dados distribuído Star como se ele fosse um
banco de dados local Ingres no seu próprio computador.
Star + Net
Dá acesso remoto como se fossem bancos de dados locais, não importando em que lugar da
rede estes bancos de dados estão armazenados.
Star + Enterprise Access
Permite o acesso a ambos os bancos de dados Ingres e não-Ingres, ou mesmo diferentes tipos
de banco de dados não-Ingres.
Star + Net + Enterprise Access
Permite o acesso a ambos os bancos de dados Ingres e não-Ingres simultaneamente, em
qualquer lugar da rede.
Sintaxe de Acesso Distribuído:
IngresCommand [vnode.:]distdbname/server_class
Deve ser especificado um nome vnode se o banco de dados distribuído reside num nó remoto.
Deve ser especificado o server_class como /star para significar que está acessando um banco
de dados distribuído pelo servidor Star.
ARQUITETURA DO STAR
Catálogos do Star
Quando é criado um banco de dados distribuído, o Star cria catálogos para coordenar o acesso
a todos os dados. Esses catálogos são coleções de tabelas que armazenam informações sobre
banco de dados distribuído. Ele descreve todo banco de dado local que é componente de um
banco de dados distribuído, assim como os objetos do banco de dados distribuído.
Componentes
15

Um banco de dados coordenador
Um banco de dados coordenador contém os catálogos que o servidor Star usa para guardar
rotas de objetos distribuídos. Quando um usuário requisita informação, o servidor Star acessa
o banco de dados coordenador e associa bancos de dados locais via o servidor local SGBD
para pegar a informação.

Entradas nos catálogos de definição de instalação
Estas entradas contém informações que definem cada banco de dados distribuído e banco de
dados coordenador na instalação, e mostra que banco de dados coordenador é associado com
que banco de dados distribuído. Ele também contém informação de configuração que permite
o Star processar eficientemente as consultas.

Link opcional de usuário específico para dados em outros bancos de dados
Links opcionais para outros dados são gerados pelo registro como statement link. Quando
registra dados existentes para um banco de dados distribuído, informações sobre a localização
dos dados são adicionadas aos catálogos específicos do Star no banco de dados coordenador.
Diagrama de como o Star acessa os dados:
O Star recebe requisições de dados por múltiplos clientes e passa essas requisições de
dados para um servidor local de SGBD. (O servidor Star nunca acessa diretamente dados de um
banco de dados). O servidor local de SGBD pode suportar acessos simultâneos de usuários à
banco de dados locais e consultas do servidor Star. O SGBD local acessa seu banco de dados e
retorna os resultados. O Star retorna os resultados da consulta distribuída para a aplicação.
16