NoSQL БД для временных рядов. Посоветуйте подход к проектированию или готовую.

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

Кстати, по поводу милисекундной точности. А часы-то синхронизируются?

Ценность есть - предложение автору пойти все проверить, а не поверить на слово каким-то анонимусам с неспециализированного форума чтобы программа потом так работала 10 лет

Система должна работать годами без всяческого вмешательства.

Наличие в системе жесткого диска предполагает, что в систему придется вмешиваться уже завтра.

Каждая из сейсмостанций имеет GPS. Говорил конструктору использовать Precision Time Protocol, но что-то он поленился (или просто решил, что GPS будет точнее, что в общем-то верно и полезно для более точного определения гипоцентров землетрясений). Время записи содержится в датаграммах, отправляемых сейсмостанциями.

У нас есть в чем-то похожий проект - коллектор и анализатор netflow (http://xenoeye.com). Прилетают netflow-пакеты, мы их обрабатываем (обновляем таблицы с агрегированными данными) и складываем на диск прямо в бинарном виде. При каких-то аномалиях пробегаемся по этим данным за период и строим более подробные отчеты.

Сначала по наивности как тут и советуют пробовали хранить в PostgreSQL.

Во-первых (как и пишет mashina) данные здорово раздуваются - один «бинарный» байт может занимать до 6 на диске. Кроме того что дисков надо больше, запросы выполняются медленнее чем по «сырым» данным. Да, пробовали и разные индексации, и партиционирование, это все очень условно помогает.

Во-вторых хранение агрегированных таблиц в СУБД тоже с особенностями. PostgreSQL версионник, то есть update с точки зрения дискового пространства это фактически insert. Место освобождается только после vacuum full, которому нужен exclusive lock.

Есть кластерные NoSQL, c map-reduce'ом, всякими наворотами, можете посмотреть, но нас ничего не впечатлило. Тоже хотелось «поставил и забыл», плюс на некоторых объектах у нас нет даже возможности часто смотреть как оно, упало или еще держится.

В итоге остановились на хранении сырых бинарных данных, приблизительно 1 файл в три дня. Отфильтрованные, агрегированные и отсортированные данные (то есть готовые для того чтоб их показать отчетом) хранятся в Berkeley DB (ну, тоже NoSQL)

один «бинарный» байт может занимать до 6 на диске

Один байт или однобайтовая запись?

Kx DB + q же

ну или что-то мумпсоподобное, GT.M или Cache, например

пруфлинки: раз два три

Только свободный софт, уже писал. Требование заказчика.

Уже точно не помню что мы сравнивали, скорее всего размер сырого netflow пакета vs сколько он занимает на диске в таблице PostgreSQL. Но цифру 6 точно помню. Да, это все применительно к нашим данным, у ТС картина может быть другой

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

# du -h
...
5,3M	./base/57650
...

create table t
(
        ip inet,
        port integer
);

create or replace function tab_fill() returns void as $$
begin
        FOR i IN 1..1000000 LOOP
                insert into t values('0.0.0.0'::inet + i, i);
        END LOOP;
end;
$$ language plpgsql;

select tab_fill();

# du -h
...
44M	./base/57650
...

Приблизительно 40 байт на запись. Сырыми байтами было бы около 6.

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

GT.M свободный

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

По хранению всё понятно, ты всё круто объяснил. { (HEADER, data, TAIL) } + ротация + сжатие + удаление совсем старых файлов.

По передаче, наверное, тоже — тупо держим tcp-сокет на каком-нибудь порту, к которому можно подключаться и запрашивать данные за выбранный период с заданным шагом по времени (ведь для графопостроения не нужно отдавать все данные, надо их как-то вырезать исходя из ширины графика). Всё по простецкому бинарному протоколу (одно соединение = один запрос = один ответ). Можно будет даже либу-клиент не писать, а в node.js сразу считывать.

А репликацию можно делать тупо по крону простенькой утилиткой (да хоть на bash) — чтобы копировала все файлы, кроме того, в который сейчас идёт запись (ведь необходимость в поддержании )

В общем, спасибо.