Quando Usar o DynamoDB (e Quando Não Usar)

O DynamoDB é um banco de dados fantástico para as cargas de trabalho para as quais foi feito e frustrante para o resto. A pergunta decisiva não é "ele é web-scale?" — é "eu conheço meus padrões de acesso de antemão, e eles são baseados em chave?" Acerte isso e o DynamoDB te dá leituras de poucos milissegundos em qualquer escala; erre e você vai brigar para sempre com a falta de joins e de consultas ad-hoc.

Quando devo usar o DynamoDB?

Use o DynamoDB quando seus padrões de acesso são conhecidos, baseados em chave e de alto volume, e você quer latência previsível de poucos milissegundos em qualquer escala, sem servidores para gerenciar. Evite-o para consultas ad-hoc, joins ricos ou analytics sobre todo o conjunto de dados, e quando os dados são pequenos e os formatos das consultas vivem mudando.

• Use o DynamoDB quando seus padrões de acesso são conhecidos, baseados em chave e de alto volume — e você quer latência previsível em qualquer escala, sem servidores para gerenciar.
• Evite-o quando você precisa de consultas ad-hoc, joins ricos ou analytics sobre todo o conjunto de dados, ou quando os dados são pequenos e os formatos das consultas vivem mudando.
• O trade central: o DynamoDB faz você projetar para suas consultas de antemão; em troca, ele nunca fica mais lento conforme você cresce.
• Ele não é um banco de dados relacional com uma sintaxe diferente — modelá-lo como um é a fonte de dor número 1.

Os sinais que favorecem o DynamoDB

O DynamoDB brilha quando a maioria destes se aplica:

• Você conhece seus padrões de acesso com antecedência. Você consegue listar as consultas exatas que o app faz ("buscar um usuário por id", "listar os pedidos de um usuário, do mais novo ao mais antigo") e elas não mudam por capricho. O DynamoDB é modelado em torno dessas consultas.
• O acesso é baseado em chave. Você busca itens por uma chave de partição conhecida, não varrendo combinações arbitrárias de atributos.
• Escala e latência previsível importam. O DynamoDB entrega desempenho consistente de poucos milissegundos seja a tabela com mil itens ou com um bilhão.
• Você quer zero sobrecarga operacional. Sem instâncias, sem failover, sem vacuum — é totalmente gerenciado e escala até zero sob demanda.
• O throughput de escrita é alto e instável. Logs de eventos, telemetria de IoT, estado de sessão/carrinho, placares — cargas de trabalho com muitos appends e uma chave clara.

Os sinais contra ele

Recorra a um banco de dados relacional (ou a um motor de busca/analytics) quando:

• Suas consultas são ad-hoc. Analistas fatiam os dados por colunas arbitrárias, ou os requisitos mudam toda semana. A flexibilidade do SQL vence; o DynamoDB precisaria de um novo índice por padrão.
• Você precisa de joins e agregações de verdade sobre todo o conjunto de dados. Relatórios, business intelligence, "somar a receita por região por mês" — isso é trabalho de OLAP/relacional.
• O conjunto de dados é pequeno e de baixo tráfego. Alguns milhares de linhas num app administrativo tranquilo não se beneficiam da escala do DynamoDB e perdem a conveniência do SQL.
• Você ainda não consegue prever os padrões de acesso. Produto em estágio inicial ainda encontrando sua forma? Um schema relacional que você pode reconsultar livremente é mais tolerante até os padrões se estabilizarem.

Calculando o custo antes de se comprometer

O preço do DynamoDB segue leituras, escritas e armazenamento — não horas de instância — então é barato para cargas instáveis e serverless e pode ser caro para varreduras pesadas e sustentadas. Modele seu mix real de leitura/escrita com a calculadora de preços do DynamoDB antes de se comprometer; uma carga de trabalho que parece tecnicamente adequada também deve fechar na conta de custo.

Depois de decidir que serve

O trabalho passa a ser modelagem. O DynamoDB recompensa projetar a tabela em torno das suas consultas — veja como modelar dados no DynamoDB e single-table design — e explicitamente quando não recorrer ao single-table.

Armadilhas e próximos passos

• Não modele o DynamoDB como um banco de dados relacional — tabelas normalizadas que você junta com join na hora da leitura é o antipadrão que ele mais castiga.
• Não o escolha para analytics — combine-o com um armazenamento de analytics (ou exporte para um) para relatórios, em vez de varrer.
• Inseguro sobre os padrões de acesso? Espere. Adotar o DynamoDB antes de conhecer suas consultas é escolher justamente o banco de dados que exige que você as conheça.
• Relacionado: query vs scan mostra o que o "acesso baseado em chave" realmente te dá.

Quer explorar uma tabela do DynamoDB antes de apostar seu app nela? Baixe o DynoTable e conecte-se aos seus dados diretamente.