Banco de dados: arquitetura, modelos e garantias do SGBD

Quase toda aplicação crítica tem um banco de dados no caminho. Mesmo assim, boa parte dos times que opera sistemas em produção raramente abre a caixa para entender o que acontece lá dentro quando uma query é executada.

Este artigo trata de banco de dados pela perspectiva de engenharia. Em vez de repetir a definição genérica, o foco é arquitetural: como um SGBD organiza as camadas internas, por que alguns modelos servem para certos workloads e outros não, como as garantias transacionais são implementadas e onde estão os pontos que toda equipe de operações acaba monitorando mais cedo ou mais tarde.

A leitura serve a quem programa, opera ou arquiteta sistemas e quer parar de tratar o banco como caixa preta. Cada seção foi pensada para conectar conceito com sinal operacional, porque é exatamente nessa ponte que decisões de design e de monitoramento nascem.

O que é banco de dados: a definição que importa para quem opera

Um banco de dados é uma coleção organizada de dados persistida em um meio durável e acessada por múltiplos consumidores simultaneamente. Essa definição parece genérica, mas três palavras carregam as garantias mais difíceis de entregar: organizada, persistida e múltiplos consumidores.

Na prática, qualquer sistema que combine essas três propriedades precisa resolver problemas incompatíveis entre si. Organizar dados exige esquema ou estrutura. Persistir exige durabilidade diante de falhas de energia ou kernel panic. Concorrência exige ordenação de operações que chegam ao mesmo tempo pedindo leitura e escrita no mesmo recurso.

É por isso que existe uma distinção importante entre banco de dados e SGBD (sistema de gerenciamento de banco de dados). O banco é o dado organizado. O SGBD é o software que orquestra acesso, concorrência, durabilidade, indexação e recuperação. Quando alguém diz “estou usando PostgreSQL”, está se referindo ao SGBD. O banco é o conjunto de tabelas que esse SGBD gerencia.

As três garantias mínimas que um SGBD sério entrega são persistência (o dado sobrevive a reinicializações), controle de concorrência (duas transações simultâneas não corrompem o estado) e durabilidade (uma escrita confirmada não se perde, mesmo com crash).

Modelos e produtos diferentes escolhem caminhos diferentes para entregar cada uma dessas garantias e é aí que a arquitetura interna começa a importar.

Arquitetura interna de um SGBD: o caminho de uma query

Quando uma aplicação envia SELECT nome FROM clientes WHERE id = 42, essa string passa por seis estágios dentro do SGBD antes de virar uma resposta. Entender esse pipeline é o que separa quem usa banco de quem opera banco com autoridade.

➡️ O primeiro estágio é o parser. Ele valida a sintaxe, resolve identificadores contra o catálogo de metadados (a tabela clientes existe? a coluna nome existe?) e produz uma árvore de análise. Se a query é malformada ou referencia objeto inexistente, o erro nasce aqui.

➡️ O segundo estágio é o otimizador, também chamado de query planner. Ele recebe a árvore do parser e gera vários planos de execução equivalentes em resultado mas diferentes em custo.

➡️ Custo aqui é uma estimativa baseada em estatísticas (cardinalidade, seletividade de índices, tamanho das tabelas) coletadas em segundo plano. O otimizador escolhe o plano de menor custo esperado e o envia para o executor.

➡️ O terceiro estágio é o executor. Ele percorre o plano como uma árvore de operadores (scan, filter, join, sort) e invoca o storage engine para cada leitura ou escrita.

➡️ O quarto estágio é o buffer pool, uma camada de cache em memória que mantém as páginas mais acessadas recentemente. Se a página está no buffer, a leitura é quase instantânea. Se não está, ocorre um cache miss e o storage engine busca em disco.

