Система сбора и обработки данных, Как лучше реализовать структуру Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Стандартный Переключить на: Линейный

[Litkevich Yuriy]

с лета никак не определюсь как должна быть устроена система.
Итак, есть море оборудования, на них датчики. С датчиков собирается информация и акумулируется в БД (FireBird). На клиентских машинах (их может быть очень много) стоит прога (назовем её клиент). С клиента всю ситему можно настривать (какие датчики опрашивать, параметры оборудования задавать и т.п.), и получать отчеты о работе оборудования (т.е. история изменения параметров, история показаний датчиков).
Отчеты в общем случае одинаковые, то есть почасовое состояние оборудования (например, сигналов с датчиков), но формулы расчета разные зависят от типа датчиков и оборудования.

Текущая структура выглядит так:

Уменьшено Р Т‘Р С• 49% 515 x 234 (15.87 килобайт)

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

Вот я думаю заменить на этой схеме желтый квадратик
либо на приложение, которое будет принимать события от БД (уведомления) заниматся расчетами и складывать в некую выходную таблицу,
либо на UDF'ку, которая будет вызыватся тригером делать расчет, а тригер будет помещать результат в некую выходную таблицу.
Т.е. вынести прикладную часть (т.н. бизнес логику)

Может у кого есть мысли по этому поводу, а то и вовсе опыт создания подобных систем?

[kuler]

возможно такая вещь называется трехзвенная система (или многозвенная)

Но пока они жестко зашиты

зашиты в код ХрПр? ну дык можно либо параметрами передавать, либо считывать из какихто таблиц, а к таблицам интерфейс.

[AD]

Собственно говоря, система анализа послеполетной информации - основной проект которым я занимаюсь. Правда, в нем нет БД. Смысл такой. Данные с датчиков, принимаемые нашими приборами, пишутся на флеш-память в определенном виде (лог-файлы). Есть входные данные, согласно которым указывается какие параметры следует выбрать из лог-файлов.
На мой взгляд, твоя задумка заменить ХП на программу правильное. Возможно, следует дать пользователю возможность вводить в некотором формализованном виде формулу (если она не является чересчур громоздкой), а программа будет ее распарсивать и в соответствии с ней делать соответствующие расчеты. На первый взгляд, у меня такое мнение.
Посмотрел схему. Чем занимается scanner??? Это ПО или какое-то БД-шная штуковина?

[Litkevich Yuriy]

зашиты в код ХрПр?

да. Например для расчета потребления эл.энергии для заданной точки учета (далее Т.У.) из таблицы эл.счетчиков берется параметр счета (кол-во импульсов на кВт*ч) и считается кВт*ч. Для другого типа Т.У. свой расчет.

Чем занимается scanner???

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

сначало Scaner запрашивает у БД, что нужно опрашивать, вызовом процедуры P_GETDEVICE. Получает масив из трех столбцов:
PORT, ADDRESS, FIELD - Номер порта, адрес устройства в сети ModBus и номер поля данных
Опрашивает устройства по полученому списку, затем возвращает в БД данные с помощью ХП P_APPENDDATA(PORT, ADDRESS, FIELD, VALUE)
эта процедура складывает данные в табличку и еще завёт какую нибудь ХП для промежуточных расчетов (примитивных)

[AD]

Лучше все промежуточные расчеты вынести из СУБД в приложение. Если не ошибаюсь, ПО быстрее делает расчет, чем СУБД (если правильно сделать, конечно! )

[kuler]

да. Например для расчета потребления эл.энергии для заданной точки учета (далее Т.У.) из таблицы эл.счетчиков берется параметр счета (кол-во импульсов на кВт*ч) и считается кВт*ч. Для другого типа Т.У. свой расчет.

ну это бизнес правила, если они простые то ничего страшного что они в ХП, если тяжелые то конечно нада вытаскивать. А ввод формулу расчета юзером - фактически это заставление юзера программить, ведь это получается чтото типа запроса. Нужно только если таких формул может быть неограниченное или очень большое число

