Облачно-граничные топологии

Облачно-граничные топологии

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Широко распространенное применение «интеллектуальных» портативных вычислительных устройств, таких как, например, смартфоны, потребителями и доступность большого количества облачных вычислительных ресурсов привели к так называемой «облачно-граничной (Cloud-Edge) топологии». Эти интеллектуальные портативные вычислительные устройства называют «интеллектуальными» потому, что улучшенные процессор и память позволяют этим устройствам иметь значительные вычислительные ресурсы, доступные пользователю. Интеллектуальные портативные вычислительные устройства могут формировать данные в режиме реального времени, как, например, местоположение GPS, расход батареи, скорость и так далее. Эти интеллектуальные портативные вычислительные устройства могут также рассматриваться как облачно-граничные устройства, так как связь между отдельным устройством и облачными ресурсами может рассматриваться как через границу.

С учетом значительных вычислительных ресурсов, доступных на интеллектуальных портативных вычислительных устройствах, пользователь может выбирать различные приложения для выполнения на своем устройстве. Многие из этих приложений могут быть обозначены как облачно-граничные приложения, так как один экземпляр приложения функционирует на интеллектуальном портативном вычислительном устройстве, а другой экземпляр приложения функционирует на облачных вычислительных ресурсах. Существует широкий класс облачно-граничных приложений, которые коррелируют данные по множеству интеллектуальных портативных вычислительных устройств и облаку, чтобы достигнуть функциональности приложения. Примером является приложение по поиску друзей, которое функционирует, чтобы уведомить пользователя, есть ли поблизости друзья. Функциональность этого приложения зависит от корреляции местоположений в режиме реального времени и медленно меняющихся данных, как, например, социальные сети. В то время как огромное количество вычислительных ресурсов доступно на интеллектуальных портативных вычислительных устройствах и облачных ресурсах, использование ресурсов, как, например, ресурсов связи, может быть значительным, когда огромные количества интеллектуальных портативных вычислительных устройств исполняют облачно-граничные приложения.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

Описание относится к облачно-граничным топологиям. Некоторые аспекты относятся к облачно-граничным приложениям и использованию ресурсов в различных облачно-граничных топологиях. Согласно одному примеру, можно оценивать запрос потоковой передачи данных реального времени, который использует данные из множества различных граничных вычислительных устройств. Это множество различных граничных вычислительных устройств может быть выполнено с возможностью связываться с облачными ресурсами, но не связываться напрямую друг с другом. Отдельные граничные вычислительные устройства включают в себя экземпляр приложения, выраженного в описательном временном языке. Согласно этому примеру, можно сравнивать использование ресурсов между первым и вторым сценарием. Первый сценарий включает в себя выгрузку данных запросов из множества различных граничных вычислительных устройств в облачные ресурсы для обработки. Второй сценарий включает в себя выгрузку данных запросов из всех кроме одного узла из множества различных граничных вычислительных устройств в облачные ресурсы и скачивание данных запросов в один узел из множества различных граничных вычислительных устройств для обработки.

Другой аспект настоящих облачно-граничных топологий может относиться к спецификации облачно-граничных приложений с использованием временного языка. Дополнительный аспект может включать в себя архитектуру, которая выполняет машины систем управления потоками данных (DSMS) в облаке и облачно-граничных компьютерах для выполнения частей запроса.

Вышеперечисленные примеры предназначены для обеспечения быстрой ссылки для помощи читателю и не предназначены для определения объема концепций, описанных в настоящей заявке.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Сопровождающие чертежи изображают варианты реализации идей, выраженных в настоящей заявке. Признаки изображенных вариантов реализации могут быть более понятны с помощью ссылки на нижеследующее описание, рассмотренное совместно с сопровождающими чертежами. Одинаковые ссылочные позиции в различных чертежах используются, где это возможно, для указания одинаковых элементов. Дополнительно, крайнее левое число каждой ссылочной позиции выражает фигуру и связанное с ней обсуждение, где в первый раз вводится ссылочная позиция.

Фиг. 1 изображает пример системы, в которой настоящие идеи использования ресурсов облачно-граничного приложения могут быть применены в соответствии с некоторыми вариантами осуществления.

