Regroupement de connexions PostgreSQL :Partie 1 – Avantages et inconvénients

Il y a longtemps, dans une galaxie très lointaine, les "threads" étaient une nouveauté de programmation rarement utilisée et peu fiable. Dans cet environnement, les premiers développeurs PostgreSQL ont décidé que créer un processus pour chaque connexion à la base de données était le choix le plus sûr. Ce serait dommage que votre base de données tombe en panne, après tout.

Depuis lors, beaucoup d'eau a coulé sous ce pont, mais la communauté PostgreSQL est restée fidèle à sa décision initiale. Il est difficile de critiquer leur argument - car il est absolument vrai que :

• Chaque client ayant son propre processus empêche un client qui se comporte mal de planter toute la base de données.
• Sur les systèmes Linux modernes, la différence de temps système entre la création d'un processus et la création d'un thread est bien moindre qu'auparavant.
• Passer à une architecture multithread nécessitera d'importantes réécritures.

Cependant, dans les applications Web modernes, les clients ont tendance à ouvrir de nombreuses connexions. Les développeurs sont souvent fortement déconseillés de maintenir une connexion à la base de données pendant que d'autres opérations ont lieu. "Ouvrir une connexion le plus tard possible, fermer une connexion le plus tôt possible". Mais cela pose un problème avec l'architecture de PostgreSQL ; créer un processus devient coûteux lorsque les transactions sont très courtes, comme le veut la sagesse commune.

L'architecture du pool de connexions

L'utilisation d'une bibliothèque de langage moderne réduit quelque peu le problème ; la mise en commun des connexions est une fonctionnalité essentielle des bibliothèques d'accès aux bases de données les plus populaires. Cela garantit que les connexions "fermées" ne sont pas vraiment fermées, mais renvoyées dans un pool, et que "l'ouverture" d'une nouvelle connexion renvoie la même "connexion physique", réduisant ainsi le forking réel du côté PostgreSQL.

Cependant, les applications Web modernes sont rarement monolithiques et utilisent souvent plusieurs langages et technologies. Utiliser un pool de connexion dans chaque module n'est guère efficace :

• Même avec un nombre relativement faible de modules et une petite taille de pool dans chacun, vous vous retrouvez avec beaucoup de processus serveur. Le changement de contexte entre eux est coûteux.
• La prise en charge de la mise en commun varie considérablement entre les bibliothèques et les langages :un pool qui se comporte mal peut consommer toutes les ressources et rendre la base de données inaccessible par d'autres modules.
• Il n'y a pas de contrôle centralisé :vous ne pouvez pas utiliser de mesures telles que les limites d'accès spécifiques au client.

En conséquence, des middlewares populaires ont été développés pour PostgreSQL. Ceux-ci se situent entre la base de données et les clients, parfois sur un serveur séparé (physique ou virtuel) et parfois sur le même boîtier, et créent un pool auquel les clients peuvent se connecter. Ces intergiciels sont :

• Optimisé pour PostgreSQL et son architecture plutôt unique parmi les SGBD modernes.
• Fournir un contrôle d'accès centralisé pour divers clients.
• Vous permet de récolter les mêmes récompenses que les pools côté client, et même plus (nous en discuterons plus en détail dans nos prochains articles) !

Inconvénients du pooleur de connexions PostgreSQL

Un pool de connexions est un élément presque indispensable d'une configuration PostgreSQL prête pour la production. Bien qu'il existe de nombreux avantages bien documentés à utiliser un pooler de connexions, il existe quelques arguments à opposer à son utilisation :

• L'introduction d'un middleware dans la communication introduit inévitablement une certaine latence. Cependant, lorsqu'ils sont situés sur le même hôte, et en tenant compte de la surcharge liée à la création d'une connexion, cela est négligeable dans la pratique, comme nous le verrons dans la section suivante.
• Un middleware devient un point de défaillance unique. L'utilisation d'un cluster à ce niveau peut résoudre ce problème, mais cela introduit une complexité supplémentaire dans l'architecture.

  

• Un middleware implique des surcoûts. Soit vous avez besoin d'un serveur supplémentaire (ou 3), soit votre ou vos serveurs de base de données doivent disposer de suffisamment de ressources pour prendre en charge un pool de connexions, en plus de PostgreSQL.
• Le partage de connexions entre différents modules peut devenir une faille de sécurité. Il est très important que nous configurions pgPool ou PgBouncer pour nettoyer les connexions avant qu'elles ne soient renvoyées dans le pool.
• L'authentification passe du SGBD au pooleur de connexions. Cela n'est peut-être pas toujours acceptable.

  

• Cela augmente la surface d'attaque, à moins que l'accès à la base de données sous-jacente ne soit verrouillé pour autoriser l'accès uniquement via le pool de connexion.
• Il crée encore un autre composant qui doit être maintenu, adapté à votre charge de travail, corrigé souvent en matière de sécurité et mis à niveau si nécessaire.

Devez-vous utiliser un pooleur de connexions PostgreSQL ?

Cependant, tous ces problèmes sont bien discutés dans la communauté PostgreSQL, et les stratégies d'atténuation garantissent que les avantages d'un pooler de connexions dépassent de loin leurs inconvénients. Nos tests montrent que même un petit nombre de clients peut bénéficier de manière significative de l'utilisation d'un pooler de connexions. Ils valent bien l'effort supplémentaire de configuration et de maintenance.

Dans le prochain article, nous discuterons de l'un des pooleurs de connexions les plus populaires dans le monde PostgreSQL :PgBouncer, suivi de Pgpool-II, et enfin d'une comparaison des tests de performances de ces deux Pooleurs de connexions PostgreSQL dans notre dernier article de la série.