- No começo deste ano, a Notion ficou fora do ar por 5 minutos enquanto realizava o sharding do PostgreSQL em que vinha trabalhando havia alguns meses
→ A reação começou a aparecer imediatamente: ficou muito mais rápido
- Quando decidiram fazer sharding
→ Após crescer dezenas de milhares de vezes ao longo de 5 anos, o monólito de Postgres que funcionava bem começou a ultrapassar sua capacidade
→ O VACUUM começou a ser interrompido continuamente, e como era esperado que em breve ocorresse TXID wraparound, o trabalho de sharding foi iniciado
- Projetando o esquema de sharding
→ Sharding no nível da aplicação
⇨ Quais dados deveriam ser shardados
⇨ Com qual chave particionar e dividir os dados
⇨ Quantos shards criar e como estruturá-los
→ Decisão #1
⇨ A Notion organiza seu modelo de dados na unidade de block
⇨ Decidiram fazer sharding de todas as tabelas conectadas à tabela block (Space, Discussion, Comment etc.)
→ Decisão #2
⇨ block é particionado por workspace ID
⇨ Como cada workspace recebe um UUID, isso foi usado
→ Decisão #3
⇨ Estrutura composta por 480 shards lógicos e 32 bancos de dados físicos
O motivo para escolher 480 em vez de 512, que é potência de 2, foi por ser um número que pode ser dividido com mais flexibilidade
- Migrando para os shards
→ 1. Escrita dupla no banco antigo e no novo (junto com Audit Log)
→ 2. Após iniciar a escrita dupla, começou o backfill dos dados do banco antigo para o novo
→ 3. Validação dos dados no novo banco
→ 4. Troca para o novo banco (de forma incremental)
- Lições aprendidas da forma mais difícil
→ Façam sharding mais cedo: como esperaram até a carga no banco existente ficar alta, a própria migração também passou a gerar carga, então não houve alternativa além de avançar lentamente
→ Tenham como meta uma migração com zero downtime: a vazão da escrita dupla foi o principal gargalo no momento da troca final.
→ Em vez de uma chave de partição separada, usem PK composta: se tivessem combinado id, que era a PK do banco existente, com space_id, que era a chave de partição, teriam evitado a necessidade de passar space_id dentro da aplicação
1 comentários
A história do TXID no Postgres é sempre um dos temas que aparecem
Defeitos do PostgreSQL https://pt.news.hada.io/topic?id=1829
O que aprendemos ao escalar PostgreSQL por 5 anos https://pt.news.hada.io/topic?id=4101