O que SQL distribuído significa

Prévia grátis 3 min de leitura

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.
Aula 1 de 7 · grátis

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.

Digite para buscar...