MODELO DE TEMPLATE DE AULA

Disciplina: ADMINISTRAÇÃO DE BANCO DE DADOS I

Aula 01: ARQUITETURA DO POSTGRESQL

Apresentação
O PostgreSQL é um sistema de gerenciamento de banco de dados objeto-
relacional (SGBDOR) de código aberto baseado em um sistema desenvolvido na
universidade de Berkeley e fornecendo suporte ao SQL92/SQL99 além de
outras funcionalidades modernas, particularmente aos aspectos Objeto
Relacional e geográficos.
Ao longo desta aula iremos estudar a história e arquitetura deste SGBD.

Objetivos

Objetivo 1 – Conhecer a historio d PostGreSql

Objetivo 2 – Identificar o tipo de licenciamento do SGBD
Objetivo 3 – Descrever a arquitetura do PostGreSql

1
Conteúdo online

História do PostgreSql

O Postgresql tem sua origem no sistema INGRES (Interactive Graphics Retrieval

System) desenvolvido na Universidade de Berkeley, na Califórnia, sob a liderança dos
doutores Michael Stonebraker e Eugene Wong na década de 1970.

Após o termino do projeto do Ingres, pela universidade, o Prof. Stonebraker,

desenvolveu um novo projeto o Post(erior) Ingres, dando origem ao nome do SGBD
PostGres a partir de 1986

O Postgres em sua concepção inicial utilizava como linguagem de consulta um

dialeto proprietário denominado PostQuel.
Em 1995 foi desenvolvido um interpretador de comando SQL para o SGBD e o
SGBD teve seu nome mudado para PostGreSql, que permanece até hoje, sendo a
versão 6.0 considerada a sua versão inicial.

Ao longo dos anos o PostGreSql teve várias versões cada uma acrescentando novas
funcionalidades:

Versão 6 - controle de concorrência multiversão

Versão 7 – melhorias no otimizador de consulta e implementação do WAL (Write-
Ahead Logging)
Versão 8 – melhorias no mecanismo de checkpoint vacuum e incorporação do
PITR(Point-in-Time Recovery)
Versão 9 – introdução da replicação síncrona, suporte ao tipo JSON e visões
materializadas
Versão 10 – melhoria do paralelismo em consultas, particionamento nativo,
replicação lógica, tabelas XML
Versão 11 - Maior Robustez e Desempenho para Particionamento, Compilação Just-
in-Time (JIT) para Expressões e Transações Suportadas em Procedimentos
Armazenados.

O PostGreSql é um SGBD de código aberto( open source) escrito basicamente em C,

sendo distribuído sob a licença BSD clássica que permite aos usuários fazerem
qualquer coisa com o código, incluindo revender os binários sem o código-fonte.
A única restrição é que os desenvolvedores do SGBD não se responsabilizam
legalmente por problemas com o programa de computador. Além disso a licença
deve aparecer em todas as cópias do programa de computador.

A licença do PostGreSql pode ser vista aqui

inicio link aqui

2
 PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group

Portions Copyright (c) 1994-1996 Regents of the University of California

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written agreement is
hereby granted, provided that the above copyright notice and this paragraph and the
following two paragraphs appear in all copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO

ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR
CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF
THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE
UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY

WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE
SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE
UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE
MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Fim link aqui

O SGBD é mantido atualmente pelo PostgreSQL Global Development Group, e

possui versões compatíveis com o LINUX , WINDOWS, BSD, MacOS e SOLARIS.

3
ARQUITETURA DO POSTGRESQL
O Cluster do PostGreSql é composto de estruturas de memória e Processos (fig1),
vamos ver cada um deste itens com mais detalhes.

Figura 1 – Arquitetura do PostGreSql

Fonte: Administração de Banco de Dados – Fabio Caiut

Estruturas de Memória
O PostgreSQL possui duas estruturas básicas de memória .(fig. 2):

 A memória de Trabalho do Backend – é área de memória utilizada pelos

processos de backend para armazenar seus dados
 - A Shared Memory- é a memória do servidor sendo dividida em :
o Shared Buffers – armazena os blocos de dados enquanto estão na
memória
o WAL Buffers – armazena as operações do log de transações até serem
salvas no disco

4
 Figura 2 – Estruturas de Memória
Fonte: Administração de Banco de Dados – Fabio Caiut

Estrutura de Processos do Servidor

