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)


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.