➡️ O quinto estágio é o storage engine propriamente dito. Ele organiza os dados em páginas de tamanho fixo (tipicamente 4 KB, 8 KB ou 16 KB), mantém índices apontando para essas páginas e cuida da disposição física em disco. Cada SGBD tem seu storage engine característico (InnoDB no MySQL, heap+btree no PostgreSQL, LSM-tree em bases como RocksDB e Cassandra).

➡️ O sexto estágio é o WAL (write-ahead log), também conhecido como redo log. Toda escrita é primeiro registrada sequencialmente no WAL antes de ser aplicada às páginas de dados. Esse passo é o que permite recuperação após crash: no restart, o SGBD relê o WAL a partir do último checkpoint e reaplica as transações confirmadas.

Esse pipeline tem reflexos operacionais diretos. Um buffer pool com hit ratio baixo significa leitura constante em disco. Um plano de execução ruim aparece como query lenta no log. Um WAL saturado gera backpressure em escritas. Por isso a observabilidade aplicada a bancos de dados olha para esses sinais internos e não só para o tempo total da query.

Modelos de dados: como cada família organiza a informação

O SGBD é o motor. O modelo de dados é a gramática que ele impõe sobre a informação. A escolha do modelo define o que é fácil e o que é caro fazer depois. Cinco famílias dominam a prática atual.

O modelo relacional organiza dados em tabelas com colunas tipadas e relaciona registros via chaves primárias e estrangeiras. É o padrão desde os anos 1970 porque SQL resolve bem consultas declarativas arbitrárias. PostgreSQL, MySQL, Oracle e SQL Server são os exemplos canônicos. Para aprofundar em um representante específico, vale o guia sobre o SGBD MySQL.

O modelo documento armazena registros semiestruturados (JSON ou BSON) com esquema flexível por documento. Cada registro carrega sua própria estrutura. MongoDB e CouchDB são os exemplos.

Serve bem quando o esquema muda com frequência ou quando o agregado é naturalmente hierárquico, como um pedido com seus itens aninhados. Para cenários de ingestão bruta em larga escala, o modelo também é a base de muitos data lakes.

O modelo chave-valor é o mais simples: uma chave aponta para um blob opaco. Leitura e escrita são O(1) por chave e não existe consulta por atributo. Redis e DynamoDB são os exemplos. Serve para cache, sessões, contadores e qualquer coisa com padrão de acesso por identificador único.

O modelo grafo representa entidades como vértices e relacionamentos como arestas, ambos com atributos. Consultas percorrem caminhos em vez de fazer joins. Neo4j é o exemplo mais conhecido. Serve para recomendação, detecção de fraude e qualquer domínio em que o relacionamento em si é o dado principal.

O modelo colunar armazena por coluna em vez de por linha. Leituras analíticas que agregam uma coluna inteira em bilhões de registros ficam uma ou duas ordens de grandeza mais rápidas do que em modelo relacional orientado a linha. ClickHouse, BigQuery e Redshift são os exemplos. É a base de grande parte dos data warehouses modernos.

Cada modelo resolve bem um conjunto de padrões de acesso e mal os demais. Se o objetivo é comparar produtos específicos e escolher um para um projeto, o guia comparativo dos principais bancos de dados traz a análise produto a produto. Este artigo segue no plano arquitetural, para explicar por que cada modelo se comporta como se comporta.

ACID, BASE e níveis de isolamento: as garantias transacionais

Toda escrita minimamente importante é embrulhada em transação: um bloco de operações que deve ser aplicado por inteiro ou não ser aplicado de forma alguma. O modelo clássico para raciocinar sobre transações é ACID, acrônimo formado por quatro propriedades.

Atomicidade garante que todas as operações da transação aparecem como uma unidade indivisível. Consistência garante que o banco passa de um estado válido para outro estado válido conforme as regras de integridade. Isolamento controla como transações concorrentes enxergam umas às outras. Durabilidade garante que o commit sobrevive a falhas de sistema.

