Sistema de gestión de flujo de datos
Un sistema de gestión de flujo de datos (DSMS) es un sistema de software para gestionar flujos de datos continuos . Es comparable a un sistema de gestión de bases de datos (DBMS) que se utiliza para bases de datos. A diferencia de un DBMS, en el que las consultas de datos estáticos se realizan brevemente, un DSMS debe poder realizar consultas continuas de flujos de datos. Se pueden utilizar lenguajes de consulta especiales , como Continuous Query Language (CQL), para formular consultas .
Los sistemas de gestión de flujo de datos son todavía relativamente nuevos en el mundo de las bases de datos. Algunos desarrollos iniciales de propósito general son:
- Stanford Stream Data Manager (STREAM) en la Universidad de Stanford
- Aurora en Brandeis University , Brown University y MIT
- TelegraphCQ en Berkeley
- PipelineDB (como TelegraphCQ, una rama de PostgreSQL )
También hay un número creciente de proyectos más pequeños con diferentes enfoques. A diferencia de los datos que no fluyen, que se gestionan casi exclusivamente con sistemas de gestión de bases de datos universales, los sistemas que están especialmente desarrollados o adaptados para la aplicación todavía se utilizan para los datos fluidos.
Diferencias con DBMS
En los sistemas de bases de datos convencionales, las consultas a corto plazo se colocan en una base de datos que permanece igual durante la evaluación de datos (ver sistema de transacciones ). Las consultas se inician y permanecen en el sistema hasta que se hayan calculado y generado los resultados. Después de eso, las solicitudes ya no están disponibles en el sistema. También se dice que los datos son persistentes y las solicitudes son volátiles. En un sistema de administración de flujo de datos, las solicitudes se instalan una vez y permanecen en el sistema hasta que se eliminan explícitamente nuevamente. Las consultas se evalúan sobre la base de datos en constante cambio, es decir, en flujos de datos. Los resultados de las consultas también se actualizan continuamente, por lo que ellos mismos también dan como resultado un flujo de datos. También se dice que las solicitudes son persistentes y los datos son volátiles. Estos dos principios complementarios también se conocen, por ejemplo, en la recuperación de información como solicitudes ad hoc (nuevas solicitudes para los mismos documentos) y tareas de enrutamiento (nuevos documentos para solicitudes específicas).
La siguiente tabla compara las diversas características de un sistema de gestión de bases de datos (DBMS) y un sistema de gestión de flujo de datos (DSMS):
| Sistema de gestión de bases de datos (DBMS) | Sistema de gestión de flujo de datos (DSMS) |
|---|---|
| Datos persistentes (relaciones) | Flujos de datos volátiles |
| Acceso aleatorio | Acceso secuencial |
| Solicitudes únicas | Consultas continuas |
| (Teóricamente) almacenamiento secundario ilimitado | Memoria principal limitada |
| Solo el estado actual es relevante | Consideración del pedido entrante |
| tasa de actualización relativamente baja | posiblemente una tasa de actualización extremadamente alta |
| poco o ningún requisito de tiempo | Requisitos en tiempo real |
| Se asumen fechas exactas | Datos desactualizados / inexactos |
| Procesamiento de consultas planificables | Llegada de datos variables y características |
Conceptos básicos
Como ya se puede ver en la tabla anterior, un DSMS tiene algunos conceptos básicos que se diferencian de un DBMS convencional. Los conceptos más importantes son las consultas continuas y las ventanas.
Consultas continuas
Una solicitud continua se instala una vez en el sistema y se ejecuta hasta que se elimina nuevamente. La solicitud tiene uno o más flujos de datos de entrada y uno o más flujos de datos de salida. Por lo tanto, el resultado de tal solicitud no es un conjunto de datos único, como es el caso de una solicitud en un DBMS, sino un flujo de datos en sí. Los resultados deben crearse casi en tiempo real, lo que significa que la latencia entre la llegada de nuevos datos y la salida de un nuevo resultado es muy relevante.
En el caso de una solicitud continua, es importante definir cuándo se producirá una nueva edición. Un modelo impulsado por el tiempo genera nuevos resultados basados en el progreso de un reloj a lo largo del tiempo, por ejemplo, la hora del sistema. Se podría generar un nuevo problema una vez por minuto. Otro enfoque son los modelos impulsados por eventos (Engl. Modelo impulsado por eventos ) en los que se producen nuevas ediciones cuando ocurren ciertos eventos en el flujo de datos. También podría z. Por ejemplo, cada nuevo elemento de datos en un flujo generará una nueva salida, ya que este elemento del flujo de datos puede influir en el resultado para este momento. Entonces se habla de un modelo impulsado por tuplas .
ventana
Los flujos de datos son potencialmente infinitos, por lo que generan una cantidad de datos potencialmente infinita. Sin embargo, solo hay una cantidad limitada de memoria disponible durante el procesamiento de solicitudes continuas, lo que ocurre principalmente en la memoria principal. Windows es una forma de limitar la cantidad de datos que deben mantenerse en la memoria. Otra motivación para usar Windows es el uso de consultas continuas. Estos deberían proporcionar resultados para los datos actuales que fluyen hacia el DSMS con el flujo de datos. Por lo tanto, solo los datos actuales son a menudo relevantes, mientras que los datos más antiguos ya no son necesarios para los resultados actuales. Para poder expresar una limitación de la validez de los elementos de datos, se utilizan ventanas.
Windows limita la vista del flujo de datos a los elementos más nuevos del flujo. Las ventanas basadas en tiempo y en elementos (también: basadas en tuplas) están muy extendidas. En las ventanas basadas en el tiempo, los elementos del flujo de datos se mantienen en el sistema durante un tiempo predeterminado determinado, por ejemplo, 30 minutos. En una ventana basada en elementos, la ventana contiene un máximo de un número predeterminado de elementos, por ejemplo, los 1000 elementos más recientes. Un ejemplo de una consulta con una ventana basada en el tiempo es: "Calcule el promedio del atributo 'x' de todos los elementos del flujo de datos durante los últimos 30 minutos".
Las ventanas de elementos y de tiempo se pueden definir de manera diferente. Aquí se encuentra principalmente entre ventanas distinguidas que se deslizan (engl. Sliding ) y que dan vueltas o rebotan (engl. Tumbling ). La diferencia es el tamaño del paso de la ventana, también llamado periodicidad. Una ventana deslizante avanza con el progreso del flujo de datos de tal manera que el tamaño del paso es mínimo. En una ventana basada en elementos, se eliminaría exactamente un elemento para un nuevo elemento que se agrega a la ventana. El tamaño de paso se puede cambiar la medida de lo que es el tamaño de la ventana, esto se llama a continuación, una ventana de saltos (Engl. Ventana de saltos ). Aquí una ventana se llena hasta el tamaño especificado. Cuando llega el siguiente elemento, que excedería el tamaño especificado de la ventana, todos los elementos anteriores se vuelven inválidos al mismo tiempo, y la nueva ventana se construye paso a paso hasta que vuelve a alcanzar el tamaño máximo. Esto se hace de forma análoga en las ventanas basadas en tiempo. Por ejemplo, una ventana oscilante sería una ventana de 30 minutos con un incremento de 30 minutos.
Paradigma de una pasada
Los recursos en términos de tiempo de cómputo y espacio de almacenamiento para calcular los resultados de los flujos de datos son limitados. Por lo tanto, los algoritmos que procesan flujos de datos no suelen guardar primero los datos por completo y luego iterar sobre todo el conjunto de datos para generar resultados, sino que procesan cada elemento individual en el flujo de datos solo una vez. Esto se denomina paradigma de un solo paso: un elemento de datos solo pasa por un algoritmo una vez. Si un nuevo elemento llega al algoritmo, el resultado del cálculo se adapta y no es necesario un nuevo acceso al elemento en un momento posterior. Por lo tanto, el algoritmo no tiene que guardar ningún elemento antiguo, solo el resultado intermedio actual.
Esto funciona para un contador simple, por ejemplo. Se debe contar el número de objetos. Si llega un nuevo elemento al algoritmo, el contador se incrementa en uno, se guarda y el elemento se puede eliminar. Solo es necesario guardar la lectura actual del medidor.
Procesamiento de flujos y relaciones
Mientras que los datos se gestionan en tablas ( relaciones ) en los sistemas de bases de datos convencionales (relacionales) , los flujos de datos se agregan como objetos de datos básicos en un DSMS. Los flujos de datos pueden entenderse como una secuencia continua de pares tiempo-valor. Dado que los flujos de datos son en principio infinitos, deben convertirse en relaciones mientras tanto para su procesamiento. Por el contrario, las relaciones se pueden volver a convertir en flujos de datos (ver figura). El procesamiento de relaciones puras puede tener lugar con métodos convencionales. La conversión de corrientes en otras corrientes se produce mediante el desvío de relaciones. El Continuous Query Language , que se basa en SQL , ofrece varios operadores para este propósito.
Formulación, planificación y optimización de consultas
Al igual que en los sistemas de bases de datos convencionales, las consultas se formulan en un lenguaje declarativo y se optimizan para su ejecución con la ayuda de un plan de consultas. Dado que se deben procesar tantas consultas como sea posible al mismo tiempo, las consultas almacenadas se combinan de la manera más inteligente posible para que las consultas parciales se puedan utilizar varias veces.
Los componentes de un plan son operadores, colas y estados. Los operadores corresponden a los operadores conocidos de las bases de datos convencionales como filtrado, ordenamiento, unión, operadores matemáticos, etc. así como la entrada y salida de flujos de datos. Los operadores individuales de un plan están vinculados por colas en las que los objetos de datos se escriben secuencialmente y el siguiente operador los lee en el mismo orden. Como resultados intermedios, hay estados como el contenido de una ventana específica.
ejemplo
Un portal de noticias quisiera mostrar las últimas noticias sobre los temas más discutidos actualmente, así como el volumen de noticias de un día en su página. Los mensajes llegan en un flujo de datos y los temas actualmente importantes en otro flujo de datos como " zeitgeist ". Cada mensaje se asigna a un tema. Específicamente, se deben mostrar los títulos de los mensajes de la última hora sobre los últimos 10 temas, así como el número de todos los mensajes relacionados dentro de las últimas 24 horas. Formulado en CQL, estas son dos consultas:
Q1: SELECT Titel FROM Nachrichten N [Range 1 HOUR], Zeitgeist Z [RANGE 10] WHERE N.Thema = Z.Thema
Q2: SELECT COUNT(*) FROM Nachrichten N [RANGE 1 DAY], Zeitgeist Z [RANGE 10]
WHERE N.Thema = Z.Thema
El DSMS ahora usa estas consultas para crear un plan que sea lo más eficiente posible, que podría parecerse al que se muestra en la siguiente ilustración, por ejemplo. Los títulos y temas de los mensajes se proyectan primero y se colocan en una cola. Los temas se colocan primero en una cola y desde allí en una ventana de longitud 10. Los mensajes y las ventanas están vinculados por un operador JOIN y llegan a una ventana que contiene todos los mensajes de un día. El resultado de la consulta Q2 se determina a partir de esta ventana utilizando el operador COUNT. Para la consulta Q1, la ventana más grande va seguida de una ventana más pequeña con una duración de una hora.
literatura
- Brian Babcock, Shivnath Babu, Mayur Data, Rajeev Motwani, Jennifer Widom. Modelos y problemas en los sistemas de flujo de datos . En: Actas del 21 ° Simposio de ACM sobre principios de sistemas de bases de datos (PODS 2002)
- Don Carney, Ugur Centintemel, Mitch Cherniack, et al.: Monitoreo de flujos: una nueva clase de aplicaciones de administración de datos (PDF; 685 kB) . (VLDB 2002)
- Sandra Geisler: Sistemas de gestión de flujo de datos . Seguimiento de Dagstuhl. Vol. 5. Centro de Ciencias de la Computación Schloss Dagstuhl-Leibniz, 2013.
- Rajeev Motwani, Jennifer Widom, Arvind Arasu, Brian Babcock, Shivnath Babu, Mayur Datar, Gurmeet Manku, Chris Olston, Justin Rosenstein y Rohit Varma: procesamiento de consultas, gestión de recursos y aproximación en un sistema de gestión de flujo de datos . Stanford, 2002 (CIDR 2003)
- Golab L., Ozsu MT Issues in data stream management , ACM SIGMOD Record Volume 32, número 2, págs. 5-14, junio de 2003.
- Michael Cammert, Christoph Heinz, Jürgen Krämer, Bernhard Seeger: Procesamiento de solicitudes en flujos de datos . Espectro de base de datos 11: 5-13, (2004).
- Jürgen Krämer: Consultas continuas sobre flujos de datos: semántica e implementación . Disertación, Philipps University Marburg, (2007).
- Jürgen Krämer, Bernhard Seeger: Semántica e implementación de consultas continuas de ventana deslizante sobre flujos de datos . (ACM TODS 2009).
enlaces web
- STREAM , página de inicio del equipo de Stream
- AURORA , StreamBase Systems, Inc.
- TelegraphCQ
- NigaraST ( Memento del 13 de octubre de 2007 en el Archivo de Internet )
- QStream
- TUBERÍAS , Analizador RTM
- StreamGlobe
- Odiseo
- PipelineDB
- RethinkDB
Evidencia individual
- ↑ Datos - Preguntas de exámenes de inglés (temas) Lista de archivos ( inglés ) Instituto Nacional de Estándares y Tecnología. Consultado el 14 de febrero de 2019.
- ↑ a b c d e Sandra Geisler: Sistemas de gestión de flujo de datos . En: Phokion G. Kolaitis y Maurizio Lenzerini y Nicole Schweikardt (Eds.): Seguimiento de Dagstuhl . cinta 5 . Schloss Dagstuhl - Centro Leibniz de Ciencias de la Computación, Dagstuhl, Alemania 2013, ISBN 978-3-939897-61-3 , p. 275-304 , doi : 10.4230 / DFU.Vol5.10452.275 ( dagstuhl.de ).