Есть устройство, которое шлёт телеметрию и есть программа, которая этим устройством управляет.

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

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

Логи вида: время, in/out/event, payload

В payload может быть как пакет в виде json, так и информация о событии внутри программы (пользователь нажал кнопку, запуск процесса и тд).

Цель базы данных в том, чтобы можно было делать такие запросы (условно):

select payload.voltage_battery
from logs
where payload_type = 'sys_status' and
      operator_name = 'NAME' -- это и следуещее поле будет добавлено к каждой 'строке' лога 
      run_id = 122           -- чтобы можно было различать разные запуски системы
order by payload.voltage_battery descending

Это, конечно, самый элементарный пример, хотелось бы делать более сложные выборки с джойнами на себя и прочим.

Кто-нибудь занимался чем-то подобным?
SQL/NoSQL?
Всё в одной таблице или нескольких?
Может, вообще, сделать таблицу вида: name/value?

каков прогнозируемый среднесуточный объём логов?
(количество записей/объём Мб)

Здравствуйте, Alex.Che, Вы писали:

AC>каков прогнозируемый среднесуточный объём логов?
AC>(количество записей/объём Мб)

Сложно прогнозировать, но врядли больше 100 Мб в день.

On 22.04.2015 12:01, ionoy wrote:

> Хочу сделать центральный сервер, куда можно было бы все эти данные
> загружать и, в последствие, делать по ним выборку.

Посмотрите elasticsearch (это примерно "база данных") + logstash
(загружает туда логи из файлов, сокетов и т.п.) + kibana (вебморда к БД)

--
WBR,
Serge.

Здравствуйте, ionoy, Вы писали:

Имеет смысл ознакомиться с существующими готовыми решениями. Возможно, одно из них подойдет без изобретения велосипедов. Например Logstash

Здравствуйте, ionoy, Вы писали:

I>Это, конечно, самый элементарный пример, хотелось бы делать более сложные выборки с джойнами на себя и прочим.

I>Кто-нибудь занимался чем-то подобным?

Да, занимался.

I>SQL/NoSQL?

Если ты хочешь использовать запросы, то уж наверное SQL, в NoSQL нет запросов.
Логично ?

I>Всё в одной таблице или нескольких?

Смотря какие у тебя данные и какая постановка задачи.
Как правило, в БД не бывает по одной таблице, как правило, данные хранятся в разных таблицах.
Количество таблиц никак ни на что не влияет и не является критерием или целью прокетирования БД.

I>Может, вообще, сделать таблицу вида: name/value?

Ну, сделай, если хочешь.

Но вообще на твой вопрос нужно ответить так: как не бывает "в общем" быстрых или медленных запросов,
так не бывает и "в общем" правильныйх или неправильных баз данных.
Базы данных проектируются исходя из конкретной постановки задачи.

Здравствуйте, ionoy, Вы писали:

I>Есть устройство, которое шлёт телеметрию и есть программа, которая этим устройством управляет.

Ещё один момент по именно данной тематике.
При хранении и получении телеметрии часто её получают по принципу "раз в интервал времени".
Отсюда следует вполне логичный вывод, что в смежных замерах значение величины будет либо
одинаково, либо мало отличаться от предыдущих. А значит такие данные можно сжимать,
а если можно -- то и нужно сжимать.

Вот этим и предлагаю заняться в первую очередь.
Причём сжатие данных -- тоже предметно-ориентированная штука.

Здравствуйте, MasterZiv, Вы писали:

MZ>Здравствуйте, ionoy, Вы писали:

I>>SQL/NoSQL?

MZ>Если ты хочешь использовать запросы, то уж наверное SQL, в NoSQL нет запросов.
MZ>Логично ?

Их нет в привычном виде SQL, но тем не менее они есть. Так что нелогично

I>>Всё в одной таблице или нескольких?

MZ>Смотря какие у тебя данные и какая постановка задачи.
MZ>Как правило, в БД не бывает по одной таблице, как правило, данные хранятся в разных таблицах.
MZ>Количество таблиц никак ни на что не влияет и не является критерием или целью прокетирования БД.

Ну я ведь привёл конкретную задачу. Или что-то ещё надо уточнить?

MZ>Но вообще на твой вопрос нужно ответить так: как не бывает "в общем" быстрых или медленных запросов,
MZ>так не бывает и "в общем" правильныйх или неправильных баз данных.
MZ>Базы данных проектируются исходя из конкретной постановки задачи.

Смотри выше.

Здравствуйте, MasterZiv, Вы писали:

MZ>Здравствуйте, ionoy, Вы писали:

I>>Есть устройство, которое шлёт телеметрию и есть программа, которая этим устройством управляет.

MZ>Ещё один момент по именно данной тематике.
MZ>При хранении и получении телеметрии часто её получают по принципу "раз в интервал времени".
MZ>Отсюда следует вполне логичный вывод, что в смежных замерах значение величины будет либо
MZ>одинаково, либо мало отличаться от предыдущих. А значит такие данные можно сжимать,
MZ>а если можно -- то и нужно сжимать.

MZ>Вот этим и предлагаю заняться в первую очередь.
MZ>Причём сжатие данных -- тоже предметно-ориентированная штука.

Да, некоторые данные можно будет сжимать, но таких там не очень много. Думаю это не самая приоритетная задача.

Здравствуйте, ionoy, Вы писали:

i> Кто-нибудь занимался чем-то подобным?
i> SQL/NoSQL?

Почти любая NoSQL база. Судя по твоим расчетам у тебя получается около 40GB в год — почти ни о чем. Про различные logstash/graylog уже написали, можно их попробовать использовать.