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

И можно ли как-то оптимизировать описанный процесс?

Ага я бы при «900 значений в секунду» и «Эти данные каждые 3 секунды считываются из БД тремя разными системами», сделал бы какую-то прослойку принимающую, кеширующую, раздающую и периодически кидающую в бд.

т.е. каждая сейсмостанция даёт по 3 120-КБайтной записи каждые 3 секунды).

120Кб*60с*60с*24ч~9Гб в день.

И это от одной?

а что в этой не устраивает? работает - не трогай.

Кстати скольки разрядный АЦП?

не каждую секунду а каждые 3

~3375MB

а да, даёт по 3

не дочитал

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

Но что касается визуализации, при наличии такой прослойки там придётся плодить костыли для того, чтобы иметь, например, возможность смотреть графики месячной давности. Хотя просмотр real-time данных там приоритетнее, да. Кстати, морда для оператора пускается прямо из браузера и использует node.js.

А бывает какая-то особая уличная БД для похожих систем мониторинга, где данные за последние пару минут лежат в кеше и быстро отдаются? И чтобы старые данные, в идеале, ещё бы и сжатыми складировались...

Угу. И это вы не учли, что скорость и перемещение тоже пишутся в БД. Так что снова возвращаемся к 9 Гб.

а что в этой не устраивает? работает - не трогай.

Система только создаётся. Работать-то работает, но менять можно как душе угодно. Оптимизировать хотелось бы. И хотелось бы сжимать поступающие данные на уровне БД.

~3375MB

И что - всегда меняются значения? В смысле нет ровных участков (не считая шума АЦП)? Их не сжимаешь?

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

Так и надо. И репликацию можно делать средствами сервера.

Кстати скольки разрядный АЦП?

Я в этих железках не разбираюсь, что за разрядность АЦП? Один отсчёт (замер, т.е. 1/50 полусекундной записи при частоте дискретизации 10 мс) на АЦП занимает 3 байта. Обрабатывается так:

/******************** Обработка входящих датаграм с записью ********************
 * Каждый пакет с записью - 512 байт.
 * Байты 0..7 - как в прочих пакетах (командах), т.е. первые два - длина пакета,
 * третий - ответивший блок (ATMega).
 * Данные начинаются с 8 (9) байта и представляют собой ускорения по трём осям.
 * Числа в идут по 3 беззнаковых байта в big endian (старший, средний, младший);
 * первые 3 байта = 1 отсчёт = Z (он опорный), X, Y.
 * При дискретизации 10 мс - 50 отсчётов (0.5 секунды / 10 мс) по 9 байт каждый,
 * т.е. всего 450 байт.
 * Числа положительные беззнаковые. Преобразуется так: делаем из этих 3 байтов
 * unsigned int (последний байт - 0x00). Значение отсчёта умножаем на цену
 * деления (2.5v/0xFFFFFF) и вычитаем середину шкалы (1.25v).
 ******************************************************************************/
void Irkut::processRecord(const IrkutAnswer &recordDatagram)
{
    Q_ASSERT(recordDatagram.size() == 512);

    QList<Vector3D> readings;
    readings.reserve(50);

    IrkutAnswer::ConstIterator it = recordDatagram.constBegin();
    for (int i = 0; i < 8; ++i) {
        ++it;
    }

    IrkutAnswer::ConstIterator end = it;
    for (int i = 0; i < 450; ++i) {
        ++end;
    }

    while (it != end) {
        Q_ASSERT(it < end);
        // z, x, y
        readings << Vector3D(getOneReading(it),
                             getOneReading(it),
                             getOneReading(it));
    }

    Q_ASSERT(readings.size() == 50);

    emit gotRecord(recordDatagram.obtainTime(), readings);
}

double Irkut::getOneReading(QByteArray::ConstIterator &it)
{
    /// Цена деления (коэффициент перевода показаний АЦП в напряжение)
    static const double delta = 2.5 / 0xFFFFFF;
    /// Середина шкалы
    static const double Vcm = 1.25;

    const unsigned char b1 = *(it++);
    const unsigned char b2 = *(it++);
    const unsigned char b3 = *(it++);

    const quint32 block =
#if Q_BYTE_ORDER == Q_BIG_ENDIAN
            (b1 << 24) +
            (b2 << 16) +
            (b3 << 8);
#else
            (b1 << 16) +
            (b2 << 8) +
            b3;
#endif

    return double(block) * delta - Vcm;
}

И что - всегда меняются значения? В смысле нет ровных участков (не считая шума АЦП)? Их не сжимаешь?

Не подумал про это. Да, конечно, ровные участки есть. По правде сказать, только они там по большей части и есть; импульсы встречаются очень редко. Надо бы как-то эту часть оптимизировать, да.

делаем из этих 3 байтов * unsigned int

