DEV Community: Joaquim Chianca

DynamoDB: Como implementar sistemas resilientes e distribuídos

Joaquim Chianca — Tue, 28 Jan 2025 17:43:12 +0000

No contexto de sistemas distribuídos, a escolha do banco de dados é decisão crucial para o desempenho, escalabilidade e disponibilidade da aplicação. O Amazon DynamoDB, criado pela AWS, destaca-se como uma solução poderosa e flexível para desenvolvedores que precisam de bancos altamente escaláveis e distribuídos. Ele permite o processamento de grandes volumes de dados com baixa latência, ideal para aplicações globais e sensíveis ao desempenho.

Nesse artigo, exploraremos como o DynamoDB implementa o conceito de consistência eventual (eventual consistency), modelo de consistência amplamente utilizado em sistemas distribuídos.

O que é o DynamoDB?

O Amazon DynamoDB é um banco de dados NoSQL totalmente gerenciado, desenvolvido pela Amazon Web Services (AWS). Projetado para aplicações que exigem alto desempenho. Suas principais características são:

Dados orientados em tabela, com suporte para chave-valor: Permite armazenar dados em estruturas flexíveis, com suporte a documentos JSON e tabelas distribuídas.
Escalabilidade automática: Garante que o banco de dados se ajuste automaticamente às necessidades de aplicações de qualquer tamanho.
Alta disponibilidade: Replica dados automaticamente em múltiplas zonas de disponibilidade. Utiliza sharding automático para distribuir o dados em múltiplas partições, baseando-se em chave primária.
Consultas complexas: Suporta índices secundários globais e locais para facilitar consultas.

Foi introduzido em 2012, como uma evolução do Amazon SimpleDB, com objetivo de fornecer um banco de dados otimizado para aplicações modernas, como e-commerces, IoT e jogos. Tais aplicações requerem escalabilidade global e consistência em sistemas distribuídos.

O DynamoDB possui foco em resolver problemas comuns de bancos de dados relacionais, como limitação de escalabilidade e gargalos em transações complexas. Sua arquitetura é fundamentada na distribuição de dados em partições que podem ser gerenciadas de forma independente, o que permite alta disponibilidade e baixíssima latência.

Teorema CAP e Eventual Consistency

O Teorema CAP estabelece que um sistema distribuído pode garantir, no máximo, dois dos três atributos a seguir:

Consistência (C): Todos os nós veem os mesmos dados ao mesmo tempo.
Disponibilidade (A): O sistema responde a todas as solicitações, mesmo que nem todos os nós estejam funcionando.
Tolerância a Particionamento (P): O sistema continua funcionando mesmo quando há falhas ou perda de comunicação entre nós.

A nível de contexto, existem três tipos de consistência:

Consistência Forte: As atualizações são imediatamente visíveis para todas as leituras em todos os nós.
Consistência Eventual: As atualizações são propagadas aos nós de forma assíncrona, e o sistema atinge consistência em um momento futuro.
Consistência Causal: Garante ordem em operações dependentes, mas não em todas operações.

Os sistemas distribuídos possuem natureza inerente à partição - são feitos para funcionar mesmo que algum nó não esteja funcionando - resultando em uma escolha entre disponibilidade ou consistência. O DynamoDB opta pela disponibilidade, uma vez que para um banco, na maioria das vezes, é mais interessante que haja uma resposta para toda consulta do que os dados estarem atualizados em todos os nós. Por isso, o banco implementa uma lógica para consistência denominada de consistência eventual.

Parece um pouco controverso que um banco de dados nem sempre esteja com todos os nós atualizados o tempo todo, afinal imagine quantos problemas podem ser provocados por respostas não atualizadas, entretanto a maneira como é implementada a consistência no DynamoDB permite o uso dessa ferramenta em sistemas globais, onde a latência é crítica e deve existir tolerância a falhas. A consistência eventual resulta em maior escalabilidade, já que não é necessária constante sincronização entre nós, o que abre portas para uma escalabilidade horizontal.

