Was wir in 5 Jahren beim Skalieren von PostgreSQL gelernt haben

 (onesignal.com)
18 Punkte von xguru 2021-04-20 | 1 Kommentare | Auf WhatsApp teilen

Was der Push-Benachrichtigungsdienst OneSignal beim Betrieb von 75 TB Daten auf 40 DB-Servern gelernt hat

  • Datenüberblick: Die Tabellen subscribers und notifications sind am größten

  • Bloat: Ein Zustand, der mehr Speicherplatz belegt, langsamer wird und mehr Rechenleistung benötigt

→ Table bloat: VACUUM

→ Index bloat: Heap Only Tuple(HOT)-Optimierung

→ autovacuum aktivieren

→ Tabellenpartitionierung mit der Erweiterung pg_partman automatisieren

→ pg_repack und pgcompacttable

  • Datenbank-Upgrades

→ pg_upgrdae erfordert eine Offline-Zeit der Datenbank und kommt daher nicht infrage

→ Einen PostgreSQL-Server mit der neuen Version separat aufsetzen und mit der Erweiterung pglogical logical replication verwenden

  • XID-Wraparound

→ Die MVCC-Funktion (Multi Version Concurrency Control) von PostgreSQL verwendet 32-Bit-Transaktions-IDs, daher kann der Bereich bei vielen Transaktionen schnell erschöpft sein

→ Die Überwachung der verbleibenden XIDs ist wichtig

→ autovacuum_freeze_max_age

  • Replica Promotion

→ Für eine schnelle Promotion von Replikas werden diese hinter haproxy platziert

  • Partitionierung

→ Neuere PostgreSQL-Versionen haben Tabellenpartitionierung integriert

→ Wenn Partitionierung nötig ist, wird empfohlen, wenn möglich in viele Partitionen aufzuteilen

→ OneSignal plant, von 16 auf 256 und dann auf 4096 Partitionen zu gehen

  • Sharding

→ Keine integrierte Unterstützung

→ Ursprünglich wurde per Tenant-ID geshardet, die anhand von Bereichen einer v4-UUID getrennt wurde

→ Derzeit wird ein Daten-Proxy entwickelt, der Partitionen und Shards erkennt

Verwandte Beiträge

1 Kommentare

 
xguru 2021-04-20