ADR  - 000001

Estado

Partes interesadas


TAGS


Tomada el


Responsable


Documentación Asociada


Solución Afectada

codigo-jira-proyecto


Responsable

Aprobado por

Consultados

Informados






Asunto a Decidir

Análisis de las estrategias de historificación respecto al cumplimiento de una seria de características no funcionales

Identificación de la decisión

Describe brevemente la decisión arquitectónica tomada.

Contexto

Consideraremos las siguientes estrategias de historificación:
NombreEstrategia de historificación
Particionado

Particionamiento de tablas. 

OTLP-OLAP

Bases de datos separadas (OTLP y OLAP)

tablas-hist

Tablas de historificación. 


Caché para datos históricos.

VistasM

Vistas materializadas.

SCDs

Control mediante columnas de fecha de vigencia (SCDs)

Sharding

Sharding basado en tiempo. 


Archivado automatizado con segregación de la data frente a la metadata. 


Los criterios respecto a a los que se evaluarán dichos sistemas son valorando cada uno de ellos del 1 al 5:

DisponibilidadResiliencia Adecuación funcionalComportamiento temporalUtilización de recursosCapacidadDisponibilidadTolerancia a fallosRecuperabilidadIntegridadAutenticidadEscalabilidadReemplazabilidad. 




Esta estrategia es dependiente de un motor de BBDD consiste en dividir una tabla en segmentos determinados por uno o varios campos. Al consultar información sobre la tabla y estás esta particionada por criterios relevantes para la historificación (por ejemplo: año/mes) puede realizar consultas de forma  muy eficiente al tomar solo en consideración  los datos relevantes.

  • Capaz de gestionar grandes volúmenes de información de forma eficiente
  • Las consultas pueden actuar simultáneamente sobre datos historificados como no historificados sin penalización en rendimiento
  • Si la consulta es compleja (cruza información con otras tablas y/o no se usa el criterio de particionamiento para reducir la volumetría) corremos el riesgo de una explosión en la combinatoria de los resultados, esto lleva a dos consecuencias:
    • Alto consumo de memoria en la BBDD
    • Degradación en el funcionamiento del motor de BBDD
  • La definición de adecuada de las particiones e indices es fundamental para el correcto desempeño de esta estrategia
  • Conviene prestar atención a las consultas que se lanzan sobre esta tabla para que realicen un uso correcto del sistema de particiones y aplicar técnicas de tunning en caso contrario

Esta estrategia se basa en el uso coordinado de dos recursos OLTP, un sistema que se encarga de capturar y procesar las transacciones en tiempo real (por ejemplo una BBDD tradicional) y una BBDD OLAP (a menudo un data warehouse) que se ocupa del almacenamiento histórico. Periodicamente la información se extrae del OLTP se transforma mediante ETL y se almacena en el OLAP

  • OLAP permite almacenar y analizar grandes volúmenes de información de forma rápida y eficiente
  • Hay una separación de responsabilidades entre los datos operacionales y los datos históricos
  • La consulta simultanea sobre datos operacionales e históricos no es posible  directamente, para hacerlo posible es necesario implementar un orquestador que asuma la responsabilidad de lanzar/adaptar la consulta en cada uno de los sistemas y combinar los resultados.
  • Al tener dos sistemas (tres con el orquestador) tenemos otros tantos puntos de error posibles

 Slowly Changing Dimensions o SCDs es una técnica que utiliza fechas de inicio y fin de vigencia para ir estableciendo un historial de cambios. Existen varias formas de implementar esta técnica por ejemplo separando los datos constantes (no susceptibles de cambio entre versiones) en una tabla, los datos susceptibles de cambio se meten en una tabla de versiones con una fecha de inicio y de fin de versión.  Los datos operacionales serán los que no tienen fecha fin de vigencia y los históricos aquellos que si la tienen. Las fechas de inicio y fin de vigencia están indexadas o forman parte de indices para optimizar las consultas.

  • Es sencillo de implementar ya que una vez planteado todo se gestiona mediante los dos capos de fecha
  • Es acumulable a otras estrategias. Esta técnica es lógica por lo que podemos aplicar otras técnicas en conjunción con ella por ejemplo podemos particionar además por el año de inicio de vigencia que es un dato que existirá en todo caso con lo que sumaremos las ventajas de ambas técnicas 
  • Las consultas se lanzan sobre el conjunto total de datos por lo que no hay penalización al consultar datos históricos o mezcla de datos históricos y operacionales
  • Por sí misma esta técnica no nos aporta ninguna optimización extra a la de los índices
  • Que las consultas realicen un uso adecuado de los índices puede ser algo desafiante especialmente cuando se quieren mezclar datos operacionales y no operacionales (pensemos por ejemplo en una consulta sql sobre una BBDD Relacional donde un " fini<=FECHA and ffin>FECHA" tomará el indice correctamente pero si añadimos los datos operacionales " or (fini<=FECHA and ffin is null)" No hará uso del índice)