O PostgreSQL é um SGBD baseado em processos, não em tread o que implica que a
cada nova conexão é criado um novo processo no sistema operacional, denominados
processos de backend, para atender ao usuário.
Além dos processos de backend o PostgreSQL possui outros que atendem as
diversas tarefas que o SGBD necessita como pode ser visto na figura 3.

5
 Figura 3 – Arquitetura de Processos do PostGreSql
Fonte: Administração de Banco de Dados – Fabio Caiut

Vejamos melhor estes processos:

 Postmaster - é o pai de todos os demais processos, é responsável pela inicialização

do SGBD, e faz a carga de todos os outros processos.
 Checkpointer - é o responsável pela realização do Checkpoint, que no PostgreSql
corresponde a gravar nos arquivos de dados as alterações existentes no WAL. Por
padrão a gravação é realizada a cada 5 minutos ou quando 3 arquivos de log
estiverem cheios.

INICIO LINK WAL

O WAL (Write-Ahead Logging) corresponde a estrutura de Log do SGBD.

6
 FIM LINK WAL

 Writer – denominado também background writer ou bgwriter realizada a gravação

no disco das páginas modificadas que estão na memória compartilhada (shared
buffer). A gravação, por padrão, é realizada em lotes de 100 paginas a cada 200
ms.
 WAL writer - realiza a gravação no disco das operações existentes nos buffers do log
(WAL buffers) em intervalos definidos no arquivo de configuração do PostgreSQL.
 Auto Vacuum – é um daemon para automatizar a operação de Vacuum.
Inicio link vacuum
Vacuum é a operação de manutenção mais importante do PostGreSql, corresponde
aproximadamente a desfragmentação dos dados e será estudada mais à frente na
disciplina.
Fim link vacuum

 Stats Coletor - realiza a coleta das estatísticas do banco de dados para uso pelo
otimizador.
 Logger - registrar o que acontece na operação do SGBD, como acesso de usuários,
erros ou problemas com locks. Não confundir com o LOG DE TRANSAÇÕES que como
vimos no PostGreSql é denominado WAL.
 Vacuum Worker – é quem executa efetivamente o Vacuum, existem por padrão 3
deles em execução que são gerenciados pelo AutoVacuum.
Archiver – realiza o arquivamento dos segmentos de WAL em um local pré-definido
no arquivo de configuração.
 Sender e Receiver – são os processos que permitem a replicação binária do servidor

Vários dos processos que vimos são opcionais, em uma instalação típica a estrutura
dos processos é a exibida na figura 4

7
 Figura 4 –Processos em uma configuração padrão
Fonte: Administração de Banco de Dados – Fabio Caiut

Processos Backend

Como já falamos estes processos são criados para atender a conexão dos usuários
O processo de conexão é realizado da seguinte forma:
Passo1 – um cliente solicita uma nova conexão ao postmaster
Passo2 – o postmaster realiza autenticação do usuário.
Passo3 – se a autenticação foi bem sucedida o postmaster cria um processo
(backend) para atender ao usuário
Passo4 – o processo criado passa a atender ao usuário

A figura 5 ilustra este processo.

8
 Figura 5 – Estabelecimento de Conexão
Fonte: Administração de Banco de Dados – Fabio Caiut

Uma vez estabelecida a conexão o processo de backend associado passa a atender

as requisições do usuário sem participação do postmaster.
Cada processo mantem uma relação de exclusividade com a conexão, de forma que
um processo atende a uma única conexão e uma conexão é atendida por um único
processo.
Desta forma sempre existira um backend para cada conexão (fig6)

Figura 6 – Processos Backend

Fonte: Administração de Banco de Dados – Fabio Caiut

Em um servidor baseado em Linux conexões de usuários se voce pedir para listar os

processos do postgresql será retornado algo como o visto na figura 7

9
 Figura 7 – Retorno do Comando

Na figura podemos ver os processos utilitários e 3 conexões em processos de

backend ( destacadas na figura)

O comando que lista os processos do PostgreSQL em execução é:

Ele lista todos os processos associados ao usuário postgres no SO.

O retorno é hierárquico e no caso dos processos em backend as informações
retornadas são:

Arquivos do Servidor
Além das estruturas vistas até agora no Servidor PostgreSql temos uma serie de
arquivos que balizam o funcionamento do servidor.
Vamos a eles:

 pg_hba.conf - é o arquivo de configuração para autenticação dos usuários.

