Ce que nous avons appris après 5 ans à faire évoluer PostgreSQL

 (onesignal.com)
18 points par xguru 2021-04-20 | 1 commentaires | Partager sur WhatsApp

Ce que le service de notifications push OneSignal a appris en exploitant 75 To de données sur 40 serveurs de base de données

  • Vue d’ensemble des données : les tables subscribers et notifications sont les plus volumineuses

  • Bloat : phénomène qui prend plus d’espace, ralentit le système et nécessite davantage de puissance de calcul

→ Table bloat : VACUUM

→ Index bloat : optimisation Heap Only Tuple (HOT)

→ activer autovacuum

→ automatiser le partitionnement des tables avec l’extension pg_partman

→ pg_repack et pgcompacttable

  • Mises à niveau de la base de données

→ pg_upgrdae nécessite une mise hors ligne de la base, donc option écartée

→ mettre en place séparément un serveur PostgreSQL sur la nouvelle version et utiliser la réplication logique avec l’extension pglogical

  • XID Wraparound

→ la fonctionnalité MVCC (Multi Version Concurrency Control) de PostgreSQL utilise des ID de transaction sur 32 bits, donc avec beaucoup de transactions la limite peut être atteinte rapidement

→ il est important de surveiller les XID restants

→ autovacuum_freeze_max_age

  • Promotion de réplica

→ pour une promotion rapide du réplica, le placer derrière haproxy

  • Partitionnement

→ les versions récentes de PostgreSQL intègrent nativement le partitionnement de tables

→ quand le partitionnement est nécessaire, il est recommandé si possible de le découper en un grand nombre de partitions

→ OneSignal prévoit de passer d’un partitionnement de 16 à 256, puis à 4096

  • Sharding

→ aucun support intégré

→ à l’origine, le sharding était fait via un Tenant ID distingué par plages de UUID v4

→ ils développent actuellement un proxy de données capable de prendre en compte partitions et shards

À lire aussi

1 commentaires

 
xguru 2021-04-20