MX2014008007A - Topologias de borde de nube. - Google Patents

Abstract

La descripción se refiere a topologías de borde de nube. Algunos aspectos se refieren a aplicaciones de borde de nube y uso de recurso en varias topologías de borde de nube. Otro aspecto de las tecnologías de borde de nube de la presente pueden referirse a la especificación de aplicaciones de borde de nube utilizando un lenguaje temporal. Un aspecto adicional puede involucrar una arquitectura que ejecuta procesadores de sistemas de manejo de flujo de datos (DSMS) en la nube y las computadoras de borde de nube para ejecutar partes de consulta.

Description

TOPOLOGIAS DE BORDE DE NUBE ANTECEDENTES La adopción extendida de dispositivos de cómputo portátiles 'inteligentes', tales como teléfonos inteligentes, por consumidores y disponibilidad de grandes cantidades de recursos de cómputo basándose en nube ha llevado a lo que se conoce como la "topología de borde de nube". Estos dispositivos de cómputo portátiles inteligentes se denominan 'inteligentes' ya que los avances de procesador y memoria permiten a estos dispositivos tener recursos de cómputo sustanciales disponibles para el usuario. Los dispositivos de cómputo portátiles inteligentes pueden generar datos en tiempo real tales como ubicación GPS, consumo de batería, velocidad, etc. Estos dispositivos de cómputo portátiles inteligentes también pueden pensarse como dispositivos de borde de nube ya que la comunicación entre un dispositivo individual y los recursos basados en nube puede pensarse como un borde.

Dados los recursos de cómputo sustanciales disponibles en el dispositivo de cómputo portátil inteligente, el usuario puede seleccionar varias aplicaciones para ejecutar en su dispositivo. Muchas de estas aplicaciones pueden denominarse como aplicaciones de borde de nube ya que un caso de aplicación se ejecuta en el dispositivo de cómputo portátil inteligente y otro caso de aplicación se ejecuta en los recursos de cómputo basados en nube. Existe una amplia clase de aplicaciones de borde de nube que correlacionan datos a través de múltiples dispositivos de cómputo portátiles inteligentes y la nube para lograr la funcionalidad de la aplicación. Un ejemplo es una aplicación para encontrar amigos que funciona para notificar a un usuario si cualquier amigo está cerca. Esta funcionalidad de aplicación depende de la correlación de ubicaciones en tiempo real y datos que cambian lentamente tal como redes sociales. Aunque están disponibles grandes cantidades de recursos de cómputo en los dispositivos de cómputo portátiles inteligentes y los recursos basados en nube, el uso de recurso, tal como recursos de comunicación, puede ser significativo cuando grandes números de dispositivos de cómputo portátiles inteligentes están ejecutando aplicaciones de borde de nube.

BREVE DESCRIPCION DE LA INVENCION La descripción se refiere a topologías de borde de nube. Algunos aspectos se refieren a aplicaciones de borde de nube y uso de recurso en varias topologías de borde de nube. Un ejemplo puede evaluar una consulta de transmisión continua en tiempo real que utiliza datos de múltiples dispositivos de cómputo de borde diferentes. Los múltiples dispositivos de cómputo de borde diferentes pueden estar configurados para comunicarse con recursos basados en nube pero no para comunicarse directamente entre si. Los dispositivos de cómputo de borde individuales incluyen un caso de una aplicación transportada en un lenguaje temporal declarativo. Este ejemplo puede comparar el uso de recurso entre primer y segundo escenarios. El primer escenario involucra cargar datos de consulta desde los múltiples dispositivos de cómputo de borde diferentes el recurso basado en nube para procesamiento. El segundo escenario involucra cargar los datos de consulta de todos excepto un nodo de los múltiples dispositivos de cómputo de borde diferentes a los recursos basados en nube y descargar los datos de consulta a un modo de los múltiples dispositivos de cómputo de borde diferentes para procesamiento.

Otro aspecto de las tecnologías de borde de nube de la presente pueden referirse a la especificación de aplicaciones de borde de nube que utilizan un lenguaje temporal. Un aspecto adicional puede involucrar u na estructura que ejecuta procesadores de sistemas de manejo de flujo de datos (DSMS) en las computadoras de nube y de borde de nube para ejecutar partes de consulta.

Los ejemplos listados anteriormente se pretenden para proporcionar una referencia rápida para ayudar al lector y no pretenden definir el alcance de los conceptos aquí descritos.

BREVE DESCRIPCION DE LOS DIBUJOS Los dibujos anexos ilustran implementaciones de los conceptos transportados en la presente solicitud. Las características de las implementaciones ilustradas pueden entenderse más fácilmente por referencia a la siguiente descripción tomada en conjunto con los dibujos anexos. Números de referencia similares en los varios dibujos se utilizan cuando sea factible para indicar elementos similares. Además, el número a la izquierda de cada número de referencia lleva la Figura y discusión asociada en donde se introduce primero el número de referencia.

La Figura 1 muestra un ejemplo de un sistema al cual pueden aplicarse los presentes conceptos de uso de recurso de aplicación de borde de nube de acuerdo con algunas implementaciones.

La Figura 2 muestra un ejemplo de una arquitectura de sistema a la cual pueden aplicarse los presentes conceptos de uso de recurso aplicación de borde de nube de acuerdo con algunas implementaciones.

Las Figuras 3-9 muestran ejemplos de gráficas a las cuales pueden aplicarse los presentes conceptos de uso de recurso de aplicación de borde de nube de acuerdo con algunas implementaciones.

La Figura 10 muestra un cuadro de flujo de un ejemplo de técnicas de uso de recurso de aplicación de borde de nube de acuerdo con algunas implementaciones de los presentes conceptos.

DESCRIPCION DETALLADA Vista General Los presentes conceptos se refieren a sistemas basados en nube y procesamiento dinámico, consciente de recurso por aplicaciones que se ejecutan en sistemas basados en nube y dispositivos conectados.

Para propósitos de explicación considerar la Figura 1 introductoria, que muestra un ejemplo de un sistema 100 que puede implementar los presentes conceptos. El sistema 100 incluye tres dispositivos de cómputo de borde de nube (en lo sucesivo, "dispositivos de cómputo") 102(1), 102(2), y 102(N) (en donde N significa que puede utilizarse cualquier número de dispositivos de cómputo). Los dispositivos de cómputo 102(1 )-102(N) pueden comunicarse con la nube 104 a través de una red 106 como se indica por las líneas 108(1 )- 108(3) , respectivamente. En este ejemplo, los dispositivos de cómputo individuales pueden comunicarse entre sí a través de la nube 104, pero no directamente con otros dispositivos de cómputo. La nube 104 puede ofrecer grandes cantidades de recursos de cómputo 110, aunque la ubicación física exacta de estos recursos de cómputo puede no ser fácilmente evidente. El cómputo de nube continúa ganando en popularidad debido a los recursos de cómputo relativamente económicos y abundantes que ofrece.

Los dispositivos de cómputo 102(1 )-102(N) pueden ser cualquier tipo de dispositivos de cómputo. Comúnmente, estos dispositivos de cómputo son dispositivos de cómputo portátiles tales como teléfonos inteligentes y computadoras de tableta. El término "computadora" o "dispositivo de cómputo" como se utiliza aquí puede significar cualquier tipo de dispositivo que tiene alguna cantidad de capacidad de procesamiento. Aunque ejemplos específicos de tales dispositivos se ilustran para propósitos de explicación, otros ejemplos de tales dispositivos pueden incluir dispositivos de cómputo tradicionales, tal como computadoras personales, teléfonos celulares, teléfonos inteligentes, asistentes digitales personales, o cualquiera de un gran número de tipos de dispositivo siempre evolucionando o aún desarrollándose. Además, en lugar de ser independiente, una computadora puede incorporarse en otro dispositivo. Por ejemplo, una computadora de tablero puede incluirse en un automóvil u otro vehículo.

Observado desde una perspectiva, los dispositivos de cómputo 102(1 )-102(N) pueden pensarse como 'dispositivos de borde' en una topología soportada por la nube 104 y la red 106. Muchos de estos dispositivos de borde están equipados con sensores que producen flujos frecuentes o continuos de datos en tiempo real tal como ubicación de GPS, velocidad, actividad actual, uso de batería del dispositivo del usuario, etc. Además, puede existir una cantidad creciente de datos de referencia que cambian más lento, tal como gráficas de red social y precios de combustible en estaciones de gasolina que se ponen a disponibilidad de la nube, por ejemplo, a través de mercados de datos. Esta proliferación de dispositivos de cómputo y datos ha promovido el interés creciente en una clase emergente de aplicaciones de borde de nube en tiempo real (o, aplicaciones de borde para resumir). Las aplicaciones de borde de nube pueden proporcionar servicios, tales como notificaciones o recomendaciones basándose en alimentaciones en tiempo real recolectadas de un gran número de dispositivos de cómputo de borde y la nube.

En algunos escenarios, los dispositivos de cómputo 102(1)-102(N) comunican sus datos a la nube 104 para procesamiento por uno o más proveedores de servicio que se ejecutan en recursos de cómputo de nube 110. Por ejemplo, asumir para propósitos de explicación que uno de tal servicio es un servicio para encontrar amigos que notifica a un usuario en cualquier momento que cualquier amigo está cerca de su ubicación actual. En algunas implementaciones, el servicio para encontrar amigos puede lograrse por una aplicación para encontrar amigos que se ejecuta en recursos de cómputo de nube 110 y aplicaciones para encontrar amigos correspondientes que se ejecutan en dispositivos de cómputo individuales 102( 1 )- 102(N).

