База данных в реальном времени (бдрв)

Когда говорят про базу данных в реальном времени, многие сразу думают про ?мгновенные обновления? или ?высокую скорость записи?. Но в реальных промышленных сценариях, особенно в энергетике, всё сложнее. Часто вижу, как люди ставят ClickHouse или даже InfluxDB для сбора телеметрии с подстанций, а потом удивляются, почему система не справляется с пиковыми нагрузками при аварийных событиях. Проблема не в том, что база ?медленная?, а в том, что архитектура не учитывает контекст данных: например, как связаны показания датчиков напряжения с состоянием физического оборудования, которое может иметь свою инерционность.

Из чего на самом деле состоит БДРВ в энергетике

В нашем проекте для OOO Шэньхэн Энергетическое Оборудование мы изначально пошли по классическому пути: TimescaleDB для хранения временных рядов, плюс PostgreSQL для метаданных по оборудованию. Казалось бы, всё логично — данные с устройств (трансформаторов, выключателей) пишутся каждые 100 мс, агрегируются, визуализируются. Но быстро столкнулись с нюансом: сами по себе цифры напряжения или тока мало что значат, если не привязаны к состоянию узла сети и к событиям технического обслуживания. Пришлось вводить дополнительный слой — так называемый ?контекстный движок?, который в реальном времени связывает потоковые данные с каталогом оборудования и журналом событий.

Например, если датчик на линии 10 кВ показывает скачок, система должна не просто записать значение, но и проверить: не проводится ли на этой линии плановые испытания? Не было ли недавно замены изолятора? Без этого любая база данных реального времени превращается в архив сырых цифр, из которых потом сложно вытащить причинно-следственные связи. Мы использовали гибридный подход: события и метаданные — в PostgreSQL, временные ряды — в TimescaleDB, а связку делали через Kafka Streams. Не идеально, но работало.

Кстати, о выборе технологий. Сейчас модно говорить про Redis Streams или Apache Druid, но в энергетике часто есть жёсткие требования к сохранности данных и аудиту. Поэтому чисто in-memory решения не всегда проходят — нужно дублирование на диск, плюс интеграция с legacy-системами типа SCADA. У Шэньхэн как раз типичный случай: часть оборудования поставляет данные по Modbus, часть — через OPC UA, а учётные системы висят на старых Oracle-базах. Пришлось писать кастомные коннекторы, которые не только перекидывают данные, но и нормализуют единицы измерения (где-то вольты, где-то проценты от шкалы).

Где чаще всего ломается реальное время

Самый болезненный момент — это не чтение, а запись при аномалиях. В штатном режиме БДРВ справляется, но представьте: короткое замыкание в сети, десятки тысяч устройств одновременно начинают сыпать аварийными сигналами с частотой до 1 мс. Если база не подготовлена, очередь на запись растёт, данные теряются или задерживаются. Мы наступили на эти грабли в одном из пилотных проектов, где использовали PostgreSQL с логической репликацией — при пике реплика отстала на несколько минут, что для диспетчерской недопустимо.

Пришлось пересматривать архитектуру: разделили потоки данных на ?горячий? (критические события) и ?холодный? (штатная телеметрия). Для горячего потока подняли отдельный кластер TimescaleDB с уменьшенным интервалом сжатия чанков, плюс добавили буфер в виде Apache Pulsar, который гарантировал доставку даже при перегрузках. Это, конечно, усложнило систему, но без такого разделения база данных в реальном времени просто не успевала обрабатывать пики.

Ещё один тонкий момент — это согласованность данных между разными системами. Например, в OOO Шэньхэн Энергетическое Оборудование есть каталог оборудования с характеристиками устройств (допустимые токи, сроки поверки). Если инженер вносит изменения в каталог (скажем, меняет уставку защиты), эти изменения должны почти мгновенно отразиться в правилах обработки потоковых данных. Мы для этого завели отдельную таблицу-?сигнал? в той же PostgreSQL, которую подписывали через LISTEN/NOTIFY, но в масштабе это стало бутылочным горлышком. Сейчас экспериментируем с Change Data Capture из PostgreSQL в Kafka, чтобы обновления каталога сразу попадали в потоковый процессор.

