Équilibreur de charge par rapport au pool de connexions - y a-t-il une différence?

Je travaille sur un projet qui devrait servir des millions d'utilisateurs peu de temps après son lancement. La base de données est postgres, et pour l'instant je suppose qu'au moins deux serveurs seront nécessaires. Un administrateur système (qui connaît bien les systèmes évolutifs) a suggéré de mettre un équilibreur de charge entre les serveurs Web et les serveurs de base de données.

Ma question concerne la différence entre l'équilibrage de charge et le pool de connexions. Pour maintenir les performances, dois-je regarder l'un ou l'autre, ou les deux?

Avec PostgreSQL, vous avez deux zones différentes qui peuvent faire du regroupement, soit au niveau de la couche d'application (c'est-à-dire jdbc intégré au regroupement, etc.) ou dans une couche intermédiaire qui se situe entre l'application et les bases de données, comme pgbouncer ou pgpool.

Si vous effectuez un regroupement dans une couche intermédiaire, comme pgbouncer ou pgpool, cette couche peut également effectuer un équilibrage de charge de certaines requêtes. De plus, lors de l'équilibrage de charge, vous pouvez effectuer des écritures de deux manières: vous pouvez soit avoir un seul maître d'écriture qui se réplique par d'autres moyens sur vos esclaves de lecture, en utilisant un outil comme slony ou la réplication de streaming intégrée qui est apparue à la pg 9.0 et au-dessus, ou vous pouvez demander à l'équilibreur de charge d'effectuer toutes les écritures, de sorte que les lectures entrantes atteignent une seule base de données, mais les écritures atteignent chaque base de données pour les garder toutes à jour.

Ou si vous êtes aventureux, vous pouvez déplacer la couche d'équilibrage de charge vers le bas d'une autre couche dans postgresql lui-même à l'aide de plproxy. Il s'agit d'un langage pl pour pgsql conçu pour vous permettre de mettre une base de données pg sur le front-end qui ne contient pas de données réelles, et cette base de données peut ensuite s'exécuter sur plusieurs dbs éventuellement redondants pour un débit incroyable. plpoxy est assez complexe à configurer et à utiliser, mais il est également assez évolutif. Notez que votre application doit être réécrite pour la prendre en charge afin qu'elle ne puisse pas être lancée sous une ancienne application et fonctionner.

http://slony.info/ http://wiki.postgresql.org/wiki/PL/Proxy http://pgpool.projects.postgresql.org/

L'équilibrage de charge et le pool de connexions sont deux choses très différentes.

Le regroupement de connexions (je viens d'un côté Microsoft du monde, mais les choses sont similaires je suppose) permet à l'application de garder la connexion à la base de données ouverte afin de pouvoir la réutiliser pour la prochaine requête au lieu d'avoir à se déconnecter et se reconnecter pour chaque requête qui doit être exécutée.

L'équilibrage de charge vous permet d'avoir plusieurs serveurs de base de données derrière l'équilibreur de charge afin que vous puissiez répartir la charge sur plusieurs serveurs au lieu d'avoir un seul serveur gérant tout le travail.

Vous pouvez utiliser le pool de connexions avec l'équilibrage de charge, mais n'oubliez pas que, comme les connexions ne seront jamais abandonnées, vous risquez de vous retrouver avec une charge non équilibrée entre les deux serveurs de base de données.

Si un seul serveur de base de données ne peut pas gérer la charge de l'application, récupérez 3 serveurs là-bas. De cette façon, vous pouvez en redémarrer un au besoin sans que l'application ne plante.