O que SQL distribuído significa
O SQL distribuído promete um banco relacional com transações e joins, espalhado por várias máquinas, sem que você precise fazer sharding. Essa promessa merece um olhar cuidadoso, porque metade dela é verdade e a outra metade tem preço.
As três coisas que ele promete
Ele sobrevive à queda de máquinas. Os dados são replicados em vários nós, e perder um não perde os dados nem interrompe as escritas.
Ele cresce com a adição de nós. Você não escolhe chave de shard nem reescreve queries, que é o trabalho a que o curso de nível Sênior "Sharding de banco de dados: horizontal" dedicou sete lições.
Ele continua falando SQL, com transações no conjunto inteiro de dados. É isso que separa o SQL distribuído da geração anterior de armazenamentos distribuídos, que pedia para abrir mão de joins e de transações de várias linhas em troca de escala.
Como ele é construído
A tabela é cortada em faixas contíguas da chave primária, cada uma com até cerca de 512 MB no CockroachDB. Cada faixa é replicada em três nós por padrão, e as três réplicas rodam um protocolo de consenso, o Raft, para concordar sobre cada escrita.
Uma escrita é confirmada quando a maioria das réplicas a tem. Duas de três é maioria, então um nó pode estar lento ou fora do ar sem interromper as escritas.
flowchart TB
T["uma tabela"] --> R1["faixa: chaves aaa a fff"]
T --> R2["faixa: chaves ggg a mmm"]
T --> R3["faixa: chaves nnn a zzz"]
R1 --> N1["réplica no nó 1"]
R1 --> N2["réplica no nó 2"]
R1 --> N3["réplica no nó 3"]
N1 --> C["uma escrita precisa que 2 dos 3 concordem"]
N2 --> C
Repare no custo desse consenso. Uma escrita não termina quando uma máquina a tem. Ela termina quando a maioria a tem, o que significa pelo menos uma ida e volta de rede até outro nó, toda vez.
Quanto custa
Escritas de uma linha só são mais lentas que no Postgres, às vezes várias vezes mais, por causa dessa ida e volta de consenso.
Transações que tocam linhas em faixas diferentes são bem mais lentas, porque a coordenação passa a envolver vários grupos de nós.
O deploy mínimo sensato tem três nós, então o cluster CockroachDB útil mais barato custa mais que o servidor inteiro desta aplicação.
O enquadramento honesto
O SQL distribuído troca latência de escrita num nó único por sobrevivência e crescimento horizontal.
Se você não precisa de nenhum dos dois, paga o imposto e não recebe nada. É a situação desta aplicação, e é por isso que este curso vai terminar recomendando não usá-lo.
Isso não é uma crítica à tecnologia. É o raciocínio usado ao longo desta série: julgue a ferramenta pelo problema que você tem.
Pontos-chave
- O SQL distribuído oferece sobrevivência, crescimento horizontal e transações SQL reais ao mesmo tempo.
- As tabelas são cortadas em faixas de chave, e cada faixa é replicada em três nós que concordam via Raft.
- A maioria confirma cada escrita, então toda escrita inclui uma ida e volta de rede.
- Escritas de uma linha só são mais lentas que no Postgres, e transações entre faixas são bem mais lentas.
- Você paga o imposto precisando ou não da sobrevivência e do crescimento.
Continue com a aula 2
O problema do relógio
Por que relógios que derivam dificultam a ordem e como o CockroachDB reinicia transações dentro da janela de incerteza.
Com uma conta grátis você também tem os quizzes, seu progresso e suas anotações, e a discussão.