SQL Streaming

Una de las asignaturas históricamente pendientes en el modelo entidad relación (E-R) es el tratamiento de la temporalidad en las relaciones. El concepto de sucesos simultáneos simplemente no existe en el E-R porque no hay ninguna forma estándar de poner marcas de tiempo a las entidades ni de realizar operaciones que tengan en cuenta dichas marcas.

Un de las área de estudio e implementación de herramientas que deberá madurar en un futuro próximo es el tratamiento en tiempo real de caudales entrantes de datos mediante lenguages estruturados de datos, lo que empieza a conocerse como SQL Streaming.

Las técnicas de SQL Streaming son complementarias a las de OLAP, estando especialmente enfocadas al tratamiento de datos según van llegando. Una limitación de OLAP es que su funcionamiento depende en gran medida de los procesos de extracción, transformación y carga (ETL) lo cual hace que que sea adecuado para comparar datos de un trimestre con otro o de un año con el anterior pero poco apropiado para conocer datos instantáneamente debido a que los ETLs funcionan esencialmente por lotes que se ejecutan a intervalos determinados de tiempo.

Un buen ejemplo de caudal de datos puede encontrarse en el gráfico de generación de electricidad por fuentes en tiempo real que publica Red Eléctrica Española, en el cual puede apreciarse, por cierto, que el coste de generación de luz no depende del precio del petróleo, como cree mucha gente, aunque esa es otra historia totalmente diferente de la de este post…

Actualmente hay dos modelos relativamente populares de SQL Streaming, el de Oracle y el de StreamBase que pueden encontrarse analizados detalladamente en Towards a Streaming SQL Standard. La diferencia fundamental entre ambos es que en el modelo de Oracle los datos (tuplas) que llegan al sistema simultáneamente son indistinguigles desde el punto de vista temporal, mientras que en el sistema de StreamBase a los datos que llegan al sistema simultáneamente se les asigna un número arbitrario de entrada que permite establecer un orden total entre todas las tuplas.

En el análisis de los modelos de SQL Streaming yo personalmente aún echo en falta el tratamiento teórico de dos cosas fundamentales: 1ª) el agrupamiento de datos por intervalos arbitrarios de tiempo (minutos, horas, días, semanas), y 2ª) la declaración de relaciones entre entidades sujetas a temporalidad (tales productos deben tener tal y cual precio hoy y mañana solamente).

Como crítica a los sistemas de SQL Streaming, Hans Gilde dice en su blog que por debajo aún están demasiado pegados a las bases de datos relacionales como sistema de almacenamiento y cita Esper como un sistema de tratamiento de streams de POJOs no ligados a ningún SGBDR.