Quando usar DynamoDB (e quando não)

DynamoDB é um banco de dados fantástico para as cargas de trabalho para as quais foi criado e um frustrante um para o resto. A questão decisiva é "eu sei meus padrões de acesso antecipadamente e eles são baseados em chave?" Faça certo e DynamoDB fornece leituras de um dígito em milissegundos em qualquer escala; entenda errado e você lutará a falta de junções e consultas ad hoc para sempre.

Quando devo usar o DynamoDB?

Use DynamoDB quando seus padrões de acesso forem conhecidos, baseados em chaves e de alto volume, e você desejam latência previsível de um dígito em milissegundos em qualquer escala com zero servidores para gerenciar. Evite-o para consultas ad hoc, junções avançadas ou análises de todo o conjunto de dados e quando os dados são pequenos e os formatos de consulta estão sempre mudando.

• Use DynamoDB quando seus padrões de acesso forem conhecidos, baseados em chave e de alto volume — e você deseja latência previsível em qualquer escala, sem servidores para gerenciar.
• Evite quando precisar de consultas ad hoc, junções avançadas ou análises gerais conjunto de dados ou quando os dados são pequenos e os formatos de consulta continuam mudando.
• O comércio principal: DynamoDB faz com que você projete suas consultas antecipadamente; em troca isso nunca desacelera à medida que você cresce.
• Não é um banco de dados relacional com uma sintaxe diferente — modelando-o como se fosse a fonte número 1 de dor.

Os sinais que favorecem o DynamoDB

DynamoDB brilha quando a maioria deles se mantém:

• Você conhece seus padrões de acesso com antecedência. Você pode listar as consultas exatas do aplicativo faz ("obter um usuário por ID", "listar os pedidos de um usuário mais novos primeiro") e eles não mudam por capricho. DynamoDB é modelado em torno dessas consultas.
• O acesso é baseado em chave. Você procura itens por uma chave de partição conhecida, não por varredura para combinações arbitrárias de atributos. A escala e a latência previsível são importantes. O DynamoDB oferece milissegundo de um dígito consistente desempenho, quer a tabela contenha mil itens ou um bilhão.
• Você deseja zero sobrecarga operacional. Sem instâncias, sem failover, sem limpeza — é totalmente gerenciado e dimensionado para zero on-demand.
• A taxa de transferência de gravação é alta e pontiaguda. Logs de eventos, telemetria IoT, session/cart estado, tabelas de classificação – cargas de trabalho pesadas com acréscimos com uma chave clara.

Os sinais contra isso

Procure um banco de dados relacional (ou um mecanismo search/analytics) quando:

• Suas consultas são ad-hoc. Os analistas dividem os dados em colunas arbitrárias ou os requisitos mudam semanalmente. A flexibilidade do SQL vence; DynamoDB precisaria de um novo índice por padrão.
• Você precisa de junções e agregações reais em todo o conjunto de dados. Relatórios, inteligência de negócios, "soma da receita por região por mês" - isso é um OLAP/relational trabalho. (A questão única contra uma mesa ativa é um caso diferente — bancada de trabalho SQL do DynoTable executa JOIN, GROUP BY, e agrega no lado do cliente DynamoDB; é a carga de trabalho permanente de BI que pertence a outro lugar.)
• O conjunto de dados é pequeno e de baixo tráfego. Alguns milhares de linhas em um aplicativo de administração silencioso não obtém nenhum benefício da escala do DynamoDB e perde a conveniência do SQL.
• Você ainda não pode prever padrões de acesso. Produto em estágio inicial ainda encontra seu forma? Um esquema relacional que você pode consultar novamente livremente é mais indulgente até que o os padrões se estabelecem.

Como o DynamoDB se compara a outros bancos de dados

"Devo usar DynamoDB ou X?" geralmente é a mesma pergunta com roupas diferentes: faz X deixe-me adiar a decisão do padrão de acesso e quanto devo pagar por isso? DynamoDB é a opção que se recusa a permitir que você adie. Cada comparação abaixo ativa essa comércio, não em listas de verificação de recursos.

Relacional: PostgreSQL, RDS e Aurora

Este é o verdadeiro garfo, e aquele que a maioria das equipes erra. Um banco de dados relacional permite escreva a consulta depois de ter os dados. O DynamoDB não — a mesa é moldada pelo consultas antes que um único item seja gravado.

Escolha relacional quando as formas de consulta ainda estiverem em movimento, quando você precisar de junções ou agregados em todo o conjunto de dados, ou quando os dados são pequenos o suficiente para que a escala não seja o problema que você tem. Escolha DynamoDB quando os padrões estiverem definidos e baseados em chave e você queremos que eles custem o mesmo em um bilhão de itens e em mil.

O RDS e o Aurora não alteram esse cálculo — eles são mecanismos relacionais gerenciados, portanto eles herdam a flexibilidade do SQL e seu modelo de escala. O que eles mudam é o operacional comparação: com Aurora Serverless, o argumento "nenhum servidor para gerenciar" para DynamoDB é obtido muito mais fraco, e a decisão recai claramente sobre os padrões de acesso. Escamas Aurora calcular; DynamoDB remove o conceito.

Documento: MongoDB e DocumentDB

Ambos armazenam documentos do tipo JSON, para que pareçam intercambiáveis com o DynamoDB à distância. Eles não são. O MongoDB indexa qualquer campo e executa consultas ad-hoc nele; DynamoDB oferece você a chave de partição, a chave de classificação e os índices que você declarou antecipadamente.

