Хранилища событий

Тип

Указывает, какой тип базы данных должен использоваться для сохранения экземпляров события.

• По умолчанию - использовать тип хранилища событий, определенный в свойстве Хранилище событий глобальной конфигурации сервера.

• Реляционная база данных - сохранение экземпляров событий в реляционной базе данных, определенной в глобальной конфигурации сервера Реляционная база данных.

• NoSQL хранилище - сохранять экземпляры событий в базе данных, определенной в глобальной конфигурации сервера NoSQL хранилище.

• Отключено - не сохранять экземпляры события.

Таблица

Имя хранилища событий. Обычно соотносится с именем подходящих данных БД.

Контекст

Путь контекста, события которого должны быть в хранилище. Если контекст не задан (null), данное хранилище будет использоваться для всех контекстов. Контекстные маски здесь НЕ поддерживаются.

Событие

Имя события экземпляров, которые должны быть в хранилище.

Привязки

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

Реляционная база данных является предпочтительным типом хранилища при использовании постоянных привязок.

Постоянные привязки можно запрашивать в базах данных NoSQL, только если включено свойство Использовать вторичные индексы свойства Параметры, специфичные для хранилища.

Пример: Хранилище, которое содержит события изменения, имеет постоянную привязку, которая хранит имя измененной переменной в отдельной ключевой колонке. Это позволяет загрузить изменения только выборочной переменной, вместо загрузки всех событий изменения в контексте.

Свойства постоянной привязки:

Тип

Тип ключевого поля.

Индекс

Имя индекса БД, который будет создан для этого ключевого поля. Индекс не будет создан в реляционных базах данных, если это значение равно null.

Чтобы создать индекс в базе данных NoSQL, необходимо включить свойство Использовать вторичные индексы свойства Параметры, специфичные для хранилища.

Выражение

Выражение, которое возвращает значение ключевого поля. Вычисляется в момент сохранения события.

Контекст по умолчанию

Контекст события.

Таблица данных по умолчанию

Таблица данных, которая содержит данные состояния.

Ряд по умолчанию

0

Переменные среды

Только стандартные переменные.

Сохранить контекст

Определяет, должен ли контекст события быть в хранилище.

Сохранить имя

Определяет, должно ли имя события быть в хранилище.

Сохранить время удаления

Определяет, должно ли время хранения события быть в хранилище.

Сохранить уровень

Определяет, должен ли уровень события быть в хранилище.

Сохранить права доступа

Определяет, должны ли права доступа к событию быть в хранилище.

Сохранить количество

Определяет, должно ли количество ограничителей события быть в хранилище.

Сохранить подтверждение

Определяет, должно ли подтверждение события быть в хранилище.

Сохранить обогащения

Определяет, должны ли дополнения события быть в хранилище.

Сохранить формат

Определяет, должен ли формат события быть в хранилище.

Сохранить данные

Определяет, должны ли данные события быть в хранилище.

Параметры, специфичные для хранилища

Динамическое свойство, содержащее свойства, специфичные для выбранного типа хранилища. Если выбрана реляционная база данных, это свойство будет пустым. В случае выбора NoSQL в качестве типа хранилища оно будет содержать одно логическое свойство Использовать вторичные индексы со следующим эффектом:

• Если False, большинство сохраняемых данных хранится как BLOB, что потенциально приводит к медленным запросам. Данные сохраняемых привязок, определенные в столбце привязки, не могут быть запрошены.

• Если True, сохраняемые данные, включая постоянные привязки, сохраняются в отдельных столбцах, которые индексируются независимо.

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