La habilitación de I a aplicación para encontrar amigos implica la correlación de ubicaciones en tiempo real de teléfonos inteligentes de los usuarios (por ejemplo, dispositivos de cómputo 102(1 )-102(N)) así como datos de referencia que cambian lentamente tal como una red social (definiendo la relación de amistad). Para facilidad de explicación considerar únicamente los dispositivos de cómputo 102(1) y 102(2) y asumir que el dispositivo de cómputo 102(1) pertenece al Usuario 1 y que el dispositivo de cómputo 102(2) pertenece al Usuario 2. Además, asumir que el Usuario 1 y el Usuario 2 han sido declarados como 'amigos'. Cada dispositivo de cómputo puede de vez en cuando cargar datos a la nube como se indica por las flechas 112(1) y 112(2). Los datos cargados pueden ser procesados por el proveedor de servicio que opera en los recursos de cómputo de nube 110. El proveedor de servicio puede determinar resultados para cada dispositivo de cómputo y comunicar sus resultados de regreso a los dispositivos de cómputo respectivos 102(1) y 102(2). En algunos casos, tal procedimiento puede implicar altos números de comunicaciones de carga y descarga a través de la red 106 entre la nube 104 y los dispositivos de cómputo 102(1) y 102(2). Los presentes conceptos pueden permitir una opción alternativa. Esta opción alternativa puede pensarse como una opción consciente de recurso dinámico. En la opción consciente de recurso dinámico, uno de los dispositivos de cómputo 102(1) y 102(2) puede determinar que el uso de recurso de sistema, tal como estas comunicaciones de red, puede reducirse por el dispositivo de cómputo individual obteniendo los datos del otro dispositivo de cómputo de la nube y manejando el procesamiento localmente en el dispositivo de cómputo individual. (Las comunicaciones de red pueden considerarse por número y/o por uso de ancho de banda de red). En tal caso, el dispositivo de cómputo individual no carga. Los otros dispositivos de cómputo (restantes) cargan como es normal, y el dispositivo de cómputo individual descarga. La opción consciente de recurso dinámico puede pensarse como dinámica ya que los cálculos de uso de recurso pueden cambiar a medida que cambia el escenario. Un ejemplo tal se describe a continuación con relación a una velocidad a la cual un dispositivo de cómputo está generando datos ubicación. Los cálculos de uso de recurso pueden producir un resultado diferente cuando la velocidad de datos de ubicación cambia. De esa forma, en lugar de ser una determinación de un tiempo, la determinación puede repetirse en una forma reiterativa a medida que cambian las condiciones o parámetros.

Para ilustrar este uso de recurso reducido, suponer que el dispositivo de cómputo 102(1) pertenece al Usuario 1 y que el dispositivo de cómputo 102(2) pertenece al Usuario 2. Además, asumir que el Usuario 1 está trabajando en su oficina (por ejemplo, relativamente estacionaria) y en el Usuario 2 está manejando en un vecindario cercano. En la configuración fijada descrita anteriormente, una aplicación para encontrar amigos existente requerirá que el Usuario 2 (dispositivo de cómputo 102(2) carga (112(2)) su ubicación frecuentemente (es decir, una vez cada 10 segundos) de manera que la nube sepa su ubicación actualizada para correlacionarla con la ubicación del Usuario 1. Sin embargo, el Usuario 1 (dispositivo de cómputo 102(1)), puede cargar (112(1)) su ubicación poco frecuentemente (digamos, una vez por hora) ya que no se está moviendo mucho. En este ejemplo, el gasto de operación de comunicación total del Usuario 1 y el Usuario 2 serán 361 mensajes por hora (ignorando mensajes de notificación finales) a través de ia red 106. Este uso de red puede ser costoso, especialmente cuando un usuario tiene muchos amigos o ejecutan muchas aplicaciones. Esto puede limitar severamente la utilidad de la aplicación ya que se fuerza a limitar que tan frecuentemente se correlacionan datos de los usuarios, lo que se traduce a latencia de notificación alta. Además, los usuarios simplemente pueden apagar la aplicación debido a su uso de recurso alto. Sin embargo, esta ineficacia puede a bordarse fácilmente en el ejemplo anterior con la opción consciente de recurso dinámica. En lugar de utilizar metodología de correlación en la nube, la ubicación del Usuario 1 puede enviarse al dispositivo de cómputo 102(2) del Usuario 2 (a través de la nube 104 como se indica por las flechas 114 y 116, respectivamente). La correlación entonces puede realizarse por el dispositivo de cómputo del Usuario 2. En este caso, el Usuario 2 no necesita enviar su ubicación a ninguna parte y el costo total se volvería únicamente 2 mensajes por hora (uno del Usuario 1 a la nube, y el otro de la nube al Usuario 2). Observar que un punto en el tiempo subsecuente, tal como cuando el Usuario 1 se está desplazando a casa, la opción consciente de recurso dinámica puede terminar un aspecto diferente, tal como procesamiento en la nube 104.

En resumen, la opción consciente de recurso dinámica puede determinar qué (si hay alguno) cálculo impulsar, y que dispositivo de cómputo de cómputo de nube impulsarla. La determinación puede pensarse como un problema de optimización que depende de varios factores tal como la topología de red, velocidades de los flujos de datos, costos de carga y descarga de datos, pares de flujos para correlacionar, etc. Además, ya que estos parámetros pueden cambiar con el tiempo (por ejemplo, velocidad el Usuario 1 puede cambiar cuando empieza a desplazarse después de horas laborales), la determinación puede actualizarse dinámicamente. Se indica una implementación de opción consciente de recurso dinámica como RACE y se describe con detalle continuación.

Brevemente, RACE (para Aplicaciones en tiempo real a través de Borde de Nube), hay una estructura y sistema para especificar y ejecutar eficientemente aplicaciones de borde de nube. La RACE puede utilizar técnicas de base de datos para abordar dos aspectos principales. Primero, la RACE aborda la especificación de aplicaciones de borde de nube en tiempo real. En segundo lugar, la RACE aborda uso de recurso de sistema asociado con ejecutar las aplicaciones de borde de nube en tiempo real. El uso de recurso de sistema puede ser mejorado y/u optimizado (en lo sucesivo, para la búsqueda de brevedad, el término "optimizado" significa "mejorado y/u optimizado").

Especificación Aplicaciones de Borde de Nube La RACE que aborda la especificación de aplicaciones de borde de nube en tiempo real al restar la lógica de núcleo de aplicaciones de borde de nube como consultas continuas agnóstica de plataforma (CQ) sobre un grupo de fuentes de datos de transmisión continúa.

Las aplicaciones de borde de nube frecuentemente se escriben en lenguajes imperativos estándares tal como Objetivo C, Java o C#. Se requiere que los desabolladores de aplicación implementan manualmente mecanismos que manejan comunicaciones de dispositivo cruzado, que publican y suscriben a flujos de datos, y semántica relacionada con tiempo en la lógica de aplicación tal como uniones temporales y cálculos en ventanas. Este procedimiento es lento y propenso a error. La RACE puede agregar soporte de plataforma para funcionalidades comunes compartidas por la mayoría de las aplicaciones de borde de nube. Diseñadores de aplicación entonces pueden enfocarse a la lógica de aplicación de núcleo, en lugar de los detalles de implementación.

La presente implementación hace uso del hecho de que mientras diferentes aplicaciones de borde de nube tienen diversas características específicas de aplicación (por ejemplo, visualización y soporte para privacidad), pueden compartir algunas similitudes. Por ejemplo, tanto datos como lógica de aplicación de núcleo para aplicaciones de borde de nube son frecuentemente temporales en naturaleza. En otras palabras, las aplicaciones de borde de nube pueden observarse como consultas continuas que correlacionan continuamente tiempo real y datos de referencia que cambian más lento (pero aún temporales) en un sistema masivamente distribuido.

Por ejemplo, la aplicación para encontrar amigos puede pensarse como una unión temporal entre las ubicaciones GPS en tiempo real de dispositivos de borde y una corriente de red social que cambia más lento. La aplicación de cupón consciente de ubicación correlaciona información de ubicación actual con perfiles de los usuarios (calculados sobre la ventana de tiempo histórica) y anuncios actuales. De esa forma, en algunas implementaciones, el lenguaje de especificación para aplicaciones de borde de nube debe contener soporte nativo para semántica temporal. Tal soporte permite una expresión limpia de operaciones orientadas a tiempo tal como uniones temporales y agregaciones en ventanas. Alternativa o adicionalmente, el lenguaje puede tener otras propiedades. Por ejemplo, una de tales propiedades es la naturaleza declarativa de lenguaje de especificación. Puede permitir a los diseñadores de aplicación especificar aplicaciones en una forma declarativa y diagnóstica de topología de red, en donde pueden enfocarse en "que" son las aplicaciones, en lugar de "cómo" se implementan. Los detalles de implementación pueden ser transparentes para diseñadores de aplicación, y a su vez pueden manejarse automáticamente por la plataforma subyacente. Otra propiedad puede referirse a concisión. La especificación de aplicaciones puede ser concisa, permitiendo prototipo, despliegue, y depuración efectivos por los diseñadores de aplicación. La concisión es alineada mutuamente con la adopción de especificaciones declarativas. La flexibilidad puede ser otra propiedad. El lenguaje de especificación puede ser flexible, de manera que los diseñadores de aplicación puedan personalizar fácilmente la aplicación de acuerdo con diferentes fuentes y configuraciones de entrada/salida.

El espacio de diseño de lenguajes de especificación se describe ahora en vista de esas propiedades. Los lenguajes declarativos tales como SQL y Datalog (y sus variantes, por ejemplo, Network Datalog) pueden permitir concisión y especificación flexible de consultas continuas en ambientes distribuidos. Sin embargo, estos lenguajes no tienen soporte nativo para semántica temporal, lo que puede ser crucial para la mayoría de las aplicaciones de borde de nube. Por otro lado, los sistemas de manejo de flujo de datos (DSMS) utilizan lenguajes temporales declarativos que satisfacen las propiedades deseadas. Ejemplos incluyen LINQ™ para Streamlnsight, y StreamSQL™ para Oracle® CEP, y StreamBase™. La descripción a continuación utiliza LINQ para Streamlnsight como el lenguaje la especificación, pero es aplicable a otras configuraciones. LINQ permite la especificación declarativa de consultas temporales, y se basa en un álgebra y semántica bien definidas para adaptarse bien con la naturaleza temporal de aplicaciones de borde de nube.

La discusión a continuación proporciona un ejemplo de una especificación de aplicación de borde de nube. Recordar que la consulta para encontrar amigos encuentra todos los pares de usuario (Usuario 1, Usuario 2) que satisfacen las condiciones: 1) Usuario 2 es un amigo de Usuario 1; y 2) los 2 usuarios están geográficamente cerca entre si en un tiempo dado. En este punto, para propósitos de explicación, asumir que la relación de amistad es asimétrica, es decir, el Usuario 2 es un amigo del Usuario 1 no necesariamente implica lo inverso, dada en un punto en el tiempo. Existen dos entradas para la aplicación para encontrar amigos, principalmente las corrientes de ubicación GPS reportadas por los dispositivos de borde, y los datos de red social. Las ubicaciones GPS son recolectadas activamente en tiempo de ejecución, mientras los datos de red social están cambiando relativamente lento y están generalmente disponibles en la nube. El buscador de amigos puede escribirse como una consulta de unión temporal de dos etapas como se ilustra a continuación. var consulta 0 = desde e1 en ubicación desde e2 en Red social en donde de e1. IdUsuario = = e2.ldUsuario seleccionar nuevo {e1.IdUsuario, e1. latitud, e1. Longitud, e2.idAmigo}; var consulta 1 = desde e1 en consulta 0 desde e2 en ubicación en donde el.ldAmigo = = e2. IdUsuario & & Distancia (e1. Latitud, e1. Longitud, e2. Latitud, e2. Longitud) <UMBRAL seleccionar nuevo {Usuario = e1.IdUsuario, Usuario 2 = e2. IdUsuario}; La Primera consulta (consulta cero) se une a la corriente de ubicación GPS (ubicación) con la corriente de referencia de red social (Red social), y la corriente de salida resultante se une con las ubicaciones GPS de nuevo (en consulta 1), para revisar la distancia entre cada par de amigos. La salida final es una corriente de pares (Usuario 1, Usuario 2) en donde los dos usuarios son amigos y están geográficamente cerca uno del otro.

