database - rtconner - Múltiples esquemas versus tablas enormes.

cviebrock eloquent taggable (1)

Considere un sistema de administración de dispositivos móviles que contenga información para cada usuario, como una tabla que almacena las aplicaciones que ha instalado en el teléfono, detalles de auditoría, información de notificación, etc. Es conveniente crear un esquema separado para cada usuario con las tablas correspondientes ? El número de tablas es grande para un solo usuario que asciende a unas 30 tablas cada una. ¿Sería mejor tener un esquema separado donde toda esta información se coloca en estas tablas (a su vez, crear tablas enormes) o tener un esquema para cada usuario?

Gracias por adelantado

Quiero ver qué método es más eficiente en términos de consulta en la base de datos.

En una base de datos de múltiples inquilinos, la consulta es solo una parte del problema. Otras partes del problema son el costo, el aislamiento y la protección de datos, el mantenimiento y la recuperación ante desastres. Estos son significativos; no puede considerar solo la eficiencia de las consultas en una base de datos de múltiples inquilinos.

Las soluciones para múltiples inquilinos van desde una base de datos por inquilino (nada compartido) hasta una fila por inquilino (todo compartido).

"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 mayor grado de aislamiento de datos.
La recuperación de 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 sus dbms podrían fácilmente soportar 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). "La nada compartida" también es la más fácil de personalizar, pero eso también plantea más problemas de mantenimiento.
El número más bajo de filas por tabla. La velocidad de consulta es casi óptima.

"Todo lo compartido", o "esquema compartido", o "una base de datos por planeta"

Menos costoso por inquilino.
El menor grado 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 sencillo exponer accidentalmente los datos de otros inquilinos.
La recuperación de desastres para un solo inquilino es relativamente complicada; Tienes que restaurar filas individuales en muchas tablas. Por otro lado, un desastre de un solo inquilino es relativamente inusual. La mayoría de los desastres probablemente afectarán a todos los inquilinos.
El mantenimiento estructural es más sencillo, dado que todos los inquilinos comparten las tablas. Sin embargo, aumenta la carga de comunicación, ya que tiene que comunicarse y coordinar cada cambio con cada inquilino. No es fácilmente personalizable.
Mayor número de filas por tabla. La consulta rápida es más difícil, pero depende de cuántos inquilinos y cuántas filas. Usted podría fácilmente volcarse en el territorio VLDB.

Entre "nada compartido" y "todo compartido" está el "esquema compartido".

"Esquema compartido"

Los inquilinos comparten una base de datos, pero cada inquilino tiene su propio esquema denominado. El costo cae entre "nada compartido" y "todo compartido"; Los sistemas grandes suelen necesitar menos servidores que "nada compartido", más servidores que "todo compartido".
Mucho mejor aislamiento que "todo lo compartido". No tanto aislamiento como "nada compartido". (Puede GRANT y REVOKE permisos en esquemas).
La recuperación de desastres para un solo inquilino requiere la restauración de uno de los muchos esquemas. Esto es relativamente fácil o bastante difícil, dependiendo de tus dbms.
El mantenimiento es más fácil que "nada compartido"; No es tan fácil como "todo lo compartido". Es relativamente sencillo escribir un procedimiento almacenado que se ejecutará en cada esquema en una base de datos. Es más fácil compartir tablas comunes entre los inquilinos que con "nada compartido".
Por lo general, más inquilinos activos por servidor que "nada compartido", lo que significa que comparten (degradan) más recursos. Pero no es tan malo como "lo compartió todo".

Microsoft tiene un buen artículo sobre arquitectura multi-tenant con más detalles. (El enlace es a solo una página de un documento de varias páginas).