Схема и взаимодействие базы данных nosql

Схема базы данных AggreGate Server  полностью динамическая, сервер создает и удаляет новые таблицы по ходу работы, чтобы отражать создание, удаление и перенастройку ресурсов системы.

Однако, несколько базовых таблиц присутствуют в любой инсталляции:

Таблица

Описание

context_directory

Содержит идентификаторы (УУИД) контекстов, которые используются для преобразования и извлечения данных из других таблиц.

Поля:

  • key - полный путь контекста
  • column1 - идентификатор (УУИД) контекста, генерируется автоматически
  • value - время создания в миллисекундах, закодированное в типе данных BLOB

ag_properties

Содержит значения всех постоянных переменных контекста сервера. AggreGate Server генерирует относительно небольшое количество запросов типа ДОБАВИТЬ и УДАЛИТЬ к этой таблице, когда создаются или удаляются объекты системы. Количество запросов ВЫБРАТЬ также относительно невелико из-за кэширования в памяти сервера. Однако, таблица ag_properties получает огромное количество запросов ОБНОВИТЬ, так как значения свойств постоянных ресурсов меняются, а сервер сохраняет значения изменений в базе данных.

Например, устройства, использующие постоянную переменную кэш, вызывают большое количество обновлений в таблице ag_properties во время синхронизации.

Поля:

ag_events

Содержит все cобытия контекста за исключением тех, которые хранятся в других (пользовательских) таблицах. Подробнее об этом см. в разделе Хранение событий контекста ниже.

Поля:

  • key - Имеет формат идентификатор (УУИД):имя, где первая часть - это идентификатор контекста, в котором возникло событие, а вторая - имя события (т.е. тип события)
  • column1 - УУИД с привязкой ко времени, содержит закодированную временную метку, когда произошло событие, и идентификатор события
  • value - закодированная информация о событии, которая содержит:
  • expirationtime - временная метка в будущем, соответствующая планируемому окончанию события
  • level - уровень события
  • permissions - настроенные права доступа, необходимые для доступа к экземпляру события, либо null, если должны использоваться права доступа, указанные в определении события
  • count - количество дубликатов зарегистрированных событий
  • ack - закодированный список подтверждений события
  • enrichments - закодированный список обогащений события
  • format - событие в закодированном формате, либо null, если должен использоваться формат, указанный в определении события
  • data - таблица данных, в которой представлены данные события, закодированные в Byte array

ag_data

Содержит блоки бинарных данных, встроенные в значения переменных контекста. Эти блоки извлекаются в данную отдельную таблицу, когда значение переменной записывается в таблицу ag_properties. Однако, бинарные блоки не загружаются сразу при загрузке значения переменной из ag_properties. Блоки загружаются только по необходимости, т.е.  через конкретные запросы от модулей  AggreGate Server, клиентов или внешних приложений.

Поля:

  • key - идентификатор (УУИД) контекста, чьи данные хранятся в строке таблицы
  • value - бинарные данные

Хранение событий контекста

Большая инсталляция AggreGate может хранить миллиарды постоянных событий контекста в базе данных. Эти события динамически распределяются между разными таблицами, чтобы повысить производительность сохранения и извлечения.

Формат всех таблиц событий соответствует формату таблицы ag_events, описанному выше.

Доступ к таблицам событий обычно включает множество операций ДОБАВИТЬ. Новая запись добавляется каждый раз при регистрации постоянного события сервера. Команды УДАЛИТЬ применяются к таблице событий в двух случаях:

  • Если ресурс системы со всеми соответствующими событиями удален
  • Если просроченные события удалены в рамках периодической задачи планировщика

Количество запросов ВЫБРАТЬ, обращенных к таблице событий, относительно мало. События загружаются в следующих случаях:

  • Если открыт Журнал событий, что вызвало активацию фильтра событий
  • Если события загружены напрямую при помощи функции get() контекста События
  • Если история переменной напрямую загружена через функцию variableHistory() контекста Утилиты
  • Во время начальной визуализации графика виджета, настроенного так, чтобы включать исторические события или значения переменных
  • В некоторых других подобных случаях

Несмотря на то, что события загружаются нечасто, количество событий, загружаемых одним запросом, не ограничено платформой, т.к.  для некоторых инсталляций необходимо загружать миллионы событий за раз. Системные архитекторы, разрабатывающие решения на базе AggreGate, должны помнить об этом и продумать максимальное количество загружаемых событий при создании конвейера обработки данных на стороне сервера, а также инструментальных панелей визуализации.

Попытка загрузить слишком много событий сразу приведет к переполнению памяти AggreGate Server, что проявится в резком снижении производительности из-за чистки памяти виртуальной машины Java. Это может вызвать полное зависание сервера или ошибки внутренней памяти.

Список таблиц событий, приведенный в документации, не является исчерпывающим. Разные модули и плагины AggreGate Server могут запросить создание других особых таблиц событий, не упомянутых здесь.

Все события, для которых нет явных настроек использовать пользовательскую таблицу, записываются в таблицу ag_events. Ниже представлен список таблиц БД, которые обычно создаются для хранения событий разного типа.

Структура таблиц такая же, как у таблицы ag_events.

Таблица

Описание

ag_info

Содержит события Информация.

ag_alert

Содержит события Тревоги.

ag_xxx_change

Содержит все события Изменение, показывая изменения переменных в одном контексте устройства (соответствует устройству xxx). Обратите внимание, что имя таблицы может быть сокращено из-за ограничения длины имени таблицы БД на самом сервере.

Прямой доступ к базе данных  %ls%

Прямой доступ сторонних приложений к базе данных AggreGate Server крайне нежелателен. AggreGate  - мощная платформа, предлагающая полноценный комплект разработчика и различные виды API для локального и удаленного доступа ко всем элементам данных, содержащимся в БД сервера. Более того, доступ через API всегда будет наследовать надлежащие блокировки, проверку прав доступа и оптимизацию производительности.

Прямое изменение данных в БД AggreGate Server в большинстве случаев приведет к некорректному поведению системы. Однако, в редких случаях допускается использование операций прямого чтения (ВЫБРАТЬ).

Пожалуйста, обратитесь в Tibbo, чтобы узнать, как избежать прямого доступа к БД.