Múltiples esquemas versus enormes tablas

Question

Considere un sistema de Administrador de dispositivos móviles que contiene información para cada usuario, como una tabla que almacena las aplicaciones que ha instalado en el teléfono, los detalles de auditoría, la 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 solo usuario que asciende a aproximadamente 30 tablas cada una. ¿Sería mejor tener un esquema separado donde se coloque toda esta información en estas tablas (a su vez, creando enormes tablas?) O tener un esquema para cada usuario?

Gracias por adelantado

Answer 1

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 de datos y la protección, el mantenimiento y la recuperación de desastres. Estos son significativos; tú no poder considerar solamente Eficiencia de consulta en una base de datos de múltiples inquilinos.

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

"No compartió nada", "base de datos separada" o una base de datos por inquilino

• Más caro por cliente. (Gran número de clientes implican grandes cantidades de servidores).
• El más alto grado 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 por el sistema indocumentado, SP_MSFORECHDB, por ejemplo. Probablemente pueda escribir el suyo). "No compartir nada" es el más fácil de personalizar, pero eso también plantea más problemas de mantenimiento.
• El menor número de filas por tabla. La velocidad de consulta es casi óptima.

"Compartido todo", o "esquema compartido", o "una base de datos por planeta"

• Menos costoso por inquilino.
• El más bajo grado 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 cada mesa, es relativamente simple exponer accidentalmente los datos de otros inquilinos.
• La recuperación ante desastres para un solo inquilino es relativamente complicada; Tienes que restaurar las 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 tabla. La consulta rápida es más difícil, pero depende de cuántos inquilinos y cuántas filas. Podrías inclinar fácilmente al territorio VLDB.

Entre "no compartido nada" y "compartido todo" es "esquema compartido".

"Esquema compartido"

• Los inquilinos comparten una base de datos, pero cada inquilino tiene su propio esquema llamado. El costo cae entre "no compartido nada" y "compartido todo"; Los sistemas grandes generalmente necesitan menos servidores que "no compartido nada", más servidores que "compartir todo".
• Aislamiento mucho mejor que "compartido todo". No tanto aislamiento como "no compartió nada". (Puede otorgar y revocar permisos en esquemas).
• La recuperación de desastres para un solo inquilino requiere restaurar uno de los muchos esquemas. Esto es relativamente fácil o bastante difícil, dependiendo de sus DBM.
• El mantenimiento es más fácil que "no compartir nada"; No es tan fácil como "compartido 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 "no compartido nada".
• Por lo general, los inquilinos más activos por servidor que "no compartieron nada", lo que significa que comparten (degradan) más recursos. Pero no tan malo como "compartido todo".

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