La especificación de consulta anterior define la lógica de alto nivel de la consulta como uniones temporales, y hace referencia a los esquemas de la corriente de ubicación y la corriente de Red social. Se escribe sobre la corriente de red social y una entrada de corriente de ubicación GPS conceptualmente unificada, y de esa forma agnóstica de topología de red. En otro ejemplo, asumir que una función deseada es encontrar amigos que visitaron una ubicación particular (digamos un restaurante) en la última semana. Para especificar esto, los presentes conceptos pueden permitir reemplazar la entrada de ubicación en consulta 1 con ubicación. Alterar Duración de Evento (Intervalo de Tiempo. Desde Días (7)). Esto extiende la "vida útil" de eventos de ubicación a 7 días, permitiendo a la unión considerar eventos de amigos dentro de la última semana.

En resumen, RACE puede utilizar una especificación declarativa de una aplicación de borde de nube. RACE puede ejecutar la lógica en el sistema distribuido compuesto de los dispositivos de borde y la nube. RACE puede utilizar un DSMS no modificado y una caja negra para ejecutar localmente consultas en dispositivos de borde individuales sin la nube. Algunas implementaciones de RACE que pueden operar sobre la suposición que la DSMS proporciona una interfase de programa de aplicación (API) de manejo para que los usuarios envíen consultas (que definen las consultas continuas para ejecutarse), tipos de evento (que especifican el esquema de corrientes de datos de entrada), y adaptadores de entrada y salida (que definen como los datos de transmisión continúa alcanza el DSMS desde el mundo exterior y viceversa). Además, la API también permite a los usuarios iniciar y detener consultas en el DSMS.

Dicho de otra forma, algunas implementaciones pueden mover diferentes flujos de datos (o partes de flujos) a la nube y/o a otros dispositivos de cómputo de borde a través de la nube. Algunos otros flujos de datos pueden retenerse localmente en el dispositivo y no cargarse a la nube. Además, estos varios flujos (movidos y locales) pueden servir como entradas para los segmentos de consulta de aplicación que se ejecutan en varias u bicaciones (tal como un sub-grupo de los dispositivos o incluso en la nube). Los flujos de salida de tales consultas por si mismos pueden ser retenidos localmente para cálculos adicionales o cargarse a la nube (y entonces enviarse posiblemente a otros dispositivos). En general, el cálculo satisfecho por el usuario final puede realizarse en una forma distribuida.

Arquitectura de RACE La Figura 2 muestra un sistema general o arquitectura de sistema 200 de una implementación de RACE. La arquitectura de sistema 200 se transporta a través de dispositivos de cómputo 102(1 )-102(N), nube 104, y red 106 de la Figura 1. La arquitectura de sistema 200 introduce un servicio de manejo de RACE 202 y un procesador de RACE 204. E I procesador de RACE incluye un constructor de gráfico 206, un optimizador 208, y un constructor de consulta 210. La arquitectura de sistema 200 también incluye datos estadísticos 214, datos de referencia 216, un plano de control 218, y un plano de datos 220. Los dispositivos de cómputo 102(1) y 102(N) incluyen un caso de DSMS 222(1 )-222(3), respectivamente, un caso de DSMS 222(4) también ocurre en la nube 104.

La arquitectura del s istema 200 se explica con relación a una experiencia proporcionada a un desarrollador de aplicación 224. El desarrollador de aplicación puede interactuar con el servicio de manejo de RACE 202 al escribir una aplicación en un lenguaje declarativo y temporal, tal como LINQ 226. Asumir para propósitos de explicación que la aplicación es una aplicación para encontrar amigos 228. La funcionalidad de aplicaciones para encontrar amigos se introdujo anteriormente con relación a la Figura 1. La aplicación para encontrar amigos 228 puede ser manifestada en los dispositivos de cómputo individuales 102(1 )-102(N) como casos de aplicación para encontrar amigos 228(1 )-228-(3), respetuosamente, y en la nube 104 como casos de aplicación para encontrar amigos 228(4). Además, aunque únicamente se ilustra con relación al dispositivo de cómputo 102(1) para búsqueda de brevedad, los dispositivos de cómputo individuales pueden incluir varios hardware 230. En este ejemplo el hardware ilustrado es un procesador 232, almacenamiento 234, y otro 236. Los elementos mencionados anteriormente se describen con más detalle a continuación.

El procesador 232 para ejecutar datos en la forma de instrucciones legibles por computadora para proporcionar una funcionalidad, tal como una funcionalidad para encontrar amigos. Los datos, tales como instrucciones legibles por computadora, pueden almacenarse en el almacenamiento 234. El almacenamiento puede ser interno o externo al dispositivo de cómputo. El almacenamiento 234 puede incluir cualquiera o más de memoria volátil o no volátil, unidades duras, y/o dispositivos de almacenamiento óptico (por ejemplo, CD. DVD, etc.), entre otros.

La computadora 102(1) también puede configurarse para recibir y/o generar datos en la forma de instrucciones legibles por computadora desde el almacenamiento 234. La computadora 102(1) también puede recibir datos en la forma de instrucciones legibles por computadora a través de la red 106 que luego se almacena en la computadora pare ejecución por su procesador.

En una configuración alternativa, la computadora 102(1) puede implementarse como un diseño de tipo de sistema en chip (SOC). En tal caso, la funcionalidad proporcionada por la computadora puede estar integrada en un SOC individual o múltiples SOC acoplados. En algunas configuraciones, los dispositivos de cómputo pueden incluir recursos compartidos y recursos dedicados. Una interfase(s) facilita la comunicación entre los recursos compartidos y los recursos dedicados. Como el nombre lo implica, los recursos dedicados pueden pensarse, incluyendo porciones individuales que están dedicadas a lograr funcionalidades específicas. Los recursos compartidos pueden ser almacenamiento, unidades de procesamiento, etc., que pueden utilizarse por múltiples funcionalidades.

