No es una respuesta fácil porque mucho depende de la arquitectura de su aplicación, el uso y los patrones de consulta, la distribución entre los clientes (es decir, ¿los niveles de uso serán aproximadamente los mismos entre los clientes, o podría tener el 10% de los clientes usando el 90% de la recursos), cuánto puede gastar en código frente a gestión de operaciones y una gran cantidad de otros problemas. Aquí hay algunas cosas a considerar:
1) tener una base de datos facilitará la administración de sus operaciones, requerirá menos recursos informáticos y puede permitirle escalar mejor, pero codificar la capa de acceso será más difícil y realmente tendrá que diseñar bien su capa de seguridad por razones obvias. También consumirá menos recursos en el extremo cliente/servidor web ya que habrá muchas menos conexiones.
Hay dos opciones de esquema populares al acercarse a una base de datos monolítica:
- Puede poner todos los datos similares en una colección (es decir, los perfiles de todas las cuentas van a la misma colección) y dar a cada documento una clave de ID de cliente para identificar qué datos pertenecen a qué cuenta. Esto puede brindarle las mejores opciones (según la arquitectura de su esquema) para escalar horizontalmente con la menor cantidad de recursos informáticos.
- Otra opción es separar los datos de los clientes por colecciones; cada cliente tendrá sus propias colecciones dentro de la base de datos identificada con un prefijo de identificación de cliente (es decir:identificación de cliente_perfiles de usuario).
2) la opción de base de datos por cliente le dará más dolores de cabeza en la administración de operaciones y le costará más, ya que necesitará más recursos informáticos. Por otro lado, sus costos de codificación deberían ser menores ya que el código será más fácil de escribir. También le permitirá distribuir mejor sus recursos entre usuarios pesados y ligeros. Por ejemplo, puede mover clientes de uso intensivo a máquinas más potentes y proporcionar fragmentación por cliente.
3) podría proporcionar una combinación de las dos opciones:bases de datos dedicadas para usuarios de gama alta (cuentas que pagan más) y luego una base de datos compartida con datos separados por recopilación para clientes de gama baja y cuentas de prueba/freemium.
Tenga en cuenta que si va por la ruta de muchas bases de datos, debe buscar en la opción de inicio --smallfiles. Esto lo ayudará en situaciones en las que muchas personas configuran "cuentas de prueba" pero no hacen mucho con ellas.
De todos modos, espero que lo anterior te dé algo para pensar. Haz una búsqueda en https://groups.google.com /forum/?fromgroups#!searchin/mongodb-user/multiinquilino ya que ha habido una serie de debates en los foros de Mongo sobre este tema específico.
En cuanto a las implicaciones de la auditoría, depende del nivel de cumplimiento de auditoría al que deba adherirse. Si espera clientes de la fortuna 1000, sus requisitos de cumplimiento serán mucho más altos (y mucho más costosos, piense en $ 10 a $ 100 de miles de dólares), que si sus clientes son nuevas empresas que quizás nunca hayan oído hablar de SAS70, etc. La respuesta también depende del tipo de datos que esté almacenando:¿son datos financieros del usuario o son solo foros de usuarios? Básicamente, si le preocupa la necesidad de pasar auditorías de seguridad para grandes empresas en el futuro, ni siquiera piense en el enfoque de base de datos compartida.
