Puede implementar la arquitectura multiinquilino con Atlas para que una sola instancia de una aplicación sirva a múltiples inquilinos. Sus decisiones iniciales de diseño para una arquitectura multiinquilino pueden tener efectos imprevistos con el tiempo, a medida que evolucionan los requisitos o cambian las expectativas de escalabilidad.
El mejor enfoque podría depender de los siguientes factores:
Requisitos de escalamiento proyectados (número de inquilinos y su uso de datos)
Requisitos 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
Para obtener recomendaciones específicas de MongoDB Vector Search, consulte Construya una arquitectura multiinquilino para MongoDB Vector Search.
Overview
Al diseñar una arquitectura multiinquilino, considere los siguientes enfoques:
Descripción | Si tiene un número pequeño y estable (hasta unos cientos) de inquilinos con requisitos de datos variados y requisitos estrictos de control de acceso, considere 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 | 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 inquilino 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 la base de datos puede limitar el acceso a los datos del inquilino. Atlas limita de forma predeterminada 100 a usuarios de la base de datos por proyecto.
Para contemplar patrones de acceso únicos para estructuras de datos variables entre inquilinos, puedes configurar la indexación.
Para mover un solo inquilino a sus propios recursos dedicados, puede migrar o escalar los datos aislados de un inquilino completo a nuevos recursos (por ejemplo, otro clúster).
Considere que podría:
Agregue más complejidad al nivel de aplicación.
Tener colecciones e índices redundantes entre inquilinos.
Detectar problemas a gran escala en un solo clúster. Los archivos de datos subyacentes necesarios para cada nueva colección e í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 almacena en el disco como un archivo independiente, lo que puede generar una gran cantidad de archivos abiertos y un alto consumo de memoria. Para mitigar esto, utilice menos de 1000 archivos de datos (colecciones e índices individuales) por nodo. Para obtener más información, consulte Límites de colecciones e índices.
Todos los inquilinos en una única 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 para nuevos patrones de consulta)
Considere los siguientes problemas potenciales:
Un solo usuario de base de datos podría acceder a este gran conjunto de datos de múltiples inquilinos.
La segmentación de datos es puramente lógica y debe implementarse 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 única base de datos
Evite agrupar todos los inquilinos con sus propias colecciones en una única base de datos. Si bien este enfoque evita problemas de personalización, complica la codificación de la aplicación y agrava los problemas de escalabilidad a largo plazo.