¿Cuál es la mejor manera de estructurar una aplicación multiinquilino utilizando NoSQL (MongoDB) / base de datos relacional (MSsql / MySql)?

Habiendo tratado con múltiples inquilinos e instancias separadas para bases de datos de clientes, mi pregunta gira principalmente sobre la seguridad de los datos. ¿Existen requisitos para mantener los datos separados, debido a regulaciones como HIPPA o PII? Esos decidirán el curso a seguir. También considere la presentación de informes necesarios de la base de datos. Un sql db es fácil de informar, incluso si las consultas son complejas. Nosql puede ser más problemático dependiendo de lo que los usuarios / clientes quieran ver

Si tiene que tomar la ruta de instancias separadas, su equipo de DBA realmente necesitará concentrarse en la seguridad y la copia de seguridad / recuperación. Como las cosas se estrellarán y los malos intentarán hackear el sistema, es vital poder recuperarse rápidamente de cualquier interrupción.

Dando un paso atrás, ¿cuántos clientes tendrá en el lanzamiento? No serán 500k.

Tener 500k es un gran problema y, para entonces, habrás hecho crecer el negocio hasta el punto de alojar tus propias instancias y no depender de otras. Pero estoy divagando, si está lanzando con 10 clientes o menos, tendrá tiempo para comprender los compromisos con los procesos necesarios para administrar los DB y decidir si NoSql es el curso de acción correcto.

Mientras esperaba una respuesta de los usuarios de quora, continué mi búsqueda y encontré información relevante que puede ser de ayuda para mí o cualquier otra persona interesada en este mismo tema.

Según el tamaño de mis datos anticipados, almacenar los datos en una sola base de datos con, digamos, 100,000 solicitudes simultáneas causará problemas de rendimiento y definitivamente ralentizará el rendimiento general de la aplicación. Dado que quiero seguir con la base de datos relacional debido a la naturaleza de mi estructura de datos anticipada, una solución nosql no me atrae. Mientras investigaba, me encontré con una solución de Microsoft para escalar un sistema de base de datos relacional. Esta es una base de datos totalmente relacional basada en Azure creada para escala. Se conoce con el nombre de Azure SQL Database Elastic Scale.
La base de datos sql admite fragmentación, lo que me permite escalar horizontalmente. No tengo que girar una sola instancia de mongoDB para cada cliente como lo sugiere algún artículo que leí durante la investigación, sino que puedo tener fragmentos de Escala elástica de base de datos Azure Sql para grupo de clientes. Puedo tener 20,000 clientes en cada pantalla. Y mi programa se ejecutará como si todos los clientes estuvieran en una única base de datos sin problemas de rendimiento, ya que las solicitudes se enrutan a diferentes fragmentos.

El nombre del fragmento y la columna de incremento automático de la tabla de fragmentos crea una identificación de cliente única que también es necesaria para establecer una conexión con la base de datos.

Este es un enlace que describe en detalle y mejor esta idea Escala elástica de Azure SQL Database
Esperando que alguien más experimentado arroje más luz sobre este tema.

La idea de 500,000 instancias parece una locura.

Una base de datos relacional normal (agrupada, equilibrio de carga), es una ruta bien conocida, y probablemente menos costosa a largo plazo, en comparación con la solución noSQL (por qué, radica en muchos factores). A menos que sus requisitos sean muy únicos.

500,000 clientes no dicen mucho acerca de cuántas transacciones por segundo espera, lo cual es una medida mucho mejor.

Una base de datos Oracle / MS SQL en un buen hardware debería alcanzar su objetivo, por ejemplo, incluso cientos de transacciones por segundo.

El front-end que se implementa correctamente hacia la base de datos, puede estar fácilmente en varios servidores para manejar la carga.

Mira en IBM Cloudant. Abogan por el enfoque en varios casos de uso de una base de datos por cliente, pero como DBaaS administrado, no tendrá que preocuparse por la sobrecarga en eso.