Neste artigo vamos focar nos bancos de dados NewSQL. Esse termo surgiu para descrever sistemas que buscam unir a consistência transacional (ACID) típica de bancos relacionais com a escalabilidade horizontal de soluções NoSQL. Exemplos incluem Google Spanner (e derivados como CockroachDB, YugaByteDB, TiDB). Avaliaremos os mesmos sete critérios que vimos até agora, atribuindo notas de 0 a 10, lembrando que cada produto específico pode apresentar variações.
1. Curva de Facilidade de Aprendizado
Nota: 7/10
Por Que
- Muitos bancos NewSQL tentam ser compatíveis com a sintaxe SQL (por exemplo, CockroachDB e YugaByteDB, que suportam comandos compatíveis com PostgreSQL).
- A base de consultas (SQL) é familiar, mas configurar um cluster distribuído, entender replicação e particionamento pode demandar um estudo adicional.
Observações
- Operar um banco de dados NewSQL requer conhecimento de cluster e rede (por exemplo, latências entre nós).
- Em contrapartida, se a equipe já domina PostgreSQL, migrar para CockroachDB (que finge ser “Postgres-like”) facilita o aprendizado no plano de queries, mas não na configuração de nós.
2. Facilidade de Modelagem de Dados
Nota: 8/10
Por Que
- O modelo relacional prevalece: tabelas, colunas, constraints, possivelmente com índices secundários e transações ACID.
- Para quem vem do mundo SQL, a modelagem é muito parecida com a de um banco relacional tradicional.
Observações
- Alguns NewSQL (como TiDB) suportam “quase 100%” do dialeto MySQL, enquanto outros (CockroachDB) se aproximam de PostgreSQL.
- Restrições e recursos como foreign keys, constraints, ou stored procedures podem estar parcialmente implementados, dependendo do produto e versão.
3. Escalabilidade / Taxa de Transferência
Nota: 8/10
Por Que
- O objetivo central do NewSQL é escalar horizontalmente mantendo uma interface SQL e transações.
- Produtos como CockroachDB ou YugaByteDB permitem adicionar nós ao cluster, redistribuindo dados e aumentando capacidade.
Observações
- O desempenho pode não atingir a mesma “simplicidade de escalabilidade” que bancos NoSQL puros (ex.: Cassandra), pois manter transações ACID distribuídas é complexo.
- Ainda assim, eles tendem a oferecer boa escalabilidade para grande parte dos cenários.
4. Disponibilidade e Tolerância de Partição
Nota: 8/10
Por Que
- A maioria dos NewSQL foi arquitetada para rodar em clusters distribuídos, espalhando réplicas de dados pelos nós. Assim, são capazes de tolerar falhas de máquina ou até zonas de disponibilidade.
- CockroachDB, por exemplo, assegura que cada range de dados tenha réplicas espalhadas, podendo sobreviver à queda de um nó. YugaByte e Spanner usam replicação sincrona com protocolos de consenso (Raft ou Paxos).
Observações
- A “prioridade” pode estar em consistência e escalabilidade, mas a tolerância a partição depende do protocolo de consenso. Em caso de partição de rede severa, pode haver degradação no throughput de escrita, pois é preciso atingir quórum.
- Ainda assim, a disponibilidade é bem superior a de um único servidor relacional.
5. Consistência
Nota: 9/10
Por Que
- Esse é o diferencial: NewSQL busca manter consistência forte (ACID) mesmo em ambientes distribuídos. Muitos usam protocolos de consenso (Raft, Paxos) para garantir que leituras e escritas sejam seriáveis.
- Google Spanner, por exemplo, oferece external consistency (uma forma de serializabilidade global com timestamps exatos).
Observações
- Uma transação que abrange nós em regiões diferentes pode ter latência maior, pois necessita “consenso”.
- Em contrapartida, se o projeto exige dados fortemente consistentes, NewSQL é uma opção poderosa, evitando a complexidade de gerenciar consistência manualmente.
6. Suporte, Maturidade, Comunidade e Compatibilidade
Nota: 7/10
Por Que
- É um segmento mais recente do que bancos relacionais clássicos ou NoSQL mais antigos (ex.: Cassandra). Então, o ecossistema e a quantidade de profissionais experientes podem ser menores.
- Grandes empresas já usam Google Spanner, mas é proprietário. CockroachDB tem uma crescente comunidade e suporte comercial, YugaByte também, mas ainda não tão difundidos quanto MySQL ou PostgreSQL.
Observações
- Em termos de compatibilidade SQL, muitos afirmam compatibilidade parcial ou quase completa com Postgres/MySQL, mas pode haver funções ou extensões faltando.
- A maturidade depende do produto: alguns estão em estágios avançados (CockroachDB, YugaByte) com versões enterprise e suporte, mas ainda longe do histórico de 20+ anos de PostgreSQL.
7. Prioridade de Leitura e Gravação
Nota: 8/10
Por Que
- O foco desses bancos é atender alto throughput tanto em leituras quanto em escritas distribuídas.
- No entanto, manter transações ACID com múltiplos nós e consenso aumenta a latência em comparação a NoSQL “AP” (como Cassandra) que sacrifica consistência rigorosa.
Observações
- Para aplicações que fazem muitas escritas de baixa latência com “eventual consistency” tolerável, um KV ou column-family puro pode ser mais rápido.
- Se a aplicação valoriza transações e fortes garantias, NewSQL equilibrará leituras/escritas distribuídas com consistência global.
Resumo das Notas
| Característica | Nota |
|---|---|
| Curva de Facilidade de Aprendizado | 7/10 |
| Facilidade de Modelagem de Dados | 8/10 |
| Escalabilidade / Taxa de Transferência | 8/10 |
| Disponibilidade e Tolerância de Partição | 8/10 |
| Consistência | 9/10 |
| Suporte, Maturidade, Comunidade, Compatibilidade | 7/10 |
| Prioridade de Leitura e Gravação | 8/10 |
Conclusão
Os bancos de dados NewSQL representam uma proposta de unir:
- Consistência e modelo relacional (com transações ACID).
- Escalabilidade horizontal e alta disponibilidade típicas de soluções NoSQL.
Eles são ideais quando o projeto exige:
- Modelo SQL (facilidade de query e transações ACID)
- Distribuição e escalabilidade (dados em vários nós/zonas)
- Consistência forte mesmo em cenários distribuídos.
Eles podem não ser a melhor escolha quando:
- Se busca a máxima simplicidade de escalabilidade e se tolera consistência eventual (bancos NoSQL AP puros podem ser mais simples ou mais rápidos).
- Se o time não está pronto para gerenciar a complexidade de um cluster distribuído que precisa de consenso para cada gravação.
Em suma, NewSQL é uma opção poderosa para aplicações que requerem o melhor dos dois mundos: transações SQL robustas e desempenho escalável em múltiplos nós. Apesar de ainda mais recente e com menor comunidade do que bancos SQL clássicos, vem ganhando espaço em sistemas que não podem abrir mão de consistência mas precisam crescer horizontalmente sem limites aparentes.
Notas Bibliográficas
- Arquitetura de Software: As Partes Difíceis. Editora Alta Books.