Фиг. 2 изображает пример архитектуры системы, в которой настоящие идеи использования ресурсов облачно-граничного приложения могут быть применены в соответствии с некоторыми вариантами осуществления.

Фиг. 3-9 изображают примеры графов, в которых настоящие идеи использования ресурсов облачно-граничного приложения могут быть применены в соответствии с некоторыми вариантами осуществления.

Фиг. 10 изображает логическую блок-схему примера способа использования ресурсов облачно-граничного приложения в соответствии с некоторыми вариантами осуществления концепций настоящего изобретения.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

ВВЕДЕНИЕ

Концепции настоящего изобретения относятся к облачным системам и динамической, с учетом ресурсов, обработке приложениями, исполняемыми в облачных системах и подсоединенных устройствах.

С целью объяснения рассмотрим вводную фиг. 1, которая изображает пример системы 100, которая может осуществлять концепции настоящего изобретения. Система 100 включает в себя три облачно-граничных вычислительных устройства (здесь и далее «вычислительные устройства») 102(1), 102(2) и 102(N) (где N обозначает, что любое число вычислительных устройств может быть использовано). Вычислительные устройства 102(1)-102(N) могут связываться с облаком 104 по сети 106, как указано линиями 108(1)-108(3), соответственно. В этом примере отдельные вычислительные устройства могут связываться друг с другом по облаку 104, но не напрямую с другими вычислительными устройствами. Облако 104 может предложить большое количество вычислительных ресурсов 110, хотя точное физическое местоположение этих вычислительных ресурсов может быть не очевидным. Облачное вычисление продолжает набирать популярность вследствие относительно дешевых и многочисленных вычислительных ресурсов, которое оно предлагает.

Вычислительные устройства 102(1)-102(N) могут быть любым типом вычислительных устройств. В общем, эти вычислительные устройства являются портативными вычислительными устройствами, как, например, смартфоны и планшетные компьютеры. Термин «компьютер» или «вычислительное устройство», как использовано в настоящем документе, может обозначать любой тип устройства, которое имеет некоторую способность обработки данных. В то время как конкретные примеры таких устройств изображены с целью объяснения, другие примеры таких устройств могут включать в себя традиционные вычислительные устройства, как, например, персональные компьютеры, сотовые телефоны, смартфоны, персональные цифровые помощники (PDA) или любые из огромного числа когда-либо разработанных или находящихся в разработке типов устройств. Дополнительно, компьютер может быть встроен в другое устройство, а не быть автономным. Например, настольный компьютер может быть включен в автомобиль или другое средство передвижения.

При рассмотрении с одной перспективы, вычислительные устройства 102(1)-102(N) могут быть рассмотрены как «граничные устройства» в топологии, поддерживаемой облаком 104 и сетью 106. Многие из этих граничных устройств оборудованы сенсорами, которые производят частые или непрерывные потоки данных в реальном времени, как, например, местоположение GPS пользователя, скорость, текущая активность, расход батареи устройства и так далее. Дополнительно, может быть растущее количество медленно изменяемых справочных данных, как, например, графы социальной сети и цены на топливо на автозаправочных станциях, которые становятся доступными в облаке, например, по рынкам данных. Этот быстрый рост вычислительных устройств и данных подкрепил растущий интерес к развивающемуся классу облачно-граничных приложений в реальном времени (или облачно-граничных приложений (АРР) для краткости). Эти облачно-граничные приложения могут обеспечивать сервисы, как, например, уведомления или рекомендации, на основании веб-каналов в реальном времени, собранных из большого числа граничных вычислительных устройств и облака.

В некоторых сценариях вычислительные устройства 102(1)-102(N) передают свои данные в облако 104 для обработки с помощью одного или нескольких провайдеров сервисов, выполняемых на облачных вычислительных ресурсах 110. Например, предположим с целью объяснения, что один такой сервис является сервисом по поиску друзей, который уведомляет пользователя, есть ли рядом с ее текущим местоположением любой из ее друзей. В некоторых вариантах осуществления сервис по поиску друзей может осуществляться приложением по поиску друзей, исполняемым на облачных вычислительных ресурсах 110, и соответствующими приложениями по поиску друзей, исполняемыми на отдельных вычислительных устройствах 102(1)-102(N).

