Хранение сигналов в базе данных

Question

Я разрабатываю приложение, которое получает информацию от примерно 100 тыс. Датчиков, которые измеряют данные временных рядов. Каждый датчик измеряет одну целочисленную точку данных каждые 15 минут, сохраняет журнал этих значений и отправляет этот журнал в мое приложение один раз каждые 4 часа. Моя заявка должна хранить около 5 лет исторических данных. Пакет, который я получаю раз в 4 часа, имеет следующую структуру:

• Данные и время начала последовательности
• Количество полученных образцов (предположим, это ради простоты, хотя на практике могут быть частичные)
• Последовательность семплов, каждый из которых составляет ровно 4 байта

Основной сценарий использования моего приложения - отображение графиков составных сигналов в определенные даты. Когда я говорю «составные» сигналы, я имею в виду, что, например, мне нужно показать результат добавления сигнала датчика A к сигналу датчика B и вычитания сигнала датчика C.

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

1. Сохраняйте каждый семпл в отдельном ряду: при получении сигнала разбивайте его на семплы и сохраняйте каждый семпл отдельно с его временной меткой. Предположим, что временные метки можно нормализовать по сигналам.
2. Сохранять каждый 4-часовой сигнал в виде отдельной строки с указанием времени начала. В этом случае всякий раз, когда приходит сигнал, я просто добавляю его в качестве BLOB в базу данных.

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

Интересно, есть ли лучшие практики для таких случаев?

Большое спасибо.

Answer 1

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

Answer 2

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

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

Это также может быть "достаточно хорошо" при запросе данных. Однако, если производительность является проблемой, и / или если вы получаете огромное количество объема [100 000 датчиков x 1 за 15 минут x 4 часа = 9 600 000 строк в день, x 5 лет = 17 529 600 000 строк или около того в течение пяти лет]. На мой взгляд, если вы хотите написать гибкие запросы к данным такого рода, вам понадобится некоторая форма структуры звездообразной схемы (которая используется в хранилищах данных).

Загружаете ли вы данные непосредственно в хранилище или позволяете создавать «построчно» для добавления в хранилище день / неделя / месяц / что угодно, зависит от времени, усилий, доступных ресурсов и т. Д. .

Последнее предложение: когда вы настраиваете тестовую среду для своего нового кода, загрузите его за несколько лет (фиктивных) данных, чтобы посмотреть, как он будет работать.

Answer 3

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

Я думаю, вы должны:

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

Answer 4

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

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