Azure Исходные соображения временного ряда (TSI) и лучшие практики - PullRequest
Новая
       27

Azure Исходные соображения временного ряда (TSI) и лучшие практики

0 голосов
/ 17 марта 2020

Мои извинения за плохое название!

Я на начальной стадии разработки решения Azure Time Series, и я столкнулся с рядом неопределенностей. Предпосылкой для перехода в TSI является то, что в настоящее время у нас есть довольно плохо спроектированная база данных космоса, которая содержит около 1 ТБ данных IoT и растет с каждой минутой. Под «плохо» я подразумеваю, что ключ раздела был разработан таким образом, что мы не можем контролировать размер разделов. Зная, что существует ограничение в 10 ГБ (?) Ключа раздела pr, у нас скоро не хватит места, и нам нужно будет найти новое решение. Кроме того, при запуске исторических запросов на базе данных космоса он не отвечает в течение приемлемого периода времени. Любые эксперименты с расчетами и изменениями пропускной способности не улучшают время отклика на принятый период времени.

Мы занимаемся регистрацией данных временных рядов IoT, включая метаданные от различных датчиков. У нас есть ряд клиентов, каждый из которых имеет от 30 до 300 датчиков - все меньше и больше клиентов. На стороне клиента датчики сгруппированы в местоположения и подобласти.

Примером события может быть что-то вроде этого: 

{
  deviceId,
  datetime,
  clientId,
  locationId,
  sub-locationId,
  sensor,
  value,
  metadata{}
}

Зная, как лучше спроектировать ключ раздела в CosmosDB, будет ли такой же подход, как описанный ниже, рассматриваться как хорошая практика в TSI при составлении TimeSeriesId?

  • В совершенно другом решении cosmosdb мы включили eventDate.datepart (YYYY-MM) в качестве часть ключа раздела, чтобы не дать ему выйти за пределы и лучше предсказать время ответа на запросы в пределах одного раздела.

Или TSI будет обрабатывать данные временных рядов по-другому, в результате чего datepart в TimeSeriesId будет устаревшим ?

Имея в виду запросы API TSI, следует ли мне учитывать простоту составленного TimeSeriesId? TimeSeriesId должен быть указан в теле каждого запроса API - насколько я могу судить, и при составлении запроса в серверной службе у меня есть доступ ко всем идентификаторам наших клиентов и идентификаторам местоположения / местоположения. И они более доступны, чем ID устройства

И, наконец, при хранении данных IoT для нескольких клиентов было бы целесообразно предоставить новое решение TSI для каждого клиента или TSI поддерживает коллекции, как это видно из CosmosDB?

1 Ответ

0 голосов
/ 18 марта 2020

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

Если ваш источник событий является концентратором IoT, ваш идентификатор временного ряда, скорее всего, будет iothub-connection-device-id.

Итак, я предполагаю, что у вас будет хотя бы один IoT Hub, который будет получать события, сообщаемые от устройств, и в этом случае вы можете использовать iothub-connection-device-id .

...