Imagine que você esteja tentando organizar uma biblioteca massiva e caótica onde milhões de pessoas estão tentando pegar emprestados, ler e reescrever livros exatamente ao mesmo tempo. No mundo da ciência da computação, este é o desafio dos bancos de dados: sistemas que armazenam informações para que as aplicações possam encontrá-las e alterá-las instantaneamente. Por décadas, a grande questão foi como fazer essas bibliotecas crescerem para lidar com toda a internet sem colapsar. O modo antigo era como ter um único bibliotecário que tinha que carimbar cada livro, criando uma fila longa que atrasava todo mundo. O modo mais novo, a "consistência eventual", era como deixar as pessoas adivinharem o que o livro dizia e corrigir os erros mais tarde, o que é rápido, mas arriscado se você precisar da verdade agora mesmo. O objetivo da engenharia de banco de dados moderna é construir um sistema que seja tão rápido quanto o método de adivinhação, mas tão confiável quanto o método de carimbar, capaz de lidar com milhões de transações por segundo sem que ninguém jamais precise gerenciar as prateleiras manualmente.

Este artigo apresenta o Aurora DSQL, um novo tipo de banco de dados projetado pela Amazon Web Services para resolver exatamente este problema. Pense nele como uma biblioteca superinteligente e autônoma que pode expandir ou encolher instantaneamente dependendo de quantas pessoas estão visitando. Os autores construíram um sistema que separa o "pensamento" (executar o código SQL) do "armazenamento" (guardar os livros) e das "regras" (garantir que duas pessoas não alterem a mesma página ao mesmo tempo). Ao usar um "Journal" (Diário) especial que atua como um diário permanente e imutável de cada alteração feita, o DSQL permite que diferentes partes do sistema trabalhem de forma independente. O artigo mostra que esse design permite que o banco de dados escale de zero usuários a milhões de transações por segundo, funcione através de diferentes continentes sem ficar lento e mantenha os dados perfeitamente consistentes, para que você nunca tenha que se preocupar em ler um livro que alguém está reescrevendo no momento.

A Magia da Biblioteca Desconectada

Para entender como o Aurora DSQL funciona, imagine uma biblioteca gigante onde os bibliotecários, as estantes e os guardiões das regras estão todos em prédios diferentes, conectados por telegramas super-rápidos. Em sistemas antigos, essas partes eram coladas; se as estantes ficassem cheias demais, a biblioteca inteira tinha que parar e se reorganizar. O DSQL as separa.

Primeiro, existem os Processadores de Consulta (Query Processors). Estes são os bibliotecários que falam com você. Quando você pede um livro, eles não carregam os livros pesados eles mesmos. Em vez disso, eles rodam dentro de pequenas salas virtuais seguras chamadas Firecracker MicroVMs. Essas salas são tão eficientes que podem ser criadas ou destruídas num piscar de olhos. Se você tiver um aumento repentino de visitantes, o sistema constrói instantaneamente mais salas. Se o movimento parar, ele as destrói para que você não pague por espaço vazio. Esta é a parte "serverless": você não gerencia os bibliotecários; eles simplesmente aparecem quando você precisa deles.

Em seguida, existem os Nós de Armazenamento (Storage Nodes). Estas são as estantes. Elas não guardam a biblioteca inteira; elas guardam apenas seções específicas de livros baseadas em uma "chave de partição" (shard key) (como ordenar livros pela primeira letra do nome do autor). Como os bibliotecários e as estantes são separados, os bibliotecários podem realizar seu próprio trabalho sem esperar que as estantes alcancem o ritmo deles. Eles leem da estante mais próxima em seu próprio bairro (Zona de Disponibilidade), o que torna a leitura incrivelmente rápida.

Finalmente, existem os Adjudicadores (Adjudicators) e o Journal (Diário). Os Adjudicadores são os guardiões das regras que decidem se uma alteração é permitida. O Journal é o diário mestre. Quando você quer alterar um livro (uma "escrita"), o bibliotecário escreve a alteração em um papel, mas não a coloca na estante ainda. Ele a envia para o guardião da regra. O guardião verifica se mais alguém está tentando alterar aquele mesmo livro ao mesmo tempo. Se estiver livre, o guardião escreve a alteração no Journal. Este Journal é a parte mais importante: é uma lista permanente e ordenada de cada alteração que já aconteceu. Uma vez que algo está no Journal, está seguro para sempre, mesmo que as estantes ou os bibliotecários desapareçam.

O Truque da Leitura "Sem Espera"

Um dos truques mais legais deste artigo é como ele lida com a leitura. Em muitos bancos de dados, se você quiser ler um livro, tem que esperar o bibliotecário garantir que ninguém está escrevendo nele no momento. Isso causa filas e atrasos. O DSQL usa um truque inteligente de viagem no tempo chamado Controle de Concorrência de Múltiplas Versões (MVCC - Multi-Version Concurrency Control).