Bancos distribuídos que priorizam disponibilidade sobre consistência estrita adotam o modelo BASE: basicamente disponível, estado mole e consistência eventual. Em vez de rejeitar escritas quando nós estão inacessíveis, eles aceitam e reconciliam depois. Dynamo, Cassandra e muitos sistemas NoSQL se encaixam nesse perfil.

A documentação oficial do PostgreSQL detalha o modelo MVCC que o Postgres usa para implementar isolamento sem bloquear leituras com escritas.

Dentro de ACID, o isolamento é a propriedade mais escorregadia na prática. O padrão ANSI SQL define quatro níveis, cada um impedindo um subconjunto de anomalias:

Dirty read é ler dado de transação ainda não confirmada. Non-repeatable read é ler o mesmo registro duas vezes na mesma transação e obter valores diferentes. Phantom read é reexecutar uma consulta de faixa e ver registros novos que não existiam antes.

Subir o nível de isolamento elimina anomalias mas aumenta contenção e reduz throughput, portanto a escolha é trade-off e não default universal.

Indexação: B-tree, hash e bitmap

Sem índice, toda consulta que filtra por atributo precisa fazer full scan: ler a tabela inteira linha a linha. Em tabelas de milhões de registros, isso é inviável. O índice é uma estrutura auxiliar que organiza valores de uma ou mais colunas de forma que o lookup seja sub-linear.

O B-tree é a estrutura de índice mais comum. É uma árvore balanceada em que cada nó contém várias chaves ordenadas e a busca desce pela árvore até a folha que aponta para o registro. Custo de busca é O(log n).

Serve bem para consultas de igualdade (WHERE id = 42) e de faixa (WHERE data BETWEEN ... AND ...) e é o padrão no PostgreSQL, MySQL e Oracle.

Quem trabalha com planos de execução lentos sabe que boa parte do trabalho de otimização é garantir que o B-tree certo seja escolhido, assunto tratado em profundidade no guia de otimização de performance no PostgreSQL.

O hash mapeia cada chave a um bucket via função de hash. Busca por igualdade é O(1) no caso médio, mais rápida que B-tree. O custo é que não serve para consultas de faixa (o hash destrói a ordem das chaves) e sofre com alta colisão.

É a estrutura natural para chaves-valor puros como Redis e para índices específicos em bancos relacionais quando o padrão de acesso é exclusivamente por igualdade.

O bitmap representa cada valor possível da coluna como um vetor de bits em que cada bit corresponde a um registro. Colunas com baixa cardinalidade (sexo, estado civil, região) viram bitmaps compactos que respondem consultas com operadores booleanos eficientes (AND, OR).

Serve bem para data warehouses e cargas analíticas. Mal para OLTP com escritas frequentes, porque toda atualização precisa recalcular vários bitmaps.

A escolha de qual índice criar é decisão de design. Índices aceleram leitura mas custam espaço e tornam escritas mais lentas, porque cada INSERT ou UPDATE precisa atualizar todos os índices da tabela. Bancos bem-afinados têm índices deliberadamente escolhidos, não acumulados.

Replicação e alta disponibilidade

Um único nó de banco é ponto único de falha. Replicação é a técnica de manter cópias do dado em nós adicionais para sobreviver à queda de um deles e, em muitos casos, para distribuir carga de leitura.

O modelo mais comum é primário-réplica: um nó aceita escritas e propaga o WAL para um ou mais nós secundários que aplicam as mesmas mudanças. A replicação pode ser síncrona (o primário só confirma o commit depois que a réplica confirmou a recepção) ou assíncrona (o primário confirma imediatamente e a réplica fica eventualmente em dia).

A escolha entre síncrono e assíncrono é trade-off direto entre RPO (recovery point objective, quanto dado aceito se perder em caso de falha) e latência de escrita. Replicação síncrona zera o RPO mas paga em latência adicional em cada commit. Assíncrona mantém a latência baixa mas expõe uma janela de replication lag em que escritas aceitas ainda não estão replicadas.