Активация приложения по поиску друзей влечет за собой корреляцию местоположений в реальном времени от смартфонов пользователей (например, вычислительных устройств 102(1)-102(N)), а также медленно изменяемых справочных данных, таких как, например, социальная сеть (определение дружеских взаимоотношений). Для облегчения объяснения рассмотрим только вычислительные устройства 102(1) и 102(2) и предположим, что вычислительное устройство 102(1) принадлежит Пользователю 1 и что вычислительное устройство 102(2) принадлежит Пользователю 2. Дополнительно, предположим, что Пользователь 1 и Пользователь 2 были определены как «друзья». Каждое вычислительное устройство может время от времени выгружать данные в облако, как указано стрелками 112(1) и 112(2). Выгруженные данные могут быть обработаны провайдером сервисов, функционирующим на облачных вычислительных ресурсах 110. Провайдер сервисов может определять результаты для каждого вычислительного устройства и передавать эти результаты обратно соответственным вычислительным устройствам 102(1) и 102(2). В некоторых случаях такой процесс может повлечь за собой большие количества осуществлений связи по выгрузке и скачиванию по сети 106 между облаком 104 и вычислительными устройствами 102(1) и 102(2). Концепции настоящего изобретения могут позволить альтернативный вариант. Этот альтернативный вариант можно рассматривать как динамический вариант с учетом ресурсов. В динамическом варианте с учетом ресурсов одно из вычислительных устройств 102(1) и 102(2) может определять, что использование ресурсов системы, как, например, этих сетевых передач, может быть сокращено путем получения отдельным вычислительным устройством данных другого вычислительного устройства из облака и локальной обработки на отдельном вычислительном устройстве. (Сетевые передачи могут учитываться по их количеству и/или использованию полосы пропускания сети). В таком случае отдельное вычислительное устройство не выполняет выгрузку. Другие (оставшиеся) вычислительные устройства выполняют выгрузку как обычно, и отдельное вычислительное устройство выполняет скачивание. Этот динамический вариант с учетом ресурсов можно рассматривать как динамический, потому что вычисления использования ресурсов могут меняться по мере изменения сценария. Один такой пример описан ниже по отношению к частоте, с которой вычислительное устройство формирует данные местоположения. Вычисления использования ресурсов могут производить другой результат, когда частота формирования данных местоположения меняется. Таким образом, определение, вместо того чтобы быть единовременным, может повторяться альтернативным образом по мере изменения условий или параметров.

Для иллюстрирования этого сокращенного использования ресурсов предположим, что вычислительное устройство 102(1) принадлежит Пользователю 1, а вычислительное устройство 102(2) принадлежит Пользователю 2. Дополнительно предположим, что Пользователь 1 работает в своем офисе (например, относительно стационарном), а Пользователь 2 ведет машину по соседству. В вышеописанной фиксированной конфигурации существующее приложение по поиску друзей попросит Пользователя 2 (вычислительное устройство 102(2)) выгружать (112(2)) его/ее местоположение часто (например, каждые 10 секунд), чтобы облако знало о его/ее обновлении местоположения для корреляции с местоположением Пользователя 1. Пользователь 1 (вычислительное устройство 102(1)), однако, может выгружать (112(1)) его/ее местоположение нечасто (например, раз в час), так как он/она не передвигается много. В этом примере общая нагрузка на связь Пользователя 1 и Пользователя 2 составляет 361 сообщение в час (с игнорированием финальных сообщений уведомления) по сети 106. Использование сети может быть дорогостоящим, особенно когда пользователь имеет много друзей или запускает много подобных приложений. Это может серьезно ограничить применимость приложения, так как приводит к ограничению того, как часто коррелируются данные пользователей, что приводит к большому времени задержки уведомлений. Более того, пользователи могут просто отключить приложение вследствие высокого использования им ресурсов. Однако эту неэффективность можно легко решить в вышеуказанном примере с помощью динамического варианта с учетом ресурсов. Вместо использования методологии корреляции в облаке, местоположение Пользователя 1 может быть отправлено вычислительному устройству 102(2) Пользователя 2 (через облако 104, как указано стрелками 114 и 116, соответственно). Корреляция может затем быть выполнена вычислительным устройством Пользователя 2. В этом случае Пользователю 2 не нужно отправлять его/ее местоположение, и общая нагрузка станет только 2 сообщения в час (одно - от Пользователя 1 в облако, и другое - из облака Пользователю 2). Необходимо отметить, что в последующую точку времени, как, например, когда Пользователь 1 едет домой, динамический вариант с учетом ресурсов может определять другой подход, такой как, например, обработка в облаке 104.

