08. Banco de dados em memória

Eliminar grande parte do acesso a disco reduz latência, mas torna memória, persistência e expiração decisões centrais. O ganho de velocidade precisa ser combinado com o nível de durabilidade exigido pelo caso.

Com o modelo e a linguagem estabelecidos, passamos a cuidar do banco em funcionamento. A sequência liga governança, arquitetura interna, transações, desempenho, observabilidade, segurança, recuperação e soluções em memória. Este é o capítulo 8 de 8 da disciplina Administração de Bancos de Dados. A leitura retoma Backup, restauração e recuperação e usa essa base para avançar. Como encerramento, ele reúne e amplia as ideias construídas ao longo da disciplina.

O fio condutor

Banco de dados deve ser estudado como um sistema de decisões conectadas. O significado atribuído ao dado orienta o modelo; o modelo condiciona consultas e atualizações; o SGBD executa essas operações sob regras de segurança, concorrência, desempenho e recuperação. Quando uma dessas camadas muda, as demais podem ser afetadas.

Ao longo da leitura, acompanhe sempre quatro perguntas: qual problema está sendo resolvido, qual estrutura representa o problema, que garantia precisa ser preservada e qual custo acompanha a escolha. Esse roteiro ajuda a compreender os conceitos em vez de apenas memorizar nomes.

Por que é mais rápido — e o que não muda

Começamos por Por que é mais rápido — e o que não muda, pois essa base permite compreender as decisões apresentadas nas seções seguintes.

A vantagem é física: acesso à RAM custa nanossegundos, e acesso a disco — mesmo SSD — custa microssegundos a milissegundos. Com todo o conjunto residente em memória, nenhuma operação corre o risco de esbarrar em E/S de disco. Mesmo comparado a um SGBD com buffer pool quente, ainda há economia: o buffer precisa localizar a página em sua estrutura de controle, sincronizar acesso concorrente a ela e conviver com a hipótese de a página ter sido substituída.

Repare como RAM × disco, Rede continua, Teto de memória participam da mesma decisão. Ao relacionar esses elementos, fica mais fácil prever o comportamento do banco e reconhecer os efeitos de cada escolha.

Durabilidade: snapshot e log

A seção anterior apresentou Por que é mais rápido — e o que não muda. Agora chegamos a Durabilidade: snapshot e log, que acrescenta a próxima peça do mesmo raciocínio.

O grau de durabilidade do AOF depende da política de sincronização: com appendfsync always, cada escrita é sincronizada antes de confirmada — próximo do commit síncrono de um relacional, com o custo correspondente; com sincronização a cada segundo, ganha-se desempenho e aceita-se perder até aquele intervalo. Afirmar que o AOF garante durabilidade total "em qualquer configuração" é uma generalização que deve ser evitada.