-
- У меня практически работающая система сбора информации построенная мной с back-end'ом на SQLite.
Гетерогенные пакеты информации стекаются real-time потоками (~около
10ка "тонких") в базу данных со скоростью 100пак/сек, стробируясь
пространственно-временной меткой (GPS тоже пишется, но строб дает
не он). Потоки динамически run-time настраиваемы (таблица-поток).
Некоторые потоки представляют собой "толстые" Lidar данные (пакет
10-20кб * ~50-100 пак/сек). SQLite RxTx(1771 знак., 11.07.2020 17:33 - 17:38, ссылка, ссылка)
- Гениально! Можно сделать гибридную систему! Evgeny_CD(168 знак., 11.07.2020 17:34)
- > Простота и скорости записи "просто лога" с удобством SQL
базы. — Именно. Я так много написал чтобы дать понять, не надо
бояться SQLite, я сам ассемблерщик, lowlevel погромизд и
изобретатель своих велосипедов. Но я не представляю как бы мы
встряли, если бы я не уговорился на SQLite. Уговорил меня человек
пишущий в SQLite инфу с видеонаблюдения (втч ежеминутные снапштоты
с видео (блобы)). - RxTx(11.07.2020 18:15)
- SQLLite как-то не зашел. PostgreSQL сильно шустрее когда с базой
работает несколько процессов одновременно (т.е. всегда) - Cкpипaч(11.07.2020 18:18)
- Так и должно быть. SQLite это по сути "твоя маленькая переносная БД-библиотека с доступом через апи C-функций, пишушая в один файл". Большие серверы, разумеется, уделают SQLite потому что давно многопроцессны/многопоточны, умеют к дискам/RAID'ам через драйвера, и планировщики запросов там ой-ой-ой... - RxTx(11.07.2020 18:29)
- Я думал мир давно уже принял sqlite, как данность, что "лучше уже не сделаешь". Его единственный недостаток на данный момент - отсутствие JIT-компиляции запросов, под капотом это все еще байткодовая виртуальная машина. lloyd(114 знак., 11.07.2020 18:17)
- Спасибо, повникаем - MBedder(11.07.2020 18:16)
- SQLLite как-то не зашел. PostgreSQL сильно шустрее когда с базой
работает несколько процессов одновременно (т.е. всегда) - Cкpипaч(11.07.2020 18:18)
- > Простота и скорости записи "просто лога" с удобством SQL
базы. — Именно. Я так много написал чтобы дать понять, не надо
бояться SQLite, я сам ассемблерщик, lowlevel погромизд и
изобретатель своих велосипедов. Но я не представляю как бы мы
встряли, если бы я не уговорился на SQLite. Уговорил меня человек
пишущий в SQLite инфу с видеонаблюдения (втч ежеминутные снапштоты
с видео (блобы)). - RxTx(11.07.2020 18:15)
- Гениально! Можно сделать гибридную систему! Evgeny_CD(168 знак., 11.07.2020 17:34)
- Я предлагаю делать так. Evgeny_CD(667 знак., 11.07.2020 00:54, ссылка, ссылка)
- Не в кодировании счастье, а несчастье в том, что блоки данных от
приборов прилетают без индивидуальных TimeStamp'ов. Алексей
(-->) предложил наиболее близкий вариант того, что я сейчас
пытаюсь сделать - только вместо платки-бьютифаера с МК на каждый
порт пробую препендить каждый прилетающий пакет централизованным
TimeStamp'ом от GPS-приемника - MBedder(11.07.2020 11:43, ссылка)
- Имел в виду, что метки времени ставишь сам, конечно. - Evgeny_CD(11.07.2020 13:35)
- Не в кодировании счастье, а несчастье в том, что блоки данных от
приборов прилетают без индивидуальных TimeStamp'ов. Алексей
(-->) предложил наиболее близкий вариант того, что я сейчас
пытаюсь сделать - только вместо платки-бьютифаера с МК на каждый
порт пробую препендить каждый прилетающий пакет централизованным
TimeStamp'ом от GPS-приемника - MBedder(11.07.2020 11:43, ссылка)
- Как вариант ASAM MDF. Используется в автомобильной индустрии, но
очень универсален и соответственно наворочен. В тоже время,
позволяет создавать относительно простые автономные устройства для
логгирования данных за счет поддержки несортированных и
нефинализированных данных. Есть опенсоурс реализации ридера и
врайтера этого формата, утилиты для сортировки и финализации лога.
Синхронизация данных конечно же присутствует, но возможно не в том
виде в каком нужно Вам. - wetter(10.07.2020 21:39, , ссылка, ссылка)
- Спасибо, прикинем - MBedder(10.07.2020 23:50)
- А почему в "единый файл"? Пусть каждый поток пишет в свой файл, но
каждая запись пусть имеет сквозной номер. Таким образом при разборе
можно выявить реальную последовательность записей, при этом
упростить формат файла каждого потока (сделав записи в каждом файле
своего одинакового размера). Этот принцип используется для фиксации
событий с возможностью составить полный журнал событий. - VLLV(10.07.2020 20:38)
- Это сейчас и делается, но вместе со "сборным" файлом. Без него
стремновато - отдельные файлы могут потеряться/побиться по пути от
самолета до московского обработчика - MBedder(10.07.2020 20:44)
- Ты openoffice видел? Его файлы на самом деле - зип. Только
расширение другое. И в этом зипе чего только нет. - fk0(10.07.2020 21:24)
- И ОО, и аутлук (ниже) не в реалтайме с оверлаппингом блоков данных
работают - MBedder(11.07.2020 00:00)
- Что значит "оверлаппинг блоков" ? Ты или что-то недоговариваешь,
или что-то не понимаешь. Я так понимаю, что на виндовсе запущены
какие-то программы которые пишут какие-то файлы. Ну и пусть пишут в
отдельные файлы. Потом в конце зазипуешь и всё. А ты хочешь сразу
писать в один результирующий файл? Но какой в этом смысл? Если он у
тебя сразу по сети куда-то уезжает, тогда есть. А если на диск --
то не очень осмысленно. Т.е. ты хочешь сериализовать несколько
(именованых, fk0(163 знак., 11.07.2020 00:43)
- Да, недоговорил - самое печальное то, что данные, прилетающие от
отдельных приборов-источников, не содержат TimeStamp'ов, поэтому
отдельные файлы в чистом виде бессмысленны, и зипование не позволит
их потом раззиповать с сохранением временнОго порядка - MBedder(11.07.2020 11:32)
- Ну и укладывайте все в общий архив по порядку прихода на
регистрацию. ETM(223 знак., 11.07.2020 17:35)
- Спасибо. Пока снабдим метками все пакеты, а дальше будем поглядеть - MBedder(11.07.2020 18:18)
- а нельзя маркировать эти данные временем прилёта нельзя? неточно? - General(11.07.2020 13:58)
- Можно, и сейчас как раз с этим упражняюсь. Точность достаточна +-10 мс - MBedder(11.07.2020 14:11)
- Ну и укладывайте все в общий архив по порядку прихода на
регистрацию. ETM(223 знак., 11.07.2020 17:35)
- Да, недоговорил - самое печальное то, что данные, прилетающие от
отдельных приборов-источников, не содержат TimeStamp'ов, поэтому
отдельные файлы в чистом виде бессмысленны, и зипование не позволит
их потом раззиповать с сохранением временнОго порядка - MBedder(11.07.2020 11:32)
- Что значит "оверлаппинг блоков" ? Ты или что-то недоговариваешь,
или что-то не понимаешь. Я так понимаю, что на виндовсе запущены
какие-то программы которые пишут какие-то файлы. Ну и пусть пишут в
отдельные файлы. Потом в конце зазипуешь и всё. А ты хочешь сразу
писать в один результирующий файл? Но какой в этом смысл? Если он у
тебя сразу по сети куда-то уезжает, тогда есть. А если на диск --
то не очень осмысленно. Т.е. ты хочешь сериализовать несколько
(именованых, fk0(163 знак., 11.07.2020 00:43)
- И ОО, и аутлук (ниже) не в реалтайме с оверлаппингом блоков данных
работают - MBedder(11.07.2020 00:00)
- Тогда не майся ерундой и отдай на откуп программерам - вот к примеру файл данных аутлука может быть практически бесконечен, при этом обеспечивается серфинг по сообщениям по разным критериям. Пусть сами думают. - VLLV(10.07.2020 20:58)
- Ты openoffice видел? Его файлы на самом деле - зип. Только
расширение другое. И в этом зипе чего только нет. - fk0(10.07.2020 21:24)
- Это сейчас и делается, но вместе со "сборным" файлом. Без него
стремновато - отдельные файлы могут потеряться/побиться по пути от
самолета до московского обработчика - MBedder(10.07.2020 20:44)
- Однонаправленный список сообщений? Несколько стандартных полей в
каждой записи (дата-время, GPS, источник сообщения, смещение до
следующей записи) + хвост переменной длины. - Cкpипaч(10.07.2020 20:01)
- ... - MBedder(10.07.2020 20:35)
- Что, ...? Какой вопрос - такой ответ. Ты видишь какие-то проблемы
обработки "этого салата" но не озвучиваешь их. Лучше Вирта, о
"структурах данных" не писал никто. Самая простая структура -
однонаправленный список, все дальше - устранение замечаний. Нет
замечаний - останавливайся, ибо нефиг от KISSа отклоняться. - Cкpипaч(10.07.2020 21:01)
- Ну где-то верно по-своему, но не панацея - MBedder(11.07.2020 00:01)
- Что, ...? Какой вопрос - такой ответ. Ты видишь какие-то проблемы
обработки "этого салата" но не озвучиваешь их. Лучше Вирта, о
"структурах данных" не писал никто. Самая простая структура -
однонаправленный список, все дальше - устранение замечаний. Нет
замечаний - останавливайся, ибо нефиг от KISSа отклоняться. - Cкpипaч(10.07.2020 21:01)
- ... - MBedder(10.07.2020 20:35)
- Поток фреймов разной длинны: маркер начала + размер данных во
фрейме (длинна) + данные + CRC. Например IEEE C37.118 - ETM(10.07.2020 19:39)
- Спасибо, КО - MBedder(10.07.2020 19:44)
- Аналогичный вопрос задавал Скрипач, может ответил бы, чем его изыскания кончились... И ещё scorpion: fk0(48 знак., 10.07.2020 18:56, ссылка, ссылка)
- В общем случае, если задача решается в лоб использованием SQL-базы
данных, то её и нужно использовать. Будет проще во многом. Другое
дело, что может получиться _сильно_ не оптимально и избыточно. В
данном случае непонятно какие выборки из базы данных потом будут
осуществляться. Если нужно просто разделить по источникам, то что
мешает сразу писать в разные же файлы, и потом брать только нужные.
А для передачи -- запаковать в зип. В случае SQL же, любая другая
база данных fk0(1594 знак., 10.07.2020 18:33)
- Я не о том, во что сложить - CSV проходит (пока), а как сложить, чтобы потом можно было восстановить исходный порядок
посылок и пакетов - MBedder(10.07.2020 18:55)
- Наверное, в таких случаях лучше всего использовать для хранения Базы данных временных рядов - BlackPrapor(10.07.2020 19:28, ссылка)
- Пишет один процесс или разные? В один файл или в разные? Если файл
один (без буферизации, разумеется, и с O_APPEND), то порядок
очевиден... можно таймштамп добавить (но он может совпадать у
соседних записей). Если процесс один, поток один, есть точка, где
всё упорядочивается явно, то там можно порядковый номер записи
добавить. fk0(1858 знак., 10.07.2020 19:24)
- Запись-то в один файл, но порядок неочевиден - пакеты рвать нельзя,
а так они неизбежно будут друг на друга наезжать - MBedder(10.07.2020 19:43)
- Ничего не понял. Так или иначе можно записывать пакеты в файл
последовательно -- какой первый появился, тот и записывается в файл
целиком. Чем не решение? Потом кто-то другой так же последовательно
вычитывает и обрабатывает, или кладёт в базу для обчётов по разным
критериям. Если пакеты мелкие, то можно положиться на атомарную
запись. Если большие, то сериализовать ручками через разделяемую
память, через множество пайпов (по пайпу на каждый источник,
который читается всегда fk0(123 знак., 10.07.2020 19:49)
- Пайпы у меня программисты курят, а я бросил :)) - MBedder(10.07.2020 20:36)
- Ничего не понял. Так или иначе можно записывать пакеты в файл
последовательно -- какой первый появился, тот и записывается в файл
целиком. Чем не решение? Потом кто-то другой так же последовательно
вычитывает и обрабатывает, или кладёт в базу для обчётов по разным
критериям. Если пакеты мелкие, то можно положиться на атомарную
запись. Если большие, то сериализовать ручками через разделяемую
память, через множество пайпов (по пайпу на каждый источник,
который читается всегда fk0(123 знак., 10.07.2020 19:49)
- Про сокеты - можно просто взять ZeroMQ, там такой сценарий есть из
коробки XPUB/XSUB. Записывать в один поток в получателе - lloyd(10.07.2020 19:34)
- Спасибо, бум поглядеть - MBedder(10.07.2020 20:37)
- А ZeroMQ зачем? Если положим, что пишем текстовые строчки. Записать
можно и с помощью socat'a или программы на C из десятка строк. - fk0(10.07.2020 19:39)
- А вот затем, что см. комментарий выше - 0MQ обеспечивает границу
сообщений на любом транспорте (межпотоковый, межпроцессный, TCP).
Там получаешь или все, или ничего (такое тоже бывает) - lloyd(10.07.2020 19:48)
- Границу сообщений можно сделать массой разных способов, 0MQ не
серебряная пуля. Если размер сообщения известен в момент отправки,
то очевидно, можно каждое сообщение предварять его длиной. - fk0(10.07.2020 19:51)
- Как будто ZMTP под капотом делает что-то другое. Вообще суть
предложения была в том, чтобы не пытаться героически превозмогать
многопоточную задачу, а перевести ее в однопоточку брокера
сообщений - lloyd(10.07.2020 19:54)
- Вызвать write() для записи в пайп -- это героическое превозмогание?
Почему бы за уши не притянуть ещё всяких брокеров, они ж такие
полезные. А потом с этом всем попытаться взлететь... - fk0(10.07.2020 19:57)
- Я так полагаю самая сложная задача - не в файл записать, а данные получить. Но пусть ТС меня поправит - lloyd(10.07.2020 20:02)
- Вызвать write() для записи в пайп -- это героическое превозмогание?
Почему бы за уши не притянуть ещё всяких брокеров, они ж такие
полезные. А потом с этом всем попытаться взлететь... - fk0(10.07.2020 19:57)
- Как будто ZMTP под капотом делает что-то другое. Вообще суть
предложения была в том, чтобы не пытаться героически превозмогать
многопоточную задачу, а перевести ее в однопоточку брокера
сообщений - lloyd(10.07.2020 19:54)
- Границу сообщений можно сделать массой разных способов, 0MQ не
серебряная пуля. Если размер сообщения известен в момент отправки,
то очевидно, можно каждое сообщение предварять его длиной. - fk0(10.07.2020 19:51)
- А вот затем, что см. комментарий выше - 0MQ обеспечивает границу
сообщений на любом транспорте (межпотоковый, межпроцессный, TCP).
Там получаешь или все, или ничего (такое тоже бывает) - lloyd(10.07.2020 19:48)
- Запись-то в один файл, но порядок неочевиден - пакеты рвать нельзя,
а так они неизбежно будут друг на друга наезжать - MBedder(10.07.2020 19:43)
- Я не о том, во что сложить - CSV проходит (пока), а как сложить, чтобы потом можно было восстановить исходный порядок
посылок и пакетов - MBedder(10.07.2020 18:55)
- Что то это мне напоминает ;) - Codavr(10.07.2020 18:15)
- Чо? - MBedder(10.07.2020 18:19)
- Автопилот про который я тут излагал, подумалось, что ты у них
подрядился. - Codavr(10.07.2020 23:48)
- Да я вроде как "подрядился" у геофизиков с 1975 года, так с тех пор
ни у кого больше и не рядился :)) - MBedder(10.07.2020 23:57)
- Набор уж очень похожий :) - Codavr(11.07.2020 00:11)
- Да я вроде как "подрядился" у геофизиков с 1975 года, так с тех пор
ни у кого больше и не рядился :)) - MBedder(10.07.2020 23:57)
- Автопилот про который я тут излагал, подумалось, что ты у них
подрядился. - Codavr(10.07.2020 23:48)
- Чо? - MBedder(10.07.2020 18:19)
- ИМХО как-то сразу видится msg_pack или protobuf.... ну или что-то
подобное, где есть отдельные поля обязательные (GPS данные), есть
необязательные (остальные, перечисляются каждые), какие то в виде
массивов... какие то просто в виде числа.... sav6622(112 знак., 10.07.2020 18:11, ссылка, ссылка)
- +1 за protobuf, только сериализацию/десериализацию придётся для вышеуказанной задачи писать самому, т.к. стандартные упаковщики например не поймут несколько одинаковых ID чередующихся в другими, либо придётся записи "закрывать", а это лишние накладные байты. Дoктyp77(347 знак., 10.07.2020 20:02, )
- Спасибо, близко. Поизучаю. - MBedder(10.07.2020 18:23)
- присвоить свой уникальный id каждому потоку, добавить timestep с
GPS. Простая самописная прога сможет выводить выбранные потоки и
экспортировать в файл. Если я конечно правильно понял задачу! - Aleksey_75(10.07.2020 17:40)
- Все правильно, но есть нюансы - пакеты данных даже внутри одного и
того же потока могут быть неравномерными, неравнодлинными и
неравнодлительными. Теоретически надо к каждому байту присобачивать
UID и TimeStamp, но это уже полный пиздец - MBedder(10.07.2020 18:05)
- а доступ есть к изменению формата пакетов потоков есть ? если да,
то думаю лучше всего сделать фиксированный размер и оформить через
структуру/union. - Aleksey_75(10.07.2020 18:14)
- Нет, это все идет от разномастных приборов - в основном буржуйских - MBedder(10.07.2020 18:18)
- максимальный размер пакетов какой ? Я мож глупость скажу, но как
варик посадить на каждый поток свою мелкую платку с мк которая бы
парсила пакеты и приводила их в божеский вид, дальше хоть по кану,
хоть по езернету на прогу адекватного логирования, все что было
раньше пусть так и будет. Aleksey_75(72 знак., 10.07.2020 20:39)
- От сотен байт до нескольких килобайт, да еще и с динамической
длиной/составом. RS232, 422 и Ethernet. В божеский вид приводить
нет смысла - MBedder(10.07.2020 20:48)
- ну значит как я изначально сказал , добавлять id потока и метку
времени, потом писать для ПК прогу ридер/парсер, ведь протоколы
потоков известны , их както полетный комп прожеывает - Aleksey_75(10.07.2020 20:56)
- Спасибо, на верном пути --> - MBedder(11.07.2020 11:44, ссылка)
- ну значит как я изначально сказал , добавлять id потока и метку
времени, потом писать для ПК прогу ридер/парсер, ведь протоколы
потоков известны , их както полетный комп прожеывает - Aleksey_75(10.07.2020 20:56)
- От сотен байт до нескольких килобайт, да еще и с динамической
длиной/составом. RS232, 422 и Ethernet. В божеский вид приводить
нет смысла - MBedder(10.07.2020 20:48)
- максимальный размер пакетов какой ? Я мож глупость скажу, но как
варик посадить на каждый поток свою мелкую платку с мк которая бы
парсила пакеты и приводила их в божеский вид, дальше хоть по кану,
хоть по езернету на прогу адекватного логирования, все что было
раньше пусть так и будет. Aleksey_75(72 знак., 10.07.2020 20:39)
- Нет, это все идет от разномастных приборов - в основном буржуйских - MBedder(10.07.2020 18:18)
- а доступ есть к изменению формата пакетов потоков есть ? если да,
то думаю лучше всего сделать фиксированный размер и оформить через
структуру/union. - Aleksey_75(10.07.2020 18:14)
- Все правильно, но есть нюансы - пакеты данных даже внутри одного и
того же потока могут быть неравномерными, неравнодлинными и
неравнодлительными. Теоретически надо к каждому байту присобачивать
UID и TimeStamp, но это уже полный пиздец - MBedder(10.07.2020 18:05)
- У меня практически работающая система сбора информации построенная мной с back-end'ом на SQLite.
Гетерогенные пакеты информации стекаются real-time потоками (~около
10ка "тонких") в базу данных со скоростью 100пак/сек, стробируясь
пространственно-временной меткой (GPS тоже пишется, но строб дает
не он). Потоки динамически run-time настраиваемы (таблица-поток).
Некоторые потоки представляют собой "толстые" Lidar данные (пакет
10-20кб * ~50-100 пак/сек). SQLite RxTx(1771 знак., 11.07.2020 17:33 - 17:38, ссылка, ссылка)