Agrupación de conexiones de PostgreSQL:Parte 1 – Pros y contras

Hace mucho tiempo, en una galaxia muy, muy lejana, los 'hilos' eran una novedad de programación que rara vez se usaba y en la que rara vez se confiaba. En ese entorno, los primeros desarrolladores de PostgreSQL decidieron bifurcar un proceso para cada conexión a la base de datos como la opción más segura. Después de todo, sería una lástima que su base de datos fallara.

Desde entonces, mucha agua ha corrido bajo ese puente, pero la comunidad de PostgreSQL se ha apegado a su decisión original. Es difícil criticar su argumento, ya que es absolutamente cierto que:

• Que cada cliente tenga su propio proceso evita que un cliente que se comporte mal bloquee toda la base de datos.
• En los sistemas Linux modernos, la diferencia de sobrecarga entre bifurcar un proceso y crear un subproceso es mucho menor de lo que solía ser.
• Pasar a una arquitectura de subprocesos múltiples requerirá reescrituras extensas.

Sin embargo, en las aplicaciones web modernas, los clientes tienden a abrir muchas conexiones. A menudo se desaconseja encarecidamente a los desarrolladores que mantengan una conexión a la base de datos mientras se realizan otras operaciones. “Abra una conexión lo más tarde posible, cierre una conexión lo antes posible”. Pero eso causa un problema con la arquitectura de PostgreSQL:bifurcar un proceso se vuelve costoso cuando las transacciones son muy cortas, como dicta la sabiduría común.

La arquitectura del grupo de conexiones

El uso de una biblioteca de idiomas moderna reduce un poco el problema:la agrupación de conexiones es una característica esencial de las bibliotecas de acceso a bases de datos más populares. Garantiza que las conexiones "cerradas" no se cierran realmente, sino que se devuelven a un grupo, y "abrir" una nueva conexión devuelve la misma "conexión física", lo que reduce la bifurcación real en el lado de PostgreSQL.

Sin embargo, las aplicaciones web modernas rara vez son monolíticos y, a menudo, utilizan varios idiomas y tecnologías. El uso de un grupo de conexiones en cada módulo es poco eficiente:

• Incluso con una cantidad relativamente pequeña de módulos y un tamaño de grupo pequeño en cada uno, termina con muchos procesos de servidor. El cambio de contexto entre ellos es costoso.
• El soporte de agrupación varía ampliamente entre bibliotecas e idiomas:una agrupación que se comporta mal puede consumir todos los recursos y dejar la base de datos inaccesible para otros módulos.
• No hay un control centralizado:no puede usar medidas como límites de acceso específicos del cliente.

Como resultado, se han desarrollado middleware populares para PostgreSQL. Estos se ubican entre la base de datos y los clientes, a veces en un servidor separado (físico o virtual) ya veces en la misma caja, y crean un grupo al que los clientes pueden conectarse. Estos programas intermedios son:

• Optimizado para PostgreSQL y su arquitectura única entre los DBMS modernos.
• Proporcione control de acceso centralizado para diversos clientes.
• ¡Le permite obtener las mismas recompensas que los grupos del lado del cliente, y luego algunas más (hablaremos de esto con más detalle en nuestras próximas publicaciones)!

Desventajas del agrupador de conexiones de PostgreSQL

Un agrupador de conexiones es una parte casi indispensable de una configuración de PostgreSQL lista para producción. Si bien hay muchos beneficios bien documentados al usar un agrupador de conexiones, hay hay algunos argumentos en contra de usar uno:

• La introducción de un middleware en la comunicación inevitablemente genera cierta latencia. Sin embargo, cuando se encuentra en el mismo host, y teniendo en cuenta la sobrecarga de bifurcar una conexión, esto es insignificante en la práctica, como veremos en la siguiente sección.
• Un middleware se convierte en un único punto de falla. El uso de un clúster en este nivel puede resolver este problema, pero eso agrega complejidad a la arquitectura.

  

• Un middleware implica costos adicionales. Necesita un servidor adicional (o 3) o su(s) servidor(es) de base de datos debe(n) tener suficientes recursos para admitir un agrupador de conexiones, además de PostgreSQL.
• Compartir conexiones entre diferentes módulos puede convertirse en una vulnerabilidad de seguridad. Es muy importante que configuremos pgPool o PgBouncer para limpiar las conexiones antes de que se devuelvan al grupo.
• La autenticación cambia del DBMS al agrupador de conexiones. Esto puede no ser siempre aceptable.

  

• Aumenta el área de superficie para el ataque, a menos que el acceso a la base de datos subyacente esté bloqueado para permitir el acceso solo a través del agrupador de conexiones.
• Crea otro componente más que se debe mantener, ajustar para su carga de trabajo, aplicar parches de seguridad con frecuencia y actualizar según sea necesario.

¿Debe utilizar un agrupador de conexiones de PostgreSQL?

Sin embargo, todos estos problemas están bien discutidos en la comunidad de PostgreSQL, y las estrategias de mitigación aseguran que las ventajas de un agrupador de conexiones superan con creces sus desventajas. Nuestras pruebas muestran que incluso un pequeño número de clientes puede beneficiarse significativamente del uso de un agrupador de conexiones. Vale la pena el esfuerzo adicional de configuración y mantenimiento.

En la siguiente publicación, analizaremos uno de los agrupadores de conexiones más populares en el mundo de PostgreSQL:PgBouncer, seguido de Pgpool-II y, por último, una comparación de prueba de rendimiento de estos dos Agrupadores de conexiones de PostgreSQL en nuestra publicación final de la serie.