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 <alvhe...@2ndquadrant.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.