Esta técnica consiste en precalcular y guardar el resultado de una consulta en tabla separada, pero accesible desde el motor de la BBDD. Como tal no trata la historificación sino que ayuda a resolver el problema de consultas de alto coste sobre datos históricos ya que esos datos se consultan y extraen a la vista materializada de forma programada en tiempos de menos carga de la BBDD.

Una vez que hemos dado el contexto previo necesario planteemos los casos donde tiene sentido aplicar una vista materializada:

Caso de AplicaciónExplicación / Ejemplo de uso
Vista Materializada de datos históricos

La vista materializada contiene los datos históricos precalculados.
Pongamos el caso en el que los datos a consultar tienen un alto coste por la combinatoria entre distintas tablas. Una solución es reducir la combinatoria separando los datos históricos de los operacionales, con esto los datos operacionales se obtienen en un tiempo razonable ,pero los datos históricos continuarán teniendo un alto coste. Para solucionar el alto coste de los datos históricos creamos una vista materializada de estos datos ya calculados con lo que podremos resolver la consulta global como la combinación de los datos operacionales mas los datos de la vista materializada (por supuesto aplicando los filtros posteriores necesarios)

Vista Materializada global

Similar al caso anterior pero no tratamos los datos históricos sino todos los datos. para que no perdamos integridad en la información la cantidad de cambios entre la creación de la vista y su refresco debe ser asumible

Hay tantos casos de aplicación como queramos imaginar , pero todos tiene unas características comunes:

  • Hay que asumir que la Vista Materializada permanecerá estática entre refrescos (y estos no van a ser ni deben ser continuos, una vez cada 24h es razonable como mínimo)
  • El objetivo de la vista materializada es apartarnos del coste en tiempo, recursos y la complejidad de las consultas que la forman
  • No es una técnica de historificación pero simplifica y permite hacer mas eficientes técnicas de historificación que no lo serían por sí solas; razón por la que resulta interesante tener en cuenta esta técnica.

Esta técnica recuerda en ciertos aspectos al particionado de tabla. Consiste en la división de los datos en periodos de tiempo (Shards). Cada shard almacena un periodo de tiempo, esto permite que las consultas acudan sólo a los shards relevantes. Cada shard puede residir en un servidor diferente lo que permite no solo almacenar grandes volúmenes de datos sino que también podremos tratar cada shard independientemente

  • Puede gestionar de forma eficiente grandes volúmenes de información
  • La consulta sobre datos historificados y operacionales no tiene penalización alguna dado que cada shard operará en paralelo
  • Es necesario algún sistema de BBDD que tenga soporte para esta técnica, por ejemplo: Cassandra, Mysql, Mongo, Elastishearch...
  • La indisponibilidad del sistema responsable de la coordinación se shards causa la indisponibilidad de todo el sistema (en el caso de Cassandra el uso de algoritmos de consenso hacen aumentar su resiliencia)
  • La indisponibilidad de alguno de los shards hace su información  inaccesible (en el caso de Cassandra el uso de algoritmos de consenso para replica de datos hacen aumentar su resiliencia)



Especifica la opción elegida y explica las razones detrás de esa elección.
Detalla las implicaciones de la decisión tomada, tanto positivas como negativas, y cómo afectará al sistema a nivel arquitectónico.
Actualiza el estado actual de la decisión y si ha habido algún cambio o evolución.