Ограничение по размеру Azure и IOT

Question

Я прочитал документацию по лазурности и обнаружил, что ограничение размера сообщений в Очереди составляет 64 КБ, а служебная шина - 256 КБ. Мы пытаемся разработать приложение, которое будет считывать данные датчиков с некоторых устройств, вызывать службу REST и загружать их в облако. Эти данные будут храниться в очередях и затем сбрасываться в базу данных Cloud.

Возможно, есть вероятность, что собранные данные датчиков превышают 256 КБ ... В таких случаях рекомендуемый подход ... Нужно ли разделить данные в службе REST, а затем положить куски данных в очереди или есть какой-либо другой рекомендуемый шаблон

любая помощь

Answer 1

у вас есть несколько противоречивых заявлений технологии. Я начну с разъяснения нескольких.

1. Сервисные шины/концентратор IoT не являются почтовыми вызовами. Почтовый вызов будет использовать восстановленную службу , которая существует отдельно. IoT Hub использует низкую систему передачи сообщений с задержкой, которая абстрагируется от вас. Эти предназначены для небольших объемов небольших объемов и подходят для большинства сценариев IoT .

2. В ситуации, в которой сообщение больше, чем 256 Кб (что очень интересно для сценария IoT, мне было бы интересно, чтобы понять, почему эти сообщения настолько велики), вы должны в идеале загрузить на хранилище больших двоичных объектов , Вы все еще можете добавлять пакеты

   • Если у вас есть доступ к памяти блоб API, с устройствами, вы должны идти по этому пути

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

     3. Вы можете запускать пост-аналитику на хранилище blob, я бы рекомендовал использовать префикс wasb, поскольку эти контейнеры соответствуют требованиям Hadoop, и вы можете встать на кластеры аналитики поверх этих механизмов хранения.

У вас нет реальной необходимости в очереди, я могу сразу увидеть.

Вы должны смотреть на узоры Усиливая:

1. поток Аналитика: https://azure.microsoft.com/en-us/services/stream-analytics/
2. Azure Data Factory: https://azure.microsoft.com/en-us/services/data-factory/

Ваш типичный прием пищи будет: Получить данные вверх в облако в супер дешевое хранилище, насколько это возможно, а затем заниматься аналитикой позже, используя кластеры, вы можете встать и снести по требованию. Это дешевое хранилище, как правило, blob, и что аналитический кластер обычно представляет собой некоторую форму Hadoop. Использование фабрики данных позволяет вам собирать ваши данные, когда вы выясняете, для чего собираетесь использовать определенные компоненты.

Пример использовав HBase в рот с дешевой хранения больших двоичных объектов в качестве подстилающего и Azure Machine Learning в рамках моего аналитического решения: http://indiedevspot.com/2015/07/09/powering-azureml-with-hadoop-hbase/