Generalmente, cualquiera de las funciones aquí descritas puede implementarse utilizando software, firmware, hardware (por ejemplo, sistema de circuitos lógicos fijo), procesamiento manual, o una combinación de estas implementaciones. Los términos "herramienta", "componente", o "módulo" como se utilizan aquí generalmente representan software, firmware, hardware, dispositivos o redes completas, o una combinación de los mismos. En el caso de una im plementación de software, por ejemplo, estos pueden representar código de programa que realiza tareas especificadas cuando se ejecutan en un procesador (por ejemplo, CPU o CPUs). El código de programa puede ser almacenado en uno o más dispositivos de memoria legibles por computadora, tales como medios de almacenamiento legibles por computadora. Las características y técnicas del componente son independientes de plataforma, lo que significa que pueden implementarse en una variedad de plataformas de cómputo comerciales que tienen una variedad de configuraciones de procesamiento.

Como se utiliza aquí, el término "medios legibles por computadora" puede incluir instrucciones transitorias y no transitorias. En contraste, el término "medios de almacenamiento legibles por computadora" excluye casos transitorios. Los medios de almacenamiento legibles por computadora pueden incluir "dispositivos de almacenamiento legibles por computadora". Ejemplos de dispositivos de almacenamiento legibles por computadora incluyen medios de almacenamiento volátiles, tales como RAM, y medios de almacenamiento no volátiles, tales como unidades duras, discos ópticos, y memoria flash, entre otros.

El otro hardware 236 puede incluir presentaciones, dispositivos de entrada/salida, sensores, etc., que pueden impletnentarse en varios dispositivos de cómputo.

El servicio de manejo de RACE 202 puede ejecutarse en la nube 104 y exponer un servicio de manejo que es completamente compatible con la API de manejo de DSMS. De esa forma, los dispositivos de cómputo individuales 102(1 )-102(N) pueden enviar su lógica de aplicación de borde de nube declarativa al servicio de manejo de RACE 202 como consultas declarativas temporales regulares soportadas por el DSMS 222(1 )-222(N) respectivo. Observar que desde la perspectiva del dispositivo de borde (por ejemplo, dispositivos de cómputo 102(1 )-102(N)), simplemente parecen comunicarse con un procesador de DSMS normal.

Visto desde otra perspectiva, el sistema de manejo de RACE 202 puede pensarse como estando configurado para interactuar con una aplicación que se ejecuta en la nube y en dispositivos de cómputo de borde individuales en comunicación con la nube. El servicio de manejo de RACE 202 puede estar configurado para imitar a un procesador de DSMS para recibir consultas declarativas temporales desde los dispositivos de cómputo de borde individuales.

Brevemente, el procesador de RACE 204 puede pensarse como interceptando y analizando la consulta entrante, adaptadores, y tipos de los dispositivos de cómputo individuales 102(1 )-102(N) que ejecutan la aplicación para encontrar amigos 228. El procesador de RACE 204 entonces recopilar estas entradas en la representación de objeto de la consulta original. La representación de objeto pasa al módulo constructor de gráfico 206 que convierte la consulta original en una gráfica de consulta más grande. Por ejemplo, la gráfica de consulta más grande puede incluir flujos de entrada por borde y operadores. La g ráfica d e consulta pasa a I módulo optimizador 208 para decidir la colocación óptima del operador. Finalmente, el módulo constructor de consulta 210 puede generar representaciones de objeto de tipos, adaptadores, y (sub-)consultas para ejecutarse en dispositivo de cómputo individual 102(1 )-102(N) o en la nube 104. Estos objetos son enviados al DSMS individual (a través de sus API de manejo) de los respectivos dispositivos de cómputo para ejecutar la lógica de aplicación en una forma distribuida. Observar que aunque en esta configuración, el servicio de manejo de RACE 202 y el procesador de RACE 204 se implementan en la nube 104, en otras implementaciones, alternativa o adicionalmente, el servicio de manejo de RACE y/o el procesador de RACE podrían implementarse en uno o más dispositivos de cómputo 102(1 )-102(N). El servicio de manejo de RACE y/o el procesador de RACE implementados en los dispositivos de cómputo podrían ser independientes o trabajar en forma cooperativa con el servicio manejo de RACE correspondiente y/o los casos de procesador de RACE en la nube.

El constructor de gráfico 206 puede pensarse como tomando la representación de objeto de una consulta como entrada, junto con estadísticas en velocidades de flujo e información de metadatos en cada entrada. El constructor de gráfico primero puede utilizar la representación de objeto de la consulta para generar un patrón de consulta, que representa la plantilla o esqueleto para generar la gráfica de consulta expandida. Por ejemplo, la Figura 3 ilustra el patrón de consulta 302 enviado por el constructor de gráfico 206 para la consulta para encontrar amigos descrita anteriormente con relación al párrafo 25.

Algunos de los flujos de entrada en el patrón de consulta 302 se refieren a flujos de datos por dispositivo tales como fuentes de ubicación G PS. El constructor de gráfico 206 p uede crear múltiples casos del patrón de consulta al dividir tales flujos en múltiples entradas, una por borde. Entradas de datos de referencia que cambian lentamente, tal como la red social, pueden materializarse para limitar el tamaño de la gráfica de consulta generada. Por ejemplo, la Figura 4 muestra una red social 400 de cuatro usuarios P, Q, R, y S. La Figura 5 muestra patrones de consulta ejemplificados correspondientes 502(1), 502(2), y 502(3) para la consulta para encontrar amigos. Observar que con el fin de permitir distribución de información y evitar bordes duplicados en los patrones de consulta ejemplificados, la fuente y los operadores de unión ejemplificados se nombran cuidadosamente, como se muestra en la Figura 5. El paso final es para unir los patrones de consulta ejemplificados 502( 1 )-502(3) en una gráfica de consulta completa.

La Figura 6 muestra una gráfica de consulta final 602 derivada de los patrones de consulta ejemplificados mostrados en la Figura 5. Observar que cuando se combinan los patrones de consulta ejemplificados, los vértices (en los patrones ejemplificados) con el mismo nombre s e trazan al mismo vértice en la gráfica d e consulta final. Por ejemplo, el vértice de Unir <GPS-P, SNP> es compartido por los patrones ejemplificados para bordes (P; R) y (P; S).

Regresando a la Figura 2, el módulo optimizador 208 acepta la gráfica de consulta final 602 como entrada, y decide en donde ejecutar cada operador (por ejemplo, parte de consulta) en la gráfica de consulta para que se minimice el costo de comunicación total o colectivo de la aplicación (o al menos se reduzca). Con miles o incluso millones de usuarios participando en el sistema de borde de nube, la gráfica de consulta final puede ser enorme, conteniendo millones de operadores. Para tal gráfica de consulta grande, la colocación del operador óptimo no es trivial. El módulo Optimizador de RACE puede utilizar varias técnicas para determinar la colocación de operador óptima. Una de tales técnicas se describe a continuación bajo el encabezado "Colocación Optima de Operador". La RACE puede realizar re-optimización periódica para ajustar la colocación a cambios en la gráfica de consulta y/o estadísticas.

Después que se toman las decisiones para la colocación de operador mejorada/óptima, el procesador de RACE 204 tiene un grupo de gráficas de consulta arraigadas (cada una que consiste de una gráfica acíclica dirigida (DAG) de operadores temporales). Cada una de tales gráficas corresponde a alguna ubicación (borde o nube). El módulo constructor de consulta 210 puede generar representaciones de objeto de los componentes de consulta (incluyendo tipos de evento, adaptadores y consulta) para cada gráfica. El módulo constructor de consulta entonces puede enviar las representaciones de objeto al DSMS correspondiente a través del plano de control 218. Observar que pueden instalarse dos adaptadores adicionales en cada caso de DSMS, uno para enviar datos de evento al plano de datos 220, y otro para recibir datos de evento desde el plano de datos.

El plano de control de RACE 218 se utiliza para desplegar los fragmentos de consulta generados y metadatos al caso de nube y los casos de borde del DSMS, utilizando la API de manejo de DSMS. Una complicación es que los dispositivos de borde (por ejemplo, teléfono) usualmente no se pueden alcanzar o abordar directamente desde servicios de manejo de RACE en 202. En lugar de esto, el servicio de manejo de RACE puede mantener un servidor para el cual los dispositivos de borde crean y mantienen conexiones persistentes con el fin de recibir comandos de manejo que se envían a los casos de DSMS en los bordes. Durante la ejecución de consulta, los eventos fluyen entre dispositivos de borde y la nube. El servicio de manejo de RACE 202 puede utilizar un plano de datos separado 220 que está expuesto como un servidor en la nube 104, y al cual pueden conectarse los dispositivos de cómputo de borde 102(1 )-102(N) pueden conectarse a través del plano de control 218. Las consultas generadas en los dispositivos de cómputo de borde y la nube se suscriben a y publican corrientes nombradas que están registradas con el plano de datos 220. El plano de datos dirige eventos desde la nube 104 hacia los dispositivos de cómputo de borde 102(1 )-102(N) y viceversa.

Con miles e incluso millones de usuarios que participan en el sistema de borde de nube, la gráfica de consulta final podría ser enorme, conteniendo millones de operadores. Ya que se distribuyen fuentes de datos (por ejemplo, flujos de datos de GPS de varios usuarios se originan desde sus dispositivos de borde), la colocación de cada operador tiene su impacto a los gastos generales de evaluación de consulta. Existen exponencialmente muchas combinaciones diferentes de colocación de operador. Un aspecto ingenuo que busca todo el espacio de diseño puede no ser factible. Además, considerar la distribución de resultados intermedios hace el problema incluso más difícil.

