Re: Numero de archivos en Schemas vs Bases

Muchas gracias por tu respuesta y tiempo Álvaro.

Si fue una decisión que pensamos mucho en su momento, inicialmente optamos
por un modelo de una tabla. Sin embargo uno de los requerimientos iniciales
fue que el sistema debería poder crear backups solo de un solo cliente, por
que ese cliente se debe poder cargar en otra instalación del mismo
software, incluso el software debe permitir cargar el mismo cliente varias
veces (de respaldos de diferentes épocas) para poder hacer comparativos.
Encontramos muy complicado mantener este modelo ya que el mismo software
sufre actualizaciones constantemente, y había errores en los scripts (por
que no se puede usar pg_dump). Si separamos físicamente la información
simplemente nos olvidamos de mantener scripts. Inicialmente nos fuimos con
bases de datos, pero en algunas ocasiones el SO necesitaba ser formateado,
por lo que hacer un backup en un equipo casero de por ejemplo 100 bases de
datos tardaba mas de una hora y hacer el restore tardaba el doble, sin
mencionar que teniamos que ajustar algunos parámetros en postgres para que
agüantara la memoria y una vez finalizado regresarlos, cuando la idea es
que este proceso lo hiciera un usuario sin conocimientos técnicos, lo cual
no era posible por lo que teniamos que atenderlo. Decidimos migrar a
schemas y usar pg_dump y pg_restore, pero también era un poco tardado y
afortunadamente encontramos una herramienta opensource para hacer dumps de
schemas (embebible en la aplicación) y la adaptamos a nuestras necesidades,
esto, incluso en un equipo casero, mejoro el tiempo en mas de 1000%,
estamos hablando que si antes se tardaba casi dos horas en 100 bases de
datos, ahora se tarda 10 minutos. Esta situación es rara pero se da, lo que
es mas común son dumps de un solo cliente y llevarse a otra instalación, lo
cual lleva segundos.

Sin embargo teníamos contemplados que como máximo habría 150 clientes en
una instalación del software y la semana pasada vimos que uno tenia 305, lo
cual me puso a pensar sobre el rendimiento por los archivos, hasta ahorita
ningún cliente ha tenido problemas de performance y este en cliente en
particular tampoco, pero bueno me entró la espinita y quize salir de dudas.

Nuevamente, muchas gracias por tu tiempo.

On Fri, Dec 20, 2019 at 1:39 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> Ivan Perales M. escribió:
>
> > Tengo entendido que postgresql crea una carpeta por cada base de datos y
> > luego un archivo por cada tabla. Si yo tengo por ejemplo 100 tablas por
> > schema y son 500 schemas habria al menos 50 mil archivos. Si utilizo
> bases
> > de datos, tendria al menos 100 archivos en cada una de las 500 carpetas.
> > Técnicamente el sistema de archivos del SO tendria que buscar entre la
> > misma cantidad de archivos físicos en el DD y no veo donde pudiera estar
> la
> > diferencia. En su experiencia, hay algun perfomance real entre ambas
> > modalidades? esta postgres limitado al número de archivos que puede
> > contener una carpeta segun el file system del SO?
>
> Ojo que cada tabla va a necesitar un FSM, un VM, algunos índices, así
> que piensa en 200000 archivos mínimo. Dicho eso, los sistemas de
> archivos modernos no se complican por almacenar unos pocos cientos de
> miles de archivos.
>
> El modelo de 50000 tablas va a hacer que Postgres consuma más memoria
> (mucha más) y quizás podría darte algún dolor de cabeza en ciertos casos
> puntuales, pero la mayor parte de las cosas debería funcionar sin
> problemas.
>
> Yo no habría optado por el modelo de cientos de esquemas separados cada
> uno con cientos de tablas. Estoy seguro que te dará problemas. Yo ya
> intenté ese modelo hace años (hmm, 18 años) y me costó como un año
> arrepentirme y hacerlo de nuevo correctamente.
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

--
Lindolfo Iván Perales Mancinas
Solo existen 10 tipos de personas en el mundo, las que saben binario y las
que no.