LINUX.ORG.RU

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


0

2

Есть куча разных сенсоров (gps, акселерометр, термодатчик, ...), данные с них собираются от 1 до 1000 раз в секунду. В теории могут быть и новые хотелки, вроде добавления микрофона и записи звука. Вопрос - как все это хранить?

Пусть сейчас 10 каналов по 1000 записей в сек, запись 2 байта = 20000 байт/сек = 51 840 000 000 в месяц, что для мобильного устройства многовато. Запись может идти неделями.

Пока в голове идея разбить данные, скажем, на минуты (1 200 000, чуть более мегабайта), а затем каждую минуту сжимать гзипом. Получившиеся «минуты» сложить в файл. Для навигации по этим минутам нужен индекс. Так как мы не знаем как долго будет идти запись, то нужен супер-индекс для адресации минутных индексов.

Не могу отделаться от ощущения, что где-то такое я уже видел, но где? В общем, не хочу думать (вместе данные писать или по датчикам разделить), хочу готовое решение, задача в общем-то очевидная и распространенная.


Пусть сейчас 10 каналов

Вот и введи в свой формат понятие канала и пиши с разной частотой. Нафига тебе знать, что за последние 100500 отсчётов температура не менялась?

по 1000 записей в сек

пиши разницу.

запись 2 байта

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

ziemin ★★
()

задача в общем-то очевидная и распространенная

а что вы с этими данными собираетесь потом делать? Как работать/использовать, хотя-бы поначалу..

можно ведь и валидный xml пихать в /dev/null :-)

ps/ самое распростое решение - каждый датчик пишет поток в свой файл со своей скоростью,форматом и частотой, но раз в секунду в индексный файл заносятся текущие длины файлов.

MKuznetsov ★★★★★
()

libgit2

Боюсь, для записей по 2 байта, будет большой оверхед

а что вы с этими данными собираетесь потом делать? Как работать/использовать, хотя-бы поначалу..

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

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

Вот и введи в свой формат понятие канала и пиши с разной частотой.

Ну это само собой, лишних данных писать никто не будет, но вот акселерометр дает скажем 1000 отсчетов и всех их надо записать.

Нафига тебе знать, что за последние 100500 отсчётов температура не менялась?

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

пиши разницу

Сначала я тоже думал что хорошее решение для температуры (потом можно RLE пожать), но если питание пропадет, мы останемся без N-последних отсчетов, которые застрянут в буффере компрессора. Опять же, если каждый канал данных писать отдельно, встает проблема синхронизации. Я уже не говорю о том, что акселерометр всегда шумит и последовательность нулей из него не вытащить (разве что изобрести шумодав, от которого может больше вреда).

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

8-12-16 бит, в зависимости от битности датчиков. Алсо, 12-битные данные хочется писать как 16-битные: во-первых работать проще, а во-вторых сжатие должно быть лучше за счет однородности данных.

dunom2
() автор топика

sqrt(2) = sqrt(1^2 + 1^2)

anonymous
()

ROOT, HDF5 уже помянутый. Я много чего смотрел в итоге свое навелосипедил с SQLite для хранения блобов и snappy для компрессии. У меня данных много прет, поэтому на существующих не взлетело.

ebantrop
()
Ответ на: комментарий от silw

А чем не устроила компрессия в hdf5?

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

ebantrop
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.