La siguiente discusión se refiere a un ejemplo de un algoritmo eficiente para colocación de operador óptima, al hacer uso de la topología de "estrella" especial de sistemas de borde de nube. Para algunas implementaciones, la concisión del algoritmo puede probarse dadas las dos suposiciones mencionadas a continuación. Además, los gastos generales de encontrar la colocación óptima pueden ser muy bajos.

Suposición 1. La salida final consultas es relativamente mucho menor a los datos de transmisión continua de entrada, y por lo tanto puede ignorarse su costo.

Esta suposición es razonable dada la naturaleza general de aplicaciones de borde de nube. Además, basándose en consideraciones de privacidad, algunas implementaciones pueden restringir las ubicaciones permitidas de operadores. Por ejemplo, los datos de transmisión continua pueden incluir información personal sensible (por ejemplo los rastros de Geo-ubicación de un teléfono móvil). Un cliente de borde no desea exponer la información sin procesar, a menos que esté apropiadamente procesada (al excluir los datos sensibles de los resultados finales de una operación de unión), o si se envía únicamente a nodos que han sido autorizados.

Suposición 2. Para cualquier unión A !> B (en donde A y B son los flujos de entrada de la unión), se realiza la operación de unión ya sea en la nube o en los nodos en donde se originaron A o B.

Observa que esta suposición no simplifica el problema de colocación; aún existe un número exponencial de posibles colocaciones de operador. Antes de presentar el razonamiento y el algoritmo propuesto se describen varias denotaciones basadas en gráfica.

Definición (Demanda) Puede ser denotada, como un par (vi, v2l) que una fuente de datos de transmisión continua v2, "demandas" (es decir, necesita correlacionarse con esta) los datos generados por otra fuente vi .

Definición (Gráfica de Demanda) Dada una aplicación de Borde de Nube, la gráfica de demanda G = (V, E) se define como a continuación: el vértice establecido V = {v/v es una fuente de datos de transmisión continúa}, y E = {(v^ vz Kv^ v2l) es un par de demanda}. Cada borde e = (i,) e E está asociado con una velocidad r¡j , que indica la velocidad de la corriente Vj que se demanda por vj.

Algoritmo 1. Generar Gráfica de Demanda de Gráfica de Consulta func Gráfica de Demanda (GQ = (VQ, EQ)) VD - f; ED «- f para vi eQ do suponer e1 = (v2, v eQ, e2 = (v'2l eQ VD <r VD + {v-,} ED <r ED + {ß? = (v2, V2), e'2 = (V2, v2)} fin para regresar GD = (VD + {e'i = (VD, ED) La Figura 7 muestra la gráfica de demanda 702 correspondiente para la consulta para encontrar amigos, dada la red social mostrada en la Figura 4. Los bordes en la gráfica de demanda 702 ilustran las relaciones de demanda. Por ejemplo, el borde (GPS-P, SNP) indica que la lectura de GPS de P (GPS-P) debe estar correlacionada con la red social (SNP). En una gráfica de demanda, se tratan los operadores de unión como fuentes de datos virtuales en la gráfica de demanda (ya que están produciendo resultados de unión como corriente). Realmente, existe una distribución de uno a uno entre gráficas de demanda y gráficas de consulta. Dado una gráfica de consulta GQ = (VQ, EQ), el Algoritmo 1 genera la gráfica de demanda G = (V , ED) correspondiente. La gráfica de consulta puede ser rediseñada a partir de la gráfica de demanda al seguir un algoritmo similar.

Asignación: Descarga contra Carga. En general, decidir colocación de operador óptima para evaluación de consulta distribuida es conocido por ser un problema difícil. La esencia del algoritmo propuesto está arraigada en hacer uso de una propiedad de red especial de la arquitectura de borde de nube. En este caso, los dispositivos de cómputo de borde no pueden comunicarse entre sí directamente. En lugar de esto, para intercambiar información, los dispositivos de cómputo de borde tienen que cargar o descargar datos a través de los servidores de lado de nube.

Definición (Carga y Descarga). Dada una gráfica de demanda G = (V, E), p ara un borde (I, j) e, esta i mplementación caracteriza vj como "cargando" (I, j), si, sin importar en donde está colocado v¡ (ya sea en un dispositivo de cómputo de borde o el servidor de nube), siempre hace el esfuerzo de tener la corriente correspondiente (demandada por Vj) disponible en el servidor de nube; de otra forma, v¡ está caracterizado como "descargando" en (i, j).

De manera intuitiva, una vez que un vértice decide cargar en un borde (que representa una correlación de datos requerida), no hay razón para descarga cualquiera de los datos para esta correlación desde el servidor de lado de nube, debido a que la correlación puede realizarse simplemente en el lado de nube (ya que los datos ya se han puesto a disponibilidad en el sitio de nube). Considerar el siguiente lema.

Lema uno. Dada una gráfica de demanda G = (V, E), en su colocación de operador óptima, V ( i , j ) <= E, (i,j) tiene que estar en uno de los dos estados: ya sea que v¡ esté cargando (pero no descargando) o descargando (pero no cargando) en (i,j).

Prueba. Suponer que un vértice v¡ e V decide tanto cargar como descargar en (i, j). El operador de unión para la correlación correspondiente puede colocarse en tres ubicaciones (de acuerdo con la suposición 2), principalmente vh v¡ y la nube. En este caso, un operador de unión no puede colocarse en v¡ en la colocación óptima: ya que v¡ ya está cargando su corriente. La operación de unión podría haber sido realizada en la nube, en cuyo caso, ahorro en costo de comunicación para descargar datos de v¡ a v¡. Por lo tanto, v¡ está descargando en (i,) (ya que ninguno de los operadores de unión está colocado en v¡).

El Lema 1 ofrece soporte para la conclusión que, dada una gráfica de demanda G = (V, E), existe una distribución de su colocación óptima para un grupo de decisiones de carga contra descarga hechas en cada vértice en G. Tal grupo de decisiones se define como una asignación.

Definición (Asignación). Dada una gráfica de demanda G = (V, E), una asignación A:E -> {D, U} se define como a continuación: A¡ j = U si vértice vj decide cargar sus datos de transmisión continua en el borde (i, j), de otra forma A¡,j = D.

La colocación óptima y su asignación correspondiente pueden denotarse como Popt y Aopt. La Figura 8 muestra la colocación óptima (Popt) para la gráfica de demanda 702 de la Figura 7. La Figura 9 muestra la asignación correspondiente (Aopt). En la colocación de operador opcional, la unión entre GPS-P y SNP se realiza en el nodo P, lo que significa que la gráfica de red social dividida SNP debe ser enviada al nodo P, es decir, SNP es "cargado" a la nube, y GPS-P no. Esto es consistente con la asignación dada en la Figura 9.

Es natural hacer las preguntas 1) si existe una distribución inversa de Aopt a Popt, y 2) si existe un algoritmo eficiente para encontrar Aopt, dada una gráfica de demanda. La discusión a continuación inicialmente se refiera a la primera pregunta, y entonces gradualmente desarrolla la respuesta para la segunda pregunta.

No todas las asignaciones pueden ser distribuidas a un plano de evaluación viable. Existe una restricción fundamental: la unión requiere la ubicación conjunta de todas sus entradas. Por lo tanto, para cualquier unión que toma entradas de diferentes fuentes (dispositivos de borde), máximo un dispositivo está descargando.

Definición (Viabilidad y Conflicto). Dada una gráfica de demanda G = (V, E), una asignación A es viable si satisface la siguiente condición: Ve = (i,)e E, Au ? D v Aj,¡ ? D. Un borde que rompe esta condición se denomina un borde de conflicto.

Por ejemplo, la Figura 9 ilustra una asignación viable dada I a gráfica de demanda mostrada en la Figura 7, para cualquier correlación, máximo una fuente de datos está decidiendo descargar. Si el ASNP, GPS-P se cambia para descargar, se invalidará la asignación, ya que el borde (SN, GPS-C) es un borde de conflicto.

Algoritmo 2. Calcular Colocación de Asignación func Colocación (GQ = (VQ EQ), Asign) //Inicia la colocación de vértices de hoja (es decir, fuentes sin procesar) Colocación {} para Vv eVQ hacer si 13 e = (?', v) e EQ entonces Colocaciónv - v fin si fin para //Determinar colocación de operador en una forma de arriba a abajo orden <- VQ Topo clasificado por clasificación de topología. para Vv e Orden Topo en la parte inferior - orden superior suponer ß? = (?1 ( v) e EQ, e2 = (v2, v) e EQ Si Asignv1 = D entonces Colocaciónv Colocaciónv1 también si Asignv2 = D entonces Colocaciónv <- Colocaciónv2 también Colocaciónv - Nube fin para regresar Colocación Lema 2. Dada una asignación viable A, A puede distribuirse a una colocación de operador correspondiente.

Prueba. Probar por construcción. Se decide la colocación del operador en una forma de abajo hacia arriba (mostrada como Algoritmo 2). Como el caso base, se conocen las ubicaciones de los vértices de hoja en una gráfica de consulta (trivialmente las fuentes de corriente). Para un vértice interno (es decir, un vértice virtual que representa un operador de unión), de acuerdo con la suposición 2, puede colocarse en el servidor de lado de nube, o se localiza conjuntamente con una de sus entradas. Si todas sus fuentes de entrada deciden cargar, entonces el operador de unión debe ser colocado en la nube; de otra forma, si existe una y solamente una fuente de entrada (dado que la asignación A es viable) que decide descargar, entonces el operador de unión debe estar localizado conjuntamente con esa fuente de entrada.

Teorema 4.5 El problema de colocación operador óptima puede reducirse para encontrar una asignación viable con costo óptimo (directamente derivado del Lema 1 y Lema 2).

Consultas de Unión de Nivel Individual Esta discusión inicia con un escenario simple, en donde las aplicaciones son especificadas como consultas de unión de nivel individual. La discusión se extenderá a consultas de unión de nivel múltiple en la discusión a continuación.

Misma Velocidad de Demanda La discusión primero considera un caso especial de las consultas de unión de nivel individual, en donde, para cualquier vértice y en una gráfica de demanda, las velocidades de corriente para todos los bordes de salida son las mismas, principalmente, V(i, j) e E; ru = r¡. Básicamente, un operador de unión requiere todos los datos de transmisión continúa para cada corriente de entrada para realizar la operación de unión. Esto corresponde a las consultas en donde no se realiza ningún filtrado (tal como proyección o selección) antes de la unión.

En lugar de considerar directamente el costo de una asignación, algunas implementaciones pueden calcular la ganancia de cambiar carga y descarga (que puede ser positivo o negativo) comparado con una asignación viable base, una solución ingenua que todos los vértices deciden cargar sus datos de transmisión continua. Al cambiar un vértice / de carga a descarga, la ganancia puede calcularse como a continuación: ganancia¡ = n - ?(iij)eErj. Principalmente, la ganancia puede pensarse como el beneficio de no cargar los datos de transmisión continúa de i a un costo de descargar todas las corrientes que están correlacionadas con la corriente de /.

Definición (optimización global). Dada una gráfica de demanda G = (V, E), para la asignación óptima global está a una a signación viable A que maximiza las ganancias totales.

La siguiente técnica para encontrar una asignación Aopt que da la optimización global considera un aspecto avaricioso en donde cada vértice en la gráfica de demanda hace localmente la decisión de asignación basándose en su propio beneficio.

Definición (Optimización local). Dada una gráfica de demanda G = (V, E), para cada vértice v e V, la asignación óptima local para v es una decisión local sobre Av que maximiza la ganancia local.

Específicamente, Av = D gananciav >0.

Se puede probar que la optimización local realmente es consistente con la optimización global, que tiene dos implicaciones: en primer lugar, los gastos generales para calcular la optimización local son bajos, lo que es lineal para el número de grados del vértice en la gráfica de demanda. En segundo lugar, significa que el problema de asignación puede dividirse y resolverse en paralelo.

Esto es particularmente importante en casos en donde la gráfica de demanda es enorme, ya que esta técnica puede hacer uso de la gran cantidad de recursos de computación en la nube para resolverlo eficientemente.

Teorema 1. Dada una gráfica de demanda G= (V, E), la asignación A = {AV|AV = asignación óptima local en v, v e V} es viable.

Prueba. Probar por contradicción. Suponer que existe un borde de conflicto e = (i,j), que significa que A¡ = D y A¡ = D. A¡ = D proporciona esa ganancial = r¡ - ?(¡,¡)eE ? > 0. Por lo tanto, r¡ > r¡. Similarmente, r¡ > r¡ puede derivarse de Aj = D, Contradicción.

Teorema 2. Optimización local es consistente con optimización global, principalmente, la optimización global puede derivarse al aplicar individualmente optimización local.

Prueba. 1) El Teorema 1 muestra que la asignación derivada al aplicar individualmente optimización local es viable. 2) Cada optimización local está calculando la ganancia máxima para un enlace físico aislado, y la optimización global es simplemente adición de las ganancias en los enlaces físicos.