Значит <16бит на отсчет. ИМХО можешь не в double, а в float хранить - в два раза меньше.

Если у тебя нет сильно распределенной реляционной модели или «транзакция или смерть», то 95% задач проще решить на MongoDB

Да, конечно, ровные участки есть.

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

^
|             **    
|            *  * 
|           *    *
|*    *    *      *    *
+------------------------->

Получается как-то так. Т.е. пишутся только изменения.

Что за дельта по пакетам? Можешь чуть подробнее расписать алгоритм, а то мой не выспавшийся мозг не вникает в ⅓ сказанного тобой.

• Если уже ссумировано пришло dP пакетов, то писать в БД, иначе сложить с аккумулятором.
• Если прошло >dT времени, то писать в БД, иначе сложить с аккумулятором.
• Если значение изменилось больше чем на dV, то писать в БД, иначе сложить с аккумулятором.

В БД пишется аккумулятор поделённый на количество отсчетов.

Так что: Если нужны пики - ставим dP и dT >9000, а дельту в минимальное изменение для твоего АЦП.

Если нужны пики, но с графиками дополнительно ставим dP и в БД будут писаться отсчеты, чтобы можно было хоть прямую построить.

Если нужен оверсэмплинг - dT, dV = 9000, а dP в нужное тебе число.

Ну и т.д.

Я с СУБД познакомился лишь неделю назад, когда начал работать над этим проектом и не понимаю основы. Слова по отдельности в словосочетаниях «сильно распределенная реляционная модель» и «транзакция или смерть» мне более-менее понятны, но сами словосочетания непонятны.

Расклад такой…

• X (пока 2, потом будет больше — около 15) серверов, к каждому из которых подключено по 3 сейсмостанции и которые складируют к себе данные с них. К каждому из них подключен монитор для просмотра поступающих данных оператором (в браузере, подключенном к node.js на локалхосте).
• 2 сервера хранения с БД (туда постоянно должна идти репликация).
• 2 компьютера для операторов (данные смотрятся в браузере, подключенном к node.js на приуроченном сервере хранения).

Система сейчас работает вполне себе хорошо. Но есть ещё куча времени для её усовершенствования по программной части.

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

Я лично в таких случаях вижу софтину, демона. Этот демон будет принимать данные от источника, кешировать их в оперативе за последние n секунд, отдавать их клиентам, ну и периодически скидывать их в бд. Оптимизируется нагрузка на бд. Демон сможет отдавать данные в любом удобном виде, в частности производить с ними любые требующиеся действия.

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

Ничего не костыли, просто сделай грамотно. Грубо говоря:

Data getData(from, to)
{
    if (from >= to)
        return Data::Error;
    if (Time::current.msecsTo(from) > n || Time::current.secsTo(to) > n)
        return this.getDataFromDB(from, to);
    else
        return this.getDataFromRAM(from, to);
}

Кстати, морда для оператора пускается прямо из браузера и использует node.js.

Для этого демон может использовать xml-rpc/json/etc. Или вообще свой примитивный http, там делов то на 5 минут.

А бывает какая-то особая уличная БД для похожих систем мониторинга, где данные за последние пару минут лежат в кеше и быстро отдаются? И чтобы старые данные, в идеале, ещё бы и сжатыми складировались...

Что-то не упомню такого...

ЗЫ Серьёзно такую софтину можно за пару вечеров на коленке наваять, и даже с http для браузерных клиентов. Любой удобный ЯП и вперёд заре на встречу.

X (пока 2, потом будет больше — около 15) серверов, к каждому из которых подключено по 3 сейсмостанции

А нафига больше-то? У меня проектец есть >1000 объектов с десятком параметров каждый и хватает.

Расстояние между 2мя объектами — сотни километров. Локалка есть, есличё, оптическая магистраль.

Локалка есть, есличё, оптическая магистраль.

Это к сейсмостанциям?

Между объектами. Два (а потом 2 десятка) объектов, между ними по 2-3 сотни и более км. Локалка одна на все объекты. К сейсмостанциям расстояние по 0.5 км в среднем, до них сейчас витуха (с POE) с репитерами, потом будет оптика.

Какая-нибудь БД подойдёт для этих целей заметно лучше Firebird'а? И можно ли как-то оптимизировать описанный процесс?

как всегда, всё начинается с основ - чем должна быть некая база лучше, чем плох/неудобен firebird и что хотим оптимизировать и почему?

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

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

Хотелка — автосжатие старых данных и временное нахождение в RAM новых.

А посмотрите на эту БД

Это можно сделать триггерами. Т.е. пишешь в табличку-времянку (естественно все расчеты уже сделаны и «система мат. обработки» уже в приёмнике). А триггер сливает данные старше, скажем часа в основную БД. Таблицу времянку можно разместить в памяти (например MySQL так может). В принципе пожно и без триггеров обойтись - разместить всю логику в приёмнике.

