Sistema de gestión de flujo de datos

A Sistema de gestión de flujo de datos (DSM) es un programa informático para administrar flujos de datos continuos. Es similar a un sistema de gestión de base de datos (DBMS), que es, sin embargo, diseñado para datos estáticos en bases de datos convencionales. Un DSM también ofrece un proceso de consulta flexible para que la información necesita puede expresarse mediante consultas. Sin embargo, en contraste con un DBMS, un DSM ejecuta un consulta continua No se realiza sólo una vez, pero está permanentemente instalado. Por lo tanto, la consulta se ejecuta continuamente hasta que explícitamente se desinstala. Puesto que la mayoría DSM está basadas en datos, una consulta continua produce nuevos resultados mientras llegan nuevos datos en el sistema. Este concepto básico es similar a Procesamiento de eventos complejos para que ambas tecnologías son parcialmente coalescente.

Principio de funcionamiento

Una de las características más importantes de un DSM es la posibilidad de manejar potencialmente infinita y cambian rápidamente flujos de datos ofreciendo un procesamiento flexible al mismo tiempo, aunque sólo hay escasos recursos como una memoria principal limitada. La tabla siguiente proporciona varios principios de DSM y compara con tradicionales DBMS.

Sistema de gestión de base de datos (DBMS)	Sistema de gestión (DSM) de flujo de datos
Datos persistentes (relaciones)	flujos de datos volátiles
Acceso aleatorio	Acceso secuencial
Consultas de una sola vez	Consultas continuas
almacenamiento secundario (teóricamente) ilimitado	memoria principal limitada
Sólo el estado actual es relevante	Consideración de la orden de la entrada
tasa de actualización relativamente baja	tasa de actualización potencialmente extremadamente alta
Poco o ningún tiempo requerido	Requisitos de tiempo real
Asume los datos exactos	Asume datos inexactos/anticuado
Procesamiento de consultas planificables	Llegada de datos variables y características de datos

Procesamiento y transmisión de los modelos

Uno de los mayores desafíos para un DSM es manejar flujos de datos potencialmente infinito mediante una cantidad fija de memoria y no hay acceso aleatorio a los datos. Existen diferentes enfoques para limitar la cantidad de datos en un solo paso, que puede ser dividido en dos clases. Por un lado, existen técnicas de compresión que intentar resumir los datos y por otra parte existen técnicas de ventana que tratan de la porción de los datos en partes (finitas).

Sinopsis

La idea detrás de técnicas de compresión es mantener sólo una sinopsis de los datos, pero no todos los puntos de datos (crudo) de la secuencia de datos. La gama de algoritmos de selección de puntos de datos aleatorios llamado muestreo para resumirla usando histogramas, cabrillas o dibujar. Un ejemplo simple de una compresión es el cálculo continuo de promedio. En lugar de memorizar cada punto de datos, la Sinopsis sólo posee la suma y el número de elementos. El medio puede calcularse dividiendo la suma por el número. Sin embargo, cabe mencionar que Sinopsis no reflejan con precisión los datos. Así, un proceso que se basa en Sinopsis puede producir resultados inexactos.

Windows

En lugar de usar Sinopsis para comprimir las características de los flujos de datos, técnicas de ventana Miren solamente una porción de los datos. Este enfoque está motivada por la idea de que sólo los datos más recientes son relevantes. Por lo tanto, una ventana continuamente se recorta una parte de la secuencia de datos, por ejemplo, los datos últimos diez elementos de la corriente y sólo considera estos elementos durante el proceso. Existen diferentes tipos de ventanas tan como ventanas que son similares a FIFO listas o agitación windows que corta fuera desune piezas. Además, las ventanas se pueden distinguir también en el elemento base para considerar, por ejemplo los últimos diez elementos, o tiempo basada en windows, por ejemplo a tener en cuenta los últimos diez segundos de datos. Además, también hay diferentes enfoques para implementar windows. Hay, por ejemplo, los enfoques que utilizan intervalos de tiempo o las marcas de tiempo para todo el sistema windows o windows basados en búfer para cada paso de proceso individual.

Procesamiento de consultas

Puesto que hay un montón de prototipos, no hay ninguna arquitectura estandarizada. Sin embargo, la mayoría DSM se basa en la consulta procesamiento en DBMS utilizando lenguajes para expresar las consultas, que se traducen en un plan de los operadores. Estos planes pueden ser optimizados y son ejecutados. Una consulta de tratamiento a menudo consiste en los siguientes pasos.

Formulación de consultas continuas

La formulación de consultas se realiza principalmente mediante lenguajes declarativos como SQL en DBMS. Puesto que no hay ningún lenguajes de consulta estandarizado para expresar las consultas continuas, hay un montón de idiomas y variaciones. Sin embargo, la mayoría de ellas está orientada a SQL como el Lenguaje de consulta continua (CQL), StreamSQL o EPL. También existen enfoques gráficos donde cada paso de proceso es una caja y el flujo de proceso se expresa mediante flechas entre las cajas.

El idioma depende fuertemente el modelo de procesamiento. Por ejemplo, si windows se utilizan para el procesamiento, la definición de la ventana debe ser expresado. En StreamSQL, una consulta con una ventana corredera para los últimos 10 elementos luce como sigue:

SELECCIONE AVG(precio) De examplestream [TAMAÑO 10 AVANCE 1 TUPLAS] DONDE VALOR > 100.0