Подводя итог, динамический вариант с учетом ресурсов может определять, какое (если оно есть) вычисление принудительно направить и какому граничному вычислительному устройству его принудительно направить. Это определение можно рассматривать как проблему оптимизации, которая зависит от различных факторов, таких как, например, топология сети, скорости передачи потоков данных, затраты на выгрузку и скачивание данных, пары потоков для корреляции и так далее. Более того, так как эти параметры могут меняться с течением времени (например, частота передачи данных от Пользователя 1 может меняться, когда он/она начинает перемещение после рабочего дня), то данное определение может динамически обновляться. Одна реализация динамического варианта с учетом ресурсов называется RACE и описана подробно ниже.

Кратко, RACE (приложения реального времени через границу облака) является структурой и системой спецификации и эффективного исполнения облачно-граничных приложений. RACE может использовать технологии баз данных для решения вопросов, касающихся двух главных аспектов. Во-первых, RACE решает вопрос, касающийся спецификации облачно-граничных приложений реального времени. Во-вторых, RACE решает вопрос, касающийся использования ресурсов системы, связанных с исполнением облачно-граничных приложений реального времени. Использование ресурсов системы может быть улучшено и/или оптимизировано (здесь и далее, для краткости, термин «оптимизированный» означает «улучшенный и/или оптимизированный»).

СПЕЦИФИКАЦИЯ ОБЛАЧНО-ГРАНИЧНЫХ ПРИЛОЖЕНИЙ

RACE решает вопрос, касающийся спецификации облачно-граничных приложений реального времени, путем абстрагирования базовой логики облачно-граничных приложений как независимых от платформы непрерывных запросов (CQ) по набору ресурсов потоковых данных.

Облачные граничные приложения часто написаны на стандартных процедурных языках, таких как, например, Objective C, Java или С#. От разработчиков приложений требуется вручную реализовать механизмы, которые обрабатывают связи между устройствами, публикацию и подписку на потоки данных и связанную со временем семантику в логике приложений, как, например, временные присоединения и оконные вычисления. Этот процесс отнимает много времени и подвержен ошибкам. RACE может добавить поддержку платформы для общего функционала, совместно используемого большинством облачно-граничных приложений. Разработчики приложений могут затем сфокусироваться на базовой логике приложений, а не на деталях реализации.

Настоящие варианты реализации используют тот факт, что, хотя различные облачно-граничные приложения имеют разнообразные характеристики, зависящие от приложений (например, визуализацию и поддержку личной информации), они могут иметь общие черты. Например, данные и базовая логика приложений для облачно-граничных приложений часто являются временными по своей природе. Другими словами, облачно-граничные приложения можно рассматривать как непрерывные запросы, которые непрерывно коррелируют данные в реальном времени и медленно меняющиеся (но по-прежнему временные) справочные данные в высокой степени распределенной системе.

Например, приложение по поиску друзей можно рассматривать как временное присоединение (связывание) между местоположениями GPS в реальном времени граничных устройств и более медленно меняющимся потоком социальной сети. Приложение купонов, учитывающее местоположение, коррелирует информацию о местоположении пользователя с профилями пользователей (вычисленными в историческом окне времени) и текущими рекламными объявлениями. Таким образом, в некоторых вариантах осуществления язык спецификации для облачно-граничных приложений должен содержать родную поддержку временной семантики. Такая поддержка способствует ясному выражению временно-ориентированных операций, как, например, временные присоединения и оконные объединения. Альтернативно или дополнительно, язык может иметь другие свойства. Например, одним таким свойством является описательная природа языка спецификации. Это может позволить разработчикам приложений определять приложения описательным и независимым от топологии сети образом, где они могут сфокусироваться на том, «какие» приложения, а не «как» они реализуются. Детали осуществления могут быть прозрачными для разработчиков приложений и быть обработанными автоматически с помощью базовой платформы. Другое свойство может относиться к краткости. Спецификация приложений может быть краткой, что позволяет продуктивную разработку прототипов, подготовку к эксплуатации и отладку для разработчиков приложений. Краткость естественным образом связана с внедрением описательных спецификаций. Гибкость может быть другим свойством. Язык спецификации может быть гибким, чтобы разработчики приложений могли легко настраивать приложение в соответствии с различными входящими/выходящими источниками и конфигурациями.