A imagem abaixo ilustra bem como funciona a consistência eventual: em que a escrita é feita num nó primário e os dados são sincronizados para os demais nós após um determinado período de tempo.

Comparando Consistência Eventual no DynamoDB e Outros Bancos

Embora a consistência eventual seja um conceito comum em sistemas distribuídos, sua implementação varia entre bancos de dados. O DynamoDB se destaca por:

Global Tables: Replicam dados automaticamente em várias regiões, garantindo consistência eventual sem necessidade de configuração manual. Em contraste, no Apache Cassandra, a replicação entre data centers requer configurações manuais detalhadas, incluindo a definição de estratégias de replicação e o gerenciamento de topologias de rede. O CouchDB, embora suporte replicação, não oferece uma solução integrada para replicação global automática, exigindo configurações adicionais e gerenciamento manual para alcançar um comportamento semelhante.
DynamoDB Streams: Permitem capturar mudanças nos dados e propagar atualizações de forma eficiente. Isso é particularmente útil para disparar eventos, atualizar caches ou sincronizar com outros sistemas. No Cassandra, funcionalidades semelhantes podem ser implementadas usando o Commit Log ou ferramentas adicionais, mas geralmente requerem configurações extras e não são tão integradas quanto no DynamoDB. O CouchDB possui um mecanismo de changes feed que permite acompanhar alterações, mas pode não oferecer a mesma eficiência e integração que o DynamoDB Streams proporciona.
Modelos de consistência configuráveis: O DynamoDB oferece aos desenvolvedores a flexibilidade de escolher entre leituras com consistência eventual (padrão) e leituras com consistência forte, dependendo das necessidades específicas da aplicação. No Cassandra, embora seja possível ajustar o nível de consistência para operações de leitura e escrita, isso requer um entendimento aprofundado da arquitetura do cluster e configurações manuais para cada operação. O CouchDB, por sua vez, adota uma abordagem de consistência eventual por padrão e não oferece suporte nativo para leituras com consistência forte, limitando as opções para aplicações que necessitam de garantias de consistência mais rígidas.

Embora Cassandra e CouchDB também implementem consistência eventual, o DynamoDB se destaca por fornecer ferramentas integradas e configuráveis que simplificam o desenvolvimento de aplicações distribuídas e resilientes. As Global Tables e o DynamoDB Streams oferecem funcionalidades avançadas de replicação e processamento de eventos que facilitam a construção de sistemas globais com alta disponibilidade e desempenho consistente.

Sem falar que tudo isso é gerenciado pela AWS, com o foco em trazer todas vantagens de um banco NoSQL com a simplicidade no processo de configuração.

Benchmarking: Amazon DynamoDB vs Google Cloud Datastore

Nessa seção, vou ilustrar um cenário comparativo entre dois bancos NoSQL: DynamoDB e Google Cloud Datastore, ambos possuem basicamente o mesmo objetivo em um sistema distribuído: alta disponibilidade com baixa latência.

A comparação se dará através das métricas vazão média e latência entre os dois bancos em diferentes workloads. Além disso o cliente para cada um dos bancos vai ser tanto o Google Compute Engine e o AWS EC2. A imagem abaixo ilustra o experimento.

Workloads utilizados e operações no banco

Workload A: 95% read, 5% update (teste de leitura)
Workload B: 50% read, 50% update (teste balanceado)
Workload C: 5% read, 95% update (teste de escrita)
Workload D: 70% read, 15% update, 15% insert (cenário especial de teste)

O estudo foi feito durante uma semana, rodando cada um dos workloads duas vezes (uma utilizando o EC2 e outra usando o Compute Engine). Mais detalhes nesse artigo em inglês.

Resultados e conclusão

O DynamoDB possui significativamente vazão média maior e latência menor em todos workloads, comparado ao Cloud Datastore, o que consequentemente proporciona uma melhor performance.

Casos de uso do DynamoDB

Jogos

O setor de jogos frequentemente envolve padrões de leitura e gravação altamente concorrentes, especialmente em jogos online multijogador massivos, onde milhares ou até milhões de jogadores podem acessar servidores de jogos simultaneamente. O servidor precisa ser capaz de lidar com as requisições de leitura e gravação de jogadores distribuídos globalmente em tempo real.

