newSQL: a resposta que você não estava procurando

Eu me lembro vividamente da febre do NoSQL, ali por volta de 2010-2012. Parecia que a cada semana surgia um novo "herói" que prometia resolver todos os problemas do mundo: web scale, schemaless, eventual consistency. Nós, arquitetos e desenvolvedores, fomos bombardeados com a ideia de que o SQL estava morto, que os bancos de dados relacionais eram relíquias de um passado monolítico e que, para sobreviver na nova era da internet, precisávamos abraçar o caos glorioso do não-relacional.

Confesso que, por um tempo, eu também bebi dessa fonte. Migramos alguns sistemas, reescrevemos outros. E o que aprendemos? Aprendemos que não existe almoço grátis. Aprendemos que schemaless muitas vezes significa "sem esquema no banco, mas com um esquema infernal e implícito espalhado por todo o código da aplicação". Aprendemos que eventual consistency é um eufemismo simpático para "em algum momento, talvez, os dados estejam corretos, mas boa sorte descobrindo quando".

A verdade é que, para a grande maioria das aplicações que realmente movem o mundo – as que lidam com dinheiro, com logística, com a saúde das pessoas –, a consistência não é um nice to have. É a base de tudo. As propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade) não são uma formalidade acadêmica; são a garantia de que o sistema não vai enlouquecer e que a conta do cliente não vai ficar negativa porque duas transações chegaram ao mesmo tempo.

E então, depois da ressaca do NoSQL, a indústria começou a se perguntar: e agora? Voltamos para os gigantes relacionais tradicionais, com suas dificuldades de escalabilidade horizontal? Ou existe um meio-termo? Um caminho que nos dê a escalabilidade e a resiliência distribuída prometidas pelo NoSQL, mas com a sanidade e a confiabilidade transacional do bom e velho SQL?

É aqui que entra o "NewSQL". Um termo que, para mim, sempre soou mais como marketing do que como uma categoria técnica. Mas recentemente, me deparei com um artigo acadêmico que me fez parar e pensar. Um estudo chamado Performance Evaluation of NewSQL Databases in a Distributed Architecture, de pesquisadores da Singapore Management University. O que me chamou a atenção não foi o título, mas a metodologia. Eles não fizeram um benchmark sintético e estéril. Eles simularam um cenário do mundo real: um sistema de microserviços bancários, distribuído geograficamente entre Singapura e os Estados Unidos, e mediram o desempenho do começo ao fim.

Eles colocaram dois competidores no ringue: o MySQL NDB Cluster, uma evolução distribuída de um velho conhecido, e o TIBCO ActiveSpaces, um In-Memory Data Grid (IMDG) que se posiciona nesse espaço NewSQL. Os resultados, meus amigos, são um banho de água fria em muito do hype que ouvimos por aí e um lembrete poderoso de que, em arquitetura de software, o diabo não está apenas nos detalhes – ele está nos fundamentos.

O que acontece quando você para de testar bancos de dados no vácuo?

A primeira coisa que me fez respeitar esse estudo foi o seu realismo. Se você está no mercado há tanto tempo quanto eu, já viu centenas de benchmarks que não significam absolutamente nada. Testes que medem milhões de "operações por segundo" em um único servidor, em uma rede local, sem latência, sem concorrência, sem a complexidade de uma aplicação real fazendo chamadas. Isso é inútil. É como testar um motor de Fórmula 1 em uma bancada e achar que sabe como o carro vai se comportar em Mônaco, na chuva.

Os autores do artigo fizeram o oposto. Eles construíram a pista de Mônaco, na chuva. O cenário deles envolvia:

1. Uma arquitetura de microserviços: Eles desenvolveram um serviço de "Recompensa de Fidelidade", um cenário bancário típico, usando SpringBoot, um framework onipresente no mundo Java.
2. Distribuição geográfica real: A arquitetura foi implantada em duas regiões da AWS, Singapura e Leste dos EUA. Isso introduz a latência do mundo real, o verdadeiro inimigo de qualquer sistema distribuído.
3. Medição de ponta a ponta: Em vez de usar ferramentas que falam direto com o banco, eles usaram o Apache JMeter para invocar as APIs do microserviço. Isso significa que a latência medida incluía a comunicação de rede, o processamento da aplicação e, finalmente, a operação do banco de dados. É a latência que o usuário sente, e a única que realmente importa.