Пространство разработки для языков спецификации описано сейчас в свете этих свойств. Описательные языки, такие как, например, SQL и Datalog (и его варианты, например, Network Datalog), могут обеспечить краткое и гибкое описание непрерывных запросов в распределенных окружениях. Однако эти языки не имеют родной поддержки временной семантики, что может быть важным для большинства облачно-граничных приложений. С другой стороны, системы управления потоками данных (DSMS) используют описательные временные языки, которые удовлетворяют желаемым свойствам. Примеры включают в себя LINQ™ для StreamInsight™, StreamSQL™ для Oracle® CEP и StreamBase™. Описание ниже использует LINQ для StreamInsight в качестве языка спецификации, но он применим и к другим конфигурациям. LINQ обеспечивает описательную спецификацию временных запросов и основан на хорошо определенной алгебре и семантике, которые соответствуют временной природе облачно-граничных приложений.

В следующем обсуждении приводится пример спецификации облачно-граничных приложений. Вспомним, что запрос по поиску друзей ищет все пары пользователей (Пользователь 1, Пользователь 2), которые удовлетворяют условиям: 1) Пользователь 2 является другом Пользователя 1; и 2) два пользователя географически близки друг к другу в данное время. Здесь, с целью объяснения, предположим, что дружеские отношения асимметричны, то есть тот факт, что Пользователь 2 является другом Пользователя 1, необязательно подразумевает обратное, в данный момент времени. Существует два ввода в приложение по поиску друзей, а именно потоки местоположения GPS, направленные граничными устройствами, и данные социальной сети. Местоположения GPS активно собираются во время исполнения, в то время как данные социальной сети относительно медленно меняются и, в общем, доступны в облаке. Приложение по поиску друзей может быть написано в качестве двухступенчатого временного запроса на присоединение, как изображено ниже.

var query0 = from e1 in location

from e2 in socialNetwork

where e1.UserId==e2.UserId

select new {e1.UserId, e1.Latitude,

e1.Longitude, e2.FriendId};

var query1 = from e1 in query0

from e2 in location

where e1.FriendId == e2.UserId &&

Distance(e1.Latitude, e1.Longitude,

e2.Latitude, e2.Longitude) < THRESHOLD

select new {User1 = e1.UserId, User2 = e2.UserId}

Первый запрос (query0) присоединяет поток (location) местоположения GPS к справочному потоку социальной сети (socialNetwork), и получившийся выходной поток присоединяется опять к местоположениям GPS (в query1) для проверки расстояния между каждой парой друзей. Конечный вывод - поток пар (Пользователь 1, Пользователь 2), где два пользователя являются друзьями и географически близки друг к другу.

Вышеуказанная спецификация запроса определяет высокоуровневую логику запроса в качестве временных присоединений и ссылается на схемы потока location и потока socialNetwork. Это записано в потоке социальной сети и концептуально объединено с вводом потока местоположения GPS, и, таким образом, является независимым от топологии сети. В качестве другого примера, предположим, что желаемая функция - найти друзей, которые посещали конкретное местоположение (например, ресторан) на прошлой неделе. Чтобы это определить, концепции настоящего изобретения могут позволить заменить ввод местоположения в query1 на location.AlterEventDuration(TimeSpan.FromDays(7)). Это расширяет «время существования» событий в местоположении до 7 дней, что позволяет при присоединении учесть события друзей за прошлую неделю.

