El rendimiento no es peor, necesariamente. Como explica el artículo, existen condiciones específicas que hacen que el enfoque del esquema sea mejor o peor según el diseño de la aplicación y la carga de trabajo. Permítanme explicar las ventajas y desventajas de los enfoques de "esquema de arrendatario" frente a "tabla compartida":
esquema de arrendatario es mejor cuando tiene un número relativamente pequeño de inquilinos bastante grandes. Un ejemplo de esto sería una aplicación de contabilidad, con solo usuarios de suscripción paga. Las cosas que hacen que sea la opción de mejor rendimiento para usted incluyen:
- una pequeña cantidad de inquilinos con una gran cantidad de datos cada uno
- un esquema relativamente simple sin muchas tablas por inquilino
- necesidad de personalizar los esquemas de algunos inquilinos
- capacidad de hacer uso de roles de base de datos por arrendatario
- requisito para migrar los datos de un inquilino de un servidor a otro
- capacidad de activar un servidor de aplicaciones dedicado en su nube para cada inquilino
Las cosas que hacen que sea una opción de bajo rendimiento incluyen:
- muchos inquilinos con muy pocos datos cada uno
- enfoque sin estado de las conexiones donde cada solicitud podría ser cualquier inquilino
- biblioteca cliente u orm que almacena metadatos para todas las tablas (como ActiveRecord)
- un requisito para la agrupación y/o el almacenamiento en caché de conexiones eficientes y de alto rendimiento
- problemas con VACUUM y otras operaciones administrativas de PostgreSQL que escalan mal en miles de tablas.
Si el esquema de inquilino es malo para las migraciones/cambios de esquema realmente depende de cómo los esté haciendo. No es bueno para implementar un cambio de esquema universal rápidamente, pero es bueno para implementar cambios de esquema como una implementación gradual entre inquilinos.
mesa compartida funciona mejor para situaciones en las que tiene muchos inquilinos y muchos de sus inquilinos tienen muy pocos datos. Un ejemplo de esto sería una aplicación móvil de redes sociales que permite cuentas gratuitas y, por lo tanto, tiene miles de cuentas abandonadas. Otras cosas que hacen que el modelo de mesa compartida sea beneficioso son:
- mejor para la agrupación de conexiones, ya que todas las conexiones pueden usar el mismo grupo
- mejor para la administración de PostgreSQL, debido a menos tablas en total
- mejor para migraciones y cambios de esquema, ya que solo hay un "conjunto" de tablas
El principal inconveniente de la tabla compartida es la necesidad de agregar la condición de filtro de inquilinos a cada consulta en la capa de la aplicación. También es problemático porque:
- las consultas que se unen a muchas tablas pueden tener un rendimiento deficiente porque el filtro de arrendatarios desbarata la planificación de consultas
- las tablas que crecen hasta 100 millones de filas pueden causar problemas específicos de rendimiento y mantenimiento
- no hay forma de hacer cambios en la aplicación específicos del inquilino o actualizaciones de esquema
- más costoso migrar inquilinos entre servidores
Entonces, qué modelo "funciona mejor" realmente depende de qué compensaciones te perjudican más.
También hay un modelo híbrido, "vista de arrendatario", donde los datos reales se almacenan en tablas compartidas, pero cada conexión de aplicación usa vistas de barrera de seguridad para ver los datos. Esto tiene algunas de las ventajas y desventajas de cada modelo. Principalmente, tiene los beneficios de seguridad del modelo de esquema de arrendatario con algunos de los inconvenientes de rendimiento de ambos modelos.
