Pool de connexions de bases de données avec PgBouncer – Meilleure programmation
Maintenant que nous comprenons ce qu’est un pool de connexions, examinons l’une des premières décisions auxquelles vous serez confronté lorsque vous implémenterez un pool de connexions: où le placer sur votre pile. Vous avez plusieurs options. Vous pouvez créer votre pool au niveau de la langue, sur votre client, en tant que middleware ou en tant qu’hybride de ces choix. Comme pour de nombreuses décisions techniques, le bon choix dépend souvent de votre situation.
Voici quelques avantages et inconvénients pour vous aider à décider.
Niveau de langue
Votre pool s’exécute localement partout où votre code en a besoin, à l’aide de bibliothèques créées spécifiquement pour votre langue. La plupart des langues incluent des bibliothèques natives ou complémentaires de regroupement de connexions (par exemple, JDBC avec Java ou Psycopg pour Python).
Avantages:
- Faible latence car le pool est sur la même case que le demandeur.
- Meilleure sécurité, car les connexions sont limitées à un seul client.
- Pas besoin d’apprendre un nouvel outil.
Les inconvénients:
- Difficile de surveiller et de contrôler les connexions à la base de données, car vous pouvez vous retrouver avec plusieurs pools de plusieurs clients.
- Optimisé pour votre langue, pas nécessairement pour Postgres.
Niveau client
Votre pool est distinct de votre code, mais s’exécute sur la même machine que votre application client.
Avantages:
- Faible latence et meilleure sécurité, similaire au niveau de langue.
- Optimisé pour Postgres, pas pour votre langue.
Les inconvénients:
- Encore une fois, comme pour le niveau de langue, il peut être difficile de surveiller et de contrôler les connexions.
Middleware
Votre pool s’exécute entre le client et la base de données, soit sur un serveur autonome, soit sur la même machine que votre base de données.
Avantages:
- Flexible – la base de données peut être remplacée.
- Optimisé pour Postgres, pas pour votre langue.
- Contrôle centralisé des connexions, ce qui facilite la surveillance et le contrôle des connexions.
Les inconvénients:
- Vous avez introduit une nouvelle couche, ainsi qu’une nouvelle latence.
- Point de défaillance unique pour les appels de base de données sur tous les clients.
- Problèmes de sécurité potentiels car vous partagez des connexions entre les couches.
- Encore une autre couche à maintenir.
L’emplacement idéal de votre piscine dépendra de votre situation unique, de vos besoins techniques et de vos forces personnelles. Cependant, dans la plupart des cas, le middleware est probablement votre meilleur choix. Pour une application moderne avec de nombreux services, le middleware vous donne plus de contrôle et de visibilité sur vos connexions.
Plongeons-nous ensuite dans ce cas d’utilisation le plus courant: les pools de connexions de middleware sur Postgres.
