database-design - tenancy - multi-tenant data architecture
Diseño de base de datos SaaS-¿Bases de datos múltiples? ¿División? (9)
¿Por qué usar la base de datos?
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 sensatos como las operaciones de dinero, pero para todo lo demás puedes usar almacenamientos distribuidos.
He visto aplicaciones SaaS alojadas de muchas maneras diferentes. ¿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?
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:
Dividir la base de datos por características podría 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.
Hay una variedad de formas de lograrlo, pero los problemas de multicliente van más allá del modelo de datos. Odio estar conectando producto, pero reviso SaaSGrid por mi compañía en la que trabajo, Apprenda. Somos un sistema operativo en la nube que le permite escribir aplicaciones SOA individuales (puede usar NHibernate para acceso a datos) que las 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!
Manténgalo como un diseño natural (desnormalizar tanto como sea necesario, normalizarlo como menos se requiera). 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).
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.
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.
Tener una única base de datos es lo 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 varias 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, pueden ser necesarias múltiples bases de datos si necesita que su sitio / aplicación sea altamente escalable (p. Ej., Escala de Internet). Por ejemplo, puede alojar cada base de datos en un servidor físico diferente.
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.