Diseño de bases de datos SaaS: ¿múltiples bases de datos?¿Dividir?

Question

He visto aplicaciones SaaS alojadas de muchas formas diferentes.¿Es una buena idea dividir funciones y módulos en varias bases de datos?Por ejemplo, ¿poner cosas como la tabla Usuario en una base de datos y tablas específicas de funciones/aplicaciones en otra base de datos y quizás otras tablas comúnmente compartidas en otra base de datos?

Answer 1

Comience con una base de datos.Dividir datos/funcionalidad cuando el proyecto lo requiera.

Esto es lo que podemos aprender de LinkedIn:

• Una sola base de datos no funciona
• La integridad referencial no será posible
• Cualquier pérdida de datos es un problema.
• El almacenamiento en caché es bueno incluso cuando es modestamente efectivo
• Nunca subestimes la trayectoria de crecimiento

Fuente:

Arquitectura de LinkedIn

Arquitectura de comunicación de LinkedIn

Answer 2

Alta escalabilidad es un buen blog para escalar aplicaciones SaaS.Como se mencionó, dividir tablas entre bases de datos como sugirió generalmente es una mala idea.Pero un concepto similar es el de fragmentación, en el que 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 utilice su aplicación, puede ser una forma eficaz de escalar.

Answer 3

Para las aplicaciones SaaS, se utilizan varias bases de datos para varios inquilinos, pero normalmente no se dividen por 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 agregue a su aplicación.

Answer 4

Tener una única base de datos es mejor para la integridad de los datos porque entonces puedes usar claves externas.No puede tener esta integridad de datos incorporada si divide los datos en varias bases de datos.Esto no es un problema si sus datos no están relacionados, pero si están relacionados, sería posible que su base de datos contenga datos que no sean consistentes con otra base de datos.En este caso, necesitará escribir algún código que escanee sus bases de datos en busca de datos inconsistentes de forma regular para poder manejarlos adecuadamente.

Sin embargo, es posible que se necesiten varias bases de datos si necesita que su sitio/aplicación sea altamente escalable (p. ej.escala de internet).Por ejemplo, podría alojar cada base de datos en un servidor físico diferente.

Answer 5

Es posible que dividir la base de datos por características no sea una buena idea a menos que vea pruebas sólidas que sugieran la necesidad.A menudo, es posible que necesite actualizar dos bases de datos como parte de una sola transacción, y es mucho más difícil trabajar con transacciones distribuidas.Además, si es necesario dividir la base de datos, es posible que pueda emplear fragmentación.

Answer 6

Hay diversas formas de lograrlo, pero los problemas del arrendamiento múltiple van más allá del simple modelo de datos.Odio estar promocionando el producto, pero mira SaaSGrid por mi empresa en la que trabajo, apprendaSomos un sistema operativo en la nube que le permite escribir aplicaciones SOA de un solo inquilino (no dude en usar NHibernate para acceder a los datos) que inyecta automáticamente múltiples inquilinos en su aplicación.Cuando publica 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 solo inquilino!

Answer 7

¿Por qué utilizar la base de datos?

Creo que es una buena idea utilizar sistemas de almacenamiento distribuido como Hadoop, Voldemort (project-voldemort.com desarrollado y utilizado por LinkedIn).

Creo que db es bueno para datos sensibles como operaciones monetarias, pero para todo lo demás puedes usar almacenamientos distribuidos.

Answer 8

Pregúntese:¿Qué se gana moviendo todo a bases de datos separadas?

Supongo que habrá mucho dolor en términos de gestión.Personalmente, estaría más interesado en tener todo en una sola base de datos y, si tiene problemas que no pueden resolverse con una sola base de datos más adelante, migre los datos a varias bases de datos.

Answer 9

Mantenga un diseño natural (desnormalice tanto como sea necesario, normalice menos según sea necesario).Divida el modelo de base de datos en sus módulos y tenga en cuenta los principios orientados a servicios al confrontar los datos con un servicio (que posee los datos).