multitenancy - ¿Cuál es el enfoque recomendado para las bases de datos de múltiples inquilinos en MongoDB?

multitenant mongodb (6)

Encontré una buena respuesta en los comentarios en este enlace:

http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/

Básicamente, la opción n. ° 2 parece ser la mejor opción.

Cita del comentario de David Mytton:

Decidimos no tener una base de datos por cliente debido a la forma en que MongoDB asigna sus archivos de datos. Cada base de datos usa su propio conjunto de archivos:
El primer archivo para una base de datos es dbname.0, luego dbname.1, etc. dbname.0 será 64MB, dbname.1 128MB, etc., hasta 2GB. Una vez que los archivos alcanzan un tamaño de 2 GB, cada archivo sucesivo también es de 2 GB.
Por lo tanto, si el último archivo de datos presente es, por ejemplo, 1 GB, ese archivo puede estar vacío en un 90% si se alcanzó recientemente.
del manual.
A medida que los usuarios se inscriben en la versión de prueba y se dan a la tarea, obtendremos más y más bases de datos con un tamaño de al menos 2 GB, incluso si no se usó todo el archivo de datos. Encontramos que esto usó una gran cantidad de espacio en disco en comparación con tener varias bases de datos para todos los clientes donde el espacio en disco se puede utilizar con la máxima eficiencia.
El sharding será por colección como estándar, lo que presenta un problema donde la colección nunca alcanza el tamaño mínimo para comenzar a fragmentarse, como es el caso de algunas de las nuestras (por ejemplo, colecciones que solo almacenan detalles de inicio de sesión). Sin embargo, hemos solicitado que esto también se pueda hacer a nivel de base de datos. Ver http://jira.mongodb.org/browse/SHARDING-41
No hay compensaciones de rendimiento que usen muchas colecciones. Ver http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

Estoy pensando en crear una aplicación multi-tenant usando MongoDB. No tengo ninguna suposición en cuanto a cuántos inquilinos tendría todavía, pero me gustaría poder escalar a miles.

Puedo pensar en tres estrategias:

Todos los inquilinos en la misma colección, utilizando campos específicos del inquilino para la seguridad
1 colección por inquilino en una única base de datos compartida
1 base de datos por inquilino

La voz en mi cabeza sugiere que vaya con la opción 2.

Pensamientos e implicaciones, ¿alguien?

Existe un artículo razonable sobre MSDN sobre la arquitectura de datos de múltiples inquilinos al que puede referirse. Algunos temas clave tocados por este artículo:

Consideraciones económicas
Seguridad
Consideraciones del inquilino
Regulatorio (legal)
Preocupaciones del conjunto de habilidades

También se mencionan algunos patrones para la configuración de Software como servicio (SaaS).

Además, vale la pena un vistazo es una reseña interesante de los chicos de SQL Anywhere .

Mi opinión personal: a menos que esté seguro de la seguridad / confianza impuesta, me gustaría ir con la opción 3, o si las inquietudes de escalabilidad prohíben el repliegue a la opción 2 como mínimo. Dicho eso ... No soy profesional con MongoDB. Me pongo bastante nerviosa usando un "esquema" compartido, pero me complaceré ante los practicantes más experimentados.

Si bien la discusión aquí está en NoSQL y principalmente en MongoDB, en Citus estamos usando PostgreSQL y construyendo una base de datos de múltiples inquilinos distribuida / fragmentada.

Nuestra guía de casos de uso recorre una aplicación de ejemplo que cubre el esquema y varias características específicas para varios inquilinos.

Para obtener más datos no estructurados, utilizamos la columna JSONB de PostgreSQL para almacenar dichos datos específicos del inquilino.

Tengo el mismo problema para resolver y también considerar variantes. Como tengo años de experiencia en la creación de aplicaciones SaaS multi-tenant, también iba a seleccionar la segunda opción en función de mi experiencia previa con las bases de datos relacionales.

Mientras hacía mi investigación encontré este artículo en el sitio de soporte de mongodb: support.mongohq.com/use-cases/multi-tenant.html

Los chicos declararon evitar las segundas opciones a cualquier costo, lo cual, como yo lo entiendo, no es particularmente específico de mongodb. Mi impresión es que esto es aplicable para la mayoría de los dbs de NoSQL que investigué (CoachDB, Cassandra, CouchBase Server, etc.) debido a los detalles del diseño de la base de datos.

Las colecciones (o cubos o como lo llamen en diferentes DB) no son lo mismo que los esquemas de seguridad en RDBMS a pesar de que se comportan como contenedores para documentos, son inútiles para aplicar una buena separación de inquilinos. No pude encontrar la base de datos NoSQL que puede aplicar restricciones de seguridad basadas en colecciones.

Por supuesto, puede usar la seguridad basada en funciones de mongodb para restringir el acceso a nivel de base de datos / servidor. ( http://docs.mongodb.org/manual/core/authorization/ )

Yo recomendaría la primera opción cuando:

Tiene suficiente tiempo y recursos para lidiar con la complejidad del diseño, implementación y prueba de este escenario.
Si no va a haber muchas diferencias en estructura y funcionalidad en la base de datos para diferentes inquilinos.
El diseño de su aplicación les 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 quiere escalar rápidamente y con un buen costo.
Si NO va a hacer copias de seguridad de los datos en base a los inquilinos (mantenga copias de seguridad separadas para cada inquilino). Es posible hacerlo incluso en este escenario, pero el esfuerzo será enorme.

Me gustaría ir a la variante 3 si:

Tendrás 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 (agregando módulos, personalizando los campos, etc.).
Si tiene suficientes recursos para escalar rápidamente con nuevos nodos de hardware.
Si se le requiere mantener versiones / respaldos de datos por inquilino. También la restauración será fácil.
Existen restricciones legales / reglamentarias 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 las funciones.
Existen grandes diferencias en materia de tamaño entre los inquilinos (tiene muchos inquilinos pequeños y pocos inquilinos muy grandes).

Si publica detalles adicionales sobre su aplicación, quizás pueda darle consejos más detallados.

Yo iría por la opción 2.

Sin embargo, podría establecer la opción de línea de comando mongod.exe --smallfiles. Esto significa que el tamaño de archivo más grande de una extensión será de 0,5 gigabytes y no de 2 gigabytes. Probé esto con mongo 1.42. Entonces la opción 3 no es imposible.

De acuerdo con mi investigación en MongoDB. Trucos y consejos. Aplicaciones multitenant. esa opción no se recomienda si no sabes cuántos inquilinos puedes tener, podría ser miles y sería complicado cuando se trata de fragmentación, también imagina tener miles de colecciones en una única base de datos ... Entonces en tu caso se recomienda usar la opción uno. Ahora, si va a tener un número limitado de usuarios, ya es diferente y sí, podría usar la opción dos tal como pensaba.