Подводя итог, RACE может использовать описательную спецификацию облачно-граничного приложения. RACE может выполнять логику на распределенной системе, состоящей из граничных устройств и облака. RACE может использовать немодифицированную DSMS в качестве черного ящика для локального выполнения запросов на отдельных граничных устройствах и в облаке. Некоторые реализации RACE могут функционировать, основываясь на предположении о том, что DSMS обеспечивает пользователям прикладной программный интерфейс (API) управления для подачи запросов (что определяет непрерывные запросы для выполнения), типов событий (что определяет схему входящих потоков данных) и адаптеров ввода и вывода (что определяет то, как потоковые данные достигают DSMS из внешнего мира и наоборот). Дополнительно, API также позволяет пользователям начинать и прекращать запросы DSMS.

Говоря другими словами, некоторые реализации могут передвинуть различные потоки данных (или части потоков) в облако и/или на другие граничные вычислительные устройства через облако. Некоторые другие потоки данных могут остаться локально в устройстве и не выгружаться в облако. Дополнительно, эти разнообразные (перемещенные и локальные) потоки могут служить в качестве вводов в сегменты запросов приложений, выполняемых в разнообразных местоположениях (как, например, подгруппа устройств или даже облако). Выходные потоки таких запросов сами могут либо остаться локально для дополнительных вычислений, либо выгружаться в облако (и затем, возможно, быть направленными на другие устройства). В общем, вычисление, определенное конечным пользователем, может быть выполнено распределенным образом.

АРХИТЕКТУРА RACE

Фиг. 2 изображает общую систему или архитектуру 200 системы одного варианта осуществления RACE. Архитектура 200 системы распространяется на вычислительные устройства 102(1)-102(N), облако 104 и сеть 106 на фиг. 1. Архитектура 200 системы вводит сервис 202 управления RACE и процессор 204 RACE. Процессор RACE включает в себя конструктор 206 графов, оптимизатор 208 и конструктор 210 запросов. Архитектура 200 системы также включает в себя статистические данные 214, справочные данные 216, плоскость 218 управления и плоскость 220 данных. Вычислительные устройства 102(1)-102(N) включают в себя экземпляр 222(1)-222(3) DSMS, соответственно. Экземпляр 222(4) DSMS также есть в облаке 104.

Архитектура 200 системы объяснена относительно опыта, обеспечиваемого разработчику 224 приложений. Разработчик приложений может взаимодействовать с сервисом 202 управления RACE путем написания приложения на описательном и временном языке, таком как, например, LINQ 226. Предположим с целью объяснения, что приложение является приложением 228 по поиску друзей. Функциональность приложений по поиску друзей была введена выше по отношению к фиг. 1. Приложение 228 по поиску друзей может быть манифестом на отдельных вычислительных устройствах 102(1)-102(N) в качестве экземпляров 228(1)-228(3), соответственно, и в облаке 104 в качестве экземпляров 228(4) приложений по поиску друзей. Дополнительно, хотя это изображено только по отношению к вычислительному устройству 102(1) для краткости, отдельные вычислительные устройства могут включать в себя разнообразные аппаратные средства 230. В этом примере изображенные аппаратные средства - это процессор 232, хранилище 234 данных и другие 236. Вышеуказанные элементы описаны более подробно ниже.

Процессор 232 может выполнять данные в форме машиночитаемых команд для обеспечения функциональности, такие как, например, функциональности приложения по поиску друзей. Данные, как, например, машиночитаемые команды, могут храниться в хранилище 234 данных. Хранилище данных может быть внутренним или внешним по отношению к вычислительному устройству. Хранилище 234 данных может включать в себя одно или несколько энергозависимых или энергонезависимых запоминающих устройств, жестких дисков и/или оптических устройств хранения (например, CD, DVD и так далее), среди прочих.

Компьютер 102(1) также может быть выполнен с возможностью принимать и/или формировать данные в форме машиночитаемых команд от хранилища 234 данных. Компьютер 102(1) может также принимать данные в форме машиночитаемых команд по сети 106, которые затем сохраняются на компьютере для выполнения процессором.

