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

Question

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

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

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

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

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

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

Я задавался вопросом, существуют ли лучшие практики для таких случаев.

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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