Os competidores, como mencionei, eram o MySQL NDB Cluster e o TIBCO ActiveSpaces. O MySQL NDB é, essencialmente, o MySQL com um motor de armazenamento em memória (NDB) projetado do zero para ser distribuído e replicado, prometendo escalabilidade horizontal e alta disponibilidade. O TIBCO ActiveSpaces vem de um mundo diferente, o dos In-Memory Data Grids (IMDGs), que são sistemas projetados para manter grandes volumes de dados na RAM para acesso ultrarrápido, mas que também adicionaram uma camada de consulta SQL e persistência para competir no espaço NewSQL.

Com o campo de batalha montado, a pergunta era: como essas duas abordagens filosóficas diferentes se sairiam sob o estresse do mundo real?

Quem ganha na corrida?

Os resultados de desempenho foram fascinantes porque não houve um vencedor claro. Em vez disso, eles revelaram a importância crítica de entender a natureza da sua carga de trabalho.

As operações em massa: domínio do TIBCO

Quando se tratava de inserir, atualizar ou deletar grandes volumes de dados de uma só vez, o TIBCO ActiveSpaces foi muito eficiente. No teste de inserção de 10.000 registros, por exemplo, o TIBCO levou cerca de 2.8 segundos, enquanto o MySQL NDB precisou de quase 7.5 segundos, mais que o dobro do tempo.

Tabela 8: Resultados de Inserção (em milissegundos)

Essa vantagem se repetiu em atualizações e exclusões em massa. A razão para isso está na arquitetura. O ActiveSpaces foi projetado para paralelizar cargas de trabalho em todos os seus nós de dados (chamados de copysets). Quando você joga um caminhão de dados nele, ele divide a carga e trabalha em paralelo. É uma arquitetura otimizada para throughput, para vazão. Isso o torna ideal para casos de uso como ingestão de dados de IoT, processamento de logs ou qualquer cenário onde você precisa absorver um grande volume de informações rapidamente.

As operações cirúrgicas e as leituras: vitória do MySQL

No entanto, a história mudou completamente quando a carga de trabalho se tornou mais transacional e orientada à leitura. Para operações de um único registro (inserir, ler, atualizar ou deletar), o MySQL NDB foi consistentemente mais rápido.

Mas a verdadeira surra veio nas operações de leitura e, especialmente, nas de agregação. Ao ler 10.000 registros, o MySQL NDB levou apenas 48 milissegundos, enquanto o TIBCO ActiveSpaces, na mesma região, precisou de 1.726 milissegundos – mais de 35 vezes mais lento!

A coisa ficou ainda mais feia nas agregações (SUM, AVG, MAX, MIN). Vejam só isso:

Tabela 12: Resultados de Agregação (em milissegundos)

Os números falam por si. O MySQL NDB respondeu em um dígito de milissegundos, enquanto o TIBCO levou mais de 1.3 segundos. Uma diferença de mais de 200 vezes. A explicação, novamente, está na arquitetura. O proxy do ActiveSpaces precisa consultar todos os nós, coletar os dados e só então realizar a agregação, um processo com um custo administrativo enorme. O MySQL NDB, por outro lado, se beneficia de um motor SQL tradicional e otimizado para esse tipo de consulta.

A analogia que me vem à mente é esta: o TIBCO é uma frota de caminhões de carga. Se você precisa mover o conteúdo de um armazém inteiro, eles são imbatíveis. Mas se você precisa entregar uma única pizza do outro lado da cidade, eles são terrivelmente ineficientes. O MySQL NDB é uma frota de motoboys ágeis. Eles são perfeitos para as entregas rápidas e direcionadas que constituem a maior parte das operações de um sistema transacional.

Quando um banco de dados mente sobre quem ele é?

Desempenho é importante, mas não é tudo. A promessa fundamental de um banco de dados que se diz compatível com ACID é a confiabilidade. E é aqui que o artigo revela o que, para mim, é o ponto mais crítico.

