Dividindo tabelas, não linhas

O sharding vertical move tabelas inteiras para outro banco. O sharding horizontal divide as linhas de uma tabela, e o vertical divide o conjunto de tabelas.

Os dois eixos

A última linha é a que faz o sharding vertical valer ser aprendido primeiro. Uma chave de shard horizontal é uma decisão medida em trimestres, mas mover uma tabela para outro banco e de volta é uma migração e um deploy.

flowchart TB
  H["horizontal"] --> H1["usuários 1-1000 aqui, 1001-2000 ali"]
  H1 --> H2["mesmas tabelas, linhas diferentes"]
  V["vertical"] --> V1["usuários e cursos aqui, eventos ali"]
  V1 --> V2["tabelas diferentes, todas as linhas delas"]
  V2 --> V3["reversível: é uma migração, não movimentação ao vivo"]

Por que ele costuma ser tentado primeiro

As costuras já estão no seu schema.

Um schema não é uma malha uniforme. Algumas tabelas são muito ligadas entre si e mal ligadas ao resto. Essas fronteiras com poucas ligações são pontos candidatos para dividir, e você não precisa inventá-las. A lição 3 mede essas fronteiras nesta aplicação.

O sharding horizontal, por outro lado, exige inventar uma chave e depois conviver com ela.

O que ele traz

Ele dá capacidade própria a uma carga que se comporta de um jeito diferente do resto.

Os candidatos comuns se reconhecem pelo formato. Alguns são tabelas com muita escrita que todo o resto só lê, como eventos, logs e trilhas de auditoria. Outros crescem sem limite, como analytics. E outros têm um padrão de acesso completamente diferente, como uma fila consultada dez vezes por segundo.

Tirar essas tabelas do banco principal dá a elas I/O próprio, agenda de vacuum própria e política de backup própria. Também impede que o crescimento delas aperte as tabelas que servem as pessoas usando o produto.

O que ele não traz

Ele não ajuda uma única tabela grande demais. Se uma tabela domina, mover as vizinhas para longe a deixa do mesmo tamanho e igualmente ocupada. Esse é um problema horizontal, e o sharding vertical não mexe nele.

Ele também não multiplica a capacidade de escrita da mesma tabela. Cada tabela continua morando numa máquina. Você só escolheu qual.

A restrição que vem junto

Quando duas tabelas moram em bancos diferentes, você não consegue fazer join entre elas nem envolvê-las numa transação.

Essa é a mesma restrição do sharding horizontal, chegando por outro eixo. É por isso que a costura importa tanto: uma boa costura é uma que nenhuma query queria atravessar mesmo.

Pontos-chave

• O sharding horizontal divide linhas, e o vertical divide quais tabelas moram onde.
• O vertical costuma ser reversível: uma migração e um deploy, e não meses movendo linhas vivas.
• As costuras já existem no seu schema, como regiões em que as tabelas têm poucas ligações entre si.
• Ele dá a uma carga que se comporta de outro jeito I/O, vacuum e política de backup próprios.
• Ele não ajuda uma tabela grande demais, e quando as tabelas se separam você perde joins e transações através da costura.