Isso torna o MongoDB a melhor opção para formas de consulta em evolução e o DynamoDB a melhor opção para os conhecidos em alto volume. O DocumentDB fica no lado AWS da mesma linha - ele fala o MongoDB API, então trate-o como "flexibilidade do MongoDB, modelo operacional do AWS", e compare-o com o DynamoDB exatamente no eixo flexibilidade versus previsibilidade acima.

Coluna larga: Cassandra

Cassandra é o parente arquitetônico mais próximo do DynamoDB: chave de partição, clustering chave, e a mesma dura verdade de que uma chave de partição incorreta é um bug de design que você não pode indexar sua saída. Se você estiver escolhendo entre eles, os fatores decisivos raramente são os modelo de dados – são eles quem o administra e como você paga. Cassandra você opera (ou compra gerenciada); DynamoDB você consome. Amazon Keyspaces é o meio-termo gerenciado do Cassandra.

Como os modelos estão tão próximos, a orientação de modelagem neste site transfere principalmente: o design de tabela única raciocínio sobre chaves de partição e os padrões de acesso se aplicam ao Cassandra quase linha por linha.

Na memória: Redis

Redis e DynamoDB resolvem problemas diferentes. O Redis prioriza a memória e é otimizado para acesso em menos de um milissegundo a dados que você pode perder ou reconstruir; DynamoDB é durável por padrão. O comum a resposta de produção é ambas - DynamoDB como sistema de registro, Redis (ou DAX, que é Cache de leitura do próprio DynamoDB) na frente das teclas de atalho.

Use apenas o Redis somente quando os dados forem genuinamente efêmeros: contadores de limite de taxa, sessões de curta duração, tabelas de classificação que você pode recalcular.

Pesquisa: Elasticsearch e OpenSearch

Search e DynamoDB também resolvem problemas diferentes – por um motivo mais claro que o Redis: DynamoDB não tem texto completo pesquise. Query corresponde à igualdade de chave e a um conjunto restrito de condições de chave de classificação. Scan com um FilterExpression lê todos os itens e depois descarta a maioria deles – é um ande pela mesa com um filtro aparafusado, não uma pesquisa, e você paga pelos itens lidos em vez de os itens devolvidos. Não há classificação de relevância, nem analisadores, nem correspondência difusa, nem lapidação.

Portanto, a questão nunca é “DynamoDB ou um mecanismo de busca”. É "essa carga de trabalho precisa pesquisa e, em caso afirmativo, o que alimenta o índice?" O formato padrão é ambos: DynamoDB como sistema de registro, um cluster de pesquisa ao lado dele e DynamoDB Streams transportando todas as alterações para o índice. Isso compra uma pesquisa real e custa um segundo sistema para ser executado e um índice que é eventualmente consistente com a tabela.OpenSearch e Elasticsearch são a mesma decisão. OpenSearch é o fork do AWS Elasticsearch, dividido em 7.10 em 2021 devido à mudança de licença da Elastic, e os dois mudaram separados desde então. Nada disso aborda esta questão - pois "a busca deve ocorrer fora DynamoDB", eles se comportam de forma idêntica. Escolha entre eles sobre licenciamento, hospedagem e quais serviço gerenciado que você deseja operar, não relacionado ao DynamoDB.

Alcance um mecanismo de pesquisa como loja principal apenas quando a pesquisa realmente é o produto - log analytics, um catálogo cujo principal padrão de acesso é o texto livre. Mesmo assim, a maioria das equipes mantém um armazenamento durável por trás dele, porque um índice de pesquisa é uma visão derivada que você precisa ser capaz de reconstruir.

O eixo de custo, que a comparação de modelos oculta

Todas as comparações acima são sobre modelos de dados, mas a surpresa na conta geralmente é estrutural: os mecanismos relacionais cobram pela capacidade que você provisiona, o DynamoDB fatura pela operações que você executa. Isso torna o DynamoDB barato para cargas de trabalho pontiagudas e ociosas e caro para varredura sustentada — a mesma carga de trabalho pode ganhar em um mecanismo e perder muito por outro, sem alteração de código entre eles.

O multiplicador que as pessoas sentem falta são os índices. Em um mecanismo relacional, um índice extra custa armazenamento e alguns escrevem latência; no DynamoDB, cada índice secundário é uma gravação extra completa do atributos projetados. Trabalhamos a aritmética em três volumes de gravação em o guia de índices — um GSI dobra a conta de gravação, dois triplicam isso. Modele seu mix read/write real no calculadora de preços antes de se comprometer com qualquer um dos lados.

Contando 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 de trabalho pontiagudas e sem servidor e pode ser caro para varreduras pesadas e sustentadas. Modele seu mix read/write real com o Calculadora de preços DynamoDB antes de confirmar; uma carga de trabalho que pareça tecnicamente adequada também deve considerar o custo.

Depois de decidir que se encaixa

O trabalho muda para modelagem. DynamoDB recompensa projetar a mesa em torno de suas consultas

• veja como modelar dados em DynamoDB e design de tabela única — e explicitamente quando não usar mesa única.

Armadilhas + próximos passos

• Não modele o DynamoDB como um banco de dados relacional — tabelas normalizadas nas quais você ingressa o tempo de leitura é o antipadrão que ele pune com mais força.
• Não escolha para análise – combine-o com uma loja de análise (ou exporte para uma) para relatórios em vez de digitalização.
• Não tem certeza sobre os padrões de acesso? Espere. Adotando o DynamoDB antes de conhecer seu consultas é escolher o banco de dados que exige que você as conheça.
• Relacionado: consulta vs varredura mostra o que é "acesso baseado em chave" realmente compra você.

Quer explorar uma mesa DynamoDB antes de apostar seu aplicativo nela? Baixe DynoTable e conecte-se diretamente aos seus dados - é SQL Workbench executa os JOINs ad-hoc e agrega O próprio DynamoDB não o fará.