Здорово, спасибо. Особенно это поравдовало: http://trac.scidb.org/raw-attachment/wiki/UseCases/seismic-use_case_scidb.pdf

http://events.yandex.ru/events/science-seminars/cern-jul-2012/talks/287/

Можешь попробовать Hadoop, хотя с RT не знаю как он будет дружить. Если нужна RT репликация только, то все реализации MR умеют хранить несколько копий чанка.

Судя по тому, что я прочитал в треде - тебе дпже и БД как таковая не нужна. Ты не будешь использоать индексы, апдейтить предыдущие записи (что вревато изменением их расположения) и т.п. БОльшую часть функционала СУБД ты не используешь. У тебя же заведомо известна периодичность поступления отсчётов, ты знаешь что у тебя в месяц будет поступать 2.3Гб данных (если 900 байт, а не значений, как ты написал, в секунду) - т.е. можно тупо создавать на свежеотформатированном винте (чтобы данные лежали последовательно) помесячные файлы и при запросе данных высчитавать смещение и размер блока, который нужно отдать клиенту. Это будет работать максимально быстро, при необходимости, если клиентов станет слишком много, можно подсовывать под эту ФС рейд-массивы, кешированием будет заниматься линупс. Но и это можно оптимизировать: какие-то данные будут востребованы особенно часто - скажем, за последний месяц. Эти данные демон, ответственный за доступ к данным, может держать в разделяемой памяти, в каком-нибудь кольцевом буфере размером 2Гб (это ничто по нынешним временам), при этом софт, запускаемый на том же сервере будет иметь практически прямой доступ к этим данным.

Во всём этом не учитывается только одна вещь, о которой ты ничего не сказал - а насколько эти данные ценны? Если система навернётся из-за какого-нибудь глюка или просто будет выведена в оффлайн для техобслуживания - насколько критична утрата данных? Возможно потребуется дублирование функционала, создание High Availability Clusters - и это уже возможно перевесит по сложности и цене весь проект, непосредственно занимающийся сбором статистики.

Кроме того, выбирая реализацию для своего проекта, тебе следует помнить о том, что софта без багов не бывает, и после сдачи его в эксплуатацию будут возникать проблемы, требующие решения, и порой немедленного. Прикинь - северокорейцы опять твой Владиосток шаталь, товарищ генерал уже завалил твой отдел телефонограммами с угрозами поставить тебя к стенке как корейского шпиона и саботажника, а у тебя что-то повисло и данные не пишутся и никто не знает, что с этим делать потому что в качестве решения ты использовал какую-то экзотическую БД, с которой никто толком и работать-то не умеет...

Вобщем тут надо очень взвешенно подходить, отталкиваясь от задачи, я так щетаю.

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

Каждая сейсмостанция отправляет по 50 значений вектора ускорения в полсекунды. Так как вектор задаётся тремя значениями (данные поступают с датчиков по X, Y и Z), а станций на объекте 3, то каждые полсекунды на объекте получается 50*50*3 = 450 значений. Т.е. с трёх сеймостанций поступает 900 значений в секунду.

Каждое значение до обработки занимает 3 байта (3-байтовое целое). После обработки (перевода из целого в передаваемый к АЦП вольтаж и после применения калибровочных коэффициентов датчика) — 8 байт (double). Итого с трёх сейсмостанций поступает 7 КиБ/сек. Это чуть менее 600 МиБ в день или около 18 ГиБ в месяц.

Помимо этого, из значений ускорения программой мат. обработки считаются скорости и перемещения. Итого на одном объекте получается чуть менее 55 ГиБ данных (ускорений, скоростей, перемещений) в месяц.

В целом, возможно, действительно лучше складировать данные в файлы. Вероятно, с каким-то сжатием, ведь 55 ГиБ/месяц — нормально для одного объекта, но когда объектов станет 20, то на серверах хранения будет уходить 15*20 = 600 ГиБ/месяц — это уже многовато, хардами не запасёшься.

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

Плюс этот комплекс можно будет легко использовать для микросейсмики: http://trac.scidb.org/raw-attachment/wiki/UseCases/seismic-use_case_scidb.pdf.

Насчёт связи между объектами я попутал — у них тут радио. Но дико быстрое.

К сейсморегистраторам, кстати, оптика идёт. Но это не суть.

В файлик нельзя башлять данные просто последовательно? Размер записи фиксированный, запись примитивная хуже некуда. 300 файлов в год будет.

С трёх сейсмостанций по UDP каждые полсекунды поступает по 50 значений ускорения по каждой оси

Так может что-то с БД оптимизированными под временные ряды? Тот же pulsedb: https://groups.google.com/forum/#!msg/erlang-russian/5WL9-3p5My0/cEwSMCWblWwJ