Número máximo de bases de datos para una sola instancia de PostgreSQL 9

9

Al desarrollar una aplicación multicliente, planeamos usar una base de datos diferente para cada cliente. Pero podría ser más de 1000 clientes (aplicaciones).

¿PostgreSQL lo manejará sin problemas?

¿Alguien ha intentado algo similar?

Nota: 35 tablas para cada una, con hasta 3000 registros como promedio, para cada base de datos.

postgresql postgresql-9.1 Juanin
fuente

Respuestas:

5

No lo he intentado yo mismo, pero hay otros que sí lo han hecho. Aquí puede ver que incluso 10,000 bases de datos se ejecutan sin problemas en una sola instancia. Incluso puede encontrar algunos aspectos prácticos en ServerFault también.

Dado que sus bases de datos son bastante pequeñas, no se encontrará con ningún tipo de limitación de número de archivo del sistema operativo host. El único problema que se me ocurre es que cuando se acceda a todas estas bases de datos simultáneamente, manejar todas esas conexiones será complicado.

Y, como última nota: eres bienvenido en este sitio. Esperamos que permanezca con nosotros por mucho tiempo.

dezso
fuente
Gracias por tus comentarios. Sí, las conexiones simultáneas podrían ser un dolor de cabeza, pero la otra opción es una tabla compartida para cada aplicación, increíblemente más compleja (necesita reprogramación para la aplicación).
Juanin
2

Suena desordenado desde el punto de vista de la administración. ¿Cómo planea hacer una copia de seguridad de tantas bases de datos? con un guión que recorre cada uno?

A menos que tenga una buena razón, ¿por qué no solo tener una base de datos donde la estructura está diseñada para que todos los datos se vinculen a un ID de cliente? Agregue índices / clave externa / claves primarias basadas en este campo que garantizará la integridad de los datos.

Entonces solo necesita tener una cláusula where en todas sus consultas para acceder a un solo ID de cliente. Esto será mucho más simple de mantener y es igual de fácil de desarrollar (porque en cualquier caso debe permitir la identificación del cliente)

adam f
fuente
1
Este es un punto muy bueno y válido. Quizás el OP debería pensar en usar esquemas, y solo tener unas pocas tablas en el esquema público, disponibles para UNIRSE con tablas en el esquema del cliente privado.
François Beausoleil
Gracias, pero esta opción fue descartada desde el principio. Este es un puerto de una aplicación ya desarrollada, y cambiar TODO el código no es tan trivial en esta etapa. Pero sí, la gestión diaria de más de 100 bases de datos será ... interesante ... ¿no?
Juanin
1
Pasar de bases de datos separadas a esquemas separados no debería implicar ningún cambio significativo en el código. En particular, no necesita prefijar los objetos con sus esquemas porque lo search_pathhace por usted.
Daniel Vérité
Archivar Wal para una copia de seguridad tendría sentido aquí.
Jharwood
0

Hay personas que hacen esto, particularmente para el alojamiento de servidores compartidos.

Pensando en los problemas aquí no hay almuerzo gratis. Probablemente podría hacerlo con esquemas en una aplicación transparente. Sin embargo, obtendrá miles de esquemas y decenas de miles de tablas, lo que planteará problemas adicionales.

Creo que, en general, el enfoque de db múltiple es más sensato dados sus comentarios.

La administración (como las copias de seguridad) será interesante. También creo que en algún momento las conexiones a la base de datos comenzarán a tomar más tiempo. Si está utilizando pg_hba.conf para restringir el acceso (que debería estar haciendo), eso también será un dolor de cabeza y probablemente querrá crear una solución para generar ese archivo para usted .....

Chris Travers
fuente
No puedo ver el problema con pg_hba.conf. Nuestra aplicación utiliza Ruby on Rails y cambia las conexiones para diferentes bases de datos, pero en el mismo cuadro de Linux todo el tiempo. ¿Estás hablando de problemas de concurrencia para acceder al archivo?
Juanin
1
No, solo si desea administrar a qué dbs se puede acceder mediante qué hosts, se convertirá en un archivo largo y la administración puede ser un poco molesta.
Chris Travers
0

Espero que este enlace sea mejor para leer: 10,000 bases de datos en un clúster PostgreSQL por Jon Jensen, 2008.

Un extracto:

La respuesta corta: Postgres 8.1 maneja 10,000 bases de datos muy bien. \l en psql genera una larga lista de bases de datos, por supuesto, pero regresa lo suficientemente rápido. La prueba de concurrencia ad-hoc estuvo bien. La ejecución de consultas, inserciones, etc. en un grupo seleccionado cuidadosamente de las diversas bases de datos de reproducción funcionó bien, incluso mientras se creaban nuevas bases de datos.

[...]

El límite real en esta plataforma [ Linux ext3 ] es probablemente 31995 bases de datos, porque cada base de datos ocupa un subdirectorio en data / base / y el sistema de archivos ext3 tiene un límite de 31998 subdirectorios por un directorio, derivado de su límite de 32000 enlaces por inodo

usuario117336
fuente
1
Las respuestas que solo contienen enlaces no son muy útiles, porque los enlaces tienden a quedarse obsoletos con el tiempo. Considere agregar el resumen de lo que sea que esté vinculando en su respuesta.
mustaccio