Добрый день,
Имеется объект (например, здание) который содержит набор потребителей электроэнергии (комната, лифтовое оборудование, освещение коридоров и т.д.), у большинства потребителей установлены приборы учета (ПУ) электроэнергии. Измерения выполняются 1 раз в минуту. Измеряются несколько параметров: расход электроэнергии за эту минуту, мгновенные значение тока и напряжения. Потребителей несколько сотен (300) и потенциально зданий может быть много до 10000.
Как было отмечено, большинство потребителей оборудованы приборам, но есть некоторые которые не оборудованы. Например, на этаж есть приборы учета комнат и общеэтажный прибор, а освещение не оборудование и освещение можно вычислить косвенно как разность показаний этажного прибора минус сумма потребления комнат.
Приборы могут "косячить" попускать данные и предоставлять данные с опозданием. Например, контроллер, который опрашивает приборы, работает корректно, но потерял связь с сервером и восстановил ее через несколько дней.
Каждый прибор измерений имеет некоторое описание (метаданные):
- здание (справочник, ссылка на здание)
- название (= номер комнаты)
- этаж (справочник этажей здания: 1,2,3-й и т.д.)
- тип (справочник производственное, хозяйственное, жилое и т.д.)
По каждому зданию требуются иметь следующий набор информации (
структуру потребления ):
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Суммарное потребление всего здания
Удельное потребление электроэнергии на комнату
Этажное потребление
потребелние этажа 1
потребление этажа 2
….
Подъездное потребление
потребление подъезда 1
потребление подъезда 2
…
Потребление по группам потребителей:
суммарное по хозяйственным
суммарное по производственным
суммарное по жилым
суммарное по лифтовому оборудованию
Для хранения данных измерений, полученных от приборов учета, планируется использовать TimescaleDB или ClickHouse.
Основным камнем преткновения является следующее:
1. данные "доходят", то есть могу прийти задним числом (через несколько дней от даты измерений)
2. структура потребления (правила по которым нужно выполнять анализ/визуализацию) может меряться довольно часто: несколько раз в месяц. Исходные минутные данные о потреблении (от приборов) хранятся несколько лет. Схем может быть несколько, например, группы составлены по другим признакам точек.
3. Объекты то появляются, то исчезают, точки то добавляются выходят из эксплуатации по этому нельзя использовать жесткий граф расчета при котором каждый узел знает кто в него входит. Изменений слишком много и операторы не справятся с отслеживанием корректности структуры потребления (будут не забывать добавлять/удалять).
В чем вопрос?
- Есть ли устоявшаяся best practice для решения подобного рода задач?
- Можно ли придумать решение такое, чтобы при отображения данных по структуре потребления объекта (за год с разбивкой по месяцам) так, чтобы не нужно было пересчитывать (сохранять в БД), а так чтобы расчет выполнялся "налету" по запросу с уровня приложений?
- Если перенести логику вычислений на приложение (в некий сервис getData) и вычислять все "налету" полагаясь при этом на возможности СУБД - на агрегацию (свертку) данных с минутных значений до месячных в рамках запросов - на сколько велика будет деградация производительности в далекой перспективе?
- На сколько утопична идея реализации выполнения «налету»?
- При необходимости выполнить сравнительный анализ объектов по показателю "удельное потребеление ЭЭ на комнату" пользователю требуется вывести результаты в таблице на странице (или отчете) и чтобы ее сформировать придется либо выполнить запрос в предрасчитанные данные (будет быстро) либо выполнить N запросов по каждому объекту для формирования единого списка... Как лучше выполнить реализацию для такого анализа?
