performance - Esquemas de PostgreSQL para aplicaciones multi-tenant
database-design schema (1)
Estoy aprendiendo sobre multi-tenant aplicaciones multi-tenant y cómo se pueden usar los esquemas de PostgreSQL para esto.
Investigando el tema, terminé encontrando un artículo en el que el autor describe una mala experiencia al usar los esquemas de PostgreSQL en aplicaciones de múltiples inquilinos. Los principales problemas serían tener un mal rendimiento para las migraciones y un alto uso de los recursos de la base de datos.
Parece que tener un solo esquema (compartir las tablas entre los inquilinos) llevaría a un mejor rendimiento que tener un esquema separado para cada inquilino. Pero me parece extraño. Pensaría lo contrario, ya que los índices en tablas más pequeñas tienden a ser más claros que los índices en tablas más grandes.
¿Por qué el rendimiento sería peor al tener datos separados en muchas tablas pequeñas (en esquemas múltiples), en lugar de tener datos separados en unas pocas tablas grandes (en un solo esquema)?
El rendimiento no es peor, necesariamente. Como lo explica el artículo, hay 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":
el esquema de arrendatario es mejor cuando tiene un número relativamente pequeño de arrendatarios bastante grandes. Un ejemplo de esto sería una aplicación de contabilidad, con solo usuarios de suscripción pagados. Las cosas que lo convierten en la mejor opción para usted incluyen:
- un pequeño número de inquilinos con una gran cantidad de datos cada
- Un esquema relativamente simple sin muchas tablas por arrendatario.
- La necesidad de personalizar los esquemas de algunos inquilinos.
- Capacidad para hacer uso de roles de base de datos por inquilino
- Requisito de migrar los datos de un inquilino de un servidor a otro
- Capacidad para activar un servidor de aplicaciones dedicado en su nube para cada inquilino
Las cosas que lo convierten en una opción de bajo rendimiento incluyen:
- muchos inquilinos con muy pocos datos cada
- enfoque sin estado a las conexiones donde cada solicitud podría ser cualquier inquilino
- biblioteca cliente u orm que almacena en caché los metadatos de todas las tablas (como ActiveRecord)
- un requisito para una agrupación de conexiones y / o almacenamiento en caché de alta eficiencia
- problemas con VACUUM y otras operaciones administrativas de PostgreSQL que se escalan pobremente en miles de tablas.
Si el esquema del arrendatario es malo para las migraciones / los cambios de esquema realmente dependen de cómo los esté haciendo. Es malo para implementar un cambio de esquema universal rápidamente, pero es bueno para implementar cambios de esquema como un despliegue gradual entre los inquilinos.
la tabla compartida funciona mejor para situaciones en las que hay muchos inquilinos y muchos inquilinos tienen muy poca información. Un ejemplo de esto sería una aplicación móvil social social que permite cuentas gratuitas y, por lo tanto, tiene miles de cuentas abandonadas. Otras cosas que hacen que el modelo de tabla compartida sea beneficioso son:
- mejor para la agrupación de conexiones, ya que todas las conexiones pueden usar la misma agrupación
- Mejor para la administración de PostgreSQL, debido a un menor número de tablas
- 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 arrendatario a cada consulta en la capa de aplicación. También es problemático porque:
- las consultas que se unen a muchas tablas pueden tener un bajo rendimiento debido a que el filtro de inquilinos desactiva la planificación de consultas
- Las tablas que crecen a 100 millones de filas pueden causar problemas específicos de rendimiento y mantenimiento.
- no hay manera de hacer cambios en la aplicación específicos del inquilino o actualizaciones de esquema
- Más caro para migrar inquilinos entre servidores
Entonces, ¿qué modelo "funciona mejor" realmente depende de qué concesiones te perjudicarán 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.