Esquemas múltiples versus tablas enormes

Considere un sistema de administrador de dispositivo móvil 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 aconsejable crear un esquema separado para cada usuario con las tablas correspondientes? ? El número de tablas es grande para un usuario único y asciende a aproximadamente 30 tablas cada una. ¿Sería mejor tener un esquema separado donde toda esta información se coloca en estas tablas (a su vez creando 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 consultas en la base de datos.

En una base de datos de múltiples usuarios, consultar 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 la consulta en una base de datos de múltiples usuarios.

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

“No se compartió nada”, “base de datos separada” o una base de datos por inquilino

  • Más caro por cliente (Un gran número de clientes implica una gran cantidad de servidores).
  • 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 su dbms podría soportar fácilmente la ejecución de procedimientos almacenados en cada base de datos. (SQL Server tiene un procedimiento almacenado en el sistema no documentado, sp_msforeachdb, por ejemplo. Probablemente pueda escribir el suyo propio). La opción “Sin compartir” también se puede personalizar más fácilmente, pero eso también genera más problemas de mantenimiento.
  • El número más bajo de filas por mesa. La velocidad de consulta es casi óptima.

“Compartido todo”, 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é inquilino pertenece una fila. Dado que las filas de inquilinos se mezclan en todas las tablas, es relativamente simple exponer accidentalmente los datos de otros inquilinos.
  • La recuperación de desastres para un único inquilino es relativamente complicada; tienes que restaurar filas individuales en muchas tablas. Por otro lado, un desastre de inquilino único es relativamente inusual. La mayoría de los desastres probablemente afectarán a todos los inquilinos.
  • El mantenimiento estructural es más simple, dado que todos los inquilinos comparten las tablas. Sin embargo, aumenta la carga de comunicación porque debe comunicarse y coordinar cada cambio con cada inquilino. No es fácilmente personalizable.
  • El mayor número de filas por mesa. La consulta rápida es más difícil, pero depende de cuántos inquilinos y cuántas filas. Podrías volcar fácilmente en territorio VLDB.

Entre “compartir nada” y “compartir todo” es “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 “compartido todo”; los grandes sistemas generalmente necesitan menos servidores que “nada compartido”, más servidores que “todo compartido”.
  • Mucho mejor aislamiento que “compartir todo”. No tanto aislamiento como “nada compartido”. (Puede conceder y REVOCAR permisos en esquemas).
  • La recuperación de desastres para un solo 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 simple 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, los inquilinos más activos por servidor que “no comparten nada”, lo que significa que comparten (degradan) más recursos. Pero no es tan malo como “compartió todo”.

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