Arquitetura dos Dados

Quando começamos a estudar bancos de dados, quase tudo acontece no nível do SQL. Criamos tabelas, inserimos registros, executamos consultas e, aos poucos, passamos a enxergar os dados como linhas organizadas em colunas. Essa abstração é extremamente conveniente, afinal é exatamente assim que interagimos com um banco de dados todos os dias. O problema é que ela também esconde um detalhe importante: internamente, o banco quase nunca trabalha com registros individuais. Para ele, a unidade fundamental de armazenamento não é a linha de uma tabela, mas um bloco de dados chamado página.

Essa mudança de perspectiva parece pequena, mas ajuda a explicar boa parte das decisões de engenharia presentes nos bancos relacionais modernos. Também explica por que estruturas como as B+ Trees funcionam tão bem e por que uma simples consulta pode ser respondida em poucos milissegundos, mesmo quando a tabela possui centenas de milhões de registros.

O banco não lê linhas. Ele lê páginas.

É comum imaginar que, ao executar uma consulta como:

SELECT *
FROM clientes
WHERE id = 42;

o banco percorra o disco até encontrar exatamente a linha correspondente ao cliente de ID 42.

Na prática, isso não acontece.

O sistema operacional e o banco de dados trabalham com blocos de tamanho fixo. Quando um registro precisa ser acessado, o banco normalmente traz para a memória toda a página onde aquele registro está armazenado. No PostgreSQL e no SQL Server, essa página possui, por padrão, 8 KB. No InnoDB, mecanismo de armazenamento utilizado pelo MySQL, ela costuma ter 16 KB.

À primeira vista isso parece um desperdício. Afinal, por que carregar oito ou dezesseis quilobytes se a consulta precisa apenas de algumas dezenas de bytes?

A resposta está no comportamento das aplicações.

Os computadores gostam de acessar dados próximos

Existe um conceito clássico da Ciência da Computação chamado localidade de referência. A ideia é simples: quando um programa acessa um dado, existe uma grande probabilidade de que, logo em seguida, ele precise acessar informações próximas.

Pense em um e-commerce. Uma consulta encontra um pedido e, quase imediatamente, outra consulta busca seus itens. Em seguida aparecem os dados do cliente, o endereço de entrega e o histórico de pagamentos. Embora sejam consultas diferentes, elas costumam acessar regiões próximas do banco de dados.

Os projetistas dos bancos perceberam isso há décadas. Em vez de buscar um único registro por vez, faz muito mais sentido trazer um bloco inteiro de dados para a memória. Se outra consulta precisar de informações armazenadas naquela mesma página, nenhuma nova leitura do disco será necessária. O dado já estará disponível no cache.

É uma decisão aparentemente simples, mas que economiza milhares — às vezes milhões — de operações de entrada e saída ao longo do funcionamento de uma aplicação.

O verdadeiro inimigo sempre foi o armazenamento

Quando falamos sobre desempenho, muita gente imagina processadores cada vez mais rápidos ou algoritmos mais eficientes. Mas, historicamente, o maior gargalo dos bancos de dados nunca esteve na CPU.

Durante décadas, acessar um disco rígido era milhões de vezes mais lento do que executar uma instrução do processador. Mesmo com SSDs modernos, essa diferença continua sendo enorme. Enquanto uma operação em memória acontece em nanossegundos, acessar o armazenamento ainda custa microssegundos — uma eternidade para um computador.

É por isso que praticamente todas as estruturas de dados utilizadas pelos bancos seguem a mesma filosofia: reduzir ao máximo a quantidade de leituras necessárias.

As páginas existem justamente para isso.

Elas permitem que uma única leitura traga uma quantidade significativa de informações úteis para a memória, reduzindo a necessidade de novos acessos ao armazenamento.

É por isso que os índices funcionam tão bem

No artigo anterior discutimos por que as B+ Trees continuam dominando os bancos relacionais. Agora fica mais fácil entender uma das razões.

Cada nó de uma B+ Tree ocupa aproximadamente uma página do banco de dados. Como uma página pode armazenar centenas de chaves, basta ler poucas páginas para eliminar uma quantidade gigantesca de possibilidades durante uma busca.

É como consultar o índice de um livro. Você não precisa folhear todas as páginas procurando uma palavra. Primeiro encontra o capítulo correto e, a partir dali, chega rapidamente à informação desejada.

As B+ Trees fazem exatamente isso, mas utilizando páginas em vez de folhas de papel. A eficiência da árvore não depende apenas do algoritmo. Ela depende também da forma como o banco organiza seus dados fisicamente no armazenamento.

Então por que exatamente 8 KB?

Essa talvez seja a pergunta mais comum quando alguém descobre a existência das páginas. A resposta é menos interessante do que muita gente imagina: não existe nada de especial no número 8. Ele representa apenas um ponto de equilíbrio.

Páginas muito pequenas aumentam o número de leituras necessárias para responder uma consulta. Páginas grandes demais desperdiçam memória e transferem mais dados do que o necessário.

Ao longo da evolução dos bancos de dados, tamanhos entre 4 KB e 16 KB mostraram um bom compromisso entre desempenho, utilização do cache e custo das operações de entrada e saída. Cada banco fez escolhas diferentes, mas todos seguem exatamente a mesma ideia.

Não existe um tamanho universalmente melhor.

Existe apenas um conjunto de compensações.

A abstração que quase ninguém vê

Quando usamos um banco de dados, pensamos em tabelas, registros e consultas SQL. É natural, porque essa é a interface que utilizamos todos os dias.

Mas, internamente, o banco enxerga um mundo completamente diferente.

Ele organiza dados em páginas. Move páginas entre o disco e a memória. Mantém páginas em cache. Atualiza páginas durante uma transação. Constrói índices pensando em páginas.

Talvez esse seja um dos aspectos mais interessantes da engenharia de software: as melhores abstrações escondem uma enorme quantidade de complexidade sem que precisemos percebê-la.

As tabelas existem para nós. As páginas existem para o banco.

E entender essa diferença ajuda a explicar não apenas como um banco de dados funciona, mas por que tantas decisões de engenharia continuam as mesmas depois de décadas.