Diferentes Velocidades de Demanda La discusión ahora se extiende para considerar el escenario en donde, para un vértice dado y, las velocidades de corriente demandadas por cada uno de los otros vértices pueden ser diferentes. Por ejemplo, en el caso de la aplicación para encontrar amigos, la velocidad de evento para un usuario particular puede ser diferente con respecto a cada uno de sus amigos. Aquí, se asume que la corriente con una velocidad inferior puede construirse utilizando una con una velocidad superior, que corresponde a consultas que aplican filtros de muestreo. En otras palabras, un filtro que necesita muestrear X eventos/segundo puede proporcionarse por otro filtro que muestrear y eventos/segundo, para cualquiera y >. x. En tal escenario, necesitan tomarse decisiones sobre carga contra descarga para cada borde (en lugar de cada vértice) en la gráfica de demanda.

Al asumir que las velocidades riiVj se clasifican en el vértice /, de manera que r¡,v1 < riiV2 < ... < r¡,vP, no es difícil observar que una asignación óptima para los p bordes clasificados debe tener el patrón [U, .... U, D D].

Definición (Optimización local). Considerar la ganancia en una asignación Vy <_ k, A¡,vji = D; gananciai vk = ri vp - r¡,vk - ??+? 8<?G?5?· Algunas implementaciones pueden seleccionar k = argmaxi<j<pgananciaiiV,k. y configurar la asignación en el patrón descrito anteriormente.

Lema 4.8. Después de aplicar optimización local en el vértice /', en ese AliVj = D es implicado para riiVj > rvj ¡.

Prueba. Prueba por contradicción. Suponer r¡ Vj . rVj,¡. De acuerdo con la definición de optimización local: ganancia¡iVk - r¡iVp - r¡ v -? + i<s<prVs,'- ganancia¡ vp — ^t. j - n,vj - ?¡ + i s<.prvs,'- Observar que j > k, ya que A¡ vj - D. También, ganancia¡,vk -ganancia¡,vk - ri Vk + ?k +i<s<Lrvs,' + (rVj, - ri, j) > 0. Esto crea una contradicción (ya que ganancia¡,vk es óptima).

Teorema 3. El teorema de viabilidad (Teorema 1) se mantiene. Prueba. Prueba por contradicción. Supongamos que existe un borde de conflicto e(v!, v2). Aplicar el Lema 3, suministra rvi,V2 > rv2,vi desde ??·,,?2 = D, y rv2,vi > rv v2 desde Av2 vi = D, que produce una contradicción.

Consultas de Unión de Nivel Múltiple Cuando se consideran consultas de unión de nivel múltiple, pueden existir dificultades que previenen aplicar ingenuamente el algoritmo desarrollado para consultas de unión de nivel individual. Por ejemplo, para consultas de unión de nivel individual, el costo de las corrientes de salida para operadores de unión no se considera (ya que se asumió que la salida final es insignificante comparada con las corrientes de entrada). Sin embargo, este no es el caso para consultas de unión de nivel múltiple. Por ejemplo, cuando se aplica ingenuamente el algoritmo presentado en la sección previa, un dispositivo de borde puede decidir individualmente descargar otras corrientes y realizar el cálculo localmente. Sin embargo, si el dispositivo de borde está consciente del hecho de que la corriente de salida entonces se requiere para un operador de unión de nivel superior (cuya colocación óptima está en el lado de nube), puede tomar una decisión diferente. La discusión a continuación se refiere a como se resuelve este reto al extender el algoritmo para uniones de nivel individual.

Suposición 3. Un flujo de datos para un borde dado aparece en no más de un sub-árbol hijo de cualquier operador en la gráfica de consulta.

Esta es una suposición razonable, ya que uno puede combinar simplemente flujos del mismo dispositivo de borde en un flujo individual, o realizar localmente el cálculo necesario en el que están involucrados estos flujos. Observar que esta suposición no evita compartir resultados de recurso o intermedias, y en particular, siempre mantiene en el caso que el patrón de consulta es un árbol profundo de hoja sobre diferentes fuentes de datos.

Colocación de Operador en una Forma de Arriba a Abajo Los operadores de unión internos en la gráfica de consulta pueden observarse como fuentes de corriente virtuales, excepto que necesiten decidirse sus ubicaciones. Intuitivamente, dada una gráfica de consulta, las presentes técnicas pueden tomar las decisiones de carga contra descarga para los operadores en la forma de arriba a abajo. Por ejemplo, la decisión puede tomarse para un vértice ?? dado que corresponde a un operador de unión, siempre y cuando se conozca la ubicación en donde se va enviar su salida (basándose en la decisión de colocación tomada por su operador padre). El algoritmo para las consultas de unión de nivel individual puede extenderse directamente al incluir adicionalmente el costo de envío a la corriente de salida al destino.

Observar que el único destino considerado es el lado de nube. Por ejemplo, incluso si el destino es otro dispositivo de borde (ya que se requiere la corriente de salida por otro vértice v2 localizado en el dispositivo de borde), la técnica no necesita considerar la parte de descarga del costo de envío (es decir, el costo de enviar la corriente de salida desde el lado de nube hacia ese dispositivo de borde), ya que este costo de descarga ya es considerado al calcular la ganancia para v2. Observar que las Suposiciones 1 y 3 aseguran que cuando se considera el vértice v,, puede desecharse la decisión de colocación real para su destino, ya que se colocará definitivamente en la nube o en algún otro borde diferente a Vi (o su sub-árbol) con el que se traslapa. Esta observación clave hace posible la extensión del algoritmo, y puede mostrarse fácilmente que el algoritmo extendido aún garantiza una asignación viable y óptima.

Carga contra Descarga en una Forma de arriba a abajo Observar que el aspecto previo (para consultas de unión de nivel individual) deriva la colocación de operadores en la forma de abajo hacia arriba después que se toman las decisiones de carga contra descarga. El Algoritmo 3 puede ser ajustado para decidir la asignación de carga contra descarga, basándose en la asignación de los operadores padre en lugar de su colocación (ya que la colocación no está disponible).