Imagine que, toda vez que um livro é alterado, a biblioteca não apaga a versão antiga. Em vez disso, ela cria uma nova cópia com um registro de tempo (timestamp). Quando você pede um livro, você não pede "o livro"; você pede "o livro como ele estava às 14:00". O sistema então encontra a versão que era válida às 14:00. Como o sistema utiliza relógios superprecisos (precisos em microssegundos), ele sabe exatamente qual versão mostrar a você. Isso significa que você pode ler um livro enquanto outra pessoa está escrevendo um novo, e você não verá as alterações bagunçadas e inacabadas dela. Você vê um snapshot perfeito e congelado do passado. Isso permite que milhões de pessoas leiam ao mesmo tempo sem nunca bloquearem umas às outras.

O Superpoder Multirregional

O artigo também aborda o problema da distância. Normalmente, se você tem uma biblioteca em Nova York e outra em Londres, mantê-las sincronizadas leva tempo devido à velocidade da luz. Se você tentar atualizar um livro em ambos os lugares ao mesmo tempo, terá que esperar uma mensagem viajar pelo oceano, o que atrasa tudo.

O DSQL resolve isso sendo ativo-ativo (active-active). Isso significa que você pode ter uma biblioteca em Nova York e uma biblioteca em Londres, e ambas podem estar totalmente abertas para negócios ao mesmo tempo. Quando você faz uma alteração em Nova York, o sistema a escreve no Journal. O Journal então envia uma cópia para Londres. A mágica é que isso acontece apenas uma vez, no exato momento em que você clica em "commit" (finaliza a transação). O sistema não impede você de ler ou escrever enquanto a mensagem viaja. Ele utiliza um sistema de "quórum", o que significa que só precisa confirmar a alteração em dois de três regiões para considerá-la segura.

O artigo mediu isso e descobriu que, mesmo com a distância entre Virgínia e Oregon (cerca de 62 milissegundos de ida e volta), o sistema paga esse "imposto de distância" apenas uma vez por transação. Para a leitura, é ainda mais rápido porque você lê da biblioteca local. Os autores mostram que esse design permite que o banco de dados permaneça rápido e consistente mesmo se uma região inteira (como uma cidade inteira) ficar offline devido a um desastre.

As Regras do Jogo

Os autores foram muito cuidadosos com o que prometeram. Eles escolheram o Isolamento de Snapshot (Snapshot Isolation), que é um conjunto específico de regras sobre como as transações se comportam. É como dizer: "Você pode ler o livro como ele estava quando começou a ler, e pode alterá-lo quando terminar, mas se alguém o alterou nesse meio tempo, você terá que tentar novamente". Isso é diferente de regras mais rígidas que o forçariam a esperar por um bloqueio (lock), o que atrasaria as coisas.

O artigo descarta explicitamente a ideia de que você precisa de um único "líder" para gerenciar tudo. Em muitos sistemas, um computador é o chefe e, se ele quebrar, tudo para. O DSQL não tem um chefe único. Cada parte pode escalar para cima ou para baixo, e se uma parte falhar, as outras continuam funcionando. O artigo também descarta a ideia de que você precisa gerenciar o hardware por conta própria. O sistema lida com o "calor" (quais partes estão ficando muito ocupadas) automaticamente. Se uma seção da biblioteca ficar muito cheia, o plano de controle (o gerente da biblioteca) divide automaticamente essa seção em duas menores e move alguns livros para uma nova estante, tudo sem que você faça nada.

Testando a Teoria

Os autores não apenas adivinharam que isso funcionaria; eles testaram exaustivamente. Eles usaram um método chamado simulação determinística, onde rodaram o sistema em um programa de computador que podia simular milhões de erros, atrasos de rede e falhas em uma fração de segundo. Eles descobriram que o sistema podia lidar com esses erros sem perder dados ou ficar confuso.

Eles também realizaram testes de estilo real (como o benchmark TPC-C, que simula uma loja movimentada). Os resultados mostraram que o DSQL pode escalar de um início a frio (onde possui muito poucos recursos) para lidar com milhões de operações por minuto. Levou cerca de 25 minutos para atingir a velocidade total a partir de um estado completamente vazio, mas uma vez "aquecido", era incrivelmente rápido. O artigo observa que, embora estejam muito confiantes nesses resultados, ainda estão trabalhando na adição de mais recursos, como chaves estrangeiras (que ligam tabelas entre si) e procedimentos armazenados.

A Conclusão

O Aurora DSQL é uma prova de que você pode ter o melhor dos dois mundos: um banco de dados que é tão fácil de usar quanto um serviço simples (onde você não gerencia nada) e tão poderoso quanto um sistema global massivo. Ao separar o pensamento, o armazenamento e as regras, e ao usar um diário permanente para rastrear o tempo, ele permite que as aplicações cresçam de zero a milhões de transações sem perder o fôlego. É um sistema projetado para um mundo onde as coisas mudam rápido, onde desastres acontecem e onde você precisa saber que a informação que está lendo é a verdade absoluta, agora mesmo.