Antes de continuar leyendo este artículo es altamente recomendable que leas:

https://firebird21.wordpress.com/2013/04/27/aplicaciones-oltp-y-aplicaciones-olap/

Si no leíste el artículo de arriba, el actual no tendrá tanto valor.

¿Qué es una tabla agregada?

Es una tabla que no guarda datos en bruto sino datos agrupados. Por ejemplo, en una tabla agregada no se guardan los datos de cada venta realizada sino los totales (diarios/semanales/mensuales/anuales) de esas ventas

¿Para qué se usan las tablas agregadas?

Para que los usuarios puedan obtener los resultados de sus consultas muy rápidamente

¿Cómo se insertan datos a las tablas agregadas?

A través de un programa que realiza un proceso de ETL (Extraction, Transformation, Loading, o en castellano: Extracción, Transformación, Carga)

Primero, se extraen los datos. Eso normalmente implica escribir un SELECT que contiene las funciones agrupadas: COUNT(), SUM(), AVG(), MAX(), MIN()

Segundo, se realizan algunas operaciones con esos datos (si es necesario, claro)

Tercero, se insertan dichos datos en la tabla agregada, la cual se encuentra en otra Base de Datos

¿Cuál es la principal tarea de una tabla agregada?

Guardar los resultados obtenidos al consultar otra/s tabla/s pero en muchísimas menos filas, por lo tanto las consultas a la tabla agregada serán mucho más rápidas que la respectiva consulta a la/s tabla/s original/es

¿Cómo se nombra a las tablas agregadas?

Aunque no es obligatorio hacerlo así, lo normal es que empiecen con el prefijo AGG_ para que todos los programadores puedan saber que se trata de una tabla agregada. Por ejemplo: AGG_VENTAS_MENSUALES, AGG_VENTAS_POR_VENDEDOR

 ¿Se deben usar tablas agregadas para todas las tablas de una Base de Datos OLTP?

No, solamente se justifica hacer el trabajo cuando las tablas OLTP tienen cientos de miles o millones de filas. Si las tablas OLTP tienen pocos miles de filas no se justifica el esfuerzo

¿Qué importante consideración debemos tener siempre en mente?

Que para que las tablas agregadas sean útiles deben tener sus filas actualizadas con los de la tabla (o tablas) OLTP correspondientes. Cada vez que los datos de una tabla OLTP son cambiados (porque se agregaron/borraron/modificaron filas) la tabla agregada relacionada con esa tabla OLTP esta automáticamente desactualizada. Esto implica que consultando a la tabla agregada se podría obtener un resultado diferente que consultando a la tabla OLTP. Y eso muchas veces no es admisible.

¿Cuáles son las estrategias para insertar, borrar o actualizar datos en una tabla agregada?

 En la literatura sobre OLAP y Data Warehousing se nombran tres estrategias:

    • Snapshot
    • Eager
    • Lazy

En snapshot (instantánea, en castellano) los datos de la tabla agregada son totalmente borrados y luego se les insertan los nuevos datos. O sea que cada vez se agregan los datos desde cero. Implementar esta estrategia es muy simple pero tiene un gran problema: la utilización del Servidor durante el tiempo que dura la inserción de las filas será muy intensiva haciendo que el tráfico en la red se vuelva muy lento para las demás aplicaciones. Por ese motivo se lo suele realizar en los horarios en que menos usuarios están conectados a las bases de datos.

En eager (ansioso, en castellano) hay un trigger para cada operación de insert/delete/update en la tabla OLTP. Cada vez que en la tabla OLTP se realiza un delete o un update dicho trigger debe recalcular los valores que pondrá en la tabla agregada. Esto significa que no se agregarán los datos desde cero como se hace en snapshot pero implementar esta estrategia es más complicado. La ventaja de usar esta estrategia es que la tabla agregada siempre está actualizada, la desventaja es que las operaciones en la tabla OLTP son más lentas porque cada insert/delete/update en ella debe actualizar a la tabla agregada también.

En lazy (perezozo, en castellano) hay un trigger en la tabla OLTP que guarda los cambios en otra tabla, en una tabla separada. Cada una de las filas de la tabla separada tiene una columna que nos indica si ya fue procesada o aún no. Periódicamente un stored procedure lee el contenido de la tabla separada y por cada fila que aún no fue procesada realiza el eager y marca a la fila como ya procesada. Esto implica que al igual que en la estrategia eager se necesita de operaciones de escritura pero la actualización se puede realizar en un mejor momento, normalmente cuando hay pocos usuarios conectados. Esta estrategia es una mezcla de las dos anteriores: no se satura al Servidor porque nunca se procesan todas las filas de la tabla OLTP y las filas de la tabla agregada están casi, casi, actualizadas con los de la tabla OLTP.

Conclusión:

Usar tablas agregadas es muy útil para aumentar la velocidad de respuesta a las consultas. En Firebird las podemos implementar utilizando stored procedures y triggers. También podemos utilizar cualquiera de las tres estrategias (snapshot, eager, lazy) mencionadas más arriba. Por supuesto que tendremos datos redundantes pero en general no deberíamos tener problemas por eso.

 

Anuncios