Puedes implementar la multi-tenencia con Atlas para que una sola instancia de una aplicación sirva a varios inquilinos. Tus decisiones de diseño iniciales para una arquitectura multiinquilino pueden tener efectos no deseados con el tiempo, a medida que los requisitos evolucionan o cambian las expectativas de escalado.
El mejor enfoque puede depender de los siguientes factores:
Requisitos de escalado proyectados (número de inquilinos y uso de sus datos)
Requerimientos de seguridad y aislamiento
Uniformidad o variabilidad de los requisitos de datos entre inquilinos
Considera estos factores al decidir el mejor enfoque para usar en tu arquitectura multiinquilino.
Nota
Ver Cree una arquitectura multiusuario para MongoDB Vector Search y Cree una arquitectura multiusuario para MongoDB Search para obtener orientación específica.
Overview
Cuando diseñes una arquitectura multiinquilino, considera las siguientes estrategias:
Descripción | Si tienes un número pequeño y estable (hasta unos pocos cientos) de inquilinos con requisitos de datos variados y requisitos estrictos de control de acceso, considera una base de datos por inquilino. | Si prevé un número de inquilinos que crece indefinidamente, y la estructura de datos y los requisitos de consulta son relativamente consistentes entre ellos, considere la posibilidad de que los datos de los inquilinos coexistan en colecciones compartidas dentro de una única base de datos. Puede usar un |
Beneficios |
|
|
Considerations | Tú podrías:
|
|
Evitar Todos los inquilinos con sus propias colecciones en una sola base de datos.
Importante
Consideraciones de seguridad
En todos los enfoques siguientes, se crea una arquitectura multiinquilino en un único clúster. Se comparte el registro de operaciones de replicación y los datos de usuario entre todos los inquilinos, lo que podría generar problemas de seguridad. Para proteger la partición de datos, se debe implementar un único conjunto de réplicas pequeñas para cada inquilino con autenticación única.
Cada arrendatario en su propia base de datos
Si tiene una cantidad pequeña y estable (hasta unos cientos) de inquilinos con requisitos de datos variados y requisitos estrictos de control de acceso, considere crear una base de datos por inquilino.
Este enfoque tiene los siguientes beneficios:
Para mayor seguridad, el usuario de base de datos puede limitar el acceso a los datos del inquilino. Atlas limita 100 usuarios de base de datos por proyecto por defecto.
Para contemplar patrones de acceso únicos para estructuras de datos variables entre inquilinos, puedes configurar la indexación.
Para trasladar a un solo arrendatario a sus propios recursos dedicados, puedes migrar o escalar los datos aislados de todo un arrendatario a nuevos recursos (por ejemplo, a otro clúster).
Considere que podría:
Agregue más complejidad para el nivel de la aplicación.
Tener colecciones e índices redundantes entre inquilinos.
Encuentra problemas a gran escala en un solo clúster. Los archivos de datos subyacentes necesarios para cada nueva colección y índice consumen recursos computacionales.
Cada inquilino tiene su propia base de datos lógica en el mismo clúster. Este enfoque permite una fácil personalización y una sólida seguridad. Permite realizar copias de seguridad y acciones de mantenimiento para un inquilino sin afectar a los demás.
Sin embargo, este enfoque puede aumentar el esfuerzo de configuración y los recursos computacionales necesarios. Las interacciones entre inquilinos requieren conexiones a varias bases de datos. Algunos comandos de MongoDB solo funcionan entre colecciones en la misma base de datos.
Cada colección e índice se almacenan en el disco como un archivo separado, lo que puede llevar a un número muy grande de archivos abiertos y un alto uso de memoria. Para mitigar esto, utilice menos de 1000 archivos de datos (colecciones e índices individuales) por nodo. Para obtener más información, consulta Límites de colección e índice.
Todos los inquilinos en una sola base de datos con colecciones compartidas
Si espera un número de inquilinos que crece indefinidamente, la estructura de los datos y los requisitos de consulta son relativamente consistentes entre los inquilinos y tiene requisitos de control de acceso menos estrictos, considere usar una única base de datos con colecciones compartidas para todos los inquilinos.
Este enfoque tiene los siguientes beneficios:
Altamente escalable (por ejemplo, puede fragmentar el clúster)
Simplifica el mantenimiento continuo (por ejemplo, la indexación de nuevos patrones de consulta)
Considere los siguientes problemas potenciales:
Un solo usuario de base de datos podría acceder a este gran grupo de datos multifuncionales.
La segmentación de los datos es puramente lógica y debe aplicarse en el nivel de aplicación.
Todos los inquilinos pueden tener documentos en todas las colecciones. La lógica de multiinquilino existe en la capa de aplicación. Cada documento debe tener un campo tenantId, y cada query a la base de datos debe filtrar por ese campo. Debes gestionar la seguridad a nivel de aplicación.
Podrías experimentar problemas de escalabilidad a largo plazo. Cualquier mantenimiento que realices afecta a todos los inquilinos simultáneamente. Si bien este enfoque funciona bien con muchos inquilinos pequeños del mismo tamaño, no es eficaz si el tamaño de los inquilinos varía. Además, personalizar la configuración para cada inquilino podría resultar difícil.
Todos los inquilinos con sus propias colecciones en una sola base de datos
Evita colocar a todos los inquilinos con sus propias colecciones en una sola base de datos. Si bien este enfoque previene problemas de personalización, complica la codificación de la aplicación y agrava los problemas de escalado a largo plazo.