He estado leyendo este question, pero no me sirve. Teniendo en cuenta la administración de db, creo que un db con esquemas múltiples es más fácil de mantener que la otra opción, pero en términos de rendimiento, ¿cuál es mejor ?, ¿hay alguna ventaja de uno sobre el otro?Postgresql un db con múltiples esquemas vs múltiples db con un esquema
TIA.
Si el rendimiento es importante, no hay sustituto para la evaluación comparativa de su caso de uso específico. Si no es tan importante, ¡entonces es más fácil de administrar! El hardware es barato en comparación con el tiempo del programador/DBA, y se compara con la tasa de accidentes más alta esperada en una configuración más compleja. Sin mencionar que las computadoras siguen la ley de Moore, pero el día obstinadamente se niega a ser más largo.
Si tuviera que adivinar , no haber sido la referencia a su caso de uso específico (ya que no puedo), supongo que una base de datos con múltiples esquemas estarán mejor rendimiento debido a que:
Cada la conexión es a una base de datos, AFAIK. La configuración/desmontaje de la conexión es costosa en PostgreSQL.
Muchos esquemas están más cerca de muchas tablas que muchas bases de datos, y espero que muchas tablas se optimicen por más de lo que espero que sean muchas bases de datos.
Sin embargo, puedo ver un contraejemplo que puede aplicarse. Cada base de datos se almacena en un solo directorio. Esto hace que separar las bases de datos en los sistemas de archivos, y por lo tanto las matrices de discos, sea realmente fácil usando las herramientas normales del sistema de archivos (por ejemplo, puntos de montaje y/o enlaces simbólicos). Es muy poco probable que dividir bases de datos en múltiples matrices supere una matriz RAID10 más grande con el mismo número de discos, pero proporcionará un mejor aislamiento (la base de datos A haciendo una consulta enorme no afectará tanto a la base de datos B). Sin embargo, consulte la documentación del programador IO de su SO; recuerde que cada conexión PostgreSQL obtiene su propio proceso de back-end, por lo que la puesta en cola de la equidad por proceso puede lograr esto mejor.
Tenga en cuenta que también puede segmentar los datos entre sistemas de archivos utilizando CREATE TABLESPACE y amigos de PostgreSQL, por lo que lo anterior también se puede hacer con esquemas.
No creo que importe de ninguna manera. Cada tabla se almacenará en un archivo separado, la única pregunta es en qué directorio se encuentra el archivo. Dado que el rendimiento se ve afectado principalmente por las operaciones de lectura y escritura en archivos individuales, la organización de los archivos en los directorios debería tener poco efecto.
En cuanto al rendimiento, dependerá completamente de su aplicación.
Por ejemplo, varias bases de datos requieren la agrupación de conexiones por base de datos. Si tiene cientos o miles de bases de datos, eso significa que no puede hacer la agrupación de conexiones. Eso le costará rendimiento para cualquier cosa, excepto una aplicación cliente con una única conexión persistente a la base de datos. Sin embargo, si solo accede a "una base de datos a la vez" (y no a segundos), solo tendrá que cargar la memoria caché de la tabla del sistema para las bases de datos que están siendo utilizadas activamente. , dejando más memoria en las tablas de usuario de la memoria caché (dado que las tablas del sistema en cada base de datos serán significativamente más pequeñas).
En la mayoría de los casos, los esquemas en una base de datos saldrán ganando. Una solución bastante común es un híbrido, de bases de datos X y esquemas Y.
Varias bases de datos no tienen ninguna ventaja de rendimiento en múltiples esquemas (espacios de nombres) que puedo ver (excepto quizás si tiene una cantidad increíblemente grande de tablas). CREATE TABLESPACE le permite colocar lo que desee donde desee en el sistema de archivos, por lo que el almacenamiento físico puede ser controlado por usted en cualquier caso.
La principal diferencia será cuando consulte múltiples esquemas, es mucho mejor que consultar en múltiples bases de datos. Además, es posible que pueda compartir más conexiones a través de un grupo de conexión si todo está en la misma base de datos.
"CREATE TABLESPACE y sus amigos, por lo que lo anterior también se puede hacer con esquemas". Sí, no veo ninguna ventaja en el rendimiento al usar muchas bases de datos. Por cierto, no entiendo cómo RAID tiene algo que ver con esta pregunta. Puedes poner lo que quieras donde quieras con tablespaces, independientemente de la pregunta de DB vs. esquema. –
@Jeff Davis: Sí, puede, es un poco más fácil de hacer con las herramientas estándar de Unix, no con los comandos SQL, con múltiples bases de datos. El punto acerca de RAID es que a menudo obtienes un mejor rendimiento que dividiéndote cuidadosamente entre discos simplemente agregando todos esos discos a un RAID10. – derobert