O DynamoDB é ideal para esse caso de uso, pois se escala facilmente por várias regiões globais, mantendo a latência de leitura e gravação em milissegundos de uma única casa decimal.

Empresas como Capcom, PennyPop e Electronic Arts utilizam o DynamoDB para escalar aplicações de jogos. Você pode aprender mais sobre os casos de uso e padrões de design do DynamoDB no setor de jogos.

Streaming de Conteúdo

Aplicações de streaming de conteúdo precisam ser altamente disponíveis e escaláveis, utilizando implementações multi-AZ (zonas de disponibilidade) para atender a audiências globais. O streaming de conteúdo também está sujeito a tráfego desigual ou picos repentinos, por isso, essas aplicações se beneficiam de modelos de computação serverless que escalam conforme a demanda.

O DynamoDB é um ótimo banco de dados para aplicações de streaming de conteúdo devido à sua capacidade de replicar dados globalmente e oferecer balanceamento de carga flexível para acomodar mudanças na audiência.

Empresas como Netflix, Hulu e Disney utilizam o DynamoDB para dar suporte às suas aplicações de streaming de conteúdo.

Bancos e Finanças

Transações financeiras acontecem em tempo real, e os aplicativos móveis são a experiência padrão para serviços bancários. Os clientes esperam poder gerenciar seu dinheiro a partir de seus telefones e fazer isso em tempo real. Bancos precisam processar muitas requisições simultâneas de clientes globais, mantendo as transações financeiras seguras e atualizadas.

O DynamoDB é ideal para o setor bancário porque pode lidar com a escala global e os padrões rápidos de leitura/gravação necessários para manter as informações financeiras atualizadas tanto no servidor quanto na aplicação voltada para o usuário. Além disso, oferece leituras fortemente consistentes mesmo em arquiteturas distribuídas, garantindo que os dados financeiros sejam precisos e atualizados.

Empresas como Capital One, Robinhood e PayPay utilizam o DynamoDB para reduzir a latência em seus aplicativos móveis.

Aplicativos Móveis e Web

Em diversos setores, incluindo os acima mencionados, aplicativos web e móveis atendem muitos usuários simultaneamente em tempo real.

Por todas as razões descritas, o DynamoDB é um banco de dados perfeito para apoiar aplicativos web e móveis construídos dentro do ecossistema AWS. Ele pode escalar para lidar com tráfego flutuante e oferece flexibilidade para maximizar a taxa de transferência sem custos elevados.

Empresas como Duolingo, AirBnB e Tinder utilizam o DynamoDB para construir aplicativos web e móveis rápidos e escaláveis.

Internet das Coisas (IoT)

Casos de uso da IoT envolvem gravações frequentes e através de um throughput imprevisível, à medida que dispositivos distribuídos globalmente geram fluxos de dados em tempo real.

Embora o DynamoDB não seja estritamente um banco de dados de séries temporais, ele pode ser usado de forma eficaz em aplicações de IoT, especialmente quando combinado com outras ferramentas AWS, como o IoT Core, Lambda e Kinesis.

Empresas como BMW, GE e Verizon utilizam o DynamoDB para processar dados da IoT.

Mais informações sobre casos de usos na indústria neste vídeo.

Conclusão

O Amazon DynamoDB se estabelece como uma solução poderosa e flexível para sistemas distribuídos que exigem escalabilidade, baixa latência e alta disponibilidade. Seu suporte à consistência eventual permite que seja altamente eficiente em ambientes globais, com tolerância a falhas e capacidade de gerenciar grandes volumes de dados em tempo real.

Ao optar pela consistência eventual, o DynamoDB garante uma escalabilidade superior, permitindo que os dados sejam propagados entre nós de forma assíncrona, com a aplicação atingindo a consistência no futuro, o que é ideal para aplicações que necessitam de disponibilidade contínua. Essa abordagem é essencial para grandes sistemas distribuídos, como jogos online, streaming de conteúdo, finanças e IoT, onde a baixa latência e a capacidade de escalar conforme a demanda são cruciais.

