PostgreSQL e SQL

O Lab 04 já está disponível no GitHub . Ele mantém uma réplica física do PostgreSQL atualizada por streaming e permite observar o que acontece quando ela fica temporariamente indisponível. Depois de exercitar backup, restore e PITR no Lab 03 , o próximo passo é acompanhar alterações continuamente. A replicação envia registros de WAL (Write-Ahead Log, o registro de alterações do PostgreSQL) do servidor principal, ou primary, à réplica, que os reproduz sobre uma cópia física do cluster. ...

Para testar uma consulta, muitas vezes precisamos de registros que ainda não existem. Para montar um relatório diário, precisamos mostrar inclusive as datas em que nenhum registro foi criado. O PostgreSQL oferece uma função útil nos dois casos: generate_series(). Ela produz um conjunto de linhas a partir de limites e de um passo. Esse conjunto pode alimentar um INSERT, compor um calendário ou participar de uma junção. No Lab 02 do PostgreSQL Reliability Lab , usei essa função na carga inicial de categorias, clientes e produtos. Neste episódio, vamos partir desse uso e construir um relatório que também mostra dias sem pedidos. ...

Ao estruturar os primeiros labs do PostgreSQL Reliability Lab, a pergunta que orientava cada etapa foi ficando mais exigente. Na fundação, eu precisava preparar um ambiente que pudesse ser iniciado e validado. Na inicialização, precisava entregar uma base com estrutura, permissões e dados coerentes. Em backup e recuperação, precisava demonstrar que o estado recuperado correspondia ao que o teste esperava. Essa evolução mudou o que considero uma entrega concluída em um laboratório. ...

Subconsultas colocadas no FROM normalmente são independentes das tabelas que aparecem antes delas. Mas alguns problemas exigem que a subconsulta seja avaliada para cada linha externa. Um exemplo comum é buscar os três produtos mais vendidos de cada categoria. No PostgreSQL, LATERAL permite expressar essa dependência diretamente. O problema Considere as tabelas: CREATE TABLE categories ( category_id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, name text NOT NULL UNIQUE ); CREATE TABLE products ( product_id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, category_id bigint NOT NULL REFERENCES categories, name text NOT NULL, sales_count integer NOT NULL DEFAULT 0 ); Queremos listar cada categoria acompanhada dos três produtos com maior sales_count. ...

Um container pode estar em execução sem que o PostgreSQL aceite conexões. O PostgreSQL pode aceitar conexões sem que o banco esperado, as roles, os schemas ou as tabelas estejam disponíveis. E todos esses objetos podem existir sem que os dados necessários tenham sido carregados corretamente. Ainda assim, é comum resumir essas situações a uma única informação: healthy O problema não está no healthcheck. O problema está em interpretar uma verificação específica como prova de que todo o sistema está pronto. ...

Agregações tradicionais reduzem várias linhas a um resultado por grupo. Isso é exatamente o que queremos ao calcular o total de vendas por vendedor. Mas e se precisarmos manter cada venda e, ao mesmo tempo, mostrar sua posição no ranking e o valor acumulado? Para esse tipo de problema, o SQL oferece funções de janela. O problema Considere uma tabela de vendas: CREATE TABLE vendas ( venda_id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, vendedor_id bigint NOT NULL, realizada_em timestamptz NOT NULL, valor numeric(12, 2) NOT NULL CHECK (valor > 0) ); Queremos exibir cada venda com: ...

Gerar um arquivo de backup e receber uma mensagem de sucesso é apenas o começo. O teste real acontece quando precisamos responder a perguntas mais difíceis: o arquivo pode ser lido? o PostgreSQL restaurado consegue iniciar? tabelas, índices, constraints e permissões continuam presentes? os dados recuperados representam o estado que esperávamos? conseguimos repetir o procedimento sem depender de improviso? Se essas respostas não foram verificadas, temos um artefato de backup, mas ainda não temos evidência de recuperação. ...

Consultas SQL costumam crescer de maneira incremental. Primeiro precisamos filtrar os dados. Depois agregar por cliente, calcular uma média, comparar cada resultado com essa média e ordenar somente os casos mais relevantes. Quando todas essas etapas ficam aninhadas em uma única expressão, a consulta pode continuar correta, mas se torna difícil de ler e modificar. Uma Common Table Expression, ou CTE, permite dividir esse raciocínio em resultados nomeados. O problema Considere uma tabela com execuções de pipelines: ...

No Lab 02 do PostgreSQL Reliability Lab , criamos uma base reproduzível com roles, schemas, extensões, tabelas relacionadas e dados suficientes para exercitar cenários operacionais. Essa base tornou possível fazer uma pergunta mais importante do que “temos backup?”: Conseguimos restaurar o banco e recuperar os dados até o ponto necessário depois de uma falha? Um arquivo de backup que nunca foi restaurado é apenas uma expectativa. Confiabilidade exige procedimento, evidência e conhecimento dos limites de recuperação. ...

Integrações, cargas de dados e consumidores de eventos frequentemente precisam executar uma operação simples de descrever: Se o registro ainda não existe, insira. Se já existe, atualize. Esse comportamento é conhecido como upsert, combinação de update e insert. No PostgreSQL, ele pode ser implementado com INSERT ... ON CONFLICT. O problema Considere uma tabela que registra o estado mais recente de cada pipeline em uma data de referência: CREATE TABLE pipeline_status ( pipeline text NOT NULL, reference_date date NOT NULL, status text NOT NULL, attempts integer NOT NULL DEFAULT 1, updated_at timestamptz NOT NULL DEFAULT now(), CONSTRAINT pipeline_status_uk UNIQUE (pipeline, reference_date) ); Uma mesma execução pode ser informada novamente por retry, reprocessamento ou entrega duplicada de mensagem. ...