Что лучше всего: публиковать данные в azure iothub или непосредственно в azure tablestorage

У меня есть веб-приложение. Текущая структура \ поток приведена ниже.

  • У этого есть веб-сервис, который используется модулем устройства для размещения данных устройства в моем хранилище таблиц.
  • В конце пользовательского интерфейса SignalR используется для отображения на панели инструментов (view-cshtml) последнего значения, отправленного в облако, когда данные с устройства попадают в TableStorage.
  • Ожидается, что данные с разных устройств попадут в TableStorage, и в конце пользовательского интерфейса, в соответствии с выбранным устройством, будут отображаться соответствующие данные.

Мой запрос

  1. Будет ли выгода от использования ресурса Azure, IOTHub, вместо прямой публикации в TableStorage, на который устройства могут публиковать свои данные? Если да, пожалуйста, дайте мне знать об этом.

    -> а. В этом случае, куда следует отнести данные, размещенные в IoTHub, для хранения всех полученных данных для дальнейшего использования?

    ---> б. Ранее я использовал вариант использования StreamAnalytics, использовал запрос для вставки данных, получаемых на конце IoTHub, в TableStorage. Доступен ли единственный \ хороший вариант?

    ---> c. Или у нас есть другие варианты хранения данных, опубликованных в IoTHub?

  2. Нормален ли текущий поток вставки данных непосредственно в TableStorage с устройства (лучшая практика?)? Если нет, пожалуйста, предложите лучший способ решения.


azure c# azure-table-storage signalr azure-iot-hub
person jAntoni    schedule 16.11.2017    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Сообщения от устройства к облаку направляются во встроенную конечную точку, ориентированную на службы (сообщения / события), которая совместима с Центры событий. Эти сообщения хранятся в Центре Интернета вещей. По умолчанию это один день, но его можно увеличить до семи дней. Вы можете изменить время хранения программно через API REST поставщика ресурсов Центра Интернета вещей или с помощью портала Azure. Таким образом, вам не нужно публиковать данные напрямую в хранилище таблиц, Центр Интернета вещей может хранить данные как кеш.

Хранилище Azure состоит из трех служб данных: Хранилище BLOB-объектов , Хранилище файлов и Хранилище очередей. Хранилище BLOB-объектов поддерживает как стандартное хранилище, так и хранилище премиум-класса, при этом в хранилище премиум-класса используются только твердотельные накопители для максимальной производительности. Еще одна функция - отличное хранилище, позволяющее хранить большие объемы редко используемых данных по более низкой цене.

person Michael Xu - MSFT    schedule 17.11.2017
comment
1. Требуется постоянное хранение данных, как в классической базе данных. В веб-приложении должны быть опции для просмотра исторических данных. Так поддерживает ли это IoTHub? ____ 2. В чем преимущество публикации в IoTHub вместо прямой вставки в TableStorage? - person jAntoni; 17.11.2017
comment
1.IoTHub не поддерживает постоянное хранение данных. 2. Вы можете получить информацию и преимущества об IoTHub по этой ссылке. - person Michael Xu - MSFT; 20.11.2017
comment
Хорошо, спасибо, MichaelXu. - person jAntoni; 20.11.2017

arrow_upward
0
arrow_downward

Я читал о получении данных с помощью IoTHub и TableStorage. Мой анализ и, самое главное, мой опыт использования хранилища таблиц дали мне некоторое понимание этого.

Есть веская причина публиковать данные в IoTHub, прежде чем хранить их в storageTable.

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

Причина

Хотя публикация данных в TableStorage тоже работает нормально, при этом могут возникнуть проблемы с производительностью.

  • Проблема здесь в том, что когда объем данных в TableStorage увеличивается, мы можем получить серьезный удар по производительности. Т.е. если TableStorage PK спроектирован таким образом, он может накапливаться для получения огромных данных в разделе в какой-то момент. Это приводит к запросу огромных данных.
  • Also TableStorage's limitation on having only index on PartitionKey and RowKey; So it works best - performance wise - when accessed via PartitionKey and RowKey.
    • Even if we access(query) via PartitionKey and RowKey there still will have huge data if the the Storage Table's data structure is designed to have such a PartitionKey. For instance if we collect 10 Device Signal details in TableStorage and design each PK to have the corresponding SignalID (such that each signal is grouped within a partition) ==> then the data coming in for Signal at one point will be huge within the partition. This in turn impacts the performance very badly.
person jAntoni    schedule 21.11.2017