✔ ADR-TRASVERSAL-HISTORIFICACIÓN-DE-DATOS

Estado

Partes interesadas

Tomada el

PRE-RELEASE	RELEASE	RETIRO
12 nov 2024	26 nov 2024	-

Responsable

ALBERTO FUENTES GOMEZ

Documentación Asociada

Solución Afectada

Todas las nuevas soluciones software a partir de la fecha de decisión.

El presente ADR será especializado en cada solución en base a sus características arquitectónicas especificas.

Responsable

Aprobado por

Consultados

Informados

AREA GOBIERNO TECNOLOGICO

LUIS MARTINEZ FONTIVEROS

ALBERTO FUENTES GOMEZ

AREA GOBIERNO TECNOLOGICO

DESARROLLO SOFTWARE ASISTENCIAL (NTTDATA)

DESARROLLO SOFTWARE ECONOMICO-FINANCIERO (NTTDATA)

DESARROLLO SOFTWARE RRHH-WEB (AYESA)

Asunto a Decidir

La historificación de registros en bases de datos, es decir, la gestión y almacenamiento de datos fríos (menos consultados) y calientes (más consultados o recientes), es clave para mantener un rendimiento óptimo y gestionar de forma eficiente el almacenamiento y los costes. Se analizarán las diferentes alternativas tecnológicas asentadas en la industria, y se realiza una evaluación de las mismas en base a una selección de características no funcionales claves identificadas del estandard ISO25010 adecuado a soluciones software.

Las características ISO/IEC 25010 evaluadas son las siguientes:

Es la capacidad del sistema para estar accesible y operativo para los usuarios cuando se necesite. En el contexto de historificación, la disponibilidad implica que tanto los datos calientes como los datos fríos deben estar accesibles de acuerdo con los niveles de servicio requeridos. Los datos calientes, que se consultan frecuentemente, deben estar disponibles de inmediato, mientras que los datos fríos pueden tener mayores tiempos de respuesta, siempre y cuando cumplan con las expectativas del usuario final.

Hace referencia a los tiempos de respuesta y la eficiencia temporal de las operaciones sobre los datos. En mecanismos de historificación, es fundamental optimizar el tiempo de acceso a datos calientes, asegurando tiempos de consulta rápidos. Para los datos fríos, los tiempos de respuesta pueden ser más relajados, pero es importante evitar que impacten el rendimiento general del sistema.

Es la capacidad del sistema para utilizar los recursos disponibles de manera eficiente. Esto incluye memoria, almacenamiento y capacidad de procesamiento. En la segregación de datos, la eficiencia en el uso de recursos se logra mediante el almacenamiento óptimo de datos fríos en medios de bajo costo o almacenamiento en la nube, evitando que estos datos consuman recursos en sistemas de alta disponibilidad que gestionan los datos calientes.

Es la habilidad del sistema para soportar grandes volúmenes de datos sin degradar su rendimiento. En un sistema con historificación, la capacidad implica asegurar que tanto los datos fríos como los calientes puedan ser gestionados en volúmenes crecientes, con una arquitectura que soporte la escalabilidad y expansión de las bases de datos sin comprometer el rendimiento.

La capacidad del sistema para continuar funcionando ante fallos. En la historificación, se requiere un diseño que garantice que, ante la pérdida o corrupción de datos fríos o calientes, el sistema mantenga su operatividad. Esto puede incluir replicación de datos, almacenamiento en capas, y respaldo, especialmente para los datos calientes, que tienen mayor demanda de disponibilidad.

La capacidad del sistema para restaurarse tras un fallo. En la gestión de datos fríos y calientes, es crucial contar con un sistema de recuperación rápida y eficaz, que permita restaurar tanto los datos fríos como los calientes en caso de fallo, especialmente en entornos que requieren alta disponibilidad y cumplimiento normativo en el almacenamiento de datos históricos.

Se refiere a la precisión y consistencia de los datos almacenados. En un sistema de historificación, la integridad es crítica para evitar inconsistencias entre datos fríos y calientes. La migración entre estos dos tipos de datos debe realizarse de forma segura para que los datos no pierdan su consistencia, lo que es especialmente importante en entornos regulados.

Garantiza que los datos sean genuinos y accesibles solo para usuarios autorizados. En el contexto de historificación, esto implica que tanto los datos fríos como los calientes deben estar protegidos contra accesos no autorizados, mediante controles de autenticación que aseguren la confidencialidad y la integridad de los datos en cada una de las capas de almacenamiento.

Es la capacidad del sistema para crecer en funcionalidad y carga sin afectar su rendimiento. En la historificación, se requiere que tanto los datos fríos como calientes puedan escalar en volumen sin afectar el rendimiento del sistema, utilizando tecnologías que permitan un escalado horizontal (agregando servidores) o vertical (aumentando capacidad) según sea necesario.

Se refiere a la facilidad de sustituir un componente del sistema por otro que cumpla la misma función. En sistemas con historificación, la reemplazabilidad permite migrar datos a nuevas tecnologías de almacenamiento (por ejemplo, cambiar un almacenamiento de datos fríos a otro más económico) sin afectar las aplicaciones que los consumen, garantizando así la adaptabilidad tecnológica.

Asegura que el sistema cumple los requisitos específicos de las tareas de historificación. Esto significa que las funcionalidades de segregación, acceso, migración, y recuperación de datos fríos y calientes están adecuadamente implementadas para cumplir con los objetivos y requerimientos de negocio, permitiendo una experiencia óptima al usuario en la consulta de los datos necesarios según su frecuencia y criticidad.

Identificación de la decisión

El presente ADR será especializado en cada solución en base a sus características arquitectónicas especificas.

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 estaADR-TRASVERSAL-HISTORIFICACIÓN-DE-DATOSrí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

Se trata de un ADR trasversal que requiere una especialización específica para cada solución a historificar en base a sus características arquitectónicas.

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

El presente ADR será especializado en cada solución en base a sus características arquitectónicas especificas.

28 nov 2024 Paso a vigente. No hay aportes externos.
12 nov 2024 Emisión publica a borrador

✔ ADR-TRASVERSAL-HISTORIFICACIÓN-DE-DATOS

Estado

Partes interesadas

TAGS

Tomada el

Responsable

Documentación Asociada

Solución Afectada

Todas las nuevas soluciones software a partir de la fecha de decisión.

Responsable

Aprobado por

Consultados

Informados

AREA GOBIERNO TECNOLOGICO

Asunto a Decidir

Identificación de la decisión

Contexto