Интеграция с бизнес-процессами: не только мониторинг

Часто БДРВ рассматривают как инструмент для дашбордов или оповещений. Но в промышленности данные в реальном времени могут напрямую влиять на бизнес-процессы. У Шэньхэн, например, есть система учёта ресурса оборудования. Данные о нагрузке и температуре с трансформаторов постоянно пишутся в базу, а на их основе считается износ изоляции. Когда износ достигает порога, система автоматически создаёт заявку на ТО в ERP — без участия диспетчера. Здесь важно, чтобы расчёт износа происходил онлайн, а не раз в сутки батчем, иначе можно пропустить критическое состояние.

Реализовали мы это через пользовательские агрегатные функции в TimescaleDB, которые считают интеграл от температуры с весовыми коэффициентами. Сами коэффициенты хранятся в каталоге оборудования и могут корректироваться технологами. Получилось гибко, но пришлось повозиться с оптимизацией запросов — сначала агрегация на лету тормозила при одновременном расчёте для сотен устройств. Разделили расчёт на два этапа: предварительная агрегация в материализованном представлении каждые 5 минут, а итоговый расчёт — по требованию.

Кстати, о производительности. В таких сценариях важно не только быстро писать, но и быстро читать с учётом контекста. Типичный запрос: ?показать температуру обмотки трансформатора Т-123 за последние 2 часа, но только в те периоды, когда нагрузка была выше 80%?. Если делать JOIN между таблицей температур и таблицей нагрузок на лету, даже с индексами можно получить задержку. Мы пошли по пути денормализации — создали отдельную потоковую таблицу, где данные сразу агрегируются по правилам бизнес-логики. Это увеличило объём хранения, но сократило время отклика до приемлемых 200–300 мс.

Ошибки, которые лучше не повторять

В одном из ранних внедрений мы попытались использовать чисто документоориентированную БД (MongoDB с capped collections) для хранения событий. Аргументы были: гибкая схема, хорошая скорость записи. Но быстро вылезли проблемы: сложные запросы по временным диапазонам и связям между документами работали плохо, плюс отсутствие JOIN усложнило интеграцию с каталогом оборудования. Пришлось мигрировать на комбинированное решение, а миграция на ходу — это отдельная боль. Вывод: для базы данных реального времени в промышленности лучше сразу выбирать специализированные движки, которые заточены под временные ряды и сложные фильтры, а не под документы.

Другая ошибка — недооценка требований к отказоустойчивости. В тестовом контуре всё работает отлично, но на проде случаются сбои сети между ЦОДом и удалёнными подстанциями. Мы сначала полагались на встроенную репликацию БД, но она не спасала при обрывах на несколько часов — очередь на отправку данных росла, а потом система пыталась отправить всё разом и падала. Добавили локальные буферы на edge-устройствах (простые SQLite-базы), которые аккумулируют данные при потере связи и потом синхронизируются, когда канал восстанавливается. Это, конечно, не совсем БДРВ в чистом виде, но без такого подхода в реальных условиях не обойтись.

И ещё про ?реальное время?. Часто заказчики хотят, чтобы данные отображались на дашборде ?мгновенно?, но при этом не готовы платить за низколатентные каналы связи или за аппаратное ускорение. Приходится объяснять, что если датчик находится в сотнях километров от ЦОДа, то даже при идеальной БД задержка будет определяться физикой передачи сигнала. В таких случаях мы вводим понятие ?достаточно реального времени? — например, обновление раз в секунду для большинства параметров, и только для критических событий — push-уведомления за миллисекунды. Это компромисс, но без него бюджет проекта может улететь в космос.

Что в сухом остатке

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

У OOO Шэньхэн Энергетическое Оборудование после всех итераций получилась система на стыке TimescaleDB, PostgreSQL и Kafka, которая закрывает около 90% потребностей. Оставшиеся 10% — это вечные доработки под новые типы оборудования или изменения в нормативах. Но это уже нормально: БДРВ должна быть не монолитом, а живой платформой, которую можно адаптировать без полной переделки. Главное — не гнаться за модными трендами, а чётко понимать, какие данные, в каком объёме и для каких процессов действительно нужны онлайн. Остальное — технические детали, которые решаются по мере поступления проблем.