El software como servicio (SaaS), definido como software que se alquila en lugar de comprarlo, es ideal para aplicaciones en la nube. En el modelo SaaS, el software está alojado en centros de datos, y los suscriptores acceden al software utilizando sus navegadores web y / o aplicaciones.
Las aplicaciones de SaaS han recorrido un largo camino desde principios de la década de 2000, cuando aparecieron por primera vez en la escena del desarrollo. Hoy en día, las aplicaciones SaaS se han vuelto ubicuas, y aunque todavía hay un mercado para las aplicaciones de escritorio y cliente / servidor tradicionales, en su mayor parte, las aplicaciones SaaS se han convertido en el orden del día, impulsando muchos procesos de una compañía, ya sean internos o externos.
Por su naturaleza, las aplicaciones SaaS requerirán que los datos de varios inquilinos residan en sus bases de datos. Este es el factor principal a considerar durante el diseño de la base de datos. Esto también significa que las bases de datos deben poder ampliarse y escalarse, y manejar el aumento de las cargas de trabajo. De lo contrario, el rendimiento de la aplicación puede deteriorarse y, por consiguiente, afectar la efectividad y la viabilidad de la aplicación SaaS.
Por lo tanto, se requiere un modelo de diseño apropiado para la base de datos de la aplicación que sea capaz de manejar la carga de trabajo inicial esperada. Este modelo también debe tener en cuenta la facilidad de migración frente a las crecientes cargas de trabajo a medida que la aplicación se vuelve popular y atrae a más usuarios.
Evaluando varios modelos de arquitectura
Al diseñar la base de datos para nuestra aplicación web SaaS de marketing por correo electrónico y automatización de marketing, los factores que consideramos incluyen los siguientes, no necesariamente clasificados según su importancia:
● Escalabilidad del modelo propuesto.
● El costo de implementación del diseño de la base de datos.
● La complejidad de gestionar y personalizar la base de datos.
● Aislamiento de datos, o el impacto de la carga de trabajo de un inquilino en el rendimiento general de la aplicación
Evaluamos cuatro (4) modelos de base de datos que podemos usar para nuestra aplicación SaaS en términos de estos factores.
Antes de comenzar con nuestra evaluación, es necesario un breve resumen de nuestras circunstancias en el momento en que desarrollamos la aplicación. Nuestra empresa fue arrastrada con fondos muy limitados. Tampoco teníamos un DBA a tiempo completo. Por lo tanto, una arquitectura de base de datos simple que se pudiera administrar fácilmente fue muy importante para nosotros. La arquitectura también debería ser relativamente barata de implementar.
Opción 1: Aplicación separada e Instancia de Base de datos por Inquilino
En este modelo, se instala una instancia de la aplicación para cada inquilino. Cada instancia de aplicación tiene su propia base de datos, con los datos del inquilino contenidos en esa única base de datos. Por lo tanto, cada inquilino tiene acceso exclusivo a una aplicación instalada y su base de datos correspondiente.
Dado que solo los datos de un único inquilino residen en la base de datos, este modelo facilita la extensión de la base de datos y la personalización de la aplicación según los requisitos del inquilino, si es necesario.
Además, este modelo cumple con nuestros requisitos de aislamiento de datos, ya que solo los datos de un inquilino se almacenan en la base de datos del inquilino. Las posibilidades de que una base de datos afecte las instancias de aplicación de otros inquilinos son prácticamente nulas.
Para mantener las bases de datos desde una ubicación central, se puede implementar un catálogo con ID de inquilinos mapeados a una «URI» de bases de datos. Este catálogo se puede utilizar para informes y análisis.
A pesar de sus ventajas, este modelo falla en un aspecto. Para evitar cualquier impacto adverso en el rendimiento de la base de datos en caso de mayores cargas de trabajo, existe la necesidad de asignar más recursos por instancia de base de datos. Al multiplicar eso por el número de inquilinos y el número de bases de datos, este modelo es el menos rentable, ya que los costos de hardware serán más altos. No solo eso, administrar el hardware y la base de datos también es más costoso. Si se tiene recursos administrativos limitados, esto será un problema.
Modelo 2: Aplicación Multi Inquilino con una Base de Datos por Inquilino
En este modelo, hay una (1) aplicación de múltiples inquilinos con muchas bases de datos, y cada inquilino tiene su propia base de datos independiente.
Dado que hay una (1) instancia de aplicación en este caso, con múltiples inquilinos que tienen acceso a la aplicación, hay dos formas de escalar la aplicación, en caso de un aumento de las cargas de trabajo. El primer método requiere más recursos por nodo; El segundo agrega más nodos a la aplicación. La escala de las bases de datos es un proceso independiente: si se supone que la base de datos está preparada para manejar las cargas de trabajo iniciales y futuras esperadas, y que cada instancia de la base de datos se ha optimizado desde el principio, es posible que no sea necesario ampliar la base de datos.
Dado que este modelo básicamente proporciona una única base de datos por arrendatario, al igual que en el modelo anterior, el aislamiento de los datos es un hecho. Esto significa que la personalización se puede hacer fácilmente, ya que los cambios en una sola base de datos no afectan a las otras bases de datos.
Nota: Si está considerando Microsoft Azure para alojar su aplicación web, una ventaja de tener una aplicación multi-tenant con muchas bases de datos es que usted puede utilizar SQL Database elastic pools, una solución simple y rentable para escalar sus múltiples bases de datos single-tenant.
Sin embargo, al igual que en el modelo anterior, este diseño adolece del hecho de que su implementación cuesta más, ya que los datos del inquilino se almacenan en bases de datos separadas.
Modelo 3: Aplicación Multi Inquilino con Base de datos Multi Inquilino
Este modelo es similar al anterior en el sentido de que solo hay una aplicación para todos los inquilinos. Sin embargo, en lugar de tener una sola base de datos por inquilino, agrupa todos los datos del inquilino en una sola base de datos.
Este es el más simple de todos los modelos incluidos en nuestra evaluación. Dado que todos los datos del inquilino residen en una sola base de datos, eso significa que solo hay una base de datos para administrar. ¿Esto se traduce en una gestión más sencilla en comparación con los otros modelos propuestos? Sí, al menos al principio, cuando el número de inquilinos todavía es manejable. Sin embargo, a medida que más inquilinos se agregan a la base de datos, la administración de esa única base de datos puede volverse difícil de manejar. La realidad de que las operaciones de gestión pueden afectar el rendimiento también es muy real.
Otro punto en contra de usar este modelo es el hecho de que sacrifica el aislamiento de los datos. Tener múltiples inquilinos en una sola base de datos seguramente afectará el rendimiento, ya que es imposible aislar el trabajo realizado en una base de datos para que no afecte el trabajo que se realiza en las otras bases de datos.
Para escalar la base de datos, se pueden agregar más recursos de almacenamiento y cómputo. Sin embargo, hay un límite para ese número. Una vez que se alcanza ese límite, se produce una degradación del rendimiento.
Modelo 4: Aplicación Multi Inquilino con Base de datos Multi Inquilino Fragmentada
Este modelo combina una aplicación multiusuario única con bases de datos fragmentada que contienen múltiples inquilinos, con los datos de cada inquilino que residen en una base de datos fragmentada única.
De todos los modelos presentados aquí, este es el más escalable, ya que distribuye inquilinos en múltiples bases de datos. Además, con cada dato del inquilino que reside en un fragmento propio, no hay un efecto adverso en el rendimiento de la aplicación cuando se trabaja en los datos del inquilino.
Sin embargo, la fragmentación (sharding) hace que el diseño y la gestión de bases de datos sean más complejos. Por un lado, se necesita un catálogo para asignar los inquilinos a las bases de datos. En términos de administración, agregar y eliminar fragmentos, mover datos de inquilinos entre fragmentos, fusionar fragmentos con muy pocos inquilinos y dividir fragmentos superpoblados en dos fragmentos con un número menor de inquilinos no son procesos triviales.
Sin embargo, la administración se puede hacer más fácil con el uso de herramientas adecuadas. Además, dado que esta arquitectura da como resultado bases de datos más pequeñas, ya que distribuye los datos de los inquilinos en varias bases de datos, los problemas con la capacidad de administración se alivian un poco.
Seleccionando el modelo de base de datos para nuestra aplicación
Sobre la base de la evaluación presentada en la sección anterior, llegamos a la pregunta: ¿Cuál es el modelo arquitectónico ideal para nuestra nueva aplicación web Saas?
La tabla 1 a continuación resume nuestros modelos y sus calificaciones correspondientes en base a los cuatro (4) factores que mencionamos anteriormente en el artículo.
| Factor/Modelo | Modelo 1: Aplicación separada e Instancia de Base de datos por Inquilino | Modelo 2: Aplicación Multi Inquilino con una Base de Datos por Inquilino | Modelo 3: Aplicación Multi Inquilino con Base de datos Multi Inquilino | Modelo 4: Aplicación Multi Inquilino con Base de datos Multi Inquilino Fragmentada |
| Escalabilidad | Medio | Alto | Medio | Muy alto |
| Costo | Alto | Alto | Bajo | Medio |
| Complejidad de desarrollo y administración | Desarrollo bajo, administración medio a alto | Desarrollo bajo, administración bajo a medio | Desarrollo bajo, administración bajo a medio | Medio |
| Aislamiento de datos | Muy alto | Muy alto | Bajo | Bajo |
Los altos costos para los modelos 1 y 2 son puntos en contra de su uso. Sus calificaciones de aislamiento de datos más altas en comparación con las otras opciones no son suficientes para justificar el gasto adicional por su uso.
De los cuatro modelos, el Modelo 3, la aplicación multi-tenant con un solo modelo de base de datos multi-tenant, parece ser el más equilibrado, al menos para aquellos que buscan una complejidad y costos de desarrollo y administración bajos.
El modelo 4 es el más atractivo en términos de escalabilidad. Combine eso con el costo relativamente bajo de configurarlo, y obtendrá una opción de migración viable, si ha elegido alguna de las otras opciones previamente para su aplicación.
En nuestro caso, un modelo que fue fácil de administrar fue alto en nuestros criterios de evaluación. Otro factor que observamos de cerca fue el costo.
Al final, decidimos utilizar el Modelo 3 o una aplicación multiusuario con una única base de datos multiusuario, basando nuestra selección en bajos costos de desarrollo y complejidad. Sin embargo, también tomamos en cuenta el hecho de que el rendimiento podría verse afectado, ya que la aplicación atrae a más suscriptores. En consecuencia, anticipamos la fragmentación de la base de datos única en varias instancias de bases de datos múltiples. El diseño de nuestra base de datos también tuvo esto en cuenta.
Migración a un nuevo modelo
La aplicación multiusuario con una única arquitectura de base de datos multiusuario que adoptamos originalmente para nuestro software de email marketing y automatización de marketing resultó ser adecuada para la tarea.
A medida que ganamos más usuarios, hubo un crecimiento correspondiente en el tamaño de nuestra base de datos de aplicaciones. Cada una de nuestras tablas más grandes tiene más de un par de miles de millones de registros de transacciones. La tabla de contactos solo contenía más de 2 mil millones de registros.
A medida que la base de datos creció, hubo una degradación correspondiente en el rendimiento. Esto se había anticipado, ya que nuestra evaluación anterior consideraba el crecimiento futuro. Inicialmente, se realizaron varias acciones para abordar el problema. Por un lado, los datos de nuestras tablas más grandes se archivaron para retener solo el valor de un año en cualquier momento.
Las medidas iniciales tuvieron éxito en abordar los problemas de rendimiento. Sin embargo, la recurrencia del problema nos llevó a considerar la migración a una nueva arquitectura. Revisamos nuestra evaluación anterior para ayudarnos a encontrar una opción de migración viable.
Al final, se decidió ampliar nuestra base de datos mediante la partición / fragmentación horizontal de nuestra única base de datos de múltiples inquilinos utilizada para la automatización de marketing. Se crearon múltiples bases de datos, con datos de algunos inquilinos alojados en cada base de datos fragmentada. A la fecha, la base de datos utilizada para Email Marketing hasta permanece en una sola base de datos. Estamos mirando a fragmentar esto también en el futuro.
Conclusión
SaaS comprende la mayoría del software disponible en el mercado hoy en día. La arquitectura de la base de datos siempre es una consideración importante al diseñar aplicaciones, ya sea que estén basadas en SaaS o no. Se espera que los modelos de base de datos que se analizan en este artículo ayuden a guiar a los arquitectos del sistema mientras diseñan sus propias aplicaciones SaaS.
https://medium.com/@dk_55214/database-design-for-saas-applications-ce92278b8836
Enlace al post original en Inglés
Espacio GT 
Deja un comentario