ADR - 000001

Estado

Partes interesadas

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:

Nombre	Estrategia 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:

Disponibilidad

Resiliencia

Adecuación funcional

Comportamiento temporal

Utilización de recursos

Capacidad

Disponibilidad

Tolerancia a fallos

Recuperabilidad

Integridad

Autenticidad

Escalabilidad

Reemplazabilidad.

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ón

Explicació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)

La historificación habitualmente ha consistido en la extracción de la información histórica a un sistema tercero muy masivo en cuanto a capacidad, el problema que presenta esa estrategia es que el acceso y el análisis de la información historificada es muy lento en comparación al acceso a la información operacional. Esta técnica busca compensar las carencias que tenía ese enfoque.

Cuando buscamos aplicar esta técnica lo que hacemos es en una primera instancia definir lo que es información pura de lo que se consideran metadatos. Los metadatos son aquellas informaciones que nos permiten identificar un registro concreto, por ejemplo, y dado que hablamos de historificación, metadatos serían los campos de auditoria. Una vez que tenemos claro en qué consisten los metadatos pasamos a la operativa en sí:

Cuando historificamos información lo que hacemos es enviar los registros a algún sistema de almacenamiento económico y de gran capacidad guardando los metadatos en una BBDD junto a una referencia que nos permita encontrar la información de forma eficiente (por ejemplo: fichero:AAAA-MM-DD.txt offset:XXXX).

Cuando lanzamos una consulta que incluye datos historificados lo que hacemos es acudir a la BBDD de metadatos y consultar allí obteniendo la ubicación de la información requerida y pudiendo acceder a esta de forma eficiente.

La información historificada se puede almacenar en un sistema de bajo coste por lo que soportaría una enorme capacidad de almacenamiento

Son necesarias tres búsquedas: Consulta sobre datos operacionales, consulta sobre los metadatos historificados y búsqueda sobre el almacenamiento con la referencias dadas por los metadatos
De las tres búsquedas dos (metadatos y almacenamiento) deben ser obligatoriamente secuenciales
En el mejor de los casos tendremos dos puntos de error, a saber: una BBDD con los datos operacionales y los metadatos y el almacenamiento externo. En el peor de los casos los metadatos estarían en una BBDD independiente por lo que tendríamos tres puntos de fallo: BBDD Operacional, BBDD Metadatos y almacenamiento externo

Aquí se plantean opciones que se plantean como habitualmente en el caso de historificación y que merecen una consideración de sus cualidades aunque no entremos en demasiado detalle.

El objetivo es mantiene una tabla donde cada cambio implica una nueva tupla reflejando el cambio, en ese sentido se podría considerar como un changelog en BBDD. Al considerar información se auditoria asociada a la tabla podríamos considerar que contiene un historial completo de un dato pero en realidad estos campos serian propios de otras técnicas quedando esta tabla como un changelog y no un estado o una versión de estado

Event sourcing por definición registra cambios/eventos por lo tanto no es aplicable a la historificación de hecho habitualmente podemos ver Event Sourcing para tratar información operativa, tratando esta como un changelog pero al historificar deja paso a alguna de las estrategias ya comentadas (es muy habitual el esquema kafka-Mongo, es decir Event sourcing - Sharding basado en tiempo)

A pesar de que son técnicas indudablemente relacionadas con las otras planteadas aquí e incluso aportan ventajas en combinación con estas, no tratan realmente la historificación y por lo tanto no aplicarían.

La evaluación de las siguientes características dependen enormemente de las soluciones concretas que se adopten por lo tanto lo que plantea no es tanto una una valoración frente a objetivo como entre las propias estrategias

Nombre de la Estrategia	Disponibilidad	Comportamiento Temporal	Utilización de Recursos	Capacidad	Tolerancia a Fallos	Recuperabilidad	Integridad	Autenticidad	Escalabilidad	Reemplazabilidad	Idoneidad Funcional
Particionado de tabla
OLTP + OLAP
SCDs
Sharding basado en tiempo	()				()
Archivo Automatizado con Segregación de Datos y Metadatos
Materialized Views

() Hay tecnologías que proveen la máxima disponibilidad y replicación de la información con lo que maximiza tanto la disponibilidad como la tolerancia a fallos

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.

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

Identificación de la decisión

Contexto