В альтернативной конфигурации, компьютер 102(1) может быть осуществлен в качестве типа дизайна системы на кристалле (SOC). В таком случае функциональность, обеспечиваемая компьютером, может быть интегрирована на единой SOC или множестве соединенных SOC. В некоторых конфигурациях вычислительные устройства могут включать в себя общие ресурсы и закрепленные ресурсы. Интерфейс(ы) усиливает связь между общими ресурсами и закрепленными ресурсами. Как подразумевает название, закрепленные ресурсы можно рассматривать как включающие отдельные части, которые закреплены для достижения конкретной функциональности. Общие ресурсы могут быть хранилищем, обрабатывающими блоками и так далее, которые могут быть использованы множеством функциональностей.

В общем, любая из функций, описанных в настоящей заявке, может быть осуществлена с использованием программного обеспечения, программно-аппаратных средств (firmware), аппаратных средств (например, неизменяемой логической схемы), ручной обработки или комбинации этих вариантов осуществления. Термин «инструмент», «компонент» или «модуль», как использовано в настоящей заявке, в общем, представляет собой программное обеспечение, программно-аппаратные средства, аппаратные средства, целые устройства или сети, либо их комбинацию. В случае осуществления в программном обеспечении, например, это может представлять собой программный код, который выполняет конкретные задания при исполнении на процессоре (например, CPU или несколько CPU). Программный код может храниться на одном или нескольких машиночитаемых запоминающих устройствах, таких как, например, машиночитаемый запоминающий носитель данных. Характеристики и способы компонента являются независимыми от платформы, что означает, что они могут быть осуществлены на различных коммерческих платформах, имеющих разнообразные конфигурации обработки.

Как использовано в настоящем документе, термин «машиночитаемые носители» может включать в себя переходные и непереходные команды. Напротив, термин «машиночитаемые запоминающие носители» исключает переходные экземпляры. Машиночитаемые запоминающие носители могут включать в себя «машиночитаемые запоминающие устройства». Примеры машиночитаемых запоминающих носителей включают в себя энергозависимые запоминающие носители, как, например, RAM, и энергонезависимые запоминающие носители, как, например, жесткие диски, оптические диски и флэш-память, среди прочих.

Другие аппаратные средства 236 могут включать в себя устройства отображения, устройства ввода/вывода, сенсоры и так далее, которые могут быть реализованы на различных вычислительных устройствах.

Сервис 202 управления RACE может выполняться в облаке 104 и предоставлять сервис управления, который полностью совместим с API управления DSMS. Таким образом, отдельные вычислительные устройства 102(1)-102(N) могут направить их описательную логику облачно-граничных приложений сервису 202 управления RACE в качестве регулярных временных описательных запросов, поддерживаемых соответствующими DSMS 222(1)-222(N). Необходимо отметить, что с точки зрения граничного устройства (например, вычислительных устройств 102(1)-102(N)), они просто связываются с обычным модулем DSMS.

Если посмотреть с другой точки зрения, сервис 202 управления RACE можно рассматривать как выполненный с возможностью взаимодействовать с приложением, выполняющимся в облаке и на отдельных граничных вычислительных устройствах в связи с облаком. Сервис 202 управления RACE может быть выполнен с возможностью воспроизводить модуль DSMS для приема временных описательных запросов от отдельных граничных вычислительных устройств.

Кратко, процессор 204 RACE можно рассматривать как перехватывающий и проводящий синтаксический анализ входящего запроса, адаптеров и типов от отдельных вычислительных устройств 102(1)-102(N), исполняющих приложение 228 по поиску друзей. Процессор 204 RACE затем компилирует эти вводы в объектное представление исходного запроса. Это объектное представление подается в модуль 206 конструктора графов, который преобразует исходный запрос в больший граф запросов. Например, больший граф запросов может включать в себя граничные входящие потоки и операторы. Граф запросов подается в модуль 208 оптимизатора для решения оптимального размещения оператора. Наконец, модуль 210 конструктора запросов может формировать представления типов, адаптеров и (под-)запросов для выполнения на отдельном вычислительном устройстве 102(1)-102(N) или в облаке 104. Эти объекты отправляются в отдельные DSMS (через их API управления) соответствующих вычислительных устройств для выполнения логики приложения распределенным образом. Необходимо отметить, что хотя в этой конфигурации сервис 202 управления RACE и процессор 204 RACE реализованы в облаке 104, в других вариантах осуществления, альтернативно или дополнительно, сервис управления RACE и/или процессор RACE могут быть реализованы в одном или нескольких вычислительных устройствах 102(1)-102(N). Сервис управления RACE и/или процессор RACE, реализованные на вычислительных устройствах, могут быть автономными или работать во взаимодействии с соответствующим сервисом управления RACE и/или экземплярами процессора RACE в облаке.