Além disso, o DynamoDB se destaca pela simplicidade em sua configuração e gerenciamento, principalmente por ser totalmente gerido pela AWS. Funcionalidades como Global Tables e DynamoDB Streams permitem replicação automática e eficiente, enquanto os modelos de consistência configuráveis fornecem flexibilidade para atender a diferentes necessidades das aplicações.

Flyway e Spring Boot em cenário de banco de dados não vazio.

Joaquim Chianca — Sat, 27 Apr 2024 07:39:58 +0000

Em um projeto de programação, em que estava construindo uma API com Spring Boot (Java), precisei adicionar alguns records numa tabela do meu banco de dados. Devido ao meu repertório e também buscando me desafiar, adicionei a dependência do Flyway para adicionar migrações ao meu banco de dados. Entretanto, ao adicionar o Flyway num projeto existente, ocorreram alguns comportamentos inesperados.

Mas, calma, tô voando.. O que é o Flyway?

Basicamente, o Flyway serve de versionamento de banco de dados. Suponha que existem 3 programadores rodando o mesmo projeto num ambiente de desenvolvimento. O ideal é que o banco de dados de todos (mesmo que em ambientes diferentes) possuam as mesmas tabelas.

Por meio de vários arquivos .sql, o Spring detecta a existência desses arquivos, roda o script SQL antes mesmo de criar as tabelas com o Hibernate. Assim, podemos criar arquivos .sql para criar as tabelas necessárias para o funcionamento correto da aplicação, garantindo que as tabelas possuem o mesmo formato para cada ambiente de desenvolvimento diferente. Uma forma de padronizar e manter o banco de dados atualizado para todos do time.

E Hibernate?

Hibernate é uma implementação da JPA (Java Persistence API), responsável pela ponte entre a sua aplicação e seu banco de dados. Todo método default do repository é implementado pelo Hibernate. O Hibernate também é o responsável por criar suas tabelas das entidades do seu projeto (classes anotadas com o @Entity).

O Hibernate já cria minhas tabelas, por qual razão eu preciso do Flyway?

Como já comentado acima, o Flyway é usado para padronizar as tabelas do seu projeto. Dessa forma, o Spring executa as migrações do Flyway antes mesmo de executar o Hibernate, logo, o ideal é que o time defina muito bem essas tabelas por meio de arquivos .sql no projeto.

A boa prática é criar as migrations antes mesmo de criar qualquer classe dentro do seu projeto.

Adicionando Flyway a um projeto existente

A motivação de escrever esse arquivo veio quando tentei adicionar o Flyway ao meu projeto que já possuía as tabelas mapeadas para cada entidade, criadas através do Hibernate.

Minha ideia era usar o Flyway apenas para inserir records numa tabela já existente, porém notei que as inserções não estavam acontecendo.

Dissecando o problema

Primeiro, fui atrás de criar novas migrations no projeto, para ter certeza de que o Flyway estava configurado corretamente e funcionando quando eu criava novas tabelas. E sim, ele funcionara corretamente quando foi criada uma tabela exemplo arbitrária.

Tendo em mente que o problema não estava na configuração da dependência externa, fui atrás de saber como funciona o relacionamento do Flyway com o Hibernate. O interessante (como já foi comentado nesse artigo) foi descobrir que o Flyway é executado antes do Hibernate. Dessa forma, era óbvio que minha lógica não funcionaria, afinal, como eu posso inserir records numa tabela que ainda não foi carregada pelo Hibernate?

O problema estava exatamente nessa ordem de execução das dependências.

Resolução

Bastou criar uma classe de configuração do Flyway para que fosse carregado o conteúdo do Hibernate antes do próprio Flyway. Para isso:

Defini a propriedade spring.flyway.enabled=false no application.properties
Criei uma classe de configuração Flyway FlywayConfig.java

@Configuration
public class FlywayConfig {