[Litkevich Yuriy]

А ввод формулу расчета юзером - фактически это заставление юзера программить, ведь это получается чтото типа запроса

несовсем так. Положим в вели еще Т.У. подключили физически. Юзер, в данном случае инженер заказчика, в водит формулу типа:
физТУ = К1ТУ*счетчикТУ

где:
физТУ - физическое значение Т.У.
счетчикТУ - значение счетчика данной Т.У. принятое из оборудования
К1ТУ - некий параметр пересчета который берется из сво-ств Т.У.

и далее пользователи (уже не только инженер) видят понятные для них цифры (литры, килограммы, кВт*ч и т.п.).
пока оперируем только примитивными расчетами и внутри БД. Но будут нужны и более серьезные, в том числе интегрирование и диференцирование.

Мне хочется понять 2 вещи
1) писать ли UDF, которая и распарсит формулу и посчитает, и использовать ее в нутри БД
или собственное приложение, которое будет работать по событиям из БД.
2) проводить расчет помере поступления данных и складывать в доптаблицу (при этом в базе появляются дополнительные данные) или
проводит расчет по запросу пользователя (т.е. формировать отчет ).

Есть такой нюанс. Данные нужно хранить 5 лет. Т.е. их будет много. Наша старая система №1 (Железо + ПК с Paradox'ом) обслуживает свыше 700 Т.У. Ситсема №2 (Железо + ПК с FireBird'ом) около 80 Т.У. И первая задача заместить старую систему №1, затем №2 (т.е. они буду единым целым), а затем наращивать кол-во Т.У. (~ до 2500 Т.У.)

[kuler]

проводить расчет помере поступления данных и складывать в доптаблицу (при этом в базе появляются дополнительные данные) или
проводит расчет по запросу пользователя (т.е. формировать отчет ).

это зависит от колва запросов одних и тех же данных. Если одни и теже данные нужны, не знаю, 100 раз то наверно лучше их один считать

Есть такой нюанс. Данные нужно хранить 5 лет. Т.е. их будет много. Наша старая система №1 (Железо + ПК с Paradox'ом) обслуживает свыше 700 Т.У. Ситсема №2 (Железо + ПК с FireBird'ом) около 80 Т.У. И первая задача заместить старую систему №1, затем №2 (т.е. они буду единым целым), а затем наращивать кол-во Т.У. (~ до 2500 Т.У.)

с какой скоростью растет база?

1) писать ли UDF, которая и распарсит формулу и посчитает, и использовать ее в нутри БД
или собственное приложение, которое будет работать по событиям из БД.

с точки зрения кода наверно одно и тоже, но приложение можно запустить на другом компе или ядре, а udf врядли, то есть будет теоретически более производительно

[Litkevich Yuriy]

с какой скоростью растет база?

про новую пока затрудняюсь сказать, оставил на недельку работать (только две Т.У.) посмотрю потом

в старых больше трех месяцев данные не копятся иначе на выборку отчета от 30 до 40 мин уходило, но тачка медленная (селерон полуторный с 512метрами памяти)

но приложение можно запустить на другом компе или ядре, а udf врядли

а UDF тоже, этож просто dll'ка которую СУБД подгружает по мере надобности

[kuler]

(селерон полуторный с 512метрами памяти)

ну это вообще не серьезно

UDF тоже, этож просто dll'ка которую СУБД подгружает по мере надобности

дык он её юзает возможно в том же процессе

[Litkevich Yuriy]

дык он её юзает возможно в том же процессе

а для меня-то в этом нет никакой разницы

или ты имеешь в виду, что запустить можно на некой соседней машине?

[Tonal]

Немного непонятно, результаты расчётов нужно хранить или только в отчётах показывать/печатать?
Если хранить, то что делать при изменении формул?
Если только показывать/печатать, то зачем сервер напрягать?

