Continuando com os artigos realizando pequenas comparações do SQL Server com o PostgreSQL, desta vez estarei escrevendo sobre write ahead log (WAL) que nada mas é gravação em disco, garantindo que os dados estejam confirmados, neste caso no arquivo de log.
Existem poucas diferenças quando falamos de WAL no SQL Server e no PostgreSQL, nas duas plataformas de banco de dados é utilizado memoria no processo de gravação dos dados, no SQL Server chamamos está aera de memória de data cache, já no PostgreSQL está área é chamada de shared buffers que é a área de memoria compartilhada.
Nas duas plataforma os processos de escrita são realizados em uma área de memoria que não pode garantir a integridade dos dados caso ocorra um crash não esperado, com isso utilizando o WAL para garantir que uma escrita só possa validada após os dados estarem em uma mídia estável (disco).
Segue abaixo um ótimo artigo que publiquei aqui no Guia DBA sobre write ahead log no SQL Server:
Transaction Log write-ahead
Antes de nos aprofundarmos um pouco mais sobre o assunto vamos primeiro analisar de forma básica como ocorre o fluxo de uma leitura nestas duas plataformas de banco de dados conforme mostrado na imagem 1,
Imagem 1 – Fluxo de uma leitura
O fluxo de uma leitura nos dois bancos de dados agem de forma bem simples, acessam o disco, trazem a informação para memoria e depois retornam a informação a aplicação, claro que estamos falando bem resumidamente sobre este fluxo, mas é basicamente isso.
Quando falamos de escrita (Insert. Update ou Delete) no PostgreSQL as coisas se tornam um pouco mas complicadas e o fluxo não se torna tão simples.
No banco de dados PostgreSQL também utiliza o modelo cliente servidor assim como o SQL Server, então para cada conexão é criado um processo. No PostgreSQL um processo é conhecido como backend conforme ilustrado na imagem 1. Uma sessão no PostgreSQL é composta por:
- Processo supervisor (postgres)
- Aplicação cliente
- Processo servidor
Este processo supervisor é responsável por gerenciar diversos processos, um deles é o processo Wal Whriter.
Quando falamos em fluxo de escrita no PostgreSQL, a primeira coisa a ser realizada pós commit é enviar ao Wal wtiter o processo de gravação dos logs, caso não tenhamos problema nesta fase, o backend faz a utilização do cache para realizar a escrita, caso não tenha espaço em cache o backend tenta fazer a escrita direta no disco.
Na imagem 2 podemos observar o fluxo de escrita no PostgreSQL.
Imagem 2 – Fluxo de escrita no PostgreSQL
Quando falamos do fluxo de escrita no SQL Server ainda podemos utilizar a imagem 1 como exemplo onde no SQL Server a página de dados é alterada no data cache e depois sim é escrita em disco, sem alteração neste fluxo.
Na imagem 3 que foi retirada do artigo Transaction Log Write-ahead podemos observar como é realizada está escrita na memoria e só depois que está alteração é realizada e a escrita é confirmada em disco (Log) temos a confirmação que a consulta foi executada.
Imagem 3 – Escrita em log
No PostgreSQL o Wal é armazenado fisicamente no pg_xlog em arquivos de 16MB, está quantidade de arquivos pode ser limitada conforme o valor definido no checkpoint_segments que já é uma outra história.
Na imagem 4 podemos observar os arquivos o diretório pg_xlog e os arquivos de Wal com 16 MB cada.
Imagem 4 – Diretorio pg_xlog