    @Autowired
    public FlywayConfig(DataSource dataSource) {
        Flyway.configure()
                .baselineVersion("0.0")
                .baselineOnMigrate(true)
                .dataSource(dataSource)
                .load().migrate();
    }
}

O próprio Spring injeta o dataSource nesse construtor do Flyway, indicando que ele deve carregar primeiro o banco de dados .dataSource(dataSource).load() e apenas depois executar a migração, por meio do método migrate().

Feito isso, criei uma nova migration com inserção de records V4__insert_user.sql

insert into tb_user(id, email, name, password, username) values
(7, 'zeldris@gmail.com', 'zeldris', 'zeldris', 'zeldris');

E voilà, a record está inserida na minha tabela:

Conclusão

O intuito desse artigo é compartilhar essa noção de funcionamento das duas dependências que lidam com banco de dados: Hibernate e Flyway, além de ajudar aqueles que estão com o projeto existente e passam pela mesma situação de mal funcionamento das migrations da ferramenta.

Como escrever uma mensagem de commit

Joaquim Chianca — Thu, 10 Aug 2023 20:45:22 +0000

Como programadores, dar nomes para as coisas (variáveis, funções, etc) faz parte da nossa rotina diária. Em linguagens de programação temos que seguir uma convenção, isto é, um modelo para nomear e isto também se aplica para as mensagens de commit no Github.

É bem difícil colocar em mais ou menos 50 caracteres as mudanças feitas no seu código. Quando não se está acostumado com as boas práticas, você adiciona uma nova feature, faz refatoração de código, cria novos testes unitários para suas funções e coloca tudo isso dentro de um mesmo commit e faz o push pro seu repositório no Github.

O grande macete é pensar nos seus commits como checkpoints do seu código.

Como num jogo, toda vez que você ganha um novo item, ou derrota um boss é interessante você salvá-lo, para não perder o progresso. O mesmo vale para seu código e seus commits.

Por exemplo, criados novos testes, faça um commit com a mensagem test: criação de testes unitários para função X. Percebe que além de uma mensagem clara, resumindo o que foi feito naquele commit, temos um nome identificando qual é o tipo de commit.

Peraí, commits possuem tipos?

Não necessariamente você é obrigado a colocar os tipos, porém em projetos open-source é comum essa prática, visto que muitos desenvolvedores estão contribuindo para o repositório e é necessária uma organização.

Considere o repositório do framework Angular, ferramenta a qual permite criar componentes visuais com Javascript de maneira mais automática:

Dentro do próprio repositório existe um arquivo, em inglês, ensinando os desenvolvedores como escrever a mensagem de commit.

Quais são os tipos?

Os tipos mais importantes, sem dúvidas, são fix e feat. O primeiro serve para denotar correção de bugs no código, enquanto o segundo define uma nova funcionalidade no código.

Além disso, temos outros tipos:

chore: mudanças que não estão ligadas à funcionalidade do projeto, mas necessárias para que o projeto funcione (manutenção de arquivos de integração contínua, processos de compilação). Basicamente, infraestrutura do código
docs: commits relacionados à documentação apenas
perf: mudanças referentes à performance do código
style: estilização do código (adição de novas linhas em branco, indentação)
refactor: refatoração de código, não corrige bugs e nem adiciona novas funcionalidades
test: correção de testes ou criação de novos testes

Outros fatores importantes

Existem mais especificações sobre qual a maneira correta de um commit, por exemplo, definir o escopo de onde ocorreu a mudança: fix(api): correção de bug na criação de usuário.

Contudo, o essencial é separar os commits em tipos, isso já deixa o ambiente muito mais organizado e a adição do escopo na mensagem só deve ser feita, caso o projeto seja complexo, ou se for instrução da empresa ou time em que se está trabalhando.

Além disso, eu desaconselho colocar emojis nas mensagens de commit, porque polui visualmente e - na maioria dos casos - confunde outros desenvolvedores.

Em suma, o mais importante é deixar claro o que foi feito no commit, para que outros possam entender como o projeto está evoluindo.

Se desejar entrar em contato: meu linkedin. Estou à disposição para networking.