Por que bancos de dados e sua complexidade agora são desnecessários
(blog.redplanetlabs.com)- A causa da complexidade de backend não está mais em falhas de produtos específicos, mas no fato de que a estrutura conceitual mantida pelos bancos de dados há muito tempo continua restringindo o design das aplicações
- Bancos de dados funcionam como estado global mutável e fazem com que desenvolvedores assumam o ônus de modelos de dados fixos, esquemas limitados e da tensão entre normalização e desnormalização
- A alternativa proposta combina event sourcing e materialized views para separar os dados de origem das views de índice, tratando índices não como modelos de dados, mas como estruturas de dados duráveis
- O Rama, da Red Planet Labs, reúne coleta, processamento, indexação, consulta, implantação e monitoramento de dados em uma única plataforma com depots, ETL, PStates e query topologies
- No caso de uma reimplementação do Mastodon em escala de Twitter, o Rama foi usado para implementar tudo com 10 mil linhas e 9 homem-mês, enquanto o produto de consumo equivalente do Twitter é comparado a 1 milhão de linhas e cerca de 200 homem-anos
O ponto de partida da complexidade dos bancos de dados
- O foco do problema não está na API, nas dificuldades operacionais ou em limitações arbitrárias de um produto específico de banco de dados, mas na estrutura conceitual coletiva que foi mantida até hoje
- Só quando surge uma forma melhor os problemas da abordagem anterior ficam claros, e a alternativa apresentada é a combinação de event sourcing com materialized views
Bancos de dados como estado global mutável
- Programadores aprendem a minimizar o uso de variáveis globais, mas bancos de dados também são, em essência, estado global mutável
- Bancos de dados têm aspectos que os tornam ainda mais difíceis de lidar do que variáveis globais comuns
- As interações estão espalhadas por vários sistemas, dificultando raciocinar sobre o estado
- Como o estado é durável, mesmo que um bug seja corrigido, os dados corrompidos não se recuperam automaticamente
- Em alguns casos, é difícil identificar com precisão o alcance da corrupção ou corrigi-la por completo
- Voltar a um backup ou mesclar apenas parte de um backup não é a solução ideal
- Com event sourcing e materialized views, é possível recalcular as views a partir do log de origem, criando margem para corrigir estados de índice corrompidos
Limites de modelos de dados fixos
- Bancos de dados são projetados em torno de modelos de dados como key/value, document, relational, column-oriented e graph
- Como um único modelo de dados dificilmente atende todos os casos de uso, é comum empresas usarem vários bancos de dados em conjunto
- Uma abstração de índice mais geral não é um modelo de dados, mas uma estrutura de dados
- Key/value: map
- Document: map of maps
- Relational: map of maps, secondary indexes são maps adicionais
- Column-oriented: map of sorted maps
- Estruturas de dados duráveis ficam armazenadas em disco, podem crescer bastante e também podem representar estruturas de dados aninhadas
- Se os índices forem especificados como combinações de estruturas de dados, torna-se possível criar não só modelos tradicionais, mas também formas de indexação muito mais variadas
- Em vez de distorcer o modelo de domínio da aplicação para se encaixar no banco de dados, a complexidade fundamental diminui quando a forma do armazenamento pode ser ajustada ao modelo de domínio
A tensão entre normalização e desnormalização
- Usuários de bancos de dados relacionais inevitavelmente se deparam com a escolha entre normalização e desnormalização
- Armazenamento normalizado cria uma fonte de verdade clara e reduz a possibilidade de inconsistências, mas pode aumentar o custo das consultas por exigir mais joins
- Quando, por desempenho, a mesma informação é armazenada de várias formas, bugs podem gerar inconsistências nos dados
- A arquitetura de um RDBMS junta no mesmo datastore a fonte de verdade e o armazenamento de índices para consultas rápidas
- A solução é uma estrutura que separa esses dois papéis
- Um subsistema representa a fonte de verdade
- Outro subsistema materializa a partir dessa fonte quantos armazenamentos de índice forem necessários
- Se o segundo sistema puder recalcular os índices com base nos dados de origem, inconsistências poderão ser corrigidas
Esquemas limitados e representação de domínio
- Bancos de dados variam muito, de produto para produto, quanto aos tipos de valores que podem armazenar
- Alguns aceitam apenas blobs como byte arrays
- Outros permitem vários tipos, como inteiros, ponto flutuante, strings e datas
- É raro armazenar informações aninhadas internas a objetos de domínio com representação de primeira classe, de forma que possam ser consultadas ou agregadas diretamente
- Como a linguagem de implementação do banco de dados costuma ser diferente da linguagem da aplicação, a interoperabilidade é difícil, e extensões como a protobuf extension para Postgres também são incômodas e limitadas
- ORM mapeia a representação de domínio para a representação do banco, mas a abstração pode vazar e causar problemas
- Quando os dados precisam ser indexados de um modo diferente da representação ideal do domínio, código adaptador se torna necessário, e os tipos de consulta que podem ser feitos com eficiência também podem ficar limitados
Implantação complexa e o modelo à la carte
- Um backend completo não é composto apenas por um banco de dados, mas por muitas ferramentas em conjunto, como banco de dados, sistemas de processamento, ferramentas de monitoramento e schedulers
- Backends em larga escala podem exigir a combinação de dezenas de ferramentas, e atualizar a aplicação pode se transformar numa orquestração de migrações, atualizações de código e mudanças de infraestrutura
- Para ficar pronto para produção, é necessário ter telemetria suficiente, mas como cada ferramenta coleta isso de um jeito diferente, consolidar tudo em um único dashboard de monitoramento vira uma tarefa extra de engenharia
- O modelo de desenvolvimento hoje dominante se aproxima de um modelo à la carte, no qual se escolhe a melhor ferramenta para cada parte da arquitetura
- O trabalho de fazer ferramentas projetadas de forma independente funcionarem juntas já é grande por si só, e, por causa de modelos de dados fixos e esquemas limitados, muitas vezes é a aplicação que precisa se adaptar às ferramentas, e não o contrário
- Como não havia um modelo coeso para compor backends, o modelo à la carte acabou prevalecendo; em um modelo coeso, há mais espaço para abstração, automação e reutilização
Um modelo simples para enxergar o backend
- As principais funções de um backend são receber dados novos e responder perguntas sobre esses dados
- A consulta mais geral pode ser expressa como a execução de uma função sobre todos os dados recebidos pelo backend
query = function(all data)
- Na prática, porém, o dataset pode ter 10 PB e a resposta da consulta pode precisar sair em milissegundos, então sistemas úteis precisam de índices
- Com índices, o modelo pode ser representado assim
indexes = function(data)query = function(indexes)
- Backends tradicionais implementam os componentes desse modelo dividindo-os entre várias ferramentas especializadas
- Em um backend com RDBMS, o próprio RDBMS pode ser usado para dados e índices, enquanto um banco separado como ElasticSearch pode ser usado para indexação adicional
- O processamento costuma ficar em handlers de servidor de API ou em jobs de background baseados em filas e workers
- Backends de grande escala podem combinar ferramentas como Cassandra, MongoDB, Neo4j, Kafka, Hadoop, Storm e Kafka Streams
- A conclusão é que, se existir uma ferramenta capaz de implementar todos esses componentes de forma integrada e de propósito geral, a complexidade anterior pode ser evitada
A composição do Rama e o caso do Mastodon
- O Rama é uma plataforma de desenvolvimento de backend projetada com base nesses princípios
- A Red Planet Labs apresentou o Rama em 15 de agosto com a tagline “the 100x development platform”
- Como exemplo de redução de custo, a empresa apresentou o trabalho de reimplementar o Mastodon em escala de Twitter
- 100 milhões de bots publicam 3.500 vezes por segundo
- O fanout médio é 403
- O produto de consumo equivalente do Twitter é comparado a 1 milhão de linhas e cerca de 200 homem-anos
- A implementação com Rama exigiu 10 mil linhas e 9 homem-mês
- A implementação é open-source e é apresentada como complete, high-performance, production-ready
- Para atingir essa escala, o Twitter construiu diretamente bancos especializados, como social graph database e in-memory timeline database, e teve uma implantação complexa em que só a configuração do Puppet tinha mais de 1 milhão de linhas
- A implementação baseada em Rama é apresentada como tendo resolvido problemas semelhantes de desempenho e escalabilidade ao combinar os elementos primitivos do Rama, em vez de criar infraestrutura especializada nova para cada subproblema
- Os performance numbers da implementação do Mastodon são apresentados como iguais ou melhores que os do Twitter
O modelo de programação do Rama
- Os conceitos do Rama correspondem diretamente ao modelo de backend apresentado antes
- Depots: logs distribuídos que armazenam quaisquer dados e correspondem a
data - PStates: sigla para partitioned state, correspondem aos índices
- ETLs: correspondem a
function(data) - Queries: correspondem a
function(indexes)
- Depots: logs distribuídos que armazenam quaisquer dados e correspondem a
- PStates podem ser criados conforme necessário como quaisquer combinações de estruturas de dados duráveis
- ETL e query são expressos com uma API de fluxo de dados Turing-complete, e o processamento pode ser executado de forma distribuída
- O Rama fornece documentação com tutorial da API Java e também tem uma API em Clojure
Como o Rama reduz a complexidade dos bancos de dados
- Os PStates do Rama cumprem um papel parecido com o de bancos de dados, mas só podem ser escritos pela topologia de ETL que possui aquele PState
- Como todas as escritas ficam no mesmo código de ETL, fica mais fácil raciocinar sobre o estado
- PStates funcionam como materialized views sobre logs de event sourcing
- Como os dados do depot são a fonte de verdade, os PStates podem ser recalculados
- As restrições de modelo de dados são tratadas especificando PStates como estruturas de dados
- A implementação do Mastodon usa 33 PStates só para profiles, statuses e timelines
- Alguns PStates atendem 10 casos de uso, enquanto outros suportam apenas um caso específico
- PStates têm propriedades de durable, partitioned e incrementally replicated
- Incremental replication significa que, em caso de falha da partição líder, outra partição já está pronta para assumir
- O que é visível no líder atual é garantido como visível também em líderes posteriores
- O problema de normalização e desnormalização é tratado separando explicitamente depots e PStates
- O problema de esquemas limitados é amenizado usando diretamente a representação de domínio
- Estruturas de dados genéricas como hash map e list
- Protocol Buffers
- Definições de objetos aninhados
- Tipos que o Rama não conhece podem ser tratados registrando um custom serializer
Implantação, integração e monitoramento
- Aplicações Rama são chamadas de modules, e um module pode incluir vários depots, ETLs, PStates e query topologies
- O Rama oferece mecanismos embutidos para implantar, atualizar e escalar modules, e cada operação pode ser feita com um one-liner no terminal
- O Rama não é uma ferramenta “all or nothing”; ele foi projetado para se integrar facilmente a outros sistemas e pode ser introduzido gradualmente em arquiteturas existentes
- Por ser uma plataforma integrada, também faz seu próprio monitoramento
- Coleta de dados de monitoramento
- Processamento
- Indexação
- Visualização
- A cluster UI telemetry é usada para entender o desempenho de um module, detectar e diagnosticar problemas e decidir quando escalar
Aprendizado e caminho de adoção
- Os seguintes recursos são apresentados para aprender mais sobre o Rama
- Quem quiser usar o Rama para criar novos recursos em produção, expandir sistemas existentes ou simplificar infraestrutura pode se inscrever na private beta
- Segundo a empresa, usuários da private beta recebem suporte não só para aprender Rama, mas também para escrever código, otimizar e testar
1 comentários
Opiniões do Hacker News
“Como vou explicar mais adiante, a abordagem melhor é event sourcing e views materializadas” — então, no fim, a solução é aumentar a complexidade? Claro que seria
A nossa implementação do Mastodon em escala Twitter é um exemplo direto. Para criar as mesmas funcionalidades em escala, ela tem literalmente 100 vezes menos código do que o Twitter precisou escrever, e também mais de 40% menos código do que a implementação oficial do Mastodon. Não é porque, por ser a segunda vez usando as mesmas ferramentas, ela foi projetada melhor; é porque foi construída com abstrações fundamentalmente melhores
Mas, a partir de uma certa escala, tudo vira um problema de engenharia de dados e, no contexto do sistema como um todo, essa abordagem pode acabar sendo uma solução relativamente simples. O conselho “é só usar mySQL/SQLite/Postgres” é ótimo só até o momento em que deixa de ser válido
Acredito sinceramente que teria sido melhor para todo mundo se o artigo original de Martin Fowler sobre event sourcing nunca tivesse sido escrito. Em 99% dos casos, acho uma má ideia
Não sei se deixei passar algo, mas parece que o texto omite completamente conceitos como concorrência, isolamento e restrições. E essa tal “topologia de consulta” não parece declarativa e parece transferir para quem escreve a responsabilidade pelo planejamento/otimização das consultas; isso é mesmo considerado uma experiência melhor para o desenvolvedor?
E sim, a forma de consulta do Rama é uma abordagem muito superior. A necessidade de um planejador de consultas complexo geralmente vem das limitações da forma como os dados são indexados, especialmente da tensão entre normalização e desnormalização. No Rama, é fácil materializar de forma robusta várias views já preparadas no formato necessário para as consultas
Há um tutorial que apresenta suavemente os conceitos do Rama aqui: https://redplanetlabs.com/docs/~/tutorial1.html
Sobre a afirmação de que “nenhum modelo de dados único consegue dar suporte a todos os casos de uso”, em teoria não há domínio, nem conjunto finito de domínios, que não possa ser modelado com precisão como tuplas e relações de coisas.
Na prática, o escopo de um banco de dados/esquema específico normalmente fica limitado a um negócio ou área de problema, mas isso também não é um grande problema desde que os tipos não se sobreponham de forma inadequada. Se você tomar cuidado com os nomes, dá perfeitamente para colocar uma varejista online e uma seguradora no mesmo esquema e fazê-lo funcionar
Colocar tudo exatamente em um único banco de dados é um superpoder. O principal motivo pelo qual defendo isso com tanta força é evitar transações distribuídas entre vários armazenamentos de dados. Quando todo o negócio acontece dentro de um único sistema transacional, a semântica se simplifica drasticamente
Quando as pessoas de fato começam a usar os dados, um servidor de banco de dados grande de US$ 1 milhão sai muito mais barato do que um array redundante de bancos de dados baratos. Todo mundo economiza tempo, sejam desenvolvedores, analistas ou executivos; talvez a exceção sejam alguns DBAs
Mesmo que, em teoria, isso seja tudo, outro problema persistente é a implementação. Hoje em dia, a maioria dos desenvolvedores não entende bem como bancos de dados funcionam nem como devem ser usados, e acaba usando-os muito mal. Foi por isso que criaram novos bancos de dados, como NoSQL, para tentar escapar desse fato, pensando menos e escrevendo mais código de cola. Isso também acabou se revelando terrível
Em breve a maré vai virar de novo, “apenas um banco de dados grande” deixará de estar na moda, e surgirá outro paradigma de “simplicidade”. Como aconteceu com microsserviços, “muitos bancos de dados pequenos” pode passar a ser visto como simples, em vez de “um banco de dados grande”. Quem não entende a história está condenado a repeti-la
É como na programação em geral: uma única estrutura de dados, ou combinação de estruturas de dados, não consegue dar suporte a todos os casos de uso. Às vezes você precisa de um mapa; às vezes, de uma lista, um conjunto, uma combinação, ou algo completamente diferente
Naturalmente, as estruturas de dados são variadas, desempenho é necessário, e isso se torna um gargalo importante demais para pessoas comuns mexerem; toda mudança precisa ser extremamente segura. Também há segurança. E se alguém encontrar um jeito de sair da seção de bugs de desenvolvimento e chegar à seção de RH ou à seção financeira exclusiva para executivos? Quem já implementou um sistema ERM genérico sabe como sistemas integrados são difíceis e dolorosos
Mas esse é o caso extremo. Tenho curiosidade sobre até onde as pessoas foram perseguindo esse ideal e como fizeram. Nunca vi um negócio operado por um único sistema. E quanto a sistemas pessoais de gestão do conhecimento? Tudo se encaixa? Ainda assim, para trabalhos rápidos não se usa planilha e, para formato livre, arquivos de texto?
Parece uma coleção de buzzwords. Trabalhei por anos com bancos de dados em uma das maiores empresas do mundo e nunca ouvi o termo topologia
Mesmo que isso economize algum tempo, ele vai embora aprendendo Java e este framework. Não há nada de errado com bancos de dados em si
Tentei criar uma tabela de texto aqui, mas a renderização da página ficou completamente quebrada, então publiquei como captura de tela: https://imgur.com/a/XtwSkyx
Como você explicaria o Rama como se eu tivesse cinco anos? A documentação também me deixou confuso: https://redplanetlabs.com/docs/~/index.html
Gostaria que deixassem de lado buzzwords como “mudança de paradigma” ou “plataforma”. Se for preciso um diagrama, quero ler um texto que explique de forma mais clara
O Rama roda como um cluster, e várias aplicações são implantadas nesse cluster na forma de “módulos”. Telemetria profunda e detalhada também vem embutida
O modelo de programação do Rama é event sourcing e views materializadas. Ao criar uma aplicação Rama, você materializa quantos índices precisar, no formato que quiser, como combinações de várias estruturas de dados persistentes. Os índices são materializados por uma API de fluxo de dados distribuído
O Rama é tão diferente do que existia antes que isso é o máximo de explicação de alto nível que consigo dar. O melhor material para aprender os fundamentos é o rama-demo-gallery, que contém exemplos curtos, completos e muito comentados aplicando o Rama a vários casos de uso. Todos são escaláveis e tolerantes a falhas: https://github.com/redplanetlabs/rama-demo-gallery
Há um log de eventos append-only chamado “Depot”, e em cima dele você cria views arbitrárias, chamadas de “P-States”. O software Rama promete atualizações de baixa latência dessas views. Uma aplicação construída sobre isso consulta as views e envia novos eventos/comandos ao Depot
Trabalhei em um projeto de um ano para criar um mecanismo flexível de views materializadas sobre um dataset de eventos ao vivo na escala de 1 a 10 TB e, antes de eu passar para outro projeto, nossa arquitetura também estava convergindo mais ou menos para a ideia de enviar o código para onde o índice está
O Rama me atrai bastante, mas acho que não o adotaria por um motivo totalmente irracional: a JVM. Simplesmente não gosto de Java/JVM. Seria ótimo se essa arquitetura fosse portada para outros ambientes
No trabalho, separamos o modelo de leitura do modelo de escrita. O modelo de escrita, ou seja, a fonte da verdade, é um modelo de domínio relacional tradicional com invariantes/restrições, e acho que não é difícil de raciocinar para a maioria dos desenvolvedores acostumados com ORM
Quase todo comando também cria um evento e o publica em uma fila compartilhada de eventos de domínio. Os modelos de leitura são criados por workers que consomem os eventos e montam as views da forma que cada um precisa, podendo também recriá-las. Por exemplo, o serviço de gerenciamento de usuários é a fonte da verdade, enquanto outros serviços funcionam como serviços de view para exibir UIs complexas, criando seus próprios modelos de leitura/índices com base em eventos do serviço de usuários e de outros serviços. Sem isso, seriam necessários joins enormes ou chamadas de API lentas entre serviços
Tecnicamente, é possível reproduzir os eventos. Na prática, já tivemos de reproduzir todos os eventos dos últimos 3 anos por causa de um bug no código da plataforma. Mas acho que raramente isso foi realmente necessário. Às vezes é preciso reconstruir uma view por causa de bugs, mas normalmente tratamos isso com programas ad hoc, como scripts especiais ou migrações SQL. Não sei exatamente como chamar nossa arquitetura, e nunca ouvi ninguém chamá-la de “event sourcing”
No fim das contas, é o velho MySQL + RabbitMQ com um pouco de código de cola. Só que fazer isso direito não é tão trivial, por causa de coisas como transactional outbox, garantia de entrega pelo menos uma vez, consistência eventual, manutenção da ordem correta de processamento dos eventos, batching dos dados de eventos, administração do banco, tratamento quando um event handler morre etc. Como já temos uma composição independente de linguagem e validada em produção, com produtores/consumidores tanto em PHP quanto em Go, fico curioso para saber o que estamos perdendo sem o Rama e como o Rama resolve os problemas da lista acima. O Rama parece mais voltado para o lado Java
Os índices do Rama são muito mais flexíveis. Por exemplo, se você precisar de um conjunto aninhado com 100 milhões de elementos, isso é trivial. Um exemplo comum é um índice de grafo social como ID de usuário → conjunto de IDs de seguidores. Índices de séries temporais particionados por granularidade, isto é, entidade → granularidade → bucket de tempo → estatísticas, também são simples
Não há restrições sobre os tipos de dados armazenados no Rama. As consultas do Rama são muito poderosas, e é fácil fazer consultas distribuídas sob demanda em tempo real sobre parte ou a totalidade dos índices. Telemetria profunda e detalhada de toda a aplicação também vem embutida, sem necessidade de construir ou manter isso separadamente
A implantação também é embutida. No modelo atual, uma atualização de aplicação pode envolver vários sistemas, como código de workers e migrações de esquema, e isso vira um trabalho de engenharia bem difícil, especialmente se você quiser zero downtime. Como o Rama integra computação e armazenamento de ponta a ponta, lançar, atualizar e escalar aplicações é tudo possível com uma única linha no terminal
O Rama é muito mais escalável. Isso é o Rama visto do ponto de vista de funcionalidades, mas é difícil expressar em palavras a diferença que faz não haver descasamento de impedância ao programar com Rama; é algo que só dá para entender usando. O Rama é para a JVM, então pode ser usado com qualquer linguagem da JVM, e atualmente oferece APIs Java e Clojure
Onde os eventos são armazenados e em que formato? Gostaria de ouvir mais detalhes
O que parece faltar agora é um nome bonito para dar a todo o ecossistema
Materializar os dados no momento da alteração pode trazer ganhos quando o produto precisa fazer uma única coisa muito rapidamente. Mas, no instante em que surgem transações complexas que precisam ser atualizadas juntas por meio de escritas atômicas, ou quando se quer adicionar um novo recurso que exige organizar os dados de outra forma, isso vira um problema
Também acho muito insatisfatório que, na parte sobre construir aplicações, isso seja tratado de forma superficial, como se fosse “basta adicionar um índice”. Índices são estado global; eles só foram movidos uma camada para baixo
Mesmo lendo este documento, não fica claro quem é o público-alvo nem o que ele está tentando resolver: https://redplanetlabs.com/docs/~/why-use-rama.html#gsc.tab=0
Acho que ajudaria pegar um caso real e mostrar sua conversão para RAMA, demonstrando como isso ficaria fácil e eficiente
O primeiro é uma implementação do Mastodon em escala Twitter, com 100 vezes menos código do que o código que o Twitter escreveu para construir a mesma coisa em escala. Isso considerando apenas o produto voltado ao consumidor. Também tem mais de 40% menos código do que a implementação oficial do Mastodon, que não é escalável: https://github.com/redplanetlabs/twitter-scale-mastodon
O repositório rama-demo-gallery também traz muitos exemplos curtos, independentes e detalhadamente comentados de aplicação do Rama a casos de uso bem diferentes. Inclui gerenciamento de perfis de usuário, análise de séries temporais e transferências bancárias atômicas e tolerantes a falhas: https://github.com/redplanetlabs/rama-demo-gallery
A menos que vocês estejam de fato operando um site com 40 milhões de usuários diários, não parece possível afirmar que isso foi comprovado por um “cliente Mastodon em escala Twitter”. É impossível simular o ambiente real, as mudanças correspondentes em código e infraestrutura, usuários reais, uso de rede etc.