Конструктор 206 графов можно рассматривать как получающий объектное представление запроса в качестве ввода вместе со статистикой потоковых скоростей передачи и информацией о метаданных по каждому вводу. Конструктор графов сначала может использовать объектное представление запроса для формирования шаблона запросов, который представляет собой шаблон или основу формирования расширенного графа запросов. Например, фиг. 3 изображает шаблон 302 запросов, выведенный конструктором 206 графов для запроса поисковика друзей, описанного выше по отношению ко второму абзацу на стр. 14.

Некоторые из входных потоков в шаблоне 302 запросов соответствуют потокам данных отдельных устройств, таких как, например, источники местоположения GPS. Конструктор 206 графов может создавать множество экземпляров шаблона запросов путем разделения таких потоков на множество вводов, один на ребро. Вводы медленно меняющихся справочных данных, таких как, например, социальная сеть, могут быть материализованы для ограничения размера сформированного графа запросов. Например, фиг. 4 изображает социальную сеть 400 из четырех пользователей P, Q, R и S. Фиг. 5 изображает соответствующие созданные экземпляры шаблонов 502(1), 502(2) и 502(3) запросов для запроса приложения по поиску друзей. Необходимо отметить, что для того, чтобы позволить делиться информацией и избежать дублирующих ребер в созданных экземплярах шаблонов запросов, созданный экземпляр источника и операторы присоединения тщательно именуются, как изображено на фиг. 5. Конечный этап - это вшить созданные экземпляры шаблонов 502(1)-502(3) запросов в завершенный граф запросов.

Фиг. 6 изображает конечный граф 602 запросов, полученный из созданных экземпляров шаблонов запросов, изображенных на фиг. 5. Необходимо отметить, что при комбинировании созданных экземпляров шаблонов запросов вершины (в созданных экземплярах шаблонов) с одинаковым именем соотносятся с одной и той же вершиной в конечном графе запросов. Например, вершина Join<GPS-P, SNP> совместно используется созданными экземплярами шаблонов для ребер (P; R) и (P; S).

Возвращаясь к фиг. 2, модуль 208 оптимизатора принимает конечный граф 602 запросов в качестве ввода и решает, где выполнять каждый оператор (например, часть запроса) в графе запросов, чтобы общие или коллективные издержки связи приложения были минимальными (или, по меньшей мере, сокращены). При участии тысячей или даже миллионов пользователей в облачно-граничной системе конечный граф запросов может быть огромным - содержащим миллионы операторов. Для такого огромного графа запросов оптимальное размещение оператора не очевидно. Модуль оптимизатора RACE может использовать разнообразные технологии для определения оптимального размещения оператора. Один такой способ описан ниже под заголовком «Оптимальное размещение оператора». RACE может выполнять периодическую повторную оптимизацию для регулирования размещения изменений в графе запросов и/или статистике.

После того как решения для улучшенного/оптимального размещения оператора приняты, процессор 204 RACE имеет группу корневых графов (каждый состоит из направленных ациклических графов (DAG) временных операторов). Каждый такой граф соответствует некоторому местоположению (границе или облаку). Модуль 210 конструктора запросов может формировать объектные представления компонентов запроса (включая типы событий, адаптеры и запросы) для каждого графа. Модуль конструктора запросов может затем направить объектные представления соответствующим DSMS через плоскость 218 управления. Необходимо отметить, что два дополнительных адаптера могут быть установлены на каждом экземпляре DSMS - один для отправки данных события в плоскость 220 данных, а другой для приема данных события от плоскости данных.

Плоскость 218 управления RACE используется для развертывания сформированных фрагментов запроса и метаданных в облачный экземпляр и граничные экземпляры DSMS, с использованием API управления DSMS. Затруднением является то, что гран