Processamento Paralelo e Distribuído em BD

Prévia do material em texto

PÓS-GRADUAÇÃO
BANCO DE DADOS E ENGENHARIA DE SOFTWARE
PROCESSAMENTO PARALELO E DISTRIBUÍDO EM
BANCOS DE DADOS
Fundamentos, projeto, implementação e arquiteturas paralelas na gerência de dados em
larga escala
2026
RESUMO
Este estudo tem por objetivo analisar os fundamentos, o projeto e a implementação dos
sistemas de banco de dados distribuídos e paralelos, evidenciando as relações entre
distribuição e paralelismo na gerência de dados. Adota-se a pesquisa bibliográfica, de
abordagem qualitativa e de caráter exploratório e descritivo, apoiada em obras de referência
das áreas de banco de dados e de sistemas distribuídos. Examinam-se as características do
sistema gerenciador de banco de dados distribuído, com ênfase nas transparências; a
fragmentação horizontal, vertical e mista e suas regras de correção; e as modalidades de
replicação. Tratam-se, ainda, as transações distribuídas, os protocolos de confirmação em duas
e em três fases, o controle de concorrência e a otimização de consultas globais, incluindo a
semijunção e a extensão dblink do PostgreSQL. Por fim, analisam-se as arquiteturas paralelas,
o particionamento de dados, o paralelismo de consultas, o balanceamento de carga e o cluster
PostgreSQL com Pgpool-II. Os resultados indicam que fragmentação e replicação constituem
o núcleo comum das duas abordagens e que a escolha das técnicas depende do perfil das
transações, do custo de comunicação e dos requisitos de consistência. Conclui-se que
distribuição e paralelismo são estratégias complementares, cuja adoção exige equilíbrio entre
desempenho, confiabilidade e complexidade de administração.
Palavras-chave: banco de dados distribuído; fragmentação e replicação; transações
distribuídas; banco de dados paralelo; cluster PostgreSQL.
ABSTRACT
This study aims to analyze the foundations, design and implementation of distributed and
parallel database systems, highlighting the relations between distribution and parallelism in
data management. It adopts bibliographic research, with a qualitative approach and an
exploratory and descriptive character, based on reference works in the fields of databases and
distributed systems. It examines the characteristics of the distributed database management
system, with emphasis on transparencies; horizontal, vertical and mixed fragmentation and
their correctness rules; and the forms of replication. It also addresses distributed transactions,
the two-phase and three-phase commit protocols, concurrency control and the optimization of
global queries, including the semijoin and the PostgreSQL dblink extension. Finally, it
analyzes parallel architectures, data partitioning, query parallelism, load balancing and the
PostgreSQL cluster with Pgpool-II. The results indicate that fragmentation and replication
form the common core of both approaches and that the choice of techniques depends on the
transaction profile, the communication cost and the consistency requirements. It is concluded
that distribution and parallelism are complementary strategies whose adoption requires a
balance between performance, reliability and administrative complexity.
Keywords: distributed database; fragmentation and replication; distributed transactions;
parallel database; PostgreSQL cluster.
SUMÁRIO
1 INTRODUÇÃO 5
2 SISTEMAS DE BANCO DE DADOS DISTRIBUÍDOS 6
2.1 Sistemas distribuídos e abordagem de banco de dados 6
2.2 Conceito e características do SGBDD 6
3 PROJETO DE BANCOS DE DADOS DISTRIBUÍDOS 8
3.1 Esquemas e abordagens de projeto 8
3.2 Fragmentação 8
3.3 Replicação, extratos e réplicas 9
4 IMPLEMENTAÇÃO DE BANCOS DE DADOS DISTRIBUÍDOS 10
4.1 Transações distribuídas e protocolos de confirmação 10
4.2 Controle de concorrência 10
4.3 Otimização de consultas distribuídas e dblink 11
5 SISTEMAS DE BANCO DE DADOS PARALELOS 13
5.1 Paralelismo e arquiteturas paralelas 13
5.2 Particionamento e paralelismo de consultas 13
5.3 Balanceamento de carga e cluster PostgreSQL 14
6 CONSIDERAÇÕES FINAIS 16
REFERÊNCIAS 17
5
1 INTRODUÇÃO
O banco de dados centralizado, nascido monolítico em torno de um computador de
grande porte, oferece economia de escala e facilidade de controle sobre segurança e
integridade, mas é vulnerável a falhas e cresce de forma pouco gradual. Organizações
geograficamente dispersas e aplicações que lidam com volumes da ordem de exabytes tornam
esses limites evidentes. Duas respostas consolidaram-se: espalhar os dados por sites
interligados em rede, preservando uma visão única para o usuário, e combinar a gerência de
dados com o processamento paralelo para ganhar desempenho e disponibilidade (ÖZSU;
VALDURIEZ, 2020).
O problema que orienta este trabalho é: de que modo os sistemas de banco de dados
distribuídos e paralelos são projetados e implementados para conciliar desempenho,
disponibilidade e consistência? O objetivo geral é analisar, à luz da literatura, os fundamentos,
o projeto, a implementação e as arquiteturas desses sistemas. Os objetivos específicos são
caracterizar o sistema gerenciador de banco de dados distribuído (SGBDD); descrever
fragmentação e replicação; examinar transações distribuídas, controle de concorrência e
otimização de consultas; e discutir arquiteturas paralelas, paralelismo de consultas,
balanceamento de carga e cluster PostgreSQL.
A justificativa reside no fato de que decisões de distribuição e de paralelismo afetam
diretamente o custo de comunicação, a confiabilidade e a integridade dos dados. Trata-se de
pesquisa bibliográfica, de abordagem qualitativa e de caráter exploratório e descritivo,
fundamentada em obras clássicas de banco de dados e de sistemas distribuídos e na
documentação do Pgpool-II. O texto organiza-se em quatro capítulos de desenvolvimento,
dedicados aos sistemas distribuídos, ao projeto, à implementação e aos sistemas paralelos,
seguidos das considerações finais.
6
2 SISTEMAS DE BANCO DE DADOS DISTRIBUÍDOS
2.1 Sistemas distribuídos e abordagem de banco de dados
Um sistema distribuído é um conjunto de computadores interligados via rede que, para
o usuário final, aparenta ser um sistema único (TANENBAUM; STEEN, 2008). As máquinas
funcionam de forma independente e podem ser diferentes entre si; a rede e o middleware,
situado entre o sistema operacional e os aplicativos, mascaram essa heterogeneidade, como
fazem CORBA, Java RMI e Web services (COULOURIS; DOLLIMORE; KINDBERG,
2013). Tais sistemas são fracamente acoplados: a comunicação por rede confere flexibilidade
e escalabilidade, ao custo de transferências mais lentas que as do barramento interno dos
sistemas fortemente acoplados.
No plano dos dados, a abordagem de banco de dados superou os sistemas baseados em
arquivos, marcados por redundância e dependência entre programas e dados. Se o dado é,
computacionalmente, um valor que por si só pouco significa (FERREIRA; ANJOS;
FERREIRA, 1999), o banco de dados é a coleção organizada desses valores para uso de
muitas aplicações, mediada pelo SGBD. Elmasri e Navathe (2011) destacam a
autoinformação, pela qual o catálogo armazena os metadados, a separação entre programas e
dados, a abstração e as múltiplas visões, além da arquitetura de três esquemas (interno,
conceitual e externo), que separa as aplicações do banco físico.
2.2 Conceito e características do SGBDD
Em um sistema de banco de dados distribuído, os dados estão dispersos em servidores
localizados em sites fisicamente separados e interligados por rede; cada site atende às suas
aplicações e às aplicações globais. O banco local funciona como um banco centralizado,
gerido de forma autônoma, enquanto o banco global enxerga os sites como partes de um todo,
por meio de um SGBD global. O SGBDD expande, assim, o SGBD convencional: o
armazenamento divide-se em vários nós, mas a visão do banco global permanece integrada
(DATE, 2000).
Essa solução atrai por razões administrativas, pois cada setor controla seus dados;
econômicas, pela redução dos custos de comunicação de longa distância; técnicas, pelo
crescimento modular e pela replicação das partescríticas; e de eficiência, pois os dados ficam
próximos de onde são mais usados. Em contrapartida, impõe dificuldades de implementação e
maior custo de desenvolvimento. O SGBDD é homogêneo quando os SGBDs locais são
semelhantes, e heterogêneo quando integra bancos já existentes. Para que as aplicações não
precisem conhecer a distribuição, ele deve apresentar as características do Quadro 1.
7
Quadro 1 – Características e transparências do SGBDD
Característica O que garante
Autonomia local Cada banco local é dono dos seus dados e os gerencia
Não dependência de um site central Nenhum site tem autoridade sobre os demais
Operação contínua Confiabilidade e disponibilidade diante de falhas
Independência de localização A localização de bancos e servidores é transparente
Independência de fragmentação O usuário tem visão única, sem perceber a fragmentação
Independência de replicação O usuário não sabe que os dados estão replicados
Consultas e transações distribuídas Supervisão pelo SGBD global, atomicidade e controle
de concorrência
Independência de hardware, sistema operacional,
rede e SGBD
Diferenças de plataforma e de fabricante são
transparentes
Fonte: elaborado pelo autor com base em Date (2000).
Quanto à organização física, distinguem-se três arquiteturas. Na de matriz e filial, a
matriz detém todos os dados e cada filial apenas os que necessita, comunicando-se somente
com a matriz. Nas bases individuais, os bancos são independentes e consultam-se
mutuamente, com caminhos alternativos, mas exigem enlaces mais velozes. Nas bases
hierárquicas, em árvore, cada site comunica-se apenas com o nível superior ou inferior, o que
ordena o acesso e reduz os enlaces, à custa de transações mais demoradas.
8
3 PROJETO DE BANCOS DE DADOS DISTRIBUÍDOS
3.1 Esquemas e abordagens de projeto
O projeto distribuído começa como o centralizado, pela criação do modelo conceitual
global (HEUSER, 2001). O esquema conceitual global é entendido como se descrevesse um
banco centralizado; a diferença está no mapeamento para o nível interno, que corresponde aos
bancos locais, cada qual com seus esquemas conceitual, interno e externo. A abordagem
descendente (top-down), própria de sistemas novos, parte das necessidades da organização
para o banco global e, pelo projeto de distribuição, chega aos bancos locais; a ascendente
(bottom-up), própria da integração de bancos existentes, mapeia os esquemas locais para um
esquema global. Casanova e Moura (1999) sintetizam a escolha da estratégia: arquivos
pequenos tendem à replicação; arquivos grandes com baixa frequência de acesso a dados não
locais, à fragmentação; arquivos grandes com alta frequência dessas exceções, à solução
centralizada.
3.2 Fragmentação
Fragmentar é particionar as tabelas entre sites de modo que o conteúdo original possa
ser reconstruído por operações da álgebra relacional. A técnica não é obrigatória, pois seria
possível apenas replicar, mas é recomendada por desempenho e custo de comunicação,
sobretudo quando o arquivo é grande demais para um site ou quando a taxa de acesso
favorece certo local (ÖZSU; VALDURIEZ, 2020). O Quadro 2 compara as modalidades.
Quadro 2 – Fragmentação horizontal, vertical e mista
Aspecto Horizontal Vertical Mista (híbrida)
Operação Seleção de linhas (σ) Projeção de colunas (π) Seleção seguida de
projeção, ou o inverso
Conteúdo do
fragmento
Subconjunto das tuplas Todas as tuplas, com parte das
colunas
Subconjunto de tuplas e
de colunas
Reconstrução União dos fragmentos Junção pela chave primária Junções e uniões na
ordem adequada
Disjunção Cada linha em um
único fragmento
Colunas não chave em um único
fragmento; a chave se repete
Decorre das regras
anteriores
Fonte: elaborado pelo autor com base em Özsu e Valduriez (2020).
Três regras evitam perda semântica: completeza, pela qual todo item aparece em ao
menos um fragmento; reconstrução; e disjunção. Numa tabela de projetos com linhas do Rio
de Janeiro, de São Paulo e de Belo Horizonte, fragmentos definidos só para as duas primeiras
cidades são incompletos; um terceiro fragmento restabelece a completeza, e a união dos três
reconstrói a tabela. Na fragmentação vertical, todos os fragmentos devem conter a chave
9
primária ou um identificador de tupla, sem o qual a junção é impossível. A mista
frequentemente gera particionamento incompleto, o que exige novos fragmentos ou uma
cópia da tabela original no banco global. Alocados os fragmentos, o banco é particionado
quando cada fragmento reside em um único site, e replicado, total ou parcialmente, quando o
mesmo fragmento existe em vários sites.
3.3 Replicação, extratos e réplicas
Replica-se por disponibilidade, desempenho, escalabilidade e requisitos de aplicação.
Cada item replicado é um item lógico cujas cópias são itens físicos, e o protocolo de controle
de réplica faz o sistema comportar-se como se houvesse uma só cópia. A atualização pode ser
centralizada, numa cópia mestre ou numa cópia primária por item, ou distribuída, em qualquer
réplica, e implementa-se por log de transações ou por gatilhos. Melo, Silva e Tanaka (1998)
distinguem extratos, cópias de somente leitura que podem ser simples, associados a data e
hora, controlados ou periodicamente atualizados, de réplicas, que admitem atualização em
qualquer site, com propagação síncrona ou assíncrona (Quadro 3).
Quadro 3 – Replicação síncrona e assíncrona
Aspecto Síncrona Assíncrona
Momento da
propagação
Durante a própria transação Depois do commit, a partir de um log
periódico
Confirmação ao
cliente
Após a confirmação de todos os sites Assim que o servidor local atualiza
seus dados
Vantagem Consistência garantida em qualquer cópia Flexibilidade; site inativo é atualizado
depois
Desvantagem Intolerância a falhas, perda de desempenho
e bloqueios
Inconsistência temporária do banco
global
Fonte: elaborado pelo autor com base em Melo, Silva e Tanaka (1998).
Um cenário ilustrativo integra esses conceitos: um distribuidor atacadista de
medicamentos com escritório central e duas sucursais. A tabela de medicamentos é
fragmentada verticalmente nas sucursais, que não recebem o preço de compra, e as vendas são
fragmentadas horizontalmente por escritório. Como só o escritório central altera
medicamentos, as sucursais recebem um extrato periodicamente atualizado, alimentado por
gatilho e por aplicativo em lote; as vendas não são replicadas, pois os relatórios gerenciais são
eventuais e podem ser obtidos por consulta distribuída.
10
4 IMPLEMENTAÇÃO DE BANCOS DE DADOS DISTRIBUÍDOS
4.1 Transações distribuídas e protocolos de confirmação
Transação é o conjunto de operações que o SGBD trata como unidade lógica,
encerrada por COMMIT, por ROLLBACK ou por falha, caso em que tudo é desfeito. Ela
observa as propriedades ACID: atomicidade, consistência, isolamento e durabilidade, esta
assegurada por arquivos de log e mecanismos de recuperação (ELMASRI; NAVATHE, 2011).
Na transferência bancária, débito e crédito precisam integrar a mesma transação:
BEGIN TRANSACTION
UPDATE CONTA SET SALDO = SALDO - 200 WHERE NRCC = 1000
UPDATE CONTA SET SALDO = SALDO + 200 WHERE NRCC = 1002
COMMIT
Transações locais são controladas como num banco centralizado; transações globais
afetam mais de um banco local e exigem otimizador de consulta global e coordenador de
transação global. Não há um SGBDD separado: o SGBD local que recebe primeiro a consulta
global elabora o plano, envia subtransações aos demais sites e decide efetivar ou abortar,
apoiado nos protocolos do Quadro 4.
Quadro 4 – Protocolos de confirmação em duas e em três fases
Aspecto 2PC (two phase commit) 3PC (three phase commit)
Fase 1 Coordenador envia "prepare"; cada participante
vota COMMIT ou ABORT
Idêntica à fase 1 do 2PC
Fase
intermediária
Inexistente Coordenador envia "preparar para
confirmar"
Fase final Um único ABORT cancela tudo; a unanimidade
efetiva a transação
Idêntica à fase 2 do 2PC
Problema
tratado
Atomicidade de transações distribuídas Bloqueio dos participantes se o
coordenador falhaSituação prática Simples e elegante, amplamente utilizado Não implementado, pelo aumento
da latência
Fonte: elaborado pelo autor com base em Özsu e Valduriez (2020).
4.2 Controle de concorrência
Sem controle, transações concorrentes produzem atualização perdida, leitura suja,
leitura não repetível, leitura fantasma e resumo incorreto. O princípio corretivo é obter o
resultado de alguma execução serial: toda execução serial é correta, e a intercalada só é aceita
quando equivalente a uma delas (SILBERSCHATZ; KORTH; SUDARSHAN, 2006). Os
métodos são pessimistas ou otimistas (Quadro 5).
11
Quadro 5 – Controle de concorrência por bloqueio e por timestamp
Aspecto Bloqueio Timestamp
Classificação Pessimista; o mais usado nesse grupo Presente nos dois grupos; o mais usado
entre os otimistas
Mecanismo Bloqueio compartilhado (S) ou exclusivo (X)
antes do acesso
Carimbo de tempo que ordena as
operações em conflito
Conflito Só S com S é compatível; a transação
incompatível espera
A transação que viola a ordem é abortada e
reiniciada
Risco
principal
Deadlock, em geral tratado por detecção e
ROLLBACK
Reinícios de transações
Fonte: elaborado pelo autor com base em Elmasri e Navathe (2011).
No ambiente distribuído surgem réplicas múltiplas, falhas de sites e de enlaces,
confirmação distribuída e deadlock distribuído. O bloqueio em duas fases (2PL) exige que
todos os bloqueios ocorram antes do primeiro desbloqueio, com fases de expansão e de
encolhimento, o que facilita a serialização. Para dados replicados, Elmasri e Navathe (2011)
descrevem o site primário, simples mas gargalo e ponto único de falha; o site primário com
backup; a cópia primária, que distribui o controle dos itens; e a votação, na qual o bloqueio é
mantido se a maioria dos sites com réplica o conceder, critério distinto da unanimidade do
2PC.
4.3 Otimização de consultas distribuídas e dblink
Consultas locais passam por análise sintática, análise semântica, reescrita algébrica,
otimização heurística e por regras ou custo, e geração do plano. Consultas globais
acrescentam mapeamento, localização dos dados, otimização global e execução distribuída
(CASANOVA; MOURA, 1999). Considere-se a consulta submetida no site 5:
SELECT NOME
FROM EMPREGADO E
INNER JOIN ALOCPROJ A ON E.MAT = A.MAT
WHERE CARGO = 'GERENTE'
Com empregados fragmentados nos sites 1 e 2 e alocações nos sites 3 e 4, enviar as
quatro tabelas ao site 5 é a pior estratégia; a mais barata é a semijunção, em que os sites 3 e 4
enviam apenas as matrículas dos gerentes, a coluna da condição de junção, reduzindo
drasticamente as linhas transferidas (ÖZSU; VALDURIEZ, 2020). Sem transparência de
distribuição, o usuário referencia o banco remoto por uma ligação: database link no Oracle,
servidores vinculados no SQL Server e a extensão dblink no PostgreSQL, que não vem criada
por padrão:
12
CREATE EXTENSION DBLINK;
SELECT *
FROM dblink('host=192.168.5.189 port=5432 user=postgres password=senha dbname=SUCURSAL',
 'select razao_social from public.farmacia') AS T(razao_social text);