Ну и для языка я бы в любом случае посоветовал бы что-нибудь высокоуровневое - Python например.
У него и библиотек много (есть оптимизированные для научных расчётов) и изучение быстрое.
Можно JavaScript подцепить - но он тормознее выйдет, и с библиотеками придётся повозится...

[Litkevich Yuriy]

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

расчеты только для отчетов.

Если только показывать/печатать, то зачем сервер напрягать?

чтобы отчет махом показывался пользователю

Если хранить, то что делать при изменении формул?

я над этим тоже пока голову ломаю. Дело в том что формулы содержат параметры, а они могут менятся. Например кол-во импульсов на кВт*ч для эл.счетчика. однако счетчики иногда выходят из строя и надо ставить новый. Тогда нужно забить новое начальное показание счетчика и его коэффициент. я это дело думаю в историю записывать. А пока делаю так:
значения (целочисленный счетчик) пишу в таблицу с данными и штам времени. Затем с помощью ХП беру коэффициент счетчика из таблицы параметров оборудования считаю кВт*ч и пишу полученное значение в доптаблицу+ID данных которым это значение соответствует.

[Tonal]

Мне кажется, ты таки зря всё это в сервер пихаешь.
Напиши себе наследника TableModel, который эти преобразования делает налету и будет тебе щастье.
Даже если для преобразования будешь использовать какой-нибудь скриптовый движёк тормоза будут заметны только на довольно больших объёмах данных.
Кстати, какие предполагаются объёмы отчётов? Какое количество инфы будешь показывать?

П.С У меня знакомый делал прогу на VB для обработки и графического отображения некоторых данных.
Данные были табличные, в простом текстовом формате по 15мб на файлик.
Перед отображением данные обрабатывались пользовательскими скриптами на VBS - скриптовый движёк встроенный в винду.
Задержек в отображении не было, хотя масштаб можно было выбирать.
Прога разрабатывалась 10-13 лет назад для стандартных на те времена машин.

Сообщение отредактировал Tonal - 26.12.2008, 8:29

[Litkevich Yuriy]

Кстати, какие предполагаются объёмы отчётов? Какое количество инфы будешь показывать?

сейчас самая потребная форма отчета такая:

Число | 00:00 | 01:00 | ... | 23:00 | Итог

т.е. для каждой Т.У. таблица по-часовой статистики за месяц.

каждая строка отрачает одини сутки и итог по суткам

Напиши себе наследника TableModel, который эти преобразования делает налету и будет тебе щастье.

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

[Tonal]

Т.е для месяца <800 значений. Нужно очень постараться, чтобы на таких объёмах отчёты тормозили.
Хотя, конечно нет предела совершенству

Ну а про модель - можно и проксёй, особенно, если нужно отображать и исходные данные и просчитанные.
Если только просчитанные, то я бы напрямую из запроса/хп тягал.

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

[kuler]

ли ты имеешь в виду, что запустить можно на некой соседней машине?

в том числе, но и проц может быть многоядерным

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

этож просто параметры

[Litkevich Yuriy]

уровень данных над базой

что значит над базой?

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

я использую вариант который привел в теме FireBird: как преобразовать строки в столбцы?

этож просто параметры

ну и что, их можно рассматривать как теже оперативные данные, только меняются с другой скоростью (не синхронно)

[AD]

уровень данных над базой

что значит над базой?

Значит, что приложение, которое будет обрабатывать данную ситуацию.

[Tonal]

уровень данных над базой

что значит над базой?

Это значит некоторый свой, по возможности, независимый от Qt набор классов и контейнеров для нужных тебе данных и преобразований над ними.
Делается GUI, который всё это добро отображает.
Далее, делается связь этого добра с базой и/или непосредственно с прибором, чтобы можно было загружать данные.

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

П.С. Кстати, этот слой и называют "слоем прикладной логики" или "бизнес логики".

Сообщение отредактировал Tonal - 27.12.2008, 7:36