DocumentDB - Сохранение данных телеметрии

Question

так быстрое обновление, почему я создал этот вопрос.

В настоящее время мы сохраняем наши данные телеметрии наших устройств в поле в Azure SQL Server. Это отлично работает (у меня много опыта с EF, LINQ и dbs отношения). Но я знаю, что это, скорее всего, не лучшее решение, особенно для хранения «больших» данных (данные пока еще малы, но будут расти в течение года).

Я выбрал DocumentDB как наше возможное решение для хранения только истории событий. Остальные останутся в SQL - пользователи, профили, информация об устройстве, sim, автомобиль и т. Д., Так как я не хочу полностью останавливать разработку, поскольку мы перемещаем 100% в docdb и скорее просто делаем то, что лучше всего - краткосрочная - стоимость + производительность.

Просматривая это видео, я, наконец, придумал возможное решение о том, как хранить данные телеметрии. https://www.youtube.com/watch?v=-o_VGpJP-Q0 Они рекомендовали один документ за период времени (пример использовался 1 раз в час). Это рекомендуемый подход?

[Index] 
    public DateTime TimestampUtc { get; set; } 
    public DateTime ReceivedTimestampUtc { get; set; } 
    [Index] 
    public EventType EventType { get; set; } 
    public Guid ConnectionId { get; set; } 
    public string RawEventMessage { get; set; } 
    [Index] 
    public Sender Sender { get; set; } 
    [Index] 
    public Channel Channel { get; set; } 
    public DbGeography Location { get; set; } 
    public double? Speed { get; set; } 
    public double? Altitude { get; set; } 
    public Int16? Heading { get; set; } 
    public Byte? HDOP { get; set; } 
    public Byte? GPSFixStatus { get; set; } 
    public Byte? GPSFixType { get; set; } 
    public string Serial { get; set; } 
    public string HardwareVersion { get; set; } 
    public string FirmwareVersion { get; set; } 
    public string Relay1 { get; set; } 
    public string Relay2 { get; set; } 
    public string Relay3 { get; set; } 
    public string Ign { get; set; } 
    public string Doors { get; set; } 
    public string Input1 { get; set; } 
    public string Input2 { get; set; } 
    public string Out1 { get; set; } 
    public string Out2 { get; set; } 
    public int V12 { get; set; } 
    public int VBat { get; set; } 

Answer 1

Это один из нескольких возможных альтернатив. Это лучше всего зависит от того, как выглядят ваши данные. Например, если у вас есть события, которые различаются по дате начала/времени и продолжительности (или дате окончания/времени), или если вы отслеживаете все изменения состояния объектов, то что-то вроде Richard Snodgrass «модель временных данных идеально. Интересно, что Microsoft SQL Server 2016 недавно добавил прямую поддержку для temporal tables, но они некоторое время были в спецификации SQL как TSQL2. Обратите внимание: спецификация TSQL2 включает в себя как поддержку valid-time, так и transaction-time, но я считаю, что недавнее дополнение MS SQL 2016 поддерживает только время ... но это нормально, так как это самое ценное. Я только указываю на это, потому что получить голову от того, как работает таблица действительного времени, достаточно сложна, без дополнительной сложности добавления транзакции.

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

Однако, как вы сказали, SQL не идеален для таких больших наборов данных. Итак, я внедрил временную модель стиля Ричарда Снодграсса на верхушке DocumentDB в моей библиотеке Lumenize, в частности, TimeSeriesCalculator и других ее функциональных возможностях. Прочтите страницы 10-19 here для получения справочной информации по модели данных и общих операций в анализе временных рядов Lumenize. Эта колода предназначена для реализации, которую я делал, когда Rally называл API обратного вызова, построенный на MongoDB, но понятия те же, и теперь я переключился на DocumentDB (но у Rally нет).

Еще один комментарий к вашей предлагаемой модели, вы можете рассмотреть отдельный документ для каждого чтения. Это немного запутанно из примера, если есть документ в минуту или по одному на устройство. Если это один на устройство в час, то вы можете быть уверены, что за 60 минут вы не пройдете, и все будет в порядке, но почти так, как я могу думать, похоже, что у вас есть риск одного неограниченный документ, который является большим нет-no в DocumentDB (и все моделирование данных NoSQL). Кроме того, как вы говорите, даже если он не является неограниченным, он будет включать множество обновлений на месте. Поскольку ваша система, вероятно, будет тяжелой, я бы предположил, что вам может быть лучше с одним документом за чтение. Если вам нужно впоследствии сохранить денормализованные скопления для скорости, у вас все еще есть возможность сделать это. Возможно, вам это даже не понадобится. Пусть это приведет к результату производственной системы.

Предлагаю вам ознакомиться с измерениями времени для звездных схем.Он очень похож на то, что вы планируете, но он также идеален для денормализованного хранилища агрегации, которое я описываю. Я не видел никаких комментариев о концепциях схемы звездочек для NoSQL, но here является одним из традиционного мира SQL, который поможет вам в концепциях.

Как я уже сказал, есть много альтернатив и, не зная больше о вашей ситуации, я не знаю, что лучше.

Answer 2

Хорошо, поэтому я думаю, что я собираюсь для 1 документа за событие (сейчас 1 раз в 5 минут, но может меняться на 1 секунду за устройство). Причина в том, что добавление к документу должно быть дорогостоящим, поскольку вам нужно «заменить» на этом документе? (теперь docdb поддерживает добавление/частичное обновление?) Конечно, это включает в себя чтение, а затем растущую замену, которая была бы более дорогостоящей и своевременной, чем просто добавление нового документа для каждого события. Единственное беспокойство - когда у нас есть миллионы/миллиарды документов ... это прекрасно?