Event Storages

Event Storages is a global server configuration property that describes logical partitions used for keeping different historical events.

The actual implementation of event storages depends on the server database type, but typically each event storage corresponds to a table in the database.

Iotellect Server creates, deletes and configures event storages automatically. Manual creation or modification of event storages is not required in most cases.

Parameters of an event storage:

Type

Indicates what type of database should be used to save instances of the event.

  • Default - use the event storage type defined in the global server configuration property Event Storage.

  • Relational Database - save event instances to the relational database defined in Relational Database global server configuration.

  • NoSQL - save event instances to the NoSQL database defined in the NoSQL Storage global server configuration.

  • Disabled - do not store instances of the event.

Table

Name of event storage. Normally matches the name of corresponding database entity.

Context

Context path whose events should be kept in the storage. If null (not set), the storage will be used for all contexts. Context masks are NOT supported here.

Event

Name of event whose instances should be kept in the storage.

Bindings

Persistence bindings that will be evaluated when an event is persisted. Each binding defines a dedicated key column that will store some event data, such as a field of the event's data table. Values of key fields may be used to load events from database using some custom search criteria.

Relational Database storage is the preferred storage type when persistence bindings are being used.

Persistence bindings can only be queried in NoSQL databases if the property Use Secondary Indices of the Storage-Specific Parameters property is enabled.

Example: A storage containing change events has a persistence binding that stores the name of changed variable in a separate key column. This allows the loading of only changes of a particular variable instead of loading all change events from a context.

Properties of a persistence binding:

Name

Name of a key field.

Type

Type of a key field.

Index

Name of a database index to be created for this key field. No index will be created in relational databases if this value is null.

In order to create an index in an NoSQL database, the property Use Secondary Indices of the Storage-Specific Parameters property must be enabled.

Expression

An expression that returns key field value. It is evaluated while event is being persisted.

Persistence Binding Expression Resolution Environment:

Default Context

Context of event.

Default Data Table

Data Table containing event-specific data.

Default Row

0

Environment Variables

Standard variables only.

Persist Context

Defines whether event context should be persisted in the storage.

Persist Name

Defines whether event name should be persisted in the storage.

Persist Expiration Time

Defines whether event expiration time should be persisted in the storage.

Persist Level

Defines whether event level should be persisted in the storage.

Persist Permissions

Defines whether event permissions should be persisted in the storage.

Persist Count

Defines whether event occurrence count should be persisted in the storage.

Persist Acknowledgments

Defines whether event acknowledgments should be persisted in the storage.

Persist Enrichments

Defines whether event enrichments should be persisted in the storage.

Persist Format

Defines whether event format should be persisted in the storage.

Persist Data

Defines whether event data should be persisted in the storage.

Storage-Specific Parameters

Dynamic property containing properties specific to the selected storage type. If Relational Database is selected, this property will be empty. In the case of NoSQL being selected as the storage type, it will contain a single boolean property, Use Secondary Indices, with the following effect:

  • When False, most persisted data is stored as a BLOB, potentially leading to slow queries. Persistent bindings data, defined in the bindings column cannot be queried.

  • When True, persisted data, including persistence bindings, are saved in separate columns, which are indexed independently.

When using secondary indices and persistent bindings, carefully consider the cardinality of the data being stored by the persistent binding. An index on a key column that contains high-cardinality data (many possible values, such as email addresses or user IDs) will have, on average, a higher overhead to query and maintain, and can degrade performance of the entire database cluster.

Was this page helpful?