Funciona determinando quem pode acessar a base de dados.
 Pg_ident.conf – usado pelo esquema ident de autenticação dos Sistemas
Operacionais, mapeia usuários do SO e da base de dados. Por padrão fica
vazio.

10
  postgresql.conf – arquivo principal de configuração do SGBD. Possui uma lista
de parâmetros que controla o funcionamento do cluster.
Além destes arquivos de configuração o PostGreSql gera uma estrutura de
diretórios de denominada normalmente pg_data

Inicio link pg_data

pgdata é um denominação geral, o diretório de dados vem após o nome da variável de
ambiente que pode ser usada para defini-lo.
Um local comum para PGDATA é /var/lib/pgsql/data.
Fim link pg_data

O diretório pg_data é dividido em subdiretórios e armazena os arquivos de controle

vistos acima.
O conteúdo de pg_data é

tem Descrição

PG_VERSION Um arquivo contendo o número da versão principal do

PostgreSQL
base Subdiretório contendo subdiretórios por banco de dados
current_logfiles Arquivo gravando o (s) arquivo (s) de registro atualmente
gravado pelo coletor de registro
global Subdiretório que contém tabelas de todo o cluster, como
pgdatabase
pg_commit_ts Subdiretório que contém dados de carimbo de data / hora de
confirmação da transação
pg_dynshmem Subdiretório que contém arquivos usados pelo subsistema de
memória compartilhada dinâmica
pg_logical Subdiretório contendo dados de status para decodificação
lógica
pg_multixact Subdiretório que contém dados de status de multitransação
(usados para bloqueios de linha compartilhados)
pg_notify Subdiretório contendo dados de status LISTEN / NOTIFY
pg_replslot Subdiretório contendo dados do slot de replicação
pg_serial Subdiretório que contém informações sobre transações
serializáveis confirmadas
pg_snapshots Subdiretório contendo instantâneos exportados

11
 tem Descrição

pg_stat Subdiretório que contém arquivos permanentes para o

subsistema de estatísticas
pg_stat_tmp Subdiretório que contém arquivos temporários para o
subsistema de estatísticas
pg_subtrans Subdiretório contendo dados de status de sub-transação
pg_tblspc Subdiretório contendo links simbólicos para os espaços de
tabela
pg_twophase Subdiretório que contém arquivos de estado para transações
preparadas
pg_wal Subdiretório que contém arquivos WAL (Write Ahead Log)
pg_xact Subdiretório que contém dados de status de confirmação da
transação
postgresql.auto.conf Um arquivo usado para armazenar parâmetros de
configuração definidos por ALTER SYSTEM
postmaster.opts Um arquivo que registra as opções de linha de comando com
as quais o servidor foi iniciado pela última vez
postmaster.pid Um arquivo de bloqueio que registra o ID do processo
postmaster atual (PID), o caminho do diretório de dados do
cluster, o registro de data e hora de início do postmaster, o
número da porta, o caminho do diretório de soquete do
domínio Unix (vazio no Windows), o primeiro endereço de
escuta válido (endereço IP ou *, ou vazio, se não estiver
escutando) no TCP) e ID do segmento de memória
compartilhada

Para cada banco de dados no cluster, há um subdiretório PGDATA/base, nomeado após

o OID do banco de dados pg_database. Esse subdiretório é o local padrão para os
arquivos do banco de dados; em particular, seus catálogos de sistema são armazenados
lá.

Cabe observar ainda que Cada tabela e índice é armazenado em um arquivo

Páginas de Dados

Todas as tabelas e índices são armazenados como uma matriz de páginas de tamanho
fixo (geralmente 8 kB, embora um tamanho de página diferente possa ser selecionado

12
ao compilar o servidor). Em uma tabela, todas as páginas são logicamente equivalentes;
portanto, um item (linha) específico pode ser armazenado em qualquer página. Nos
índices, a primeira página geralmente é reservada como uma meta-página contendo
informações de controle e pode haver diferentes tipos de páginas no índice,
dependendo do método de acesso ao índice.

O layout geral de uma página é

Item Descrição

PageHeaderData 24 bytes. Contém informações gerais sobre a página, incluindo

ponteiros de espaço livre.

ItemIdData Matriz de identificadores de itens apontando para os itens