A função dblink retorna registros e é usada na cláusula FROM com alias e colunas
tipadas; dblink_exec executa comandos que não retornam linhas e devolve texto de status;
dblink_connect e dblink_disconnect abrem e fecham conexões persistentes nomeadas.
13
5 SISTEMAS DE BANCO DE DADOS PARALELOS
5.1 Paralelismo e arquiteturas paralelas
O processamento paralelo reúne unidades que colaboram, cada uma com parte do
trabalho, e exige programas escritos com múltiplas threads, pois o sistema operacional não
paraleliza automaticamente. Os sistemas distribuídos são um tipo de sistema paralelo
fracamente acoplado, que difere na motivação: reduzir o custo de comunicação em redes de
longa distância com base na localidade física (ÖZSU; VALDURIEZ, 2020). Como cada
processador acrescentado degrada um pouco os demais, surgiram as arquiteturas do Quadro 6.
Quadro 6 – Arquiteturas de sistemas paralelos
Arquitetura Organização Vantagens Limitações
Memória
compartilhada
Processadores acessam
memória e discos por
barramento comum ou
interconexão rápida
Comunicação eficiente;
interconsulta quase sem
adaptação
Barramento como
gargalo, apenas
minimizado e a custo
elevado
Disco
compartilhado
Cada nó tem processador e
memória, e todos acessam
todos os discos
Escala mais processadores;
melhor tolerância a falhas;
baixo custo
Todas as E/S passam pela
rede de interconexão
Nada
compartilhado
Cada nó tem processador,
memória e discos e serve os
próprios dados
Alta escalabilidade;
adequada a volumes
enormes
Acesso a disco não local
mais caro
Hierárquica Combinação das anteriores Concilia os benefícios das
demais
Maior complexidade
Fonte: elaborado pelo autor com base em Silberschatz, Korth e Sudarshan (2006).
5.2 Particionamento e paralelismo de consultas
O banco paralelo visa a alto desempenho, alta disponibilidade e escalabilidade. Seu
problema clássico é o gargalo de entrada e saída: um banco em um disco de vazão T tem
vazão T, mas, particionado em N discos, alcança em tese N vezes T. A forma mais eficiente é
o particionamento horizontal (Quadro 7); o vertical é possível, porém pouco usado.
Quadro 7 – Técnicas de particionamento horizontal em bancos paralelos
Técnica Distribuição das linhas Favorece Desfavorece
Round-
robin
Circular, sem critério de valor Distribuição uniforme e
leitura da tabela inteira
Buscas pontuais e por
faixa
Hash Função de hash sobre uma ou mais
colunas
Consultas pontuais pela
coluna de particionamento
Buscas por intervalo
Por faixa Valores contíguos no mesmo disco,
segundo vetor de particionamento
Consultas pontuais e por
intervalo
Concentração de carga
em uma faixa
Fonte: elaborado pelo autor com base em Silberschatz, Korth e Sudarshan (2006).
14
O paralelismo interconsulta executa várias consultas simultaneamente e aumenta as
transações por segundo, mas exige protocolos de coerência de cache nas arquiteturas de disco
compartilhado e sem compartilhamento. O intraconsulta acelera cada consulta e desdobra-se
em intraoperação, que paraleliza uma única operação, como ordenação ou junção, e em
interoperação, que executa operações distintas em paralelo, em pipeline ou de forma
independente. Na consulta a seguir, em pipeline, cada conta filtrada segue imediatamente para
a junção:
SELECT CL.Nome
FROM Cliente CL
INNER JOIN Conta_Corrente CC ON CC.CPF = CL.CPF
WHERE CC.Saldo > 2500
A junção particionada aplica-se a condições de igualdade; para desigualdades, usa-se
fragmentar e replicar, replicando uma das tabelas em todos os nós. A otimização baseia-se no
operador de troca, único responsável pela troca de dados entre nós, de modo que os demais
operadores executam localmente. O tempo de resposta de um plano soma, para cada fase, o
maior tempo de resposta acrescido do atraso de pipeline entre seus operadores, mais o atraso
de armazenamento da fase (ÖZSU; VALDURIEZ, 2020, p. 373).
5.3 Balanceamento de carga e cluster PostgreSQL
O balanceamento de carga atua em três níveis: intraoperações, com técnicas
adaptativas ou especializadas; interoperações, escolhendo quantos e quais processadores
atribuir a cada operador; e intraconsulta, pelo modelo de processamento dinâmico, que
decompõe a consulta em ativações executáveis por qualquer processador (ÖZSU;
VALDURIEZ, 2020). Frente aos computadores de grande porte, caros e de difícil
redimensionamento, clusters e grids de máquinas comuns oferecem baixo custo total de
propriedade e fácil expansão (MUSSI; SANTOS, 2013). No banco em cluster, um SGBD
convencional, que ignora estar em cluster, é orquestrado por middleware replicado em cada
nó, em arquitetura sem compartilhamento. O PostgreSQL oferece, em seu núcleo, streaming
replication com hot standby somente leitura, warm standby por log shipping e extração lógica
de alterações; os middlewares comparam-se no Quadro 8.
Quadro 8 – Middlewares de cluster para PostgreSQL
Projeto Replicação Sincronização Pool de
conexão
Balanceamento Consulta
paralela
PgCluster Mestre-mestreSíncrona Não Sim Não
Pgpool-II Baseada em
middleware
Síncrona Sim Sim Sim
Slony Réplica primária Assíncrona Não Não Não
15
Projeto Replicação Sincronização Pool de
conexão
Balanceamento Consulta
paralela
Bucardo Mestre-mestre Assíncrona Não Não Não
Londiste Réplica primária Assíncrona Não Não Não
Fonte: elaborado pelo autor com base em Mussi e Santos (2013).
O Pgpool-II, o mais completo, situa-se entre clientes e servidores PostgreSQL, suporta
até 128 nós e oferece pool de conexões, replicação síncrona baseada em consultas,
balanceamento de carga e consulta paralela (THE PGPOOL GLOBAL DEVELOPMENT
GROUP, [s.d.]). No arquivo pgpool.conf definem-se o modo de cluster, cujo padrão é
streaming_replication, a porta 9999 para os clientes, a porta 9898 da interface de
administração PCP, os servidores de retaguarda e o parâmetro load_balance_mode, que
distribui as consultas SELECT. O PostgreSQL deve ser iniciado antes do pgpool, sob pena de
failover, e desligado somente depois dele.
16
6 CONSIDERAÇÕES FINAIS
Este estudo analisou os sistemas de banco de dados distribuídos e paralelos quanto a
fundamentos, projeto, implementação e arquitetura, atingindo os objetivos propostos.
Verificou-se que o SGBDD amplia o SGBD convencional por meio de transparências que
preservam a visão integrada do banco global, e que o projeto distribuído depende da correta
aplicação das regras de completeza, reconstrução e disjunção e de uma escolha criteriosa entre
extratos e réplicas, síncronas ou assíncronas.
Na implementação, o 2PC mostrou-se o mecanismo prático de atomicidade, enquanto
o 3PC não se difundiu pela latência; o controle de concorrência apoia-se predominantemente
no bloqueio e no 2PL, e a otimização de consultas globais busca reduzir transferências, como
na semijunção. Nos bancos paralelos, a arquitetura sem compartilhamento, o particionamento
horizontal, o paralelismo de consultas e o balanceamento de carga respondem ao gargalo de
entrada e saída, princípios materializados pelo cluster PostgreSQL com Pgpool-II.
Conclui-se que distribuição e paralelismo partilham o mesmo núcleo conceitual,
fragmentar e replicar dados, mas diferem na motivação: a localidade física e a autonomia, de
um lado, e o desempenho sobre grandes volumes, de outro. Em ambos, ganhos de
disponibilidade e de desempenho cobram o preço da complexidade de administração e da
manutenção da consistência. Sugere-se, como continuidade, a investigação empírica
comparativa dos modos de replicação do Pgpool-II.
17
REFERÊNCIAS
CASANOVA, M. A.; MOURA, A. V. Princípios de sistemas de gerência de bancos de
dados distribuídos. Ed. rev. [S. l.: s. n.], 1999.
COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Sistemas distribuídos: conceitos e
projeto. 5. ed. Rio de Janeiro: Bookman, 2013.
DATE, C. J. Introdução a sistemas de banco de dados. 7. ed. [S. l.]: Campus, 2000.
ELMASRI, R.; NAVATHE, S. Sistemas de banco de dados. 6. ed. São Paulo: Pearson, 2011.
FERREIRA, A. B. H.; ANJOS, M.; FERREIRA, M. B. Novo Aurélio Século XXI: o
dicionário da língua portuguesa. 3. ed. Rio de Janeiro: Nova Fronteira, 1999.
HEUSER, C. A. Projeto de banco de dados. 4. ed. Porto Alegre: Sagra Luzzatto, 2001.
MELO, R. N.; SILVA, S. D.; TANAKA, A. K. Banco de dados em aplicações cliente-
servidor. 6. ed. São Paulo: Infobook, 1998.
MUSSI, E.; SANTOS, E. PostgreSQL: cluster, alta disponibilidade e balanceamento de
carga. Brasília, 2013.
ÖZSU, T.; VALDURIEZ, P. Princípios de sistemas de banco de dados distribuídos. 4. ed.
Americana: Spring, 2020.
SILBERSCHATZ, A.; KORTH, H.; SUDARSHAN, S. Sistemas de banco de dados. 5. ed.
Rio de Janeiro: Elsevier, 2006.
TANENBAUM, A.; STEEN, M. Sistemas distribuídos: princípios e paradigmas. 2. ed. São
Paulo: Pearson Prentice Hall, 2008.
THE PGPOOL GLOBAL DEVELOPMENT GROUP. Documentação oficial do Pgpool II
4.4.2. [S. l.], [s.d.]. Acesso em: 8 maio 2023.