Esta corriente continuamente calcula el valor promedio del "precio" de los últimos 10 tuplas, pero sólo considera las tuplas para el cálculo del promedio cuando el precio sea superior a 100.0.

En el siguiente paso, la consulta declarativa se traduce en un plan de consulta lógica. Un plan de consulta es un grafo dirigido donde los nodos son los operadores y los bordes describen el flujo de proceso. Cada operador dentro del plan de consulta encapsula la semántica de una operación específica como filtrado o agregación. En DSM que procesan secuencias de datos relacionales, los operadores son iguales o similares a los operadores de la Álgebra relacional, así que hay operadores para la selección, proyección, unirse, o fije las operaciones. Este concepto de operador permite el procesamiento de un DSM muy flexible y versátil.

Optimización de consultas

El plan de consulta lógica puede ser optimizado, que depende fuertemente el modelo de transmisión. Los conceptos básicos para la optimización de consultas continuas son iguales a los de sistemas de base de datos. Si existen flujos de datos relacionales y el plan de consulta lógica se basa en los operadores relacionales de la Álgebra relacional, un optimizador de consultas puede usar las equivalencias algebraicas para optimizar el plan. Estos pueden ser, por ejemplo, a los operadores de selección a situar las fuentes, porque no son tan cálculo intensivos como operadores de combinación.

Además, también existen técnicas de optimización basada en el costo como en DBMS, donde se elige un plan de consulta con los costos más bajos de planes diferentes consultas equivalente. Un ejemplo es para elegir el orden de dos operadores sucesivas. En DBMS esta decisión se realiza principalmente por ciertas estadísticas de las bases de datos involucrados. Pero, puesto que los datos de una secuencias de datos se desconoce de antemano, no existen tales estadísticas en un DSM. Sin embargo, es posible observar una secuencia de datos durante cierto tiempo obtener algunas estadísticas. Con estas estadísticas, la consulta puede también ser optimizada más tarde. Así que, en contraste con un DBMS, algunos DSM permite para optimizar la consulta incluso en tiempo de ejecución. Por lo tanto, un DSM necesita algunas estrategias de migración plan para reemplazar a un plan de consulta corriendo por una nueva.

Transformación de consultas

Puesto que un operador lógico sólo es responsable de la semántica de una operación pero no consiste en cualquier algoritmos, el plan de consulta lógica debe transformarse en una contraparte ejecutable. Esto se llama un plan de consulta física. La distinción entre una lógica y un plan de operador físico permite más de una aplicación para el mismo operador lógico. La Unión, por ejemplo, es lógicamente el mismo, aunque se puede implementar por diferentes algoritmos como un Bucle anidado o un Tipo-combinación de mezcla. Aviso, estos algoritmos también fuertemente dependen de la corriente usada y el modelo de procesamiento. Finalmente, la consulta está disponible como un plan de consulta física.

Ejecución de consultas

Puesto que el plan de consulta física consta de algoritmos ejecutables, pueden ejecutarse directamente. Para ello, el plan de consulta física está instalado en el sistema. La parte inferior del gráfico (del plan de consulta) está conectada a las fuentes entrantes, que pueden ser todo como conectores para los sensores. La parte superior del gráfico está conectada a los fregaderos salientes, que pueden ser por ejemplo una visualización. Puesto que la mayoría DSM es basadas en datos, se ejecuta una consulta empujando el elemento de datos entrantes de la fuente a través del plan de consulta para el fregadero. Cada vez que cuando el elemento de datos pasa a un operador, el operador realiza su operación específica en el elemento de datos y remite el resultado con todos los operadores sucesivos.

Sistemas de gestión de flujo de datos

• SQLstream
• ARROYO
• AURORA, StreamBase Systems, Inc.
• TelegraphCQ
• NiagaraCQ,
• QStream
• TUBOS, webMethods Business Events
• StreamGlobe
• Odysseus
• StreamInsight
• InfoSphere arroyos
• Motor de procesamiento de flujo de eventos SAS

Véase también

• Procesamiento de eventos complejos
• Procesamiento de eventos de corriente
• Sistema de gestión de flujo de datos relacionales

Referencias

• Aggarwal, Charu C. (2007). Flujos de datos: Algoritmos y modelos. Nueva York: Springer. ISBN978-0-387-47534-9.
• Golab, Lukasz; Özsu, M. Tamer (2010). Gestión del flujo de datos. Waterloo, EEUU: Morgan y Claypool. ISBN978-1-608-45272-9.

Enlaces externos

• Utilizando sistemas de gestión de flujo de datos para análisis de tráfico: A Case Study, visitó por última vez 2013-01-10
• CORRIENTE: Stanford Stream Data Manager, visitó por última vez 2013-01-10
• NiagaraST: Un sistema de gestión de investigación Data Stream de Portland State University, visitó por última vez 2013-01-10
• Odiseo: Una fuente abierta basada en Java framework para Data Stream Management Systems, visitó por última vez 2013-01-10
• Procesamiento de flujos de información: desde el Stream de datos para el procesamiento de eventos complejos -Artículo encuesta sobre flujo de datos y eventos procesamiento de sistemas complejos, visitó por última vez 2013-01-10
• Referencia StreamSQL, visitó por última vez 2013-01-10
• Secuencia de procesamiento con SQL -Introducción a la administración de datos con SQL de streaming

Otras Páginas

• Nokia Asha 300
• Motor Ford Sidevalve
• Casa Capital Group
• Loteria de Kentucky (seccion Cash bola)
• Destilacion
• Coping With
• Recibo de sueldo
• Resolvconf