O documento discute as diferenças entre SQL e NoSQL, destacando os benefícios e limitações de cada abordagem. Apresenta o Google Cloud Spanner como uma solução que combina características de ambos, garantindo consistência, escalabilidade horizontal e alta disponibilidade. O texto também menciona casos de uso e comparações entre distintas tecnologias de banco de dados.

1. NewSQL
Deixando de lado a batalha SQL x NoSQL

2. People are very open-minded
about new things, as long as
they're exactly like the old ones
Charles F. Kettering

3. O Modelo Relacional (SQL)

4. Modelo
Relacional
Baseado em conceitos que as pessoas já
entendem (linhas e colunas)
Permite o relacionamento entre entidades
(tabelas)
Passa no ACID Test:
Permite a Atomicidade de uma transação
Garante a Consistência de uma transação
Habilita o Isolamento de uma transação
Torna Duráveis as mudanças feitas
SQL
Facts

5. Modelo
Relacional
Disponibilidade: Surgiram várias técnicas,
mas nenhuma bala de prata
Escalabilidade: Fortemente vertical e
levemente horizontal
Investimento: Investimentos em hardwares
caros são essenciais para grandes
ambientes
SQL
Nem tudo são flores

7. NoSQL
Schemaless: BigData não significa apenas uma
grande quantidade de dados, mas também de
várias fontes distintas e com modelos de dados
diferentes
Escalabilidade: Projetado para suportar
crescimento horizontal
Not Only SQL

8. NoSQL
SQL: Nem todos os bancos NoSQL apresentam
uma interface SQL, comum a boa parte dos
programadores e não programadores
Consistência: Devido ao foco em disponibilidade
e escabalidade horizontal, a consistência, embora
existente, é eventual
Not Only SQL

10. Conflito:
ACID / Escalabilidade Vertical
x
Non-ACID / Escalabilidade Horizontal

11. Google Cloud Spanner

12. NewSQL
ACID: Sim
SQL: Sim
Escalabilidade Horizontal: Sim (inclusive
através de diferentes data centers)
Replicação: Sim
Cloud Spanner

13. O Teorema CAP

15. Arquitetura
Bases de Dados Consistentes e Altamente
Disponíveis
Controle da infraestrutura de Rede, provendo
Network Partition Tolerance
Controle da Infraestrutura de Dados com o
Google Colossus provendo Durabilidade dos
dados em disco
Protocolo de comunicação gRPC
Cloud Spanner

17. Arquitetura
A Consistência é sempre o item mais prioritário.
Isto geralmente envolve locks do tipo "two phase
commit" entre diferentes nós. A consistência das
leituras é feita com Timestamp nos registros e uso
do Google True Time.
A resistência aos problemas de rede (Network
Partition Tolerance - P) acontece devido à
infraestrutura de rede do Google
A Disponibilidade (A) é da ordem de 99.9999%,
não é garantida em 100% do tempo.
Cloud Spanner

21. Arquitetura
Banco de Dados do tipo CA (RDBMS)
Network Partition Tolerance (P) provida pela
infraestrutura de rede interna do Google
Possui shard automático de dados entre os nós
do cluster
Possui ACID
A adição de nós horizontalmente aumenta a
capacidade de processamento do cluster
Resumo

22. Arquitetura
Leituras por segundo (por nó): 2.000
Escritas por segundo (por nó): 10.000
Storage por nó: 2 TB
Funciona apenas na nuvem pois depende
extremamente da arquitetura Google para prover
suas funcionalidades: TrueTime, Low Latency
Global Network, Colossus
Limitações

23. Caso de Estudo
Quizlet

24. MySQL x
Cloud
Spanner
DB 700 GB
Maior tabela: 600 GB
6 bilhões de registros
80 GB de Índices
Pico de 3.000 queries/seg

29. Além do
Spanner
CockroachDB - Baseado no PostgreSQL e
no Spanner
CitusDB - Baseado em PostgreSQL
Postgres-XL - Baseado em PostgreSQL
Galera Cluster - MySQL

30. Obrigado!