Bancos de dados na nuvem

O problema das 2 da manhã que um banco gerenciado resolve

Um banco de dados trava às 2 da manhã. Alguém precisa perceber, diagnosticar se foi um patch ruim, uma falha de disco ou uma query descontrolada, e trazer o banco de volta sem perder dados. Rodar um banco por conta própria, mesmo em uma máquina virtual na nuvem, significa que esse alguém é você. Um serviço de banco de dados gerenciado existe para que esse alguém seja o provedor, em tudo, exceto nas partes que só você consegue responder, como quais queries a sua aplicação realmente roda.

O que "gerenciado" realmente assume

O Amazon RDS é o modelo de um banco relacional gerenciado, e a própria documentação da AWS é específica sobre a divisão de responsabilidades. Compare rodar um banco on-premises, em uma instância EC2 simples e no RDS:

Sair do on-premises para a EC2 entrega o hardware físico para a AWS. Sair da EC2 para o RDS entrega quase tudo sobre rodar o próprio engine do banco: patches, backups, escalonamento, detecção e recuperação de falhas. O que fica com você em toda coluna é o ajuste fino de queries, porque isso depende inteiramente da sua aplicação específica, das suas queries específicas e dos seus dados específicos, um trabalho que nenhum serviço gerenciado consegue fazer em seu nome.

Bancos relacionais: linhas que se relacionam com outras linhas

Imagine a tabela Pedidos de uma loja online. Toda linha precisa de um cliente_id que aponte para uma linha real na tabela Clientes separada, e um produto_id que aponte para uma linha em Estoque. Essa relação obrigatória, um pedido que não pode existir sem um cliente e um produto correspondentes, é a característica definidora de um banco de dados relacional: dados organizados em tabelas com linhas e colunas, consultados com SQL, e conectados entre tabelas por chaves. O Amazon RDS suporta 6 engines nesse modelo: MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, Oracle Database e IBM Db2, todos consultáveis com o mesmo modelo relacional mesmo com engines diferentes por baixo.

Essa estrutura é exatamente o que um pedido precisa. Se um pagamento falha no meio do checkout, o banco não pode deixar um pedido apontando para uma linha de cliente ou estoque que não faz mais sentido, e bancos relacionais são construídos para garantir esse tipo de consistência.

Bancos NoSQL: buscas rápidas sem as relações

Agora imagine o placar de um jogo com 10 milhões de jogadores simultâneos, ou um carrinho de compras lido e reescrito a cada clique. Nenhum dos 2 precisa ser relacionado com outra tabela, e nenhum se beneficia do custo de garantir relações entre tabelas. Bancos NoSQL, modelados no Amazon DynamoDB, abandonam o modelo de tabelas e junções em favor de itens recuperados diretamente por uma chave, com uma estrutura flexível que pode variar de um item para outro. O DynamoDB anuncia desempenho de milissegundos únicos, atendendo dezenas de milhares ou centenas de milhões de usuários simultâneos, porque todo o desenho troca as relações entre itens por esse tipo de escala.

A fronteira: combine o modelo com o padrão de acesso

Exemplo prático: 1 plataforma, 2 bancos de dados

A mesma plataforma de e-commerce da lição anterior precisa dos 2 modelos ao mesmo tempo, não de uma escolha única entre eles. Pedidos, clientes e estoque vão para um banco relacional, porque um pedido que referencia um cliente inexistente ou uma linha de estoque errada é um bug, e o modelo relacional é o que impede isso. O conteúdo do carrinho e os dados de sessão vão para um banco NoSQL, porque esse dado muda o tempo todo, é lido em quase todo carregamento de página e nunca precisa ser relacionado com a tabela de Pedidos para cumprir sua função. Rodar os 2 lado a lado, em vez de forçar todo tipo de dado por um único modelo, é arquitetura normal, não uma solução de compromisso.

A armadilha: mais novo não significa universalmente melhor

É tentador tratar NoSQL como o upgrade moderno e relacional como a opção legada. Esse enquadramento ignora o que cada um abre mão de fato. NoSQL escala para uma carga concorrente enorme justamente porque não garante relações entre itens, exatamente a garantia da qual um sistema de pedidos e estoque depende. Uma aplicação bem projetada não escolhe um lado de uma vez só, ela coloca cada tipo de dado no modelo feito para o seu padrão de acesso, e é por isso que sistemas reais costumam rodar bancos relacionais e NoSQL lado a lado, em vez de escolher um para tudo.

Onde isso deixa você

Um serviço de banco de dados gerenciado assume patches, backups e recuperação de falhas para você focar nas queries e no esquema que só você entende. Recorra a um banco relacional quando registros precisam ficar consistentes entre tabelas, e recorra a NoSQL quando a carga é uma busca simples de alto volume que não precisa dessas relações. A próxima lição cobre como o tráfego realmente chega até esses bancos e a computação na frente deles: redes na nuvem.