- Anfang dieses Jahres wurde Notion für 5 Minuten offline genommen, um das seit mehreren Monaten laufende PostgreSQL-Sharding durchzuführen
→ Unmittelbar danach kamen erste Reaktionen, dass es deutlich schneller geworden sei
- Wann fiel die Entscheidung für Sharding?
→ Nach einem Wachstum um mehrere Zehntausendfache über 5 Jahre begann der lange gut funktionierende Postgres-Monolith an seine Kapazitätsgrenzen zu stoßen
→ VACUUM wurde immer wieder unterbrochen, und da bald ein TXID-Wraparound erwartet wurde, begann man mit dem Sharding-Projekt
- Entwurf des Sharding-Schemas
→ Sharding auf Anwendungsebene
⇨ Welche Daten sollen geshardet werden?
⇨ Nach welchem Schlüssel sollen die Daten partitioniert und aufgeteilt werden?
⇨ Wie viele Shards sollen erstellt werden und wie sollen sie aufgebaut sein?
→ Entscheidung #1
⇨ Notion hat ein Datenmodell, das auf der Block-Ebene aufgebaut ist
⇨ Alle Tabellen, die mit der block-Tabelle verknüpft sind, wurden für das Sharding ausgewählt (Space, Discussion, Comment usw.)
→ Entscheidung #2
⇨ block wird nach Workspace-ID partitioniert
⇨ Jeder Workspace erhält eine UUID, die dafür verwendet wird
→ Entscheidung #3
⇨ Aufbau aus 480 logischen Shards und 32 physischen Datenbanken
Der Grund für 480 statt 512 als Zweierpotenz war, dass sich diese Zahl flexibler aufteilen lässt
- Migration auf die Shards
→ 1. Gleichzeitiges Schreiben in alte und neue DB (zusammen mit Audit-Logs)
→ 2. Nach Start des Dual-Writes begann das Backfilling der Daten aus der alten DB in die neue DB
→ 3. Validierung der Daten in der neuen DB
→ 4. Umstellung auf die neue DB (inkrementell durchgeführt)
- Mühsam gelernte Lektionen
→ Fangt früher mit dem Sharding an: Man wartete, bis die Last auf der bestehenden DB groß wurde; dadurch belastete schon die Migration selbst das System und musste zwangsläufig langsam erfolgen
→ Zielt auf eine Migration ohne Downtime: Der Durchsatz des Dual-Writes war beim finalen Cutover der entscheidende Engpass.
→ Nutzt statt eines separaten Partitionsschlüssels lieber einen zusammengesetzten Primärschlüssel: Hätte man die bestehende PK id der alten DB mit dem Partitionsschlüssel space_id kombiniert, hätte man space_id nicht innerhalb der App überall weiterreichen müssen
1 Kommentare
Über die TXID von Postgres wird immer wieder gesprochen.
Fehler und Schwächen von PostgreSQL https://de.news.hada.io/topic?id=1829
Was man beim Skalieren von PostgreSQL über 5 Jahre gelernt hat https://de.news.hada.io/topic?id=4101