Por que bancos de dados e sua complexidade agora são desnecessários

Os problemas dos bancos de dados e por que sua complexidade é desnecessária

• Bancos de dados são um estado mutável global, o que torna o código mais complexo e difícil de entender.
• Os modelos de dados são limitados e não conseguem dar suporte a todos os casos de uso, exigindo o uso de vários bancos de dados.
• O problema de normalização versus desnormalização cria uma tensão entre consistência dos dados e desempenho.
• Esquemas limitados geram complexidade ao forçar a adaptação da representação do domínio ao banco de dados.
• Implantações complexas aumentam custo e complexidade por causa da combinação e integração de várias ferramentas.

Um modelo consistente para construir backends de aplicações

• A função básica de um backend é receber novos dados e responder perguntas sobre esses dados.
• O design ideal de um backend deve chegar o mais perto possível do ideal, ao mesmo tempo em que atende às restrições do mundo real.

Rama

• Rama é uma plataforma de desenvolvimento de backends que reimplementou o Mastodon para oferecer um serviço em escala de Twitter.
• Rama implementa todos os elementos de um backend — dados, índices, ETL, consultas etc. — de forma genérica.
• Rama simplifica implantações complexas e integra o monitoramento, reduzindo drasticamente os custos de desenvolvimento e manutenção.

Opinião do GN⁺

• O problema do estado mutável global dos bancos de dados aumenta a complexidade do código e a possibilidade de erros, algo que desenvolvedores enfrentam com frequência.
• Rama apresenta uma nova abordagem para superar as limitações dos bancos de dados tradicionais e reduzir a complexidade do desenvolvimento de backends.
• Este texto oferece informações interessantes e úteis para desenvolvedores que querem reduzir a complexidade de bancos de dados e sistemas de backend.

[GN⁺]

Comentários do Hacker News

• Deve-se usar um subsistema que represente a fonte da verdade e outro subsistema que implemente vários armazenamentos de índice derivados dessa fonte. Isso é a combinação de event sourcing e materialized views.

  • Event sourcing e materialized views: a solução é gerenciar separadamente o sistema que representa a fonte da verdade e os armazenamentos de índice baseados nele.

• Separamos o modelo de leitura e o modelo de escrita: o modelo de escrita ("fonte da verdade") é composto por um modelo de domínio relacional tradicional, e quase todo comando gera eventos que são publicados em uma fila compartilhada de eventos de domínio. O modelo de leitura é composto por workers que consomem os eventos e constroem views.

  • Separação entre modelos de leitura e escrita: o modelo de escrita é composto por um modelo de domínio relacional, e os comandos geram eventos que são publicados na fila de eventos de domínio. O modelo de leitura consome esses eventos para construir views.

• Materializar dados quando há mudanças pode trazer benefícios quando o produto precisa fazer uma única tarefa muito rapidamente. Mas os problemas surgem quando se tenta adicionar novos recursos que exigem transações complexas ou dados organizados de outra forma.

  • Limites da materialização de dados: é útil quando otimizada para uma única tarefa, mas pode causar problemas ao adicionar recursos que exigem transações complexas ou novas estruturas de dados.

• Afirmar que isso foi comprovado como um "cliente Mastodon em escala Twitter" é impossível, a menos que você realmente opere um site com 40 milhões de usuários por dia.

  • A importância da escala: é impossível simular um ambiente real com usuários em escala massiva, então é difícil sustentar esse tipo de afirmação.

• Uma abordagem melhor é a combinação de event sourcing e materialized views.

  • Combinação de event sourcing e materialized views: é apresentada como uma abordagem melhor, embora venha com mais complexidade.

• Um único modelo de dados não consegue atender todos os casos de uso.

  • Diversidade de modelos de dados: é impossível atender todos os casos de uso com um único modelo de dados.

• Não tenho nenhuma reclamação sobre bancos de dados.

  • Validade dos bancos de dados: não há reclamações contra bancos de dados; eles continuam sendo ferramentas válidas.

• Estão faltando conceitos como concorrência, isolamento e restrições? A "topologia de consultas" é realmente superior para a experiência do desenvolvedor?

  • Dúvidas sobre a topologia de consultas: questiona-se se conceitos importantes como concorrência, isolamento e restrições estão ausentes, e se a topologia de consultas é mesmo superior para a experiência do desenvolvedor.

• Preciso de uma explicação ELI5 do Rama. A documentação é confusa, e por favor sem buzzwords como "mudança de paradigma" ou "plataforma".

  • Pedido de explicação simples sobre o Rama: pede-se uma explicação fácil e clara sobre o Rama, sem usar buzzwords.

• Event sourcing (+ materialized views e índices) não significa abandonar o RDBMS. Dá para usar os dois juntos.

  • Coexistência entre event sourcing e RDBMS: event sourcing e materialized views podem ser usados junto com um RDBMS; não são mutuamente excludentes.

Conhecimento de contexto:

• Event Sourcing: padrão de projeto em que as mudanças de estado do sistema são registradas como eventos, permitindo reconstruir o estado do sistema por meio da reprodução desses eventos.
• Materialized Views: técnica que armazena fisicamente o resultado de consultas do banco de dados para melhorar o desempenho de leitura.
• RDBMS (Relational Database Management System): sistema para gerenciar bancos de dados relacionais.