Os pesquisadores elaboraram um cenário engenhoso para testar a propriedade de Isolamento do ACID. A ideia era simular um processo de "ganhar recompensa", onde o cálculo do novo saldo de um cliente dependia do saldo da última transação. Para que o cálculo seja correto, o registro da última transação precisa ser "travado" enquanto um novo registro está sendo criado. Se o banco de dados permitir que duas transações leiam o mesmo "último registro" ao mesmo tempo, ambas calcularão o novo saldo com base na mesma informação, resultando em um erro de contabilidade e, essencialmente, em um "double spend" da recompensa.

Eles executaram 10.000 transações concorrentes e depois verificaram quantas vezes a mesma transação anterior foi referenciada mais de uma vez. O resultado é assustador.

Tabela 14: Resultados do Teste de Violação de Isolamento

O MySQL NDB se comportou exatamente como esperado de um banco de dados ACID: zero violações. O TIBCO ActiveSpaces, por outro lado, falhou 93 vezes. O mais chocante é que, segundo o artigo, a documentação do TIBCO alega suportar o nível de isolamento mais alto possível: serializable.

Isso, para um arquiteto, é uma quebra de contrato fundamental. Se um banco de dados não consegue garantir o isolamento que promete, toda a lógica de negócio construída sobre ele está em risco. Para qualquer sistema que lide com finanças, inventário, reservas ou qualquer estado crítico, essa falha é inaceitável.

Como se não bastasse, o estudo também avaliou a consistência da replicação entre as duas regiões geográficas. O MySQL NDB, com sua configuração de replicação ativa-ativa, levou em média 109 milissegundos para que um dado escrito em uma região estivesse legível na outra. O TIBCO ActiveSpaces, que segundo o artigo só suporta uma configuração ativa-passiva, levou 957 milissegundos. Quase nove vezes mais lento. Essa é a diferença entre um sistema globalmente responsivo e um que parece estar sempre um passo atrás.

O código que você não escreve é o melhor código. Concorda?

Por fim, o artigo toca em um ponto que muitas vezes é negligenciado em análises puramente técnicas, mas que, na prática, pode determinar o sucesso ou o fracasso de um projeto: a Experiência do Desenvolvedor (DevEx).

Os autores relatam que configurar o MySQL NDB foi "relativamente simples". Já a experiência com o TIBCO ActiveSpaces foi um pesadelo: documentação escassa, falta de suporte da comunidade, a necessidade de fuçar scripts de exemplo para entender como as coisas funcionavam e, a cereja do bolo, a dependência de bibliotecas externas (DLLs) que complicaram enormemente a criação de um contêiner para a aplicação.

Mas o ponto crucial foi este: o MySQL NDB é compatível com o ecossistema maduro do Java, incluindo o Spring Boot JPA. Isso permite que os desenvolvedores usem abstrações de alto nível para lidar com sessões, transações e conexões, acelerando o desenvolvimento e reduzindo a chance de erros. O TIBCO, por sua vez, não se integra ao JPA, forçando os desenvolvedores a gerenciar tudo manualmente, na unha.

Isso não é um detalhe. Cada linha de código de infraestrutura que você é forçado a escrever é uma linha a mais para testar, para depurar e para manter. É um desvio de foco do que realmente importa: a lógica de negócio.

Além disso, o TIBCO ActiveSpaces carecia de recursos SQL básicos que consideramos garantidos há décadas, como a capacidade de definir chaves estrangeiras (foreign keys) ou restrições NOT NULL. A ausência de chaves estrangeiras é particularmente grave. Significa que a responsabilidade de manter a integridade referencial dos dados é empurrada para a aplicação. E todos nós sabemos como isso termina: com dados órfãos, inconsistências e uma complexidade que se espalha como um vírus pelo código.

Análise crítica: E os outros?

Apesar de eu ter gostado muito do artigo, como um provocador por natureza, não posso deixar de apontar algumas questões. A principal crítica que faço ao estudo é a escolha do TIBCO ActiveSpaces como representante do "mundo novo". Com todo o respeito à TIBCO, seu produto não é exatamente um nome de destaque no cenário NewSQL. Comparar o MySQL NDB com ele é um pouco como comparar um sedã alemão estabelecido e confiável com um carro elétrico de uma startup pouco conhecida. A comparação é válida, mas não representa a vanguarda do mercado.

