Tecnologias/02 - Bancos de Dados/03 - NewSQL2 min
Produtos de SQL Distribuído
CockroachDB
Banco SQL distribuído que separa processamento SQL, transações e armazenamento chave-valor. Os dados são divididos em ranges replicados. A interface compatível com o protocolo PostgreSQL facilita o uso de clientes, mas não significa equivalência integral com a implementação do PostgreSQL. Arquitetura oficial.
TiDB
A camada SQL do TiDB atende conexões compatíveis com o protocolo MySQL. TiKV fornece armazenamento distribuído, enquanto o Placement Driver participa do gerenciamento e da coordenação do cluster. TiFlash acrescenta armazenamento colunar para operações analíticas. A separação permite tratar computação e armazenamento como componentes distintos, com responsabilidades próprias. Guia de arquitetura da PingCAP.
YugabyteDB
Combina uma camada de consulta com armazenamento distribuído DocDB. A API YSQL atende SQL, enquanto YCQL oferece outra interface de consulta. Dados são divididos em tablets, e a camada de armazenamento cuida da persistência e da replicação. Arquitetura oficial.
Google Spanner
Serviço de banco distribuído do Google Cloud. Combina transações e versões dos dados com mecanismos de coordenação e timestamps. TrueTime participa da atribuição de tempo que sustenta suas garantias de consistência externa no modo serializável. Isso não significa ausência de comunicação ou custo de escrita entre regiões. TrueTime e consistência externa.
Diferenças que importam
| Aspecto | Efeito para a aplicação |
|---|---|
| Compatibilidade SQL | Determina comandos, tipos, drivers e recursos que podem ser usados |
| Isolamento | Determina efeitos permitidos entre operações concorrentes |
| Distribuição | Afeta quais nós participam de consultas e escritas |
| Retries | Define como a aplicação trata conflitos e resultados incertos |
Esses produtos não são substitutos idênticos. Um SQL aceito por dois sistemas pode ter execução, isolamento e custos diferentes.
Aprofundamento aplicado
Prova de compatibilidade com a aplicação real
Compatibilidade de protocolo permite conectar um driver; compatibilidade semântica exige examinar tipos, DDL, isolamento, funções, índices e códigos de erro usados. Uma prova útil começa pelo conjunto de operações da aplicação e seus casos de concorrência.
| Experimento | O que revela |
|---|---|
| Duas reservas do último item | Isolamento e estratégia de conflito |
| Desconexão no commit | Resultado incerto e reconciliação |
| Consulta para cliente muito grande | Distribuição desigual e plano |
| Mudança de schema com tráfego | Processo operacional de migração |
| Perda de um nó ou região | Garantias da topologia configurada |
Evite comparar desempenho com durabilidade e consistência diferentes sem declarar essa diferença. Também separe operação gerenciada de operação própria: backups, atualizações e resposta a falhas podem ficar com responsáveis diferentes.
Exercício: monte uma matriz para dois produtos usando três consultas e duas transações reais. Resultado esperado: cada conclusão aponta uma funcionalidade documentada ou um resultado medido, e os pontos ainda não verificados permanecem explícitos.
Referências de implementação: CockroachDB, TiDB, YugabyteDB e Spanner.
Relacionado: 1. NewSQL e SQL Distribuído · 4. Transações e Isolamento em NewSQL.
Parte de NewSQL