Una vez que se conoce la decisión del vértice padre v,, algunas implementaciones pueden considerar que decisión deben tomar para un vértice hijo v2. De nuevo, v2 tiene dos elecciones, ya sea carga o descarga.

En un escenario, si la decisión del vértice padre v, es descargar, significa que no hay necesidad de hacer el esfuerzo de tener la salida disponible en el servidor de nube. Por lo tanto, cuando se encuentra la optimización local para v2, no se considera el costo de la corriente de salida al calcular las ganancias.

En otro escenario, si la decisión del vértice padre v-, es cargar, significa que la corriente de salida de v2 debe hacerse disponible en el servidor de nube. Por lo tanto, cuando se encuentra la optimización local para v2, debe considerarse el costo de la corriente de salida.

El algoritmo 3 toma la gráfica d e demanda G = (V,E) como la entrada, y calcular la colocación de operador óptima. El algoritmo aplica un escenario genérico en donde asume una consulta de unión de nivel múltiple, y velocidades de demanda por grado (es decir, las velocidades asociadas con los bordes de demanda partiendo de un vértice dado puede ser diferente). De acuerdo con los Teoremas 1 y 2, no es difícil ver que la asignación derivada es viable y óptima. Algoritmo 3. Calcular Asignación Óptima.

Func Asignación (GQ = (VQ, EQ), G° = (VD, ED)) //Calcular optimización local en una forma de arriba a abajo Orden Topo VQ clasificado por clasificación de topología: Asignar - {}; para Vve Orden Topo en el orden de arriba abajo hacer E Inicio <r {ek = (v, v')|ekeED)) Clasificar E Inicio de acuerdo con rv>Vj r ^~ maX(v,v')eE in¡c¡o r v.v¡ para V ek = (vk, v'k)e E Inicio hacer gananciak rma - rvkiV¡k - ?k + i <s<prvs.vk Vp <- padre vk en la gráfica de consulta Si Asignvp = U entonces //Ganancia debe incluir el costo de salida de unión. gananciak <- gananciak+r(¡j)//r(ij) es costo del resultado de unión terminar si terminar para Kopt r argmax^nípgananciaK para V/<k<kopt Asignarv,k <- U para Vkop,<k<p Asignarv k D terminar para regresar Asign Costos de Carga/Descarga Asimétricos Hasta ahora, las técnicas anteriores han operado sobre la suposición que el costo de carga y el costo de descarga son los mismos. Sin embargo, en realidad, puede no ser el caso. Por ejemplo, los precios por unidad de utilización de ancho de banda para carga y descarga pueden ser diferentes (por ejemplo, proveedor de servicio de nube puede introducir costos asimétricos para alentar a los usuarios a alimentar datos dentro de la nube). Como otro ejemplo, un dispositivo de borde puede exhibir diferentes consumos de batería para carga y descarga.

La discusión a continuación considera costos de carga/descarga asimétricos. El costo por unidad para carga y descarga se deno+an como Cu y Cd. Para escenarios en donde Cu < Cd, los resultados para Cu = Cd presentados en los escenarios previos se mantienen. Básicamente, el razonamiento del teorema de viabilidad clave (Teorema 1) se mantiene.

Por otro lado, la decisión de la colocación de operador óptima es un problema más difícil para casos en donde Cu > Cd. Para un caso especial en donde Cd = 0, se puede mostrar que el problema de colocación de operador óptima se puede probar difícil por reducción del problema de cubierta de vértice mínimo ponderado clásico (WMVC). Esencialmente, el teorema de viabilidad se divide en estos casos, por lo tanto, tener dispositivos de borde aplica individualmente optimización local o que puede resultar en conflictos. En tales casos, aún puede obtenerse una asignación viable al resolver los conflictos al establecer algunos vértices en la gráfica de demanda para cargar con velocidades superiores. Por lo tanto, el problema se reduce al problema de WMVC en la gráfica residual, que carece de una solución general eficiente. La siguiente discusión se refiere a una condición. Si se satisfacen la condición, puede resolverse eficientemente el problema de colocación de operador óptima.

Definición. Dada una gráfica de demanda G = (V,E), la tendencia de un vértice ve V, Sv se define como la relación entre la velocidad máxima y mínima asociada con los bordes de salida desde v. Principalmente, Sv = maX(v.i)e E,i)rv,¡ min(v,j)e Eii)rVij.

Definición Dada una gráfica de demanda G = (V,E), la tendencia de G se define como la tendencia máxima entre los nodos en G. Principalmente, S = maxveVSv.

Cuadro 1: muestra un resumen del algoritmo de colocación de operador. Se logra optimización global en todos los casos.

Lema 4. Dada la tendencia S de una gráfica G, si Cu < Cd < (1 + 1/S) Cd, después de aplicar optimización local sobre todo los vértices, la gráfica residual G' que consiste de los bordes de conflicto es acíclica (es decir, árboles separados).

Prueba. Prueba por contradicción. Suponer que existe un ciclo ( i, v2), (v2, v3) (v(p-i). vP,)> (VP, vi) en la gráfica residual G'.

Para el propósito de presentación, de notar que v0 = vp y v(p+i) = Ya que cada borde en el ciclo es un borde de conflicto, V1 ± i <_ p, existe un límite flojo que Cu · max(rVii Vi?¡, rVi> +1) > Cd¦ (rV + rVi+í¡ v. ).

Al agregar estas diferencias se puede derivar que Cu ·?i=i= max (rv. Vj_i, rVi¡ v.+i) > Cd '?i=i<p(rv¡-i, VÍ · rvi+1 d = Cd '?lsi C d '?l=i=P m'n(rf ¡, v (+1)· Por lo tanto, esta implementación puede derivar la siguiente contradicción: cu/cd > i +-— -— -11· 1+1 ¾ > 1 + 1/S.

Teorema 4. Si Cd < Cu < (1+1/S) Cd, la colocación de operador óptima puede encontrarse en tiempo P.

Prueba. Se puede concluir al aplicar el Lema 4 que G' es acíclica. Esta discusión muestra que, para cada árbol en la g ráfica residual G', su cubierta de vértice mínimo ponderado puede encontrarse en tiempo lineal, utilizando un algoritmo de programa dinámico.

Partiendo de los vértices de hoja, para cada vértice v, considerar el costo de la cubierta de vértice para el sub-árbol (arraigado por v), que tiene (o que no tiene) v en el grupo de cubierta. Para cualquier vértice interior v, si v no es el grupo de cubierta, entonces todo los hijos de v deben estar en el grupo de cubierta. Por lo tanto, Costo"v =?ie hijo(v)Costo+v. Por otro lado, si v está en el grupo de cubierta, entonces cada sub-árbol puede elegir independientemente su cubierta de vértice: Costo+v = cv + min! e hijo(v)(Costo"v, Costo + v).

Observar que para un caso especial en donde las velocidades de corriente requeridas por diferentes amigos son las mismas, la colocación óptima puede encontrarse en tiempo P, si Cd < Cu < 2 Cd (que se mantiene en escenarios muy prácticos). Empíricamente, incluso si Cu > 2 · Cd, los bordes en conflicto aún forman árboles aislados.

Breve Descripción El Cuadro 1 resume los árboles teóricos y la complejidad de tiempo del algoritmo de colocación de operador propuesto, dadas varias combinaciones de complejidades de consulta, condiciones de selección, y relaciones de costo de carga/descarga.

El algoritmo de colocación de operador calcula la solución globalmente óptima al considerar individualmente optimización local para cada vértice en la g ráfica de demanda. Esta discusión prueba que la optimización local es consistente con la optimización global (si Cu <. Cd). Se propone un algoritmo avaricioso eficiente para calcular optimización local. Con este algoritmo codicioso eficiente cada nube elige individualmente la solución que maximiza la ganancia local.

El algoritmo maneja tanto consultas de unión de nivel individual como de nivel múltiple más complejas. En el caso de consultas de unión de nivel múltiple los operadores de unión en una gráfica de consulta son tratados como vértices virtuales. La optimización local puede ser calculada para cada vértice individual en una forma de arriba a abajo. Además, en el caso común en donde la gráfica residual es acíclica (para Cu > Cd), existe un algoritmo de programación dinámico eficiente (DP) para encontrar la asignación óptima para la gráfica de demanda. Por lo tanto, puede determinarse una colocación de operador óptima para la gráfica de consulta. La extensión de estos conceptos a gráficas de consulta generales con operadores de caja negra también se explica.

Dada la naturaleza de aplicaciones de borde de nube (que son usualmente correlaciones a través de datos en tiempo real), la discusión anterior se enfocó principalmente en consultas de unión (con filtros de muestreo). La discusión a continuación se refiere a cómo puede a plicarse el algoritmo p ropuesto para soportar gráficas de consulta generales en una topología de borde de nube. La discusión además explica cómo puede manejarse el dinamismo de tiempo de ejecución tal como cambios en la gráfica de consulta y velocidades de evento.

