¿Las bases de datos multiinquilino tienen múltiples bases de datos o tablas compartidas?

Es una base de datos multiinquilino:

¿Un servidor de base de datos que tiene una base de datos / esquema (idéntico) diferente para cada cliente / inquilino ?; o
¿Un servidor de base de datos que tiene una base de datos / esquema donde los clientes / inquilinos comparten registros dentro de las mismas tablas?

Por ejemplo, en la Opción # 1 anterior, podría tener un servidor MySQL en, digamos mydb01.example.com, y podría tener una customer1base de datos dentro de él. Esta customer1base de datos puede tener, por ejemplo, 10 tablas que potencian mi aplicación para ese cliente en particular (Cliente # 1). También podría tener una customer2base de datos con exactamente las mismas 10 tablas, pero que solo contenga datos para el Cliente # 2. Puede tener una customer3base de datos, una customer4base de datos, etc.

En la Opción # 2 anterior, solo habría una única base de datos / esquema, digamos myapp_db, nuevamente con 10 tablas (las mismas que las anteriores). Pero aquí, los datos de todos los clientes existen dentro de esas 10 tablas y, por lo tanto, "comparten" las tablas. Y en la capa de aplicación, la lógica y el control de seguridad a los que los clientes tienen acceso a qué registros en esas 10 tablas, y se tiene mucho cuidado para garantizar que el Cliente # 1 nunca inicie sesión en la aplicación y vea los datos del Cliente # 3, etc.

¿Cuál de estos paradigmas constituye un DB tradicional "multiinquilino"? Y si ninguno de los dos, ¿alguien puede darme un ejemplo (usando los escenarios descritos anteriormente) de lo que es un DB multiinquilino?

database-design multitenancy

— smeeb
fuente

"multiinquilino" implica una seguridad sólida, implementada en alguna parte , de modo que un inquilino no pueda ver los datos de otros, no pueda modificarlos, no pueda negar el acceso a ellos, etc. Esa seguridad debe implementarse de alguna manera. Las opciones n. ° 1 y n. ° 2 del OP funcionan, pero el análisis de seguridad y el trabajo requerido para implementar la seguridad son diferentes. Por lo que vale, trabajé en una startup que implementó la tenencia múltiple a través de la opción # 2, donde las tablas, con filas pertenecientes a múltiples inquilinos, estaban ocultas (a través de permisos) de todos los usuarios finales y la seguridad se implementó por completo en los procedimientos almacenados.

— davidbak

Posible duplicado de Multi-

— tenancy

Si esto termina cerrándose como un duplicado, creo que deberíamos marcar para fusionarlo con el objetivo de engaño porque ambas preguntas tienen algunas respuestas realmente buenas.

Respuestas:

¿Cuál de estos paradigmas constituye un DB tradicional "multiinquilino"?

Ambos conceptos se llaman multicliente, ya que es solo un concepto lógico "en el que una sola instancia de software se ejecuta en un servidor y sirve a múltiples inquilinos" (de Wikipedia ). Pero cómo implementar este concepto "físicamente" depende de usted.

Por supuesto, la aplicación necesita un concepto de base de datos que permita separar los datos de diferentes inquilinos, y la idea de la tenencia múltiple es compartir algunos recursos del servidor (al menos el hardware) para una mejor utilización de los recursos y una administración más fácil. Por lo tanto, una "base de datos de múltiples inquilinos" es la que admite esto directamente , donde se comparten partes del modelo o tablas db.

Para ser precisos, es posible construir una aplicación multiinquilino con una base de datos no multiinquilino, proporcionando una instancia de base de datos individual por cliente. Sin embargo, esto impide compartir los recursos de la base de datos directamente entre los inquilinos, y la capa de aplicación debe asegurarse de conectar el inquilino correcto a la base de datos correcta.

— Doc Brown
fuente

Gracias @Doc Brown (+1) pero entonces, ¿cómo podría tener una base de datos que no fuera multiinquilino ?

— smeeb

@smeeb: multi-tenancy es una propiedad de la aplicación utilizada por diferentes inquilinos, no de la base de datos "detrás" de la aplicación. Por supuesto, el concepto db debe admitir la tenencia múltiple para que esto sea posible.

— Doc Brown

@smeeb: supongamos que tiene una tabla de usuario con la restricción de que el nombre de usuario es único, ahora algún empleado de un inquilino ya no puede usar un nombre de usuario solo porque otra persona que trabaja en otro inquilino ya lo está utilizando.

— RemcoGerlich

@smeeb: si la única forma de servir a dos inquilinos es instalar y ejecutar una aplicación dos veces, en dos servidores diferentes, con dos bases de datos separadas, creo que uno no llamaría a este arrendamiento múltiple.

— Doc Brown

Hace un tiempo fui a una presentación en Azure que decía que MYOB ejecutaba su solución en la nube en Azure, y cada inquilino obtiene su propia base de datos (y presumiblemente también servidores web); solo tienen algunas excelentes herramientas de automatización para administrar los cientos de instancias de DB que deben requerir. Por otro lado, la organización para la que trabajo actualmente maneja a cientos de clientes desde una sola base de datos, solo se está trabajando bastante en el software para forzar el aislamiento de los datos de los clientes. También consideramos un híbrido, donde nuestros clientes más grandes obtendrían su propio DB, mientras que otros compartieron el original.

— David Keaveny

Según Microsoft, el término tiene 3 significados potenciales (una base de datos para todos los inquilinos o una base de datos por inquilino).

Para usar su ejemplo, cada cliente sería su propio inquilino.

Una base de datos por inquilino (cliente)
- Cada inquilino está aislado de los demás (sin acceso accidental a los datos de otros inquilinos)
- El aislamiento también facilita la gestión de la restauración de datos, así como la adaptación de las necesidades de almacenamiento para las necesidades de los inquilinos.
Una base de datos compartida, esquema separado.
- Cada inquilino tiene su propio esquema, y sus datos están en sus propias tablas.
- La restauración puede llevar más tiempo, ya que todos están en la misma base de datos, no puede simplemente restaurar la base de datos a una copia de seguridad anterior (revertiría los datos de cada inquilino). Una opción es restaurar a una nueva base de datos y luego combinar / copiar solo los datos de 1 inquilinos.
Una base de datos compartida, esquema compartido.
- Los datos de cada inquilino están en las mismas tablas. Si realiza un seguimiento de los pedidos, por ejemplo, los pedidos de cada inquilino se ubicarían en "dbo.Orders".
- Los datos de los inquilinos están separados por una columna en cada tabla (podría ser TenantId), que muestra el propietario de la fila.

Hay pros y contras para cada uno, bien explicados en este artículo: https://msdn.microsoft.com/en-us/library/aa479086.aspx

Bonificación: puedes considerarlo como una vivienda (muy simplificada).

Cada inquilino tiene su propia casa. Pueden hacer lo que quieran, y si se quema, realmente no afecta a nadie más.
Cada inquilino está en el mismo edificio, pero tiene su propio apartamento.
Todos viven en el mismo departamento, y todas las cosas están marcadas con una nota adhesiva para mostrar quién es el propietario.

— lmms90
fuente

Gracias por su respuesta. ¿Podría por favor elaborar un poco su respuesta? Eso crearía una mejor respuesta.

— Thomas Junk

su ejemplo de bonificación es impresionante @ imms90

— Aravin

Microsoft ha eliminado la página que ha vinculado desde MSDN. La máquina wayback todavía tiene una copia.

— Mike Sherrill 'Cat Recall'

Artículo similar de MS (quizás el mismo que se ha movido): docs.microsoft.com/en-us/azure/sql-database/…

— Pierre Henry