Модуль подсистемы "Архивы" <DBArch>
| Модуль: | DBArch |
| Имя: | Архиватор на БД |
| Тип: | Архив |
| Источник: | arh_DBArch.so |
| Версия: | 2.3.0 |
| Автор: | Роман Савоченко |
| Описание: | Модуль архиватора. Предоставляет функции архивирования сообщений и значений на БД. |
| Лицензия: | GPL |
Введение
Модуль предназначен для архивирования сообщений и значений системы OpenSCADA на одну из баз данных, поддерживаемых OpenSCADA.
Любая SCADA система предоставляет возможность архивирования собранных данных, т.е. формирование истории изменения (динамики) процессов. Архивы условно можно разделить на два типа: архивы сообщений и архивы значений.
Особенностью архивов сообщений является то, что архивируются, так называемые, события. Характерным признаком события является его время возникновения. Архивы сообщений обычно используются для архивирования сообщений в системе, т.е. ведение логов и протоколов. В зависимости от источника сообщения могут классифицироваться по различным критериям. Например, это могут быть протоколы аварийных ситуаций, протоколы действий операторов, протоколы сбоев связи и др.
Особенностью архивов значений является их периодичность, определяемая промежутком времени между двумя смежными значениями. Архивы значений применяются для архивирования истории непрерывных процессов. Поскольку процесс непрерывный, то и архивировать его можно только путём введения понятия квантования времени опроса, поскольку иначе мы получаем архивы бесконечных размеров ввиду непрерывности самой природы процесса. Кроме этого, практически мы можем получать значения с периодом ограниченным самими источниками данных. Например, довольно качественные источники данных в промышленности редко позволяют получать данные с частотой более 1кГц. И это без учёта самих датчиков, имеющих ещё менее качественные характеристики.
Для ведения архивов в системе OpenSCADA предусмотрена подсистема "Архивы". Данная подсистема, в соответствии с типами архивов, состоит из двух частей: архив сообщений и архивы значений. Подсистема в целом является модульной, что позволяет создавать архивы основанные на различной природе и способах хранения данных. Данный модуль предоставляет механизм архивирования на БД как для потока сообщений, так и для потока значений.
1. Архиватор сообщений
Архивы сообщений формируются архиваторами. Архиваторов может быть множество с индивидуальными настройками, позволяющими разделять архивирование различных классов сообщений.
Архиватор сообщений этого модуля хранит данные в таблице БД, которая называется "DBAMsg_{ArchID}", где:
- ArchID — идентификатор архиватора сообщений.
Модулем предоставляются дополнительные параметры настройки процесса архивирования (рис.1).
Рис.1. Дополнительные параметры настройки процесса архивирования сообщений.
В число дополнительных параметров входят:
- Размер архива (дней) — определяет размер архива по времени. После превышения лимита старые записи начнут удаляться! Установить в 0 для отключения этого лимита и некоторого повышения производительности.
- Формировать время как строка — сохранять время сообщения в читабельном виде. Только для БД это поддерживающих в специфическом формате данных вроде "datetime" в MySQL.
Данная опция несовместима, т.е. при её изменении Вы потеряете существующие архивы.
Таблица БД архиватора сообщений имеет структуру {MIN, TM, TMU, CATEG, MESS, LEV}, где:
- MIN — UTC время, в минутах, используется при чтении минутами, для ускорения.
- TM — UTC время сообщения, секунды от эпохи (01.01.1970). В БД, содержащих специализированный тип для хранения даты и времени, может использоваться этот специализированный тип, для параметра "Формировать время как строка".
- TMU — микросекунды времени.
- CATEG — категория сообщения.
- MESS — текст сообщения.
- LEV — уровень сообщения.
2. Архиватор значений
Архивы значений, по умолчанию, формируются архиваторами значений индивидуально для каждого зарегистрированного архива. Архиваторов может быть множество с индивидуальными настройками, позволяющими разделить архивы по различным параметрам, например, по точности и глубине. Архивы параметров одного архиватора могут группироваться в группы, одна таблица, с указанным ограничением количества параметров в группе. Группирование позволяет значительно увеличить производительность архивации за счёт отправки в БД одного запроса со значениями параметров в группе.
Архив значений является независимым компонентом, который включает буфер, обрабатываемый архиваторами. Основным параметром архива значения является источник данных. В роли источника данных могут выступать атрибуты параметров системы OpenSCADA, а также другие внешние источники данных (пассивный режим). Другими источниками данных могут быть: сетевые архиваторы удалённых OpenSCADA систем, среда программирования системы OpenSCADA и др. Не менее важными параметрами архива являются параметры его буфера. От параметров буфера зависит возможность работы архиваторов. Так, периодичность значений в буфере должна быть не больше периодичности самого быстрого архиватора, а размер буфера не менее двойного размера для самого медленного архиватора. В противном случае возможны потери данных.
Общая схема архивирования значений наглядно изображена на рис. 2.
Рис.2. Общая схема процесса архивирования значений.
Архиватор значений этого модуля хранит данные в таблице БД, которая именуется "DBAVl_{ArchivatorID}_{ArchiveID}", для одиночного режима, и "DBAVl_{ArchivatorID}_<GRP>{N}", для групового режима, где:
- ArchivatorID — Идентификатор архиватора значений.
- ArchiveID — Идентификатор архива значений.
- N — Номер группы, опущен для первой.
Модулем предоставляются дополнительные параметры настройки процесса архивирования (рис.3).
Рис.3. Дополнительные параметры настройки процесса архивирования значений.
В число дополнительных параметров входят:
- Размер архива (дней) — определяет размер архива по времени. После превышения лимита старые записи начнут удаляться! Установить в 0 для отключения этого лимита и некоторого повышения производительности.
- Формировать время как строка — сохранять время значения в читабельном виде. Только для БД это поддерживающих в специфическом формате данных вроде "datetime" в MySQL. Данная опция несовместима, т.е. при её изменении Вы потеряете существующие архивы.
- Ограничение группировки параметров — ненулевое значение включает групповое архивирование и определяет ограничение на количество параметров в группе/таблице.
Таблица БД архиватора значений имеет структуру {MARK, TM, VAL}, для одиночного режима, и {MARK, TM, {PRM1}, {PRM2}, {PRMN}}, для группового, где:
- MARK — метка быстрого доступа/чтения архива, {TM}/(10*{period}).
- TM — UTC время значения, секунды от эпохи (01.01.1970). В БД, содержащих специализированный тип для хранения даты и времени, может использоваться этот специализированный тип, для параметра "Формировать время как строка".
- VAL — Значение параметра в одиночном режиме, тип значения определяет тип данной колонки (Целое, Вещественное, Строка).
- PRM1...PRMN — Значение параметра с идентификатор в имени колонки в групповом режиме, тип значения определяет тип данной колонки (Целое, Вещественное, Строка).
3. Информационная таблица архивных таблиц
Для хранения начала, конца и иной служебной информации архивов в архивных таблицах создаётся информационная таблица с именем данного модуля: "DBArch". Данная таблица имеет структуру {TBL, BEGIN, END, PRM1, PRM2, PRM3}, где:
- TBL — Имя таблицы архива.
- BEGIN — Начало данных в архиве. Секунды для сообщений и микросекунды для значений от эпохи UNIX (01.01.1970).
- END — Конец данных в архиве. Секунды для сообщений и микросекунды для значений от эпохи UNIX (01.01.1970).
- PRM1 — Дополнительный параметр 1: периодичность значений, в микросекундах.
- PRM2 — Дополнительный параметр 2: тип значений параметра в одиночном режиме или перечень параметров в группе {Type}:{ArchiveId} для группового режима.
- PRM3 — Дополнительный параметр 3.
Согласно информации в указанной таблице для архиваторов значений поддерживается восстановление и создание объектов архива.
4. Эффективность
При проектировании и реализации данного модуля особых механизмов повышения эффективности процесса архивирования не закладывалось в виду наличия объективных ограничений самих баз данных и интерфейсов доступа к ним. Следовательно эффективность архивации на БД в основном связана с самой БД и интерфейса доступа к ней. Из наиболее эффективных интерфейсов и подходов по повышению производительности нужно отметить следующие:
- Чтение из БД нескольких записей не отдельными/конкретными командами SELECT, а обобщающими SELECT запросами, что для всех БД минимум на порядок быстрее. Для использования этой особенности слой доступа к БД в OpenSCADA, в лице запроса "dataSeek()", был расширен на предмет поддержки предзагрузки всех записей ответа на запрос в full. Данным модулем эта особенность также теперь используется позволяя данные часто получать быстрее чем они потом обрабатываются, хотя и уступая архивации на файловую систему.
- Запись в БД одной лишней колонки также значительно быстрее, чем отдельная запись. Данным модулем эта особенность используется в части архивации значений и в режима группировки, т.е. значения отдельных параметров пишутся в одну таблицу как отдельная колонка.
Результаты измерений производительности архивации сведены в таблице ниже:
| Тест / Окружение и БД | Intel Core3 1.3GHz, Local PostgreSQL 9.3, SSD | AMD A8 3.5GHz, Local PostgreSQL 9.3, HDD |
| Архивация значений, 60 записей, 1 сигнал (секунд) | 53...63 | 13...14 |
| Архивация значений, 60 записей, 10 сигналов (секунд) | 65...67 | 16...19 |
| Архивация значений, 60 записей, 100 сигналов (секунд) | 154...163 | 52...60 |
| Результат: среднее время записи 60 значений одного параметра (миллисекунд), максимальное количество арх. сигналов периодичностью 1 секунда | 1, 60000 | 0.4, 150000 |
Ссылки