A verdadeira batalha pela alma do banco de dados distribuído hoje acontece entre a filosofia do MySQL NDB (que é uma evolução de uma arquitetura existente) e a dos chamados "Spanner-likes": bancos de dados como  CockroachDB, YugabyteDB e TiDB.

Esses sistemas foram inspirados pelo Google Spanner e projetados, desde o primeiro dia, para serem bancos de dados SQL geograficamente distribuídos, com consistência forte por padrão. Eles não usam replicação ativa-ativa tradicional. Em vez disso, eles formam um único cluster lógico que se estende por múltiplas regiões, usando protocolos de consenso como o Raft para garantir que as transações sejam aplicadas de forma consistente em todo o cluster.

Como esses bancos de dados teriam se saído no teste do artigo?

• No teste de Isolamento: CockroachDB, YugabyteDB e TiDB oferecem isolamento Serializable por padrão. É o DNA deles. Eles teriam passado com nota máxima, assim como o MySQL NDB. A falha do TIBCO aqui o coloca em uma categoria completamente diferente de seriedade.
• No desempenho: A história seria mais complexa. A escrita em um cluster geograficamente distribuído como o do CockroachDB incorre em uma latência inerente, pois o protocolo Raft exige que um quórum de nós confirme a escrita. Dependendo da configuração, essa latência pode ser maior que a da replicação assíncrona do MySQL NDB. No entanto, a simplicidade para o desenvolvedor é imensa: você se conecta a um único banco de dados lógico, e ele se encarrega de rotear as leituras e escritas para os nós corretos, garantindo a consistência.
• Na Experiência do Desenvolvedor: Esses sistemas são, em sua maioria, compatíveis com o protocolo do PostgreSQL (no caso do Cockroach e Yugabyte) ou do MySQL (no caso do TiDB). Isso significa que eles se integram perfeitamente com o ecossistema de ferramentas e frameworks existentes, uma vantagem gigantesca que o TIBCO ActiveSpaces, como vimos, não possui.

Portanto, embora o artigo nos dê um duelo fascinante, a guerra real é mais ampla. É a batalha entre diferentes filosofias arquitetônicas para resolver o mesmo problema: como escalar o SQL de forma confiável em um mundo distribuído.

Meu veredito: escolha sua arma com sabedoria

No final, o estudo chega a uma conclusão sóbria e pragmática, resumida em sua tabela final de recomendações.

Tabela 16: Principais Considerações para a Escolha

A mensagem é clara:

• O MySQL NDB Cluster brilha em aplicações que são o coração do negócio. Sistemas que exigem processos complexos, integridade de dados inegociável e a robustez das garantias ACID. É a escolha para o seu core bancário, seu sistema de ERP, sua plataforma de e-commerce.
• O TIBCO ActiveSpaces (e, por extensão, outros IMDGs focados em ingestão) tem seu lugar em desafios de Big Data, especificamente para lidar com Volume e Velocidade. Pense em um sistema de detecção de fraude que precisa ingerir milhões de transações de cartão de crédito em tempo real para análise. Nesses cenários, a velocidade de escrita em massa é crucial, e talvez uma pequena inconsistência ocasional seja um preço aceitável a pagar.

A lição que eu tiro de tudo isso, depois de mais de duas décadas construindo sistemas, é que as ferramentas evoluem, os nomes mudam, o marketing se reinventa, mas os princípios fundamentais da engenharia de software permanecem. Não existe bala de prata. A busca pela ferramenta "perfeita" é uma ilusão. A verdadeira habilidade de um arquiteto não está em conhecer a última tecnologia da moda, mas em entender profundamente os trade-offs e escolher a ferramenta certa para o trabalho certo.

Então, da próxima vez que alguém tentar lhe vender uma solução mágica de "escala infinita", pare e faça as perguntas difíceis. Pergunte sobre o modelo de consistência. Pergunte sobre o que acontece durante uma falha de rede. Pergunte sobre a experiência de quem vai ter que viver com aquele código todos os dias.

Estamos tão obcecados com a "escala infinita" que esquecemos de perguntar o que acontece quando a conta não fecha no final? Talvez a tecnologia mais "chata" e confiável seja, no final das contas, a mais inovadora de todas.

O que você acha?