He visto aplicaciones SaaS alojadas de diferentes maneras. ¿Es una buena idea dividir las características y módulos en múltiples bases de datos? Por ejemplo, poner cosas como la tabla de Usuario en un DB y tablas específicas de función/aplicación en otro DB y quizás otras tablas comúnmente compartidas en otro DB?Diseño de base de datos SaaS - ¿Bases de datos múltiples? ¿División?
Comience con una base de datos. Dividir datos/funcionalidad cuando el proyecto lo requiera.
Esto es lo que podemos aprender de LinkedIn:
Fuente:
Pregúntese: ¿Qué gana al mover todo a bases de datos separadas?
Mucho dolor en términos de gestión sería mi suposición. Sería más entusiasta personalmente tener todo en una sola base de datos y si se tocan problemas que una simple base de datos no puede resolver más tarde, entonces migre los datos a múltiples bases de datos.
¿Qué hay del rendimiento y la escalabilidad? – Vyrotek
Tener una única base de datos es mejor para la integridad de los datos porque entonces puede usar claves externas. No puede tener esta integridad de datos integrada si divide los datos en múltiples bases de datos. Esto no es un problema si sus datos no están relacionados, pero si están relacionados, su única base de datos podría contener datos que son inconsistentes con otra base de datos. En este caso, necesitaría escribir un código que escanea sus bases de datos en busca de datos incoherentes regularmente para que pueda manejarlo de manera adecuada.
Sin embargo, es posible que se necesiten varias bases de datos si necesita que su sitio/aplicación sea altamente escalable (por ejemplo, la escala de Internet). Por ejemplo, puede alojar cada base de datos en un servidor físico diferente.
La división de la base de datos por características puede no ser una buena idea a menos que vea evidencia sólida que sugiera la necesidad. A menudo es posible que necesite actualizar dos bases de datos como parte de una sola transacción, y las transacciones distribuidas son mucho más difíciles de manejar. Además, si la base de datos debe dividirse, es posible que pueda utilizar sharding.
High Scalability es un buen blog para escalar aplicaciones SaaS. Como se mencionó, dividir tablas en bases de datos como sugirió es generalmente una mala idea. Pero un concepto similar es el sharding, donde se mantiene el mismo esquema (o similar), pero se dividen los datos en varios servidores. Por ejemplo, los usuarios 1-5000 están en el servidor1 y los usuarios 5000-10000 en el servidor2. Dependiendo de las consultas que utiliza su aplicación, puede ser una forma eficiente de escalar.
Para las aplicaciones SaaS, utiliza múltiples bases de datos para varios inquilinos, pero generalmente no las divide en módulos.
Este es el modelo más común que he visto en el diseño de aplicaciones SaaS. Su esquema base se replica para cada inquilino que agrega a su aplicación.
mantenerlo en diseño natural (desnormalizar tanto como sea necesario, a normalizar lo mínimo requerido). Divida el Modelo de BD en sus módulos y tenga en cuenta los principios orientados al servicio al afrontar los datos con un servicio (que posee los datos).
Hay una variedad de formas de lograrlo, pero los problemas de multi-tenancy van más allá del simple modelo de datos. No me gusta enchufar el producto, pero mira SaaSGrid de my la compañía donde trabajo, Apprenda. Somos un sistema operativo en la nube que te permite escribir SOA de inquilinos individuales (puedes usar NHibernate para acceso a datos) que se inyecta automáticamente multi-tenancy en su aplicación. Cuando publique su aplicación, puede hacer cosas como elegir un modelo de datos (base de datos aislada o compartida) y SaaSGrid se implementará en consecuencia y su aplicación se ejecutará sin ningún cambio de código, ¡simplemente escriba el código como si fuera para un único inquilino!
¿Por qué usar la base de datos en absoluto?
Creo que es una buena idea usar sistemas de almacenamiento distribuido como Hadoop, Voldemort (project-voldemort.com desarrollado y utilizado por LinkedIn).
Creo que es bueno para datos sensitivos como las operaciones de dinero, pero para todo lo demás puedes usar almacenamientos distribuidos.
posible duplicado de [¿Cuáles son las ventajas de utilizar una única base de datos para CADA cliente?] (Http://stackoverflow.com/questions/13348/what-are-the-advantages-of-using-a-single- database-for-each-client) – givanse