almessadi.
Retour à l'index

PgBouncer Protège Postgres Des Couches de Calcul Plus Éclatées_

Les plateformes serverless et auto-scalables peuvent créer plus de variations de connexion que PostgreSQL ne souhaite gérer directement, c'est pourquoi les couches de pooling deviennent importantes.

Publié12 novembre 2024
Temps de lecture5 min read

Les plateformes serverless sont très efficaces pour créer de la concurrence rapidement. PostgreSQL n'est pas conçu pour gérer des milliers de clients éphémères ouvrant des connexions directes en même temps. Ce décalage est l'un des modes de défaillance les plus courants dans les architectures d'application modernes : la couche applicative se scale, et la base de données passe son temps à gérer le changement de connexion.

C'est pourquoi PgBouncer est important.

Pourquoi PgBouncer Aide

PgBouncer se situe entre votre application et Postgres et réutilise un nombre réduit de véritables connexions à la base de données à travers un nombre plus important de clients applicatifs. En pratique, cela améliore généralement :

  • la stabilité des connexions sous afflux
  • la pression mémoire sur la base de données
  • la survie lors des déploiements et des pics de trafic

Une configuration courante ressemble à ceci :

[databases]
app = host=postgres.internal port=5432 dbname=appdb

[pgbouncer]
pool_mode = transaction
default_pool_size = 50
max_client_conn = 1000

L'idée n'est pas de laisser 1 000 requêtes ouvrir 1 000 véritables sessions Postgres. L'objectif est d'harmoniser la couche de calcul en quelque chose que la base de données peut tolérer.

Le Compromis Important

PgBouncer modifie la sémantique des connexions, surtout en mode pooling transaction. Les fonctionnalités qui supposent un état de session peuvent se briser ou se comporter différemment :

  • déclarations préparées au niveau de la session
  • tables temporaires entre transactions
  • état SET qui suppose une persistance des connexions

Cela signifie que vous devez choisir le mode de pooling de manière délibérée et vérifier les hypothèses de votre ORM ou de votre couche de requêtes.

Meilleure Règle Opérationnelle

Si la couche de calcul est éclatée, considérez la gestion des connexions comme une architecture, et non comme un détail d'optimisation de bas niveau. Serverless plus connexions directes à Postgres fonctionne souvent bien en développement et est douloureux en production. PgBouncer existe pour absorber ce décalage avant que la base de données ne devienne le goulot d'étranglement.

Lecture Complémentaire