Ce que Notion a appris en shardant Postgres

 (notion.so)
29 points par xguru 2021-10-18 | 1 commentaires | Partager sur WhatsApp
  • En début d’année, Notion a subi une panne de 5 minutes et a mené un sharding PostgreSQL préparé depuis plusieurs mois

→ les réactions ont immédiatement commencé à signaler que c’était devenu énormément plus rapide

  • Quand la décision de shard a-t-elle été prise ?

→ après une croissance de plusieurs ordres de grandeur sur 5 ans, le monolithe Postgres qui fonctionnait bien jusque-là a commencé à dépasser ses limites de capacité

→ VACUUM a commencé à être interrompu en continu, et comme un TXID wraparound était attendu à brève échéance, le travail de sharding a commencé

  • Concevoir le schéma de sharding

→ sharding au niveau applicatif

⇨ quelles données faut-il sharder ?

⇨ selon quelle clé partitionner les données ?

⇨ combien de shards faut-il créer, et comment les organiser ?

→ Décision n°1

⇨ le modèle de données de Notion est structuré autour de l’unité block

⇨ il a été décidé de sharder toutes les tables liées à la table block (Space, Discussion, Comment, etc.)

→ Décision n°2

⇨ block est partitionné par workspace ID

⇨ chaque workspace reçoit un UUID, qui est donc utilisé ici

→ Décision n°3

⇨ architecture composée de 480 shards logiques et de 32 bases de données physiques

la raison du choix de 480 au lieu de 512, pourtant une puissance de 2, est que c’est un nombre plus flexible à subdiviser

  • Migrer vers les shards

→ 1. écriture en double sur l’ancienne et la nouvelle base (avec Audit Log)

→ 2. après le début de la double écriture, lancement du backfill des données de l’ancienne base vers la nouvelle

→ 3. validation des données de la nouvelle base

→ 4. bascule vers la nouvelle base (de manière incrémentale)

  • Leçons apprises à la dure

→ shardez plus tôt : comme ils ont attendu que la charge sur la base existante devienne trop importante, la migration elle-même a aussi ajouté de la charge, ce qui a obligé à avancer lentement

→ visez une migration sans interruption : le débit de la double écriture a été le principal goulot d’étranglement au moment de la bascule finale.

→ utilisez une clé primaire composite plutôt qu’une clé de partition séparée : en combinant id, la clé primaire de la base existante, avec space_id, la clé de partition, il aurait été possible d’éviter de devoir faire passer les space_id dans l’application

À lire aussi

1 commentaires

 
xguru 2021-10-18

L’histoire des TXID de Postgres est toujours un sujet qui revient