Menú principal de Patrones de diseño en la nube
Patrones de diseño en la nube – Arquitectura de datos
La arquitectura de los datos es un punto clave en el diseño en la nube.
Existen varios patrones para utilizar ya que existe una amplia gama de situaciones en donde los datos están involucrados, como la distribución de datos, la localización de los mismos, sincronización, consistencia, mantenimiento, etc.
Para lograrlo existen los siguientes patrones:
Cache de datos independiente (Cache Aside Pattern)
Es un elemento fundamental para optimizar el acceso a datos. Mucha información común y repetida puede ser consultada por miles de usuarios (o también disgregada que es necesario unificar), con lo cual es importante poder tener esa información lo más rápido procesada y disponible. Un cache de datos independiente permite almacenar esta información y cuando consultamos la misma información el cache nos retorna la información ya procesada previamente de cuando se almaceno en cache.
En alguna ocasión cuando no existían las aplicaciones en la nube implemente un sistema/servicio de cache a memoria y disco en donde a través de una serie de key/values almacenaba la información y la recuperaba, el mecanismo va alineado a este patrón, el circuito era el siguiente: el usuario hacia un request a un servicio web, el servicio como primer instancia generaba una key con datos del request (era la info de consulta) y con esa key verificaba en la instancia de memoria si existía la información (eso implicaba que en esta instancia aplicación/proceso de los servicios no había sido consultada), si no estaba se consultaba en el cache de disco, si tampoco estaba se la guardaba en ambos cache y si existía en disco se levantaba en memoria. Una vez en memoria en la próxima consulta repetida, se retornaba esa información. Cuando la info era cambiada, también se verificaba en cache que existan instancias relacionadas a esos datos y se actualizaba y rompía la info de cache.
Para la solución que queriamos implementar era valida la instancia de memoria, pero normalmente con la instancia de datos en disco es suficiente (esta info en disco podría ser utilizada en servicios y componentes de cache o implementar bases custom de datos como JSON en bases de datos documentales o XML en un disco por dar un ejemplo). En lo que hace a la nube, la realidad es que se utilizan componentes de cache que internamente administran y procesan la información.
Es importante considerar los tiempos de la info en cache o los tiempos de actualización, limites de datos, si inicializamos el cache, si se usa también la memoria, etc.
(Proximamente capítulo dedicado a este patrón)
Patrón de Segregación de responsabilidad de comando y consulta (CQRS Pattern)
Este patrón es utilizado para segregar la responsabilidad de operar con los datos y no centralizarla, ya que no permite que se escale ni que se evolucione.
En muchas aplicaciones es acceso a datos es el mismo y a una sola base de datos.
Este patrón permite separar información en repositorios (respositories), unidades de trabajo (unitofwok) y separar el dominio de datos de la aplicación de los datos, además de tener bases de datos disgregadas. La separación de comandos y consultas dentro de la aplicación permite no cruzar problemas de dominio entre la actualización de datos y su consulta. Es común que este patrón también se utilice con el de «Suministro de Eventos» utilizado para sincronizar los datos. Los distintos patrones que se pueden utilizar los dejo para otro post.
(Proximamente capítulo dedicado a este patrón)
Patrón de Suministro de Eventos (Event Sourcing Pattern)
Normalmente lo que ocurría hasta ahora en aplicaciones CRUD era que uno obtenía datos de la base llevandolas a un dominio de la aplicación, las modificaba y luego llevaba ese estado del objeto del dominio a la base de datos. Con este patrón la idea es diseñar un mecanismo donde se almacén eventos ordenados en una secuencia que ocasionan ese cambio de información. Con lo cual tenemos una serie de eventos que nos permite luego ser consultada para ver que información tenemos. En otro post explicare mucho más en detalle este patrón.
(Proximamente capítulo dedicado a este patrón)
Patrón de indexación de tabla (Index Table Pattern)
La idea de este patrón es indexar la información utilizando tablas con índices que permiten identificar distintos grupos de información. Al identificar la información con algún código de identificación se puede consultar información rápidamente con el índice de información. Este patrón también amerita otro post para poder explicar en profundidad y no llegar a confusiones.
(Proximamente capítulo dedicado a este patrón)
Patrón de vista materializada (Materialized View Pattern)
Este patrón es similar a la generación de vista preprocesadas. La idea es poder generar vista de datos o almacenar datos en el formato esperado de salida o con la información consolidad de datos disgregados. Por ejemplo, en una base de datos relacional nosotros tenemos distintas tablas donde realizamos intersecciones para consolidar información. Con este patrón, podríamos tener un almacenamiento de datos en formato JSON con información consolidada de datos de distintos repositorios.
Al consultar la información ya tenemos la información consolidada.
(Proximamente capítulo dedicado a este patrón)
Patrón de fragmentación (Sharding Pattern)
Este patrón es utilizado para fragmentar la información en conceptos de información más pequeña. Supongamos que tenemos una base de datos con información de ventas a nivel mundial con gran volumen de información. Si quisiésemos operar almacenando ventas, consultándola para informes, aplicando cambios o realizando consultas simples, al querer escalar en el diseño nos encontraríamos con muchos problemas. Hacer un cambio en la tabla de clientes podría afectar a todo. En cambio, si separamos las entidades por ejemplo en bases de datos distintas, cada información podría seguir escalando sin afectar. En casos puros donde se utiliza de esta forma descripta desde una aplicación, la aplicación es la encargada de consultar las fuentes que necesita y unificar la información, aunque existen otros mecanismos como utilizar en conjunto con otros patrones aquí explicados.
(Proximamente capítulo dedicado a este patrón)
Patrón de alojamiento de contenido estático (Static Hosting Pattern)
Cuando utilizamos contenido estático como imágenes u otros tipos de archivos, es una buena solución para utilizar en la nube un repositorio o contenedor de contenidos aislado a la aplicación y los datos. Esto permite aislar su actualización y los recursos utilizados para obtenerlos. Por ejemplo, suele ocurrir que en aplicaciones web se utilizan carpetas para esto o se almacenan en base de datos, con lo cual incide en los tiempos y recursos de la aplicación o de la base de datos, aislándolo lo evitamos.
(Proximamente capítulo dedicado a este patrón)
Patrón de llave valet (Valet Key Pattern)
Este patrón es utilizado para utilizar un token que garantice que quien accede a la información esta autenticado para hacerlo. Si cada vez que accedemos a data distribuida en la nube tenemos que hacer un mecanismo de logueo o autenticación perdemos tiempo y recursos. La idea de generar un token, es realizar la autenticación una sola vez y utilizar ese token cada vez que el mismo cliente quiere acceder a la información.
(Proximamente capítulo dedicado a este patrón)
Todos estos patrones pueden ser combinados para utilizarse según la necesidad.
Menú principal de Patrones de diseño en la nube
|
|
|
|
|
|
|
|
|
|
|
|
Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License
|
|
This content is property of Matias Creimerman Any misuse of this material will be punishable This work is licensed under a International Copyright Law protects «original works of authorship» including photographs, videos, and blog posts posted on social media sites The content has no rights to be shared without authorization or citation to the author. This content cannot be sold be adapted or modified partially or totally. All content shared outside this blog that doesn’t belong to the author must have citations to the author. |
Desarrollo y Arquitectura de Software por Matías Creimerman 
3 comentarios en “Patrones de diseño en la nube – Arquitectura de datos”