Múltiples clientes; una aplicación alojada. Está describiendo una base de datos de múltiples inquilinos.
Cuando crea una base de datos multiinquilino, debe considerar
- consultar
- coste
- aislamiento y protección de datos
- mantenimiento y
- recuperación de desastres.
Las soluciones multiinquilino van desde una base de datos por inquilino (nada compartido) hasta una fila por inquilino (compartido todo).
"Nada compartido", "base de datos separada" o una base de datos por inquilino
- Más caro por cliente. (Un gran número de clientes implica un gran número de servidores).
- El grado más alto de aislamiento de datos.
- La recuperación ante desastres para un solo inquilino es simple y directa.
- El mantenimiento es teóricamente más difícil, porque los cambios deben llevarse a cabo en cada base de datos. Pero su dbms podría admitir fácilmente la ejecución de procedimientos almacenados en cada base de datos. (SQL Server tiene un procedimiento almacenado del sistema no documentado, sp_msforeachdb, por ejemplo. Probablemente pueda escribir el suyo propio). "No se comparte nada" también es el más fácil de personalizar, pero eso también genera más problemas de mantenimiento.
- Número más bajo de filas por tabla. La velocidad de consulta es casi óptima.
"Todo compartido", o "esquema compartido", o "una base de datos por planeta"
- Menos costoso por inquilino.
- El grado más bajo de aislamiento de datos. Cada tabla tiene una columna que identifica a qué arrendatario pertenece una fila. Dado que las filas de inquilinos se mezclan en cada tabla, es relativamente simple exponer accidentalmente los datos de otros inquilinos.
- La recuperación ante desastres para un único inquilino es relativamente complicada; tiene que restaurar filas individuales en muchas tablas.
- El mantenimiento estructural es más sencillo, dado que todos los inquilinos comparten las mesas. Sin embargo, aumenta la carga de comunicación porque tiene que comunicar y coordinar cada cambio con cada inquilino. No es fácil de personalizar.
- Número más alto de filas por tabla. La consulta rápida es más difícil, pero depende de cuántos inquilinos y cuántas filas. Podría caer fácilmente en territorio VLDB.
Entre "nada compartido" y "todo compartido" está "esquema compartido".
"Esquema compartido"
- Los inquilinos comparten una base de datos, pero cada inquilino tiene su propio esquema con nombre. El costo cae entre "nada compartido" y "todo compartido"; los sistemas grandes normalmente necesitan menos servidores que "nada compartido", más servidores que "todo compartido".
- Mucho mejor aislamiento que "compartir todo". No tanto aislamiento como "no compartir nada". (Puede OTORGAR y REVOCAR permisos en esquemas).
- La recuperación ante desastres para un único inquilino requiere restaurar uno de muchos esquemas. Esto es relativamente fácil o bastante difícil, dependiendo de su dbms.
- El mantenimiento es más fácil que "no compartir nada"; no es tan fácil como "compartir todo". Es relativamente sencillo escribir un procedimiento almacenado que se ejecutará en cada esquema de una base de datos. Es más fácil compartir mesas comunes entre inquilinos que con "nada compartido".
- Por lo general, más inquilinos activos por servidor que "no comparten nada", lo que significa que comparten (degradan) más recursos. Pero no tan malo como "compartir todo".
Microsoft tiene un buen artículo sobre arquitectura multiinquilino con más detalles. (El enlace es solo a una página de un documento de varias páginas).