Arquiteturas multi-primário (como Cassandra e a maioria dos bancos em estilo Dynamo) aceitam escritas em qualquer nó e usam protocolos de reconciliação baseados em quórum. Eles trocam consistência estrita por disponibilidade diante de partição de rede, conforme o teorema CAP. Para quem quer entender os protocolos por trás, a especificação do protocolo Raft é referência obrigatória.

Alta disponibilidade depende também de failover: o processo automático ou assistido de promover uma réplica a primário quando o primário original falha.

Failover mal-configurado causa dois problemas clássicos: split-brain (dois primários aceitando escritas em paralelo) e perda de dados na janela de replication lag. É por isso que monitorar o banco de dados com visibilidade contínua do lag, da posição do WAL e do estado de replicação é pré-requisito para qualquer operação séria.

Normalização vs desnormalização

Normalização é o processo de eliminar redundância em um esquema relacional aplicando formas normais sucessivas. A primeira forma normal (1FN) exige atomicidade dos valores (nenhum campo carrega lista). A segunda (2FN) elimina dependências parciais em chaves compostas. A terceira (3FN) elimina dependências transitivas.

Um esquema em 3FN tem cada fato em exatamente um lugar. Atualizações são baratas e consistentes porque não há duplicação. O custo é que consultas que precisam combinar informação passam a depender de joins. Joins entre tabelas grandes custam I/O e CPU.

Desnormalização é o movimento inverso: duplicar deliberadamente dados em várias tabelas ou em uma única tabela larga para evitar joins e acelerar leitura. O custo é escrita mais cara e risco de inconsistência, porque o mesmo fato precisa ser atualizado em múltiplos lugares.

Em OLTP (transactional, escritas frequentes, integridade crítica), normalização vence. Em OLAP (analytical, leituras massivas, agregações complexas), desnormalização vence.

Por isso data warehouses usam esquemas estrela ou floco de neve, com uma tabela fato central desnormalizada e dimensões ao redor. A decisão correta depende do workload, não de preferência estética.

Equipes que operam ambos os regimes em produção geralmente separam fisicamente OLTP e OLAP, com pipelines de engenharia de dados movendo dados do primeiro para o segundo em lotes ou em streaming.

Quando usar cada modelo: guia de decisão

A pergunta prática que fecha o raciocínio arquitetural é: qual modelo serve a qual workload? A tabela abaixo organiza as escolhas típicas.

Arquiteturas modernas raramente ficam em um único modelo. É comum ver OLTP relacional combinado com cache chave-valor e data warehouse colunar na mesma empresa.

A prática se chama polyglot persistence e exige observabilidade transversal para acompanhar o que acontece em cada banco sem precisar pular de console em console. Referências de isolamento e MVCC em RDBMS tradicionais podem ser consultadas também no guia de concorrência do Oracle.

Conclusão

Tratar banco de dados como caixa preta funciona até o dia em que uma query lenta em produção, um lag de replicação ou um deadlock começa a custar dinheiro. O caminho para parar de operar no escuro é entender a arquitetura interna do SGBD, reconhecer o modelo certo para cada workload e acompanhar as garantias transacionais como parâmetros conscientes, não como defaults invisíveis.

A boa notícia é que o mesmo conjunto de conceitos se aplica a PostgreSQL, MySQL, Oracle, MongoDB, Cassandra ou ClickHouse. Muda o produto, mas parser, otimizador, storage engine, isolamento, índice, WAL e replicação continuam sendo os pilares comuns. Dominar esses pilares é o que permite uma equipe escolher, afinar e monitorar qualquer banco com o mesmo rigor.

Se o próximo passo é traduzir essa arquitetura em visibilidade operacional concreta sobre seus bancos críticos, fale com um especialista da OpServices para entender como o monitoramento contínuo pode cobrir replicação, planos de execução e saúde do storage engine de ponta a ponta.