Cómo agrupar conexiones
Cada plataforma tiene una interfaz de agrupación de conexiones diferente. Deberá leer la documentación de la plataforma específica que utiliza (Ruby+Rails o lo que sea) o utilizar una capa intermedia de agrupación genérica como PgBouncer.
Las respuestas relacionadas con una herramienta (por ejemplo, PHP con Zend Framework) no tendrán nada que ver con las respuestas relacionadas con otra herramienta (como Ruby on Rails). Incluso si elige algo como PgBouncer, todavía hay detalles relacionados con cómo la plataforma maneja la duración de las transacciones, el modo de agrupación para elegir según las necesidades de la aplicación, etc.
Por lo tanto, primero debe determinar qué está usando y qué debe hacer con él. Entonces estudie cómo configurar su agrupación de conexiones. (Con muchas herramientas es simplemente automático).
Si sigues atascado después de leer la documentación de la plataforma que elijas , solicite una nueva detallada y específica pregunta etiquetada apropiadamente para la plataforma.
Grupo y middleware
No haga que su aplicación se conecte directamente a PostgreSQL. Especialmente si es a través de Internet de clientes aleatorios.
Use un servidor web cerca del servidor PostgreSQL y haga que acepte solicitudes de servicios web para intermediar el acceso a la base de datos a través de una API web bien definida con transacciones cortas que están destinadas a solicitar en la mayor medida posible.
Esto no es solo un caso de sabiduría recibida:hay buenas razones para hacerlo y serios problemas con la ejecución de PostgreSQL desde dispositivos aleatorios a través de Internet.
Aplicación de Android hablando directamente con Pg
Los problemas para hablar con Pg directamente a través de Internet desde muchos clientes incluyen:
-
Cada backend de PostgreSQL tiene un costo, esté inactivo o no. PgBouncer en el modo de agrupación de transacciones ayuda con esto hasta cierto punto.
-
Las conexiones se pierden aleatoriamente cuando trabajas a través de Internet. Caídas de WiFi, cambios de dirección IP en servicios IP dinámicos, servicios móviles que se desvanecen o alcanzan su capacidad máxima o simplemente se tambalean junto con una gran pérdida de paquetes allí. Esto lo deja con muchas conexiones de PostgreSQL en estados indeterminados, probablemente con transacciones abiertas, lo que le brinda
<IDLE> in transactiony la necesidad de permitir muchas más conexiones de las que realmente funcionan. -
Es transaccional:si algo no termina, puede cancelar la transacción y saber que no tendrá ningún efecto.
Ventajas de tener una capa intermedia
Un servidor que responda a las solicitudes de servicios web HTTP de su aplicación en dispositivos Android para actuar como intermediario para el acceso a la base de datos puede ser una gran ventaja.
-
Puede definir una API versionada, de modo que cuando introduzca nuevas funciones o necesite cambiar la API, no tendrá que interrumpir a los clientes antiguos. Esto es posible con Pg utilizando procedimientos almacenados o muchas vistas, pero puede volverse torpe.
-
Usted controla estrictamente el alcance del acceso a la base de datos y la duración de las transacciones.
-
Puede definir una API idempotente, donde ejecutar la misma solicitud varias veces solo tiene un efecto. (Recomiendo encarecidamente hacer esto debido al siguiente punto).
-
Todo es apátrida y puede tener tiempos de espera cortos. Si algo no funciona, simplemente vuelve a intentarlo.
-
Cada conexión de la base de datos se realiza a través de un grupo, por lo que no tiene sesiones inactivas. Cada back-end de la base de datos está trabajando duro para obtener el máximo rendimiento.
-
Puede poner en cola el trabajo en lugar de intentar hacer toneladas al mismo tiempo y destrozar el servidor. (También puede hacer esto con PgBouncer en el modo de agrupación de transacciones).
... y vuelve a editar para cambiar el significado de la pregunta:
Rendimiento
Su rendimiento "También" es realmente una pregunta totalmente diferente (y preferiblemente debería publicarse como tal). La versión muy corta:totalmente imposible de predecir sin mucha más información sobre la carga de trabajo, como la cantidad de solicitudes de base de datos por solicitud de aplicación del cliente, tipo de datos, tipo de consultas, tamaño de los datos, frecuencia de las consultas, practicidad del almacenamiento en caché, .. .... sin fin. Cualquiera que pretenda responder definitivamente a esa pregunta es el primer verdadero psíquico de la historia o está completamente lleno de ella.
Debe averiguar aproximadamente cuál será el tamaño de sus datos, los patrones de consulta, etc. Calcule cuánto puede permitirse almacenar en caché en un caché de capa intermedia como redis/memcached, qué tan obsoleto puede dejar que se vuelva, qué nivel de invalidación de caché necesita. Determine si su conjunto de datos "caliente" (al que accede mucho) cabe en la RAM o no. Determine si los índices de las tablas consultadas con frecuencia caben en la RAM o no. Calcule cuál es su balance aproximado de lectura/escritura y cuánto es probable que sus escrituras sean de solo inserción (agregar) o OLTP más regulares (insertar/actualizar/eliminar). Manipule un conjunto de datos y algunas cargas de trabajo del cliente. Entonces puede comenzar a responder esa pregunta, tal vez. Para hacerlo bien, también debe simular clientes estancados/desaparecidos, etc.
Vea por qué no es solo un "¿También?".
