актуальная тутМодуль подсистемы "Архивы" <DBArch>
| Модуль: | DBArch |
| Имя: | Архиватор на БД |
| Тип: | Архив |
| Источник: | arh_DBArch.so |
| Версия: | 2.4 |
| Автор: | Роман Савоченко |
| Описание: | Модуль архиватора. Предоставляет функции архивирования сообщений и значений на БД. |
| Лицензия: | 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. Данным модулем эта особенность также теперь используется позволяя данные получать часто быстрее чем они потом обрабатываются, хотя и уступая архивации на файловую систему.
- Запись в БД отдельной колонки также значительно быстрее, чем отдельная запись. Данным модулем эта особенность используется в части архивации значений и в режиме группировки, т.е. значения отдельных сигналов пишутся в одну таблицу как отдельная колонка.
Результаты измерений производительности архивации сведены в таблице ниже:
| Test / Environment and DB | Intel Core3 1.3GHz, Local PostgreSQL 9.3, SSD | AMD A8 3.5GHz, Local PostgreSQL 9.3, HDD |
| Values archiving, 60 records, 1 signal (seconds) | 53...63 | 13...14 |
| Values archiving, 60 records, 10 signal (seconds) | 65...67 | 16...19 |
| Values archiving, 60 records, 100 signal (seconds) | 154...163 | 52...60 |
| Result: average time of writing 60 values of signal (millisecond), maximum number of the archiving signals in periodicity 1 second | 1, 60000 | 0.4, 150000 |