Manejo de Gráficas de Consulta Generales Una gráfica de consulta G se define como una gráfica acíclica dirigida (DAG) sobre un grupo de operadores de caja negra (denotados como O), en donde las hojas en G son denominadas fuentes, y las raíces son denominados visitadores. Cada operador en O puede tomar cero (para las fuentes) o más entradas, y su salida puede utilizarse como una entrada para otros operadores. La selección y proyección son ejemplos de operadores de una entrada, mientras la operación de unión es un ejemplo de operaciones de dos entradas (o un operador de entrada múltiple para uniones espesas). Las intuiciones de alto nivel del algoritmo de colocación de operador mantienen aún que cada operador puede decidir individualmente (en un orden de arriba hacia abajo) si debe cargar (o descarga) su salida para optimizar su costo local. En este caso, la viabilidad de la asignación aún es garantizada como anteriormente. Además, dado que se consideran los operadores como cajas negras, no hay oportunidad adicional de explotar distribución a través de la salida de diferentes operadores. En este caso, la consistencia entre óptima local y óptima global se mantiene, siguiendo un razonamiento similar al Teorema 2. Por lo tanto, el problema de nuevo puede reducirse a encontrar las asignaciones de carga/descarga óptimas, y pueden utilizarse los algoritmos de optimización local eficientes propuestos.

Manejo de Dinamismo Algunos casos del algoritmo asumen la disponibilidad de la gráfica de consulta, y estadísticas de velocidad para todas las corrientes. La colocación óptima es calculada basándose en su información recolectada en la etapa de optimización. Sin embargo, la gráfica de consulta puede cambiar con el tiempo, por ejemplo, debido a la adición y remoción de bordes de la red social. Similarmente, también pueden cambiar con el tiempo velocidades de evento. De esa forma, puede ser necesario adaptar estos cambios durante tiempo de funcionamiento. Dado que el algoritmo de optimización propuesto es muy eficiente, la re-optimización periódica es una solución viable. Sin embargo, la re-optimización puede encontrar gastos generales de despliegue (por ejemplo, enviar mensajes de plano de control tal como definiciones de consulta). Si las implementaciones se re-optimizan frecuentemente, los gastos generales de re-optimización pueden ocultar los beneficios de la optimización.

Para resolver este dilema, una solución es utilizar un algoritmo en línea basado en costo. Por ejemplo, tal algoritmo puede estimar y mantener la pérdida acumulada debido a re-optimización que no se realiza, y elegir realizar la re-optimización si la pérdida acumulada excede los gastos generales de re-optimización. Una propiedad potencialmente benéfica de este aspecto es que es competitiva en 3 sentidos, se garantiza que el costo general está unido por 3 veces de lo óptimo (incluso con un conocimiento a priori de los cambios).

La discusión anterior ofrece gran detalle de implementaciones de RACE específicas. RACE puede soportar una amplia clase de aplicaciones de borde de nube en tiempo real. La RACE abordó dos retos técnicos principales: (1) la especificación de tales aplicaciones; y (2) su ejecución optimizada en la topología de borde de nube. Para (1), la discusión muestra que utilizar un lenguaje de consulta temporal declarativo (tal como LINQ para Streamlnsight) para expresar estas aplicaciones es muy poderoso e intuitivo. Para (2), el uso de procesadores de DSMS se propone para compartir procesamiento y ejecutar diferentes porciones de la lógica de aplicación en dispositivos de borde y la nube. Aquí, los algoritmos novedosos son altamente eficientes pero probablemente minimizan costos de red global, mientras manejan redes asimétricas, gráficas de consulta generales, y distribución de resultados intermedios. Las implementaciones de RACE anteriores están configuradas para trabajar con Streamlnsight™ de Microsoft®, un DSMS comercialmente disponible. Otras implementaciones puede configurarse para utilizar otras opciones de DSMS.

Experimentos sobre grupos de datos reales indicaron que el optimizado de RACE es de órdenes de magnitud más eficiente que técnicas de colocación óptima de estado de la técnica. Además, las colocaciones logradas por las presentes implementaciones incurrieron a varios factores de costo inferior que esquemas más simples para la aplicación para encontrar amigos sobre una g ráfica de red social realista con 8:6 millones de bordes. La RACE es fácilmente paralelizable dentro de la nube. También se escala bien utilizando sólo una máquina individual en despliegues reales con hasta 500 clientes de borde. Detalles de algunas implementaciones se describen anteriormente en un nivel fino de granularidad. La discusión a continuación ofrece una descripción más amplia que puede referirse a las implementaciones mencionadas anteriormente y/u o a otras implementaciones.

Ejemplos Adicionales de Método La Figura 10 ilustra un cuadro de flujo de una técnica o método 1000 que es consistente con al menos algunas implementaciones de los presentes conceptos.

En el bloque 1002, el método puede obtener una consulta de transmisión continúa declarativa en una topología de borde de nube que incluye dispositivos de borde múltiple y recursos basados en nube.

En el bloque 1004, el método puede convertir la consulta de transmisión continúa declarativa en una gráfica de consulta que refleja los dispositivos de borde múltiple.

En el bloque 1006, el método puede determinar si ejecuta operadores de la gráfica de consulta en dispositivos de borde individuales o en los recursos basados en nube, basándose en uso de recurso para la topología de borde de nube.

El orden en el cual se describen los métodos mencionados anteriormente no pretende interpretarse como una limitación, y puede combinarse cualquier número de bloques descritos en cualquier orden para implementar el método, o un método alterno. Además, el método puede implementarse en cualquier hardware, software, firmware o combinación adecuada de los mismos, de manera que un dispositivo de cómputo puede implementar el método. En un caso, el método es almacenado en un medio de almacenamiento legible por computadora como un grupo de instrucciones de manera que la ejecución por un dispositivo de cómputo hace que el dispositivo de cómputo realice el método.

Conclusión Aunque se describen técnicas, métodos, dispositivos, sistemas, etc., que pertenecen a recursos de borde de nube y su distribución en lenguaje específico a características estructurales y/o actos metodológicos, se entenderá que el tema definido en las reivindicaciones anexas no necesariamente está limitado a las características o actos específicos descritos. Más bien, las características y actos específicos se describen como formas ilustrativas para implementar los métodos, dispositivos, sistemas reclamados, etc.

Claims (10)

REIVINDICACIONES

1. - Un método que comprende: obtener una consulta de transmisión continua declarativa en una topología de borde de nube que incluye múltiples dispositivos de borde y recursos basados en nube; convertir la consulta de transmisión continua declarativa en una gráfica de consulta que refleja los múltiples dispositivos de borde; y, determinar si se ejecutan operadores de la gráfica de consulta sobre dispositivos de borde individuales o sobre los recursos basados en nube basándose en el uso de recurso para la topología de borde de nube.

2. - El método de acuerdo con la reivindicación 1, en donde los dispositivos de cómputo de borde comprenden dispositivos de cómputo inteligentes que están configurados para comunicarse directamente con los recursos basados en nube a través de una red y en donde la red no está configurada para permitir que los dispositivos de cómputo inteligentes individuales se comuniquen directamente entre si, en lugar de que los dispositivos de cómputo inteligentes individuales se comuniquen entre sí indirectamente través de los recursos basados en nube.

3. - El método de acuerdo con la reivindicación 1, en donde la determinación comprende determinar un óptimo global con relación a los recursos basados en nube que se refiere al uso de recurso de ancho de banda de red.

4. - El método de acuerdo con la reivindicación 3, en donde la determinación de un óptimo global comprende permitir que los nodos de la gráfica de consulta tomen decisiones locales en una forma codiciosa y en donde las decisiones locales cuando se observan acumulativamente producen el óptimo global.

5. - Un sistema, que comprende: un servicio de manejo basado en nube de Aplicaciones en Tiempo Real a través de Borde de Nube (RACE) configurado para interactuar con una aplicación que se ejecuta en la nube y en dispositivos de cómputo de borde individuales en comunicación con la nube, el servicio de manejo basado en nube de RACE configurado para imitar un procesador de sistemas d e manejo de flujo d e datos (DSMS) para recibir consultas declarativas temporales desde los dispositivos de cómputo de borde individuales; y, un procesador de RACE configurado para interceptar las consultas declarativas temporales y para analizar y recopilar consultas declarativas temporales individuales en una representación de objeto.

6. - El sistema de acuerdo con la reivindicación 5, en donde el procesador de RACE comprende un constructor de gráfico configurado para generar un patrón de consulta de la representación de objeto.

7. - El sistema de acuerdo con la reivindicación 6, en donde, en un caso en donde el patrón de consulta incluye flujos de entrada que hacen referencia a flujos de datos de cada dispositivo de cómputo de borde, el constructor de gráfico está configurado adicionalmente para crear una gráfica de consulta que incluye múltiples casos del patrón de consulta al dividir los flujos de datos en múltiples casos del patrón de consulta con un flujo de entrada por borde de la gráfica de consulta.

8. - El sistema de acuerdo con la reivindicación 7, en donde el procesador de RACE comprende un optimizador configurado para determinar en donde ejecutar operadores individuales de la gráfica de consulta para reducir los costos de comunicación totales entre los dispositivos de cómputo de borde y los recursos basados en nube.

9. - El sistema de acuerdo con la reivindicación 8, en donde el optimizador está configurado para determinar en donde ejecutar operadores individuales de la gráfica de consulta para minimizar los costos de comunicación totales entre los dispositivos de cómputo de borde y los recursos basados en nube.

10. - El sistema de acuerdo con la reivindicación 5, en donde el procesador de RACE comprende un constructor de consulta configurado para generar representaciones de objeto de tipos, adaptadores y sub-consultas que se van a ejecutar en cada dispositivo de cómputo de borde o en la nube.