ВведениеАктуальность исследования обусловлена тем, что динамическое ценообразование для розничных потребителей электроэнергии и сочетание тарифов по времени использования и пиковых тарифов дают больший эффект при совместном использовании, что позволяет оптимизировать нагрузку на электросеть. В экономической теории, определяющей основы ценообразования на рынке электроэнергии, крайней противоположностью фиксированного розничного тарифа выступает тарификация в режиме реального времени, исходя из условий оптового рынка электроэнергии и мощности. Варианты тарификации, основанные на времени использования (time-of-use, TOU) и пиковом тарифе (critical-peak pricing, CPP) занимают промежуточное положение. В ценах TOU указаны тарифы для разного времени суток, дней недели или времени года. Тарификация CPP основывается на установлении особого повышенного тарифа в часы пиковой нагрузки, когда предполагается, что энергосистема будет близка к максимальной нагрузке.Исследование сглаживающей политики ценообразования, при которой динамическое ценообразование в режиме реального времени сочетается с установлением коридора цен и обеспечивает значительно больший прирост эффективности, чем TOU или CPP, представляет несомненную актуальность в период, когда многие страны осуществляют глобальный энергетический переход. В случае же невозможности перехода на полностью динамическое ценообразование комбинация TOU и CPP дает больший эффект при совместном их использовании, т. к. CPP нацелен на сокращение издержек эксплуатации маневровых мощностей для покрытия пиковой нагрузки, тогда как TOU нацелен на сглаживание циклических колебаний нагрузки в течение дня [1]. Материалы и методы исследованияВ работе использовались общенаучные методы теоретического исследования – индукции, дедукции, анализа и синтеза – для наблюдения за информационной инфраструктурой энергосбытовой компании и формирования на этой основе гипотез о путях повышения эффективности вычислительных операций за счет использования баз данных временных рядов. Для характеристик операций расчета стоимости услуг и агрегации данных по мощности за расчетный период использован метод описания. Также применялись общелогические методы исследования – абстрагирование, обобщение, идеализация, аналогии – в целях установления закономерностей функционирования баз данных временных рядов.В рамках исследования был развернут тестовый стенд, на котором была протестирована производительность базы данных временных рядов (TSDB), оптимизированная для данных с временными метками, и реляционная база данных (RDB), произведено сравнение их производительности, а также работа корутин для параллельных вычислений.В качестве источника данных показаний счетчиков используется текстовый набор данных из 168 млн строк с интервалом передачи потребленной энергии, усредненной за полчаса [2]. Каждая строка набора данных содержит следующие данные, разделенные запятой:– идентификатор счетчика;– тип тарифа: Std – общий тариф, ToU – динамический тариф;– дата и время показаний прибора с интервалом в полчаса;– усредненная потребленная энергия, кВт/ч.Первые 3 строки тестового набора:MAC000002, Std,2012-10-12 11:30:00, 0.143 MAC000002, Std,2012-10-12 12:00:00, 0.663 MAC000002, Std,2012-10-12 12:30:00, 0.256 Получасовые временные интервалы динамического тарифа содержатся в отдельном тестовом наборе времени действия тарифа. Тарификация имеет три режима: low – пониженный, normal – обычный, high – повышенный. Тестовый набор данных из 17 тыс. строк содержит следующие данные, разделенные запятой:– время действия тарифа с интервалом в полчаса;– текущий тариф.Первые 3 строки тестового набора:2013-01-01 00:00:00, Normal2013-01-01 00:30:00, Normal2013-01-01 01:00:00, NormalСтоимостное выражение тарифа хранится в отдельной таблице на каждый день.Тестовый архив данных загружался в RDB и TSDB для оценки скорости записи данных в разные типы баз данных. В качестве RDB использовалась MySQL в силу простоты развертыванияи нетребовательности к ресурсам. Для оценки производительности TSDB использовалась InfluxDB.Оценка производительности баз данных на чтение производилась замером времени на расчет стоимости потребленной энергии за месяц как для клиентов, использующих фиксированный тариф, так и для клиентов с динамическим тарифом. Для тестирования параллельных вычислений стоимости потребленной энергии использовался фреймворк Ktor, оценивалось время завершения операции расчета стоимости потребленной энергии в одном потоке и разделения на подоперации в корутинах. Технологии и инструменты хранения и обработки показаний приборовПрогнозирование потребления и выработки электроэнергии имеет решающее значение для определения прогнозной цены ресурса и функционирования розничного рынка электроэнергии. S. Lahmiri исследовал прогнозы цен на электроэнергию в применением гауссовой регрессии, регрессии опорных векторов, деревьев регрессии, k-ближайших соседей и глубоких нейронных сетей прямого распространения [3]. Прогнозная цена на электроэнергию на 48 ч вперед сообщается пользователю и впоследствии уточняется, а потребители адаптируют спрос в соответствии с ценой ресурса [4]. В [5] Т. Yamazaki и др. представлена методология разработки программ реагирования на спрос при одновременном смягчении негативных последствий. Авторы рассматривают способы оценки дисбаланса электроэнергии, что мотивирует потребителей к снижению нагрузки в таких случаях. С позиции потребителя оптимизация потребления электроэнергии заключается в планировании «гибких» энергоемких видов деятельности в зависимости от стоимости ресурса [6]. Переход на оптимизированную модель потребления гибких видов деятельности приводит к сокращению расходов на оплату энергии на 38 % [7]. Переход от фиксированного тарифа к динамическому ценообразованию требует модернизации информационной инфраструктуры энергосбытовой компании [8]. При использовании фиксированного тарифа алгоритмы расчета стоимости оказанных услуг относительно просты и нагрузка на базу данных относительна невелика. В условиях динамического ценообразования необходимо хранить историю потребления электрической энергии по каждому прибору, рассчитанную за определенные промежутки времени (профили мощности) в Автоматизированной системе коммерческого учета электроэнергии.  Счетчики электроэнергии используют беспроводную защищенную сеть передачи данных Wide Area Network для передачи показаний на серверы оператора обработки данных информации о потребленной энергии. Информация со счетчика передается в зашифрованном виде и без персональных данных. Энергосбытовая компания получает данные с сервера оператора обработки данных, дешифрует данные и по идентификатору счетчика сопоставляет его с клиентом. По завершении расчетного периода на основании переданных показаний рассчитывается стоимость потребленной энергии. В зависимости от конфигурации счетчика показания усредняются за определенный промежуток времени, например каждые 30 минут. Это дает энергосбытовой компании наиболее точную картину потребления энергии и возможность рассчитать стоимость энергии по динамическому тарифу. Для хранения показаний приборов возможно использование различных хранилищ: файловый csv или txt формат, или в базе данных (RDB, нереляционной или TSDB). Операции расчета стоимости услуг и агрегации данных по мощности за расчетный период очень сложно оптимизировать с помощью текстовых файлов и хранилища «ключ-значение»; RDB обладает инструментами индексирования данных, но уступает в производительности TSDB. TSDB оптимизирована для данных с временными метками, стандартный набор инструментов TSDB содержит механизмы управления жизненным циклом данных (удаление устаревших данных, агрегация записей), оптимизированы алгоритмы расчета итогов и обхода множества записей. Для повышения производительности и устойчивости системы применяется репликация данных – это процесс создания и развертывания нескольких копий одинаковых баз данных на разных серверах. В глобальных системах пользователям предоставляется доступ к ближайшему серверу, что сокращает задержки передачи данных. В случае географического распределения серверов при утере канала или выходе из строя оборудования система сохраняет свою работоспособность. Наряду с репликацией для повышения производительности может быть использовано сегментирование базы данных – горизонтальное масштабирование баз данных, при котором данные распределяются по нескольким базам данных или сегментам, чтобы повысить производительность в системах с большими объемами данных.  При проектировании системы важное значение имеет общая ее производительность, которая складывается из скорости чтения/записи информации в базу данных и скорости вычислительных операций, с целью сокращения времени ожидания пользователя и устранения узких мест, препятствующих масштабированию системы. Существует несколько подходов к решению этой проблемы, в том числе:1. Многопочность – распространенный подход параллельных вычислений, обладающий рядом недостатков:– количество потоков, которые могут быть запущены, ограничено операционной системой;– сложность передачи данных между потоками;– трудности в отладке и управлении последовательностью операций.2. Обратные вызовы – при данном подходев качестве параметра передают функцию, которую необходимо запустить после завершения операции. При этом возникают сложности описания вложенных обратных вызовов, когда нужно выполнить каскад операций. 3. Реактивные расширения – комбинация лучших идей из шаблона наблюдателя, шаблона итератора и функционального программирования, представляет собой наблюдаемый поток. 4. Корутины – технология асинхронных вычислений, в которой операция может быть приостановлена и возобновлена позже. При данном подходе используется пул потоков, управляемых контроллером состояния. В разработке использование корутин помогает улучшить синтаксис асинхронного кода, который мало чем отличается от обычного кода, но такой код обладает рядом преимуществ:– можно запустить много корутин на одном потоке из-за возможности приостановки, которая не блокирует поток;– меньше утечек памяти, операции выполняются в рамках жизненного цикла;– встроенная поддержка отмены операции и обработки ошибок, которая распространяется на вложенные корутины. Оценка производительности различных типов баз данныхПо результатам стендовых испытаний можно сделать вывод о производительности TSDB, сегментированной по тарифам, и увеличении скорости вычислительных операций при разделении операции на подоперации в корутинах. В MySQL создана база покупателей «customers». Для регистрации данных счетчиков создана таблица «measurements» со следующей структурой (табл. 1).  Таблица 1 Table 1Таблица измерений показаний «measurements»Measurement table of readings «measurements»ПолеНазначение поляТипМожет быть пустымIdИдентификатор записи, первичный ключIntНетdate_timeВремя событияTimestampДаTariffТариф std или touvarchar(5)TypeТип измерительного прибораvarchar(6)ZipКод местонахождения прибораvarchar(6)dev_idИдентификатор прибораvarchar(10)ValueПотребленная энергия, кВт/чFloat  В InfluxDB для регистрации данных счетчиков создан раздел «meters» с похожей структурой:– измерение: power;– тэги: tariff, zip, dev_id;– поле: power.Для оценки производительности фиксации показаний приборов учета мы использовали имитационную модель записи показаний приборов в базуданных из csv-файла.Запись тестовых данных в MySQL производилась сериями по 1 млн записей через Python-скрипт. В InfluxDB запись тестовых данных производилась аналогично сериями по 1 млн записей через Python-скрипт. Результаты представлены в табл. 2. Таблица 2 Table 2Производительность баз данных на записьWrite database performanceПоказательMySQLInfluxDBВремя загрузки первых 10 серий0:01:290:01:390:01:360:01:320:01:320:02:350:02:490:03:000:03:220:04:270:22:230:22:210:22:440:24:170:22:290:22:290:23:110:23:280:23:030:24:00Время загрузки последних 10 серий0:14:270:14:470:14:400:14:480:14:310:15:170:14:440:14:510:14:380:13:460:24:060:23:360:23:340:23:370:23:380:23:350:23:340:24:200:24:080:22:30Общее время загрузки, сут : ч : мин : с1:14:30:372:23:19:27Загрузка процессора, %4,64,2Потребление памяти, Gb6,80,2Размер таблицы показаний, Gb201,2  Запись 168 млн строк в MySQL почти в 2 раза быстрее, при этом с ростом размера базы скорость замедляется из-за построения индексов. Скорость записи в InfluxDB не зависит от размера базы.В записи InfluxDB проигрывает MySQL из-за особенности файловой архитектуры. MySQL хранит таблицу в отдельном файле, раздел базы данных InfluxDB содержит множество папок и файловс индексами и сериями. Потребление ресурсов процессора не сильно отличается, а потребление оперативной памяти у InfluxDB в 28 раз меньше. На диске таблица данных InfluxDB занимает в 16 раз меньше места. Оценка производительности баз данных на чтение производилась моделированием расчета стоимости потребленной энергии за месяц с извлечением из базы информации об объемах потребленных услуг и цены и выполнением операций разделения данных по тарифам. Для клиентов, использующих общий тариф (Std), цена устанавливается раз в месяц, поэтому мы извлекаем цену по тарифу Std на конец расчетного периода. Для клиентов, использующих динамический тариф (ToU), стоимость определяется исходя из категории тарифа для временного диапазона, которая может быть стандартной (Normal), повышенной (High) или пониженной (Low), а цена тарифа определяется аналогично тарифу Std – конец расчетного периода. Добавим в MySQL таблицу категорий динамических тарифов «tou_tariffs» (табл. 3). Таблица 3Table 3Категории динамических тарифов «tou_tariffs»Categories of dynamic tariffs «tou_tariffs»ПолеНазначение поляТипМожет быть пустымIdИдентификатор записи,первичный ключIntНетdate_timeВремя действия тарифаTimestampДаtou_tariffТарифvarchar(6)  Добавим в MySQL таблицу истории цен на электроэнергию «price_list» (табл. 4). Таблица 4Table 4Цены на электроэнергиюElectricity pricesПолеНазначение поляТипМожет быть пустымIdИдентификатор записи,первичный ключIntНетdate_timeВремя установления ценыTimestampДаtariffТарифvarchar(6)priceЦенаFloat  Для хранения истории в InfluxDB тарифов создан раздел price_list со следующей структурой:– измерение: tou – для динамических тарифов, std – для фиксированных тарифов;– тэги: tariff;– поле: price.Рассчитаем стоимость потребленной энергии за один месяц в MySQL, получив информацию из таблиц measurements, price_list и tou_tariffs. Выполнение запроса заняло 1 ч 10 мин 5 с. На выходе получаем таблицу со следующей структурой (в качестве примера выведены первые три строки) (табл. 5). Таблица 5Table 5Результат выполнения запроса в MySQL расчета стоимости потребленной энергииResult of energy cost calculation MySQL  query executionУстройствоТарифКоличество, кВт/чЦена, руб.MAC000002Std351,114,41MAC0000031 050,96MAC00000454,33  Аналогично рассчитаем стоимость потребленной энергии за один месяц в InfluxDB. Выполнение запроса заняло 8 мин и 23 с. На выходе получаем таблицу со следующей структурой (табл. 6). В качестве примера выведена первая строка. Таблица 6Table 6Результат выполнения запроса в InfluxDB расчета стоимости потребленной энергииResult of energy cost calculation InfluxDB query executionИзмерениеТарифДата началапериодаДата окончанияпериодаКоличество, кВт/чЦена, руб.УстройствоРежимдинамическоготарифаКодтерриториальнойединицыpowertou2013-01-01T00:00:002013-02-01T00:00:000,1424,56MAC000005High100100  Производительность баз данных на чтение для выполнения расчета стоимости потребленной энергии за один месяц представлена в табл. 7.  Таблица 7Table 7Производительность баз данных на расчет стоимости потребленной энергии за один месяцDatabase performance for calculating the cost of energy consumed for one monthПоказательMySQLInfluxDBВремя выполнения запроса расчета ценыи объема потребленной электроэнергии, ч : мин : с01 : 10 : 050 : 08 : 23Загрузка процессора, %1,126,7Потребление памяти, Mb844891  Скорость выполнения запроса в InfluxDB в 8 раз быстрее, чем в MySQL. InfluxDB нагружает процессор значительней MySQL, потребление памяти одинаково. Интеграция TSDB с учетной системойСуществующие учетные системы можно разделить на 2 категории: основанные на платформе 1С : Предприятие и построенные на сервисах с использованием PostgreSQL (табл. 8). Таблица 8Table 8Платформы расчета стоимости электроэнергииPlatforms for calculating the cost of electricityПлатформаДостоинстваНедостатки1С : ПредприятиеПрисутствует блокрегламентированного учета.Скорость внедренияНизкая производительность.Ограниченная интеграцияс сервисами в качестве сервераPostgreSQLПроизводительность.ГибкостьСложность развертывания системы  Исходя из рассмотренных выше преимуществ TSDB мы можем интегрировать ее в сервис регистрации показаний. Архитектура системы в тестовом стенде спроектирована на RESTful API.Сервис регистрации показаний. Получает показания приборов учета от оператора обработки данных и записывает в TSDB, обрабатывает запросы сервиса расчетов с клиентами для определения стоимости потребленной энергии. В нашем тестовом стенде сервис регистрации показаний спроектирован на основе Ktor и InfluxDB. Сервис расчетов с клиентами осуществляет операции с RDB, где содержится информация о приборах учета, клиентах энергосбытовой компании, тарифах и начисленных суммах, производит регламентные операции расчета начислений за потребленные услуги, спроектирован на основе Ktor и MySQL. В качестве метода авторизации используется JSON Web Token (JWT).При JWT-авторизации клиент отправляет POST запрос на ресурс login, логин и пароль передаются в формате JSON. Если логин и пароль правильны, сервер генерирует токен и подписывает его с помощью алгоритма HS256. В дальнейшем токен передается в заголовке authorization при обращениях к серверу расчетов с клиентами. Пример GET-запроса объема потребленных услуг:GET http://127.0.0.1:9090/measurements/2012/03 Authorization: Bearer Token Если срок действия логина не истек, сервер Ktor обрабатывает запрос и отправляет ответ в формате JSON.Учетная система. Выполняет функции регламентированного учета, ведения договоров, клиентов, организации электронного документооборота. В нашем тестовом стенде в качестве учетной системы мы использовали типовую конфигурацию 1С Бухгалтерии 3.0. В системе расчета розничной стоимости электроэнергии участвуют следующие объекты конфигурации.Справочники:– контрагенты – для ведения информации о клиентах энергосбытовой компании. Справочник «контрагенты» синхронизируется по коду с сервисом расчетов с клиентами через POST-запросы фонового задания по расписанию;– договоры с контрагентами – для регистрации заключенных договоров, ведения учета срока их действия и существенных условий договорных обязательств;– номенклатура – для ведения перечня оказываемых услуг;– виды цен – для регистрации используемых тарифов на электроэнергию;– цены номенклатуры – для фиксации стоимости тарифа на определенную дату для конкретной услуги. Прайс-лист синхронизируется с сервисом расчетов с клиентами через POST-запросы фонового задания по расписанию.Документы.Реализация услуг – для регистрации количества, перечня и стоимости оказанных услуг в расчетном периоде. Продажи синхронизируются с сервисом расчетов с клиентами через GET-запрос лицом, обладающим соответствующими полномочиями, вручную, после выполнения регламентного задания расчета стоимости оказанных услуг в сервисе расчетов с клиентами и  выполнения  контрольных  процедур выверки корректности исчисленных данных. Приходный кассовый ордер и входящее платежное поручение – для ведения расчетов по оказанным услугам. Акт сверки взаиморасчетов – для установления факта верности данных бухгалтерского учета. Формируются ежеквартально по клиентам-юридическим лицам после закрытия расчетного периода.Сервис расчетов через адаптеры предоставляет возможность операторам взаимодействовать с сервисом расчетов с клиентами для просмотра и изменения информации о приборах учета, объема потребленных ресурсов (рис. 1).    Рис. 1. Информационная модель учета расчетов потребленной энергии  при динамическом ценообразовании Fig. 1. Information model of accounting for calculations of consumed energy in dynamic pricing  Для взаимодействия с сервисом расчетов с клиентами мы использовали объект 1С – HTTPСоединение.Для оптимизации скорости выполнения расчетов мы произвели сегментирование базы показаний приборов на 6 сегментов по идентификатору прибора:MAC000000 - MAC001000 MAC001000 - MAC002000 MAC002000 - MAC003000 MAC003000 - MAC004000 MAC004000 - MAC005000 MAC005000 - MAC006000 Для организации параллельных запросов мы использовали корутины. Расчет стоимости потребленной энергии производился в сервисе расчетовс клиентами в асинхронном режиме по каждому сегменту базы показаний приборов с записью рассчитанных стоимостных и количественных значений потребленных ресурсов по каждому счетчику в RDB (рис. 2).    Рис. 2. Взаимодействие сервиса расчетов с клиентами и учетной системы Fig. 2. Interaction of the customer settlement service and the accounting system  По окончании расчета вызывается оповещение пользователя. Используя корутины и сегментирование базы, мы сократили время на осуществление регламентной операции расчета стоимости потребленной энергии за один месяц до 1 мин 45 с.  ЗаключениеВ ходе проведенного исследования были сравнены производительность и эффективность использования RBD MySQL и TSDB InfluxDB для хранения и обработки данных о потребленной электроэнергии. Экспериментальные результаты показали, что при записи данных MySQL обеспечивает в 2 раза более высокую скорость по сравнению с InfluxDB, однако с увеличением объема данных производительность MySQL снижается из-за необходимости построения индексов. InfluxDB, в свою очередь, демонстрирует стабильную скорость записи, но проигрывает MySQL из-за особенностей файловой архитектуры.Анализ чтения данных выявил обратную тенденцию: InfluxDB выполняет запросы в 8 раз быстрее, чем MySQL, что обусловлено оптимизированной структурой хранения временных рядов и возможностью выполнения агрегатных операций с меньшей вычислительной нагрузкой. Однако использование InfluxDB сопровождается значительным увеличением нагрузки на процессор, что следует учитывать при проектировании высоконагруженных систем.Для оптимизации процесса расчетов была реализована сегментация базы данных показаний по диапазонам идентификаторов приборов учета, а также применение параллельной обработки данных с использованием корутин. Это позволило значительно сократить время выполнения расчетов и повысить общую производительность системы. Разработанная архитектура демонстрирует возможность масштабируемого решения для автоматизации учета электроэнергии, обеспечивая гибкость и высокую степень интеграции с существующими учетными системами.