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

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

Различные форматы NoSQL используют разную терминологию для описания групп отдельных записей. Например, в базах данных ключевых значений пары ключ-значение объединяются в пространства имен или ведра. Аналогичная структура в Cassandra ("тип широкой колоночной базы данных") - это пространство ключей, а в базах данных документов используется термин "коллекция". Термин "коллекция" в следующей статье относится к этому типу структуры более высокого уровня, но в конечном итоге зависит от типа используемой базы данных. Аналогично, в разных базах данных используется разная терминология для обозначения списка пар ключ-значение, которые существуют в записи. В следующей статье термин "поля" используется для обозначения списка пар ключ-значение, которые встречаются в каждой записи "коллекции".

Основные коллекции, которые существуют в каждой установке, следующие:

Коллекция	Описание
context_directory	Содержит идентификаторы (УУИД) контекстов, которые используются для преобразования и извлечения данных из других коллекций. Поля: key - полный путь контекста column1 - идентификатор (УУИД) контекста, генерируется автоматически value - время создания в миллисекундах, закодированное в типе данных BLOB
ag_properties	Содержит значения всех постоянных переменных контекста сервера. AggreGate Server создает и удаляет относительно небольшое количество записей в этой коллекции при создании и уничтожении системных объектов. Кэширование памяти на стороне сервера также уменьшает количество запросов к этой коллекции. Однако записи в коллекции ag_properties часто обновляются, поскольку значения свойств постоянных ресурсов изменяются, и сервер сохраняет измененные значения в базе данных. Поля: key - идентификатор (УУИД) контекста, значение чьих переменных хранится в записи property - имя переменной value - таблица данных, представляющая значение переменной, закодированной как string, с использованием невидимых разделителей
		Например, устройства, использующие постоянную переменную кэш, вызывают большое количество обновлений в таблице 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.

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

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

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