reais. Cada entrada é um par (deslocamento, comprimento). 4
bytes por item.

Espaço livre O espaço não alocado. Novos identificadores de itens são alocados

desde o início desta área, novos itens a partir do final.

Itens Os itens reais em si.

Espaço especial Dados específicos do método de acesso ao índice. Métodos

diferentes armazenam dados diferentes. Vazio em mesas comuns.

13
Linhas das tabelas

Todas as linhas da tabela são estruturadas da mesma maneira. Há um cabeçalho de

tamanho fixo (ocupando 23 bytes na maioria das máquinas), seguido por um bitmap
nulo opcional, um campo opcional de ID do objeto e os dados do usuário. O cabeçalho
está detalhado na Tabela abaixo:

compriment
Campo Tipo o Descrição

t_xmin TransactionId 4 bytes inserir carimbo XID

t_xmax TransactionId 4 bytes excluir carimbo XID

t_cid CommandId 4 bytes inserir e / ou excluir carimbo CID

(sobreposições com t_xvac)

t_xvac TransactionId 4 bytes XID para operação VACUUM movendo uma

versão de linha

t_ctid ItemPointerDat 6 bytes TID atual desta ou da versão da linha mais

a recente

t_infomask2 uint16 2 bytes número de atributos, além de vários bits de

flag

t_infomask uint16 2 bytes vários bits de flag

t_hoff uint8 1 byte deslocamento para dados do usuário

Os dados reais do usuário (colunas da linha) começam no deslocamento indicado por

t_hoff, que deve sempre ser um múltiplo da distância MAXALIGN da plataforma.

14
O bitmap nulo estará presente apenas se o bit HEAP_HASNULL estiver definido
t_infomask. Se estiver presente, começa logo após o cabeçalho fixo e ocupa bytes
suficientes para ter um bit por coluna de dados (ou seja,t_nattsbits por completo). Nesta
lista de bits, 1 bit indica não nulo, 0 bit é nulo. Quando o bitmap não está presente,
todas as colunas são assumidas como não nulas.

O ID do objeto está presente apenas se o bit HEAP_HASOID estiver definido t_infomask.

Se presente, ele aparece logo antes do t_hofflimite.

Qualquer preenchimento necessário para tornar t_hoffum MAXALIGN múltiplo

aparecerá entre o bitmap nulo e o ID do objeto. (Isso, por sua vez, garante que o ID
do objeto esteja alinhado adequadamente.)

15
Atividades

Atividade 1:
Onde são registradas as operações realizadas pelas transações no PostGreSql?

Gabarito comentado
No WAL (Write-Ahead Logging).
O Wal corresponde no Postgresql a estrutura de log de transações do sistema, ou
seja aonde são registradas as operações realizadas pelas transações

Atividade2:
Quantos processos backend estarão em execução se tivermos 5 conexões no SGBD?

Gabarito Comentado:
Serão 5
No Postgresql os processos de backend mantem um relação direta com as conexões,
sendo gerada 1 processo para cada conexão.
Como na situação citada existem 5 conexões existirão 5 processos em backend, um
para cada conexão que irá atender as requisições.

Atividade3: Se você gerar um novo produto a partir do postgresql o que deverá

constar na sua licença em relação ao código do SGBD?

Gabarito Comentado:
Na licença de seu produto deverá constar que:

1. A citação a licença do postgresql

2. A observações que os desenvolvedores do SGBD não assumem
responsabilidade pelo uso do sistema

Atividade 4: O PostgreSQL é multi tread ou multiprocesso? Explique a implicação

disso

16
Gabarito Comentado:
O Postgresql é multi-processo, ou seja ele tem um processo Pai, denominado
Postmaster que gera processos filhos para atender as demais tarefas do sistema.
pela inicialização do SGBD, e faz a carga de todos os outros processos

Referências
Manual do PostGreSql
Santos E. V. Administração do PostGreSql 1ª.Ed 2017
Caiut , Fabio Administração de Banco de Dados 1ª.Ed 2015

Próximos passos

Na próxima aula veremos a instalação do SGBD

Explore +

Acesse o site do projeto do postgresql

https://www.postgresql.org/
Documentação oficial do SGBD
https://www.postgresql.org/docs/

Livro PostGreSql
https://pt.wikibooks.org/wiki/PostgreSQL_Pr%C3%A1tico

17