Administração de Banco de Dados I

Aula 1: 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, estudaremos a história e arquitetura deste SGBD.

 Objetivos
Definir a história do PostgreSQL;

Identificar o tipo de licenciamento do SGBD;

Descrever a arquitetura do PostgreSQL.

História do PostgreSQL

Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online

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 término do projeto do INGRES, pela universidade, o prof. Stonebraker, desenvolveu um novo
projeto, o Post(erior) INGRES, dando origem ao nome do SGBD PostgreSQL a partir de 1986.

O PostgreSQL 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.

Ao longo dos anos, o PostgreSQL teve várias versões, sendo a versão 6.0 considerada a sua versão inicial. A cada uma dessas
versões são acrescentadas novas funcionalidades. Vejamos:

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.

 Fonte: Shutterstock

Saiba mais
Clique aqui para acessar a licença do PostgreSQL.

O SGBD é mantido atualmente pelo PostgreSQL Global Development Group,

e possui versões compatíveis com o Linux, Windows, BSD, MacOS e Solaris.

Arquitetura do PostgreSQL
O cluster do PostgreSQL é composto de estruturas de memória e processos. Vamos ver cada um destes itens com mais
detalhes:

Estruturas de memória

Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online

O PostgreSQL possui duas estruturas básicas de memória.

A memória de trabalho do back-end é a área de memória utilizada pelos processos de back-end para armazenar seus dados.

Já a shared memory é a memória do servidor, sendo dividida em:

Shared Buffers: armazena os blocos de dados enquanto estão na memória.

WAL Buffers: armazena as operações do log de transações até serem salvas no disco.

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, denominado processo de back-end, para atender ao usuário.
Além dos processos de back-end, o PostgreSQL possui outros que atendem as diversas tarefas que o SGBD necessita como
pode ser visto na figura a seguir.

Vejamos melhor estes processos:

1 Postmaster: é o pai de todos os demais processos, responsável pela inicialização do SGBD, e faz a carga de todos os outros
processos.

2. 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.

3. 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 páginas a cada 200ms.

4. 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.
5. Auto Vacuum: é um daemon para automatizar a operação de vacuum .

6. Stats Collector: realiza a coleta das estatísticas do banco de dados para uso pelo otimizador.

7. Logger: registra 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.

8. Vacuum Worker: é quem executa efetivamente o Vacuum. Existem por padrão 3 deles em execução que são gerenciados
pelo Autovacuum.

9. Archiver: realiza o arquivamento dos segmentos de WAL em um local predefenido no arquivo de configuração.

10. 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 nesta figura:

Processos Back-end

Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online

Como já falamos, esses processos são criados para atender à conexão dos usuários.

O processo de conexão é realizado da seguinte forma:

Passo 1
Um cliente solicita uma nova conexão ao Postmaster.
Passo 2
O Postmaster realiza autenticação do usuário.
Passo 3
Se a autenticação foi bem-sucedida, o Postmaster cria um processo (back-end) para atender ao usuário.
Uma vez estabelecida a conexão, o processo de back-end associado passa a atender as requisições do usuário sem
participação do Postmaster.

Cada processo mantém 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.

Dessa forma, sempre existirá um back-end para cada conexão:

Em um servidor baseado em Linux, em conexões de usuários, se você pedir para listar os processos do PostgreSQL, será
retornado algo como o visto na figura a seguir:

Na figura, podemos ver os processos utilitários e 3 conexões em processos de back-end (destacadas na figura).

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

Passo 4
O processo criado passa a atender ao usuário.

Esse comando lista todos os processos associados ao usuário Postgres no SO. O retorno é hierárquico e, no caso dos
processos em back-end, as informações retornadas são:

Arquivos do servidor
Além das estruturas vistas até agora no Servidor PostgreSQL, temos uma série de arquivos que balizam o funcionamento do
servidor.

Vamos a eles:

Clique nos botões para ver as informações.

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.

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 denominada normalmente pg_data .

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

Veja, a seguir, o conteúdo de pg_data.

 Item 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(s) pelo coletor de registro.

global Subdiretório que contém tabelas de todo o cluster, como pg_database.

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.

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 subtransaçã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.

 Atenção! Para visualização completa da tabela utilize a rolagem horizontal

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 8kB, embora um
tamanho de página diferente possa ser selecionado 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 (POSTGRESQL, 2020).

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.

 Atenção! Para visualização completa da tabela utilize a rolagem horizontal

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
(POSTGRESQL, 2020).

O cabeçalho está detalhado na tabela a seguir.

Campo Tipo Comprimento 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 ItemPointerData 6 bytes TID atual desta ou da versão da linha mais 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.

 Atenção! Para visualização completa da tabela utilize a rolagem horizontal

1. 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.

2. 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).

3. Nesta lista de bits, 1 bit indica não nulo, 0 bits é nulo. Quando o bitmap não está presente, todas as colunas são assumidas
como não nulas.

4. 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.

5. 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).

Atividade
Questão 1. Onde são registradas as operações realizadas pelas transações no PostgreSQL?

Questão 2. Quantos processos back-end estarão em execução se tivermos 5 conexões no SGBD?

Questão 3. 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?

Questão 4. O PostgreSQL é multi tread ou multiprocesso? Explique a implicação disso.

Notas

WAL

O WAL (write-ahead logging) corresponde à estrutura de log do SGBD.

Vacuum

Vacuum é a operação de manutenção mais importante do PostgreSQL. Corresponde aproximadamente à desfragmentação

dos dados e será estudada mais à frente na disciplina.

pg_data

Pg_data é uma 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.

Referências

GONZAGA, Jorge Luiz. Dominando o PostgreSQLM. Rio de Janeiro: Ciência Moderna, 2007.

POSTGRESQL. Disposição das páginas de banco de dados. Disponível em: // pgdocptbr .sourceforge .net /pg80 /storage -page
-layout .html. Acesso em: 07 jan. 2020.

SANTOS, E. V. Administração do PostgreSQL. 1. ed. 2017. E-book.

Próxima aula

Instalação e configuração do cluster do SGBD.

Explore mais

Leia o texto PostgreSQL: The World's Most Advanced Open Source Relational Database no site do projeto do PostgreSQL;

Leia o texto Documentation SGBD.