Tengo el mismo problema que resolver y también estoy considerando variantes. Como tengo años de experiencia en la creación de aplicaciones multiusuario de SaaS, también iba a seleccionar la segunda opción en función de mi experiencia previa con las bases de datos relacionales.
Mientras investigaba, encontré este artículo en el sitio de soporte de mongodb (se agregó hace mucho tiempo desde que desapareció):https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi -inquilino.html
Los muchachos dijeron que evitarían las segundas opciones a toda costa, lo que, según tengo entendido, no es particularmente específico de mongodb. Mi impresión es que esto se aplica a la mayoría de las bases de datos NoSQL que investigué (CoachDB, Cassandra, CouchBase Server, etc.) debido a las características específicas del diseño de la base de datos.
Las colecciones (o cubos o como lo llamen en diferentes bases de datos) no son lo mismo que los esquemas de seguridad en RDBMS, a pesar de que se comportan como contenedores de documentos, son inútiles para aplicar una buena separación de inquilinos. No pude encontrar una base de datos NoSQL que pueda aplicar restricciones de seguridad basadas en colecciones.
Por supuesto, puede usar la seguridad basada en roles de mongodb para restringir el acceso a nivel de base de datos/servidor. (http://docs.mongodb.org/manual/core/authorization/)
Recomendaría la primera opción cuando:
- Dispone de tiempo y recursos suficientes para afrontar la complejidad del diseño, la implementación y las pruebas de este escenario.
- Si no va a tener muchas diferencias en estructura y funcionalidad en la base de datos para diferentes inquilinos.
- El diseño de su aplicación permitirá a los inquilinos realizar solo personalizaciones mínimas en tiempo de ejecución.
- Si desea optimizar el espacio y minimizar el uso de recursos de hardware.
- Si vas a tener miles de inquilinos.
- Si desea escalar rápidamente y a un buen costo.
- Si NO va a realizar una copia de seguridad de los datos en función de los inquilinos (mantenga copias de seguridad separadas para cada inquilino). Es posible hacerlo incluso en este escenario, pero el esfuerzo será enorme.
Elegiría la variante 3 si:
- Vas a tener una pequeña lista de inquilinos (varios cientos).
- Las características específicas del negocio requieren que pueda soportar grandes diferencias en la estructura de la base de datos para diferentes inquilinos (por ejemplo, integración con sistemas de terceros, importación y exportación de datos).
- El diseño de su aplicación permitirá a los clientes (inquilinos) realizar cambios significativos en el tiempo de ejecución de la aplicación (agregar módulos, personalizar los campos, etc.).
- Si tiene suficientes recursos para escalar rápidamente con nuevos nodos de hardware.
- Si debe mantener versiones o copias de seguridad de los datos por inquilino. Además, la restauración será fácil.
- Existen restricciones legales/normativas que lo obligan a mantener diferentes inquilinos en diferentes bases de datos (incluso centros de datos).
- Si desea utilizar completamente las funciones de seguridad listas para usar de mongodb, como los roles.
- Existen grandes diferencias en cuanto al tamaño entre los inquilinos (hay muchos inquilinos pequeños y pocos inquilinos muy grandes).
Si publica detalles adicionales sobre su solicitud, tal vez pueda brindarle un consejo más detallado.
