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)