Estamos construyendo una plataforma web que incorpora múltiples servicios, cada uno con sus propios datos subyacentes. Estos servicios se construyen de forma independiente siguiendo los principios de la Arquitectura Orientada a Servicios , pero realizan transacciones contra datos potencialmente relacionados. Estamos considerando si estos servicios deberían compartir una gran base de datos o si cada uno tiene su propia base de datos. (Estamos planeando usar SQL Server 2008 Enterprise en un clúster de Windows 2008).

Algunas de las ventajas de cada enfoque que ya hemos considerado incluyen:

Base de datos única

• Los datos relacionados de diferentes servicios pueden estar unidos por restricciones de clave externa
• Los extractos analíticos son más simples de escribir y más rápidos de ejecutar.
• En caso de desastre, es más fácil restaurar la plataforma a un estado consistente
• Para los datos a los que hacen referencia varios servicios, es probable que otro servicio utilice los datos almacenados en caché poco después.
• La administración y el monitoreo son más simples y económicos por adelantado

Múltiples bases de datos

• El trabajo de mantenimiento, los problemas de hardware, las infracciones de seguridad, etc., no afectan necesariamente a toda la plataforma.
• Suponiendo que cada base de datos esté en un hardware separado, la ampliación de varias máquinas produce más beneficios de rendimiento que la ampliación de una gran

Desde una perspectiva operativa, ¿es más ventajoso que cada servicio en esta plataforma obtenga su propia base de datos o que todos vayan en la misma base de datos? ¿Qué factores clave informan una respuesta a esta pregunta?

En mi opinión, el diferenciador clave de los verdaderos sistemas SOA (sobre el pseudo SOA, sistemas más ntier / distribuidos que se están volviendo ubicuos) es que no debería haber interacción cero entre servicios discretos. Cuando esto se logra, cualquier aplicación que componga de estos servicios puede y debe construirse para tolerar la falla de cualquier parte consistente. Una falla reduce la funcionalidad pero se mantiene el servicio.

En este escenario, es lógico, o necesario, separar la base de datos subyacente para cada servicio. Sin embargo, si tiene servicios que son interdependientes, hay poco (tal vez nada) que obtener de una división.

Recomiendo leer sitios como HighScalability.com que profundizan en las arquitecturas adoptadas por los sitios web que nunca fallan. Uno de mis favoritos en los últimos tiempos fue la historia del mono del caos de Netflix que se mencionó en Coding Horror .

Abordar un par de puntos en su pregunta:

En caso de desastre, es más fácil restaurar la plataforma a un estado consistente.

Esto es cierto, pero quizás debería estar pensando en cómo desacoplar mejor estos servicios para que esto deje de ser un problema. Alternativamente, existen métodos para garantizar la sincronización entre múltiples bases de datos, por ejemplo , marcas de transacción en SQL Server .

Para los datos a los que hacen referencia múltiples servicios, es probable que otro servicio utilice los datos almacenados en caché poco después.

Las soluciones de caché distribuidas (memcached et al) podrían ayudar aquí, pero estaría violando los principios de independencia del servicio. Esto sería comparable a tener dos servicios que se comunican entre sí directamente, o peor aún, tener un servicio que acceda a otro almacén de datos, sin pasar por la interfaz del servicio. Inevitablemente, los datos estarán relacionados y la plataforma de llamadas los entregará entre los servicios, las decisiones difíciles tienden a estar en torno a qué servicio poseerá qué datos. Los sitios de StackOverflow o Programmers podrían estar mejor ubicados para ayudar con los problemas de SOA más generales.

Suponiendo que cada base de datos esté en un hardware separado, la ampliación de escala produce más beneficios de rendimiento.

Ciertamente, puede ser más barato escalar en varias máquinas con especificaciones más bajas que escalar una sola máquina. Sin embargo, los costos de hardware más bajos pueden verse reducidos en el costo total de propiedad cuando se tienen en cuenta los costos blandos del esfuerzo de desarrollo adicional y la complejidad operativa.

Si esto no es SOA y solo tiene un caso en el que los servicios componentes de esta plataforma están siendo construidos por diferentes equipos / proveedores por razones logísticas, ¡quédese con una sola base de datos e ignore completamente todo lo anterior! :)