Steve Swartz, Architect
Clemens Vaster, Program Managaer
Connected System Division
Cuando se habla de Arquitectura de datos, los arquitectos junior quieren un libro de cocina. Esto por definición es un error.
Las aplicaciones tradicionales no necesitan arquitectura de datos, si las nuevas distribuidas. Shared Data es el tema. Con esto ocurre que los datos dejan de ser de la aplicación y pasan a ser compartidos.
En este punto comienza la colaboración y llegan los nuevos desafíos para la arquitectura de datos.
Existen diferentes tipos de bases de datos.
Reference Database, en este modelo toda la organización la usa. La mayoria de los sistemas lee desde estas bases, pero solo algunas escriben, por eso es una base de referencia. Tiene problema de latencia de los cambios de datos.
Fresh Data, en estas bases todo el mundo quiere leer los datos actualizados. Por ejemplo precios o valores de la bolsa. Aquí el punto principal es que los datos DEBEN estar actualizados, esto es un problema para los arquitectos porque es muy caro lograrlo.
Stale Data, Cada aplicación tiene sus datos y de manera Batch los lleva a una base central. Esto es un problema del mundo real, pasa todo el tiempo. Los desafíos en esto son el manejo concurrente de los datos y la sincronización. El estado de los datos es una “creación” de lo que la arquitectura de datos defina.
Huge Data, las aplicaciones para estas bases de datos deben pensar que cada registro es una base de datos :O, esto porque estas bases están en muchos Server y cada registro puede estar en cualquier parte.
Distributed Database, aplicaciones con muchas bases diferentes. Por ejemplo si quieres leer una entidad de diferentes bases debes hacer un pool de los datos y agregar la entidad.
Patrones acceso a Datos
Ø Access Direct
Ø Access Remote
Ø Access Intermediated: un patrón muy poderoso. Tiene una capa de soporte a aplicaciones que puede tener mucha flexibilidad y control del acceso a los datos.
Patrones de manejo de errores
Ø Error ACID: relativamente facil implementar aplicaciones así. Pero es terriblemente costoso por los bloqueos de los recursos.
Ø Error Accountig: La capa intermedia de acceso a los datos, si hay un error lo manda a un LOG. Esto hace que sea extremadamente rápido y sin bloqueos
Ø Errors Compensation: acciones de modificación y corrección de los datos. Ambos son código hecho específicamente. Esto es el mejor patrón para aplicaciones distribuidas.
Los tres patrones Error son para enfrentar las posibilidades de conflictos en bases de datos.
Patrón de distribución de datos
Ø Distribution Caching: acceso rápido, para aplicaciones.
Ø Distribution Federation: cuando se tienen varias bases, una base “concentra” los datos de las otras para mostrarla a la aplicación. Esta composición es una agregación lógica. Los problemas de concurrencia son controlados por esta base de datos. Típicamente con compensaciones. Esto no es fácil, cuando las bases son de solo lectura es trivial. Biztalk es un buen implementador de esto, porque con una orquestación puede coordinar los cambios en todas las bases.
Ø Distribution R/O Replication: replicación de datos hacia las aplicaciones. Solo lectura. Reduce la latencia y las fallas en el acceso a los datos. Esto porque los datos “estan cerca” de la aplicación. La diferencia con CACHE es que en este caso el Server pasa (fuerza) los datos al cliente, mientras que en cache el cliente tiene una copia que el obtuvo.
Ø Distribution R/W Replication: lo mas difícil de lograr. Las aplicaciones tiene copias cercanas de los datos y pueden cambiar los datos de manera distribuida. Temas a tener en cuenta: se pueden caer las bases, cada cliente tiene diferentes copias de los datos activas.
Ø Distribution Reporting: Esto es una lectura del estado de los datos, desde diferentes fuentes de datos. Esto es hacer copias de solo lectura para acceso rápido.
Los escenarios.
Ø Outlook / Exchange: calendar, contacts, Drafts y Task es fresh porque es manejado por la aplicación para cada usuario.
Ø Game: estos son ambientes muy volátiles, de acceso rápido a los datos. Share Store con vistas rápidas y “parciales” de los datos.
Ø Bank Machine: Tiene un intermediado para ir a los datos, porque usted puede acceder a cualquier banco. Es una federación.
Ø Hotmail: Existe una base Índice y un montón de bases con los datos. Load Manager administra la base índice. Es una base distribuida, federada en la indexación. Cada mail (registro) es tratado como una base de datos particular, muy interesante idea. Esto es recomendable cuando se maneja mucha información para cada persona.
Ø Identity Integration: Microsoft Identity Integration Server. Es un concentrador de identidad. Existen muchas bases de datos y este Server tiene concentrado una vista única para la aplicación de todas las bases. Es una federación.
Ø Active Directory: replicación activa de bases de datos.
Takeaways
Ø Toda la data es diferente.
Ø El acceso a los datos puede ser dividido en patrones simples.
Ø La arquitectura de datos correcta es al final la optimización del desempeño.
..:: Liarjo of Locksley ::.. 