Table

In Cortex, Table Nodes are designed to create, read, or update in-memory tables. Table Nodes have also the capability to connect to tables that reside in external databases to create, read, update, or delete external tables.

• Table Nodes are defined by a detailed schema including attributes with specific types and names. This ensures consistency across all events within a table. (cf. Step 1 - General)

• They also support primary keys for data uniqueness and indexes for enhanced searchability, facilitating efficient data manipulation and retrieval operations. (cf. Step 2 - Primary Keys and Indices)

• Besides in-memory storage, tables can be synchronized with external databases using the Store Element, allowing for broader data management strategies. (cf. Step 3 - Store Type )

• Also, when external databases are used for external tables, the resultant I/O latencies can be reduced by enabling Cache for each Table Node. (cf. Step 5 - Cache)

This comprehensive approach to event storage significantly aids in organizing and accessing event data effectively.

Step 1 - General

Name and Description

When configuring a Table Node in Cortex, Step 1 involves several key actions.

• Assign a unique name to the Node, distinct from other Nodes in your Application.

• Optionally, add a Description for detail and clarity.

• The Node Name and Description will help distinguish it in the Canvas via Node Preview.

Enable Vault

You can also integrate Application-level Vaults into your Table Node configuration.

• Activate the toggle to use Application-level Vaults.

• Choose from existing Vaults and enter the corresponding Personal Encryption Key for access.

New Attributes

Defining new Attributes for the Node is a crucial part of Step 2. Here, you must not only name these Attributes but also select their respective Attribute Types.

• Specify New Attributes for the Node and select their Attribute Types.

• This setup is crucial for Cortex to work and you cannot complete node setup unless you have defined at least one New Attribute and defined its Attribute Type.

Step 2 - Primary Keys and Indices

Primary Keys

In Table Node, Primary Keys play a crucial role in managing table data. Even though they are optional, Primary Keys are instrumental in avoiding data duplication. For any table, Primary Keys ensure that no two events in a table have the same values for the same set of Primary Key Attributes.

Primary Keys make sure every Primary Key Attribute value is unique in the table.

• Primary Keys are optional but recommended as they index the table, enabling faster event access.

• They ensure no two events have identical values in the Key Attributes, preventing data duplication.

• When multiple attributes defines a Primary Key, the event's uniqueness is based on their composite value.

If events with identical Primary Key are inserted into the table; the newer event replaces the existing one in the table.

Indexes

Indexes in Cortex enhance the speed of searching and modifying events in tables.

Indexes differ from Primary Keys as Indexes allow duplicate values in the indexed attributes.

• Indexes are optional but recommended as they enhance search and modification speed in tables.

Step 3 - Store Type

You can choose to perform manipulations on tables that are in a Table Node using external stores. This way, you can create, update, read, and delete tables in your Application flow.

Store Element in Cortex are interfaces for external data stores like RDBMS, MongoDB, Redis, and Elasticsearch using Table Node tables as a proxy.

For further information you can refer to #stores.

Enable Store

You can Enable Store and then choose from Store Types. In Step 4, you can configure the chosen Store Type with your requirements.

Step 4 - Store Parameters

RDBMS

You can manipulate tables that are kept in and RDBMS that reside out of Cortex.

For further information and configuration instructions refer to RDBMS.

MongoDB

You can manipulate tables that are kept in a MongoDB that reside out of Cortex.

For further information and configuration instructions refer to MongoDB.

Redis

You can manipulate tables that are kept in a Redis DB that reside out of Cortex.

For further information and configuration instructions refer to Redis.

Elasticsearch

You can manipulate tables that are kept in an Elasticsearch DB that reside out of Cortex.

For further information and configuration instructions refer to Elasticsearch.

Step 5 - Cache

Using external Stores to manipulate tables in the Table Node may lead to significant I/O latency. As Applications' performance are directly related to latency, you should be aware of the performance-wise advantages and disadvantages enabling Stores.

For highly latency-critical Applications, we do not recommended to enable Stores.

Enable Cache

Working with external data Stores in Cortex can result in higher I/O latency compared to in-memory tables.

• To address performance decrease, defining a Cache can be effective.

• By caching recently accessed data in-memory, retrieval times are significantly improved, leading to faster and more efficient data access.

• This approach helps mitigate the latency challenges associated with external data store interactions.

For further information and configuration instructions refer to Cache.

Step 6 - Preview

In Preview Step, you're provided with a concise summary of all the changes you've made to the Table Node. This step is pivotal for reviewing and ensuring that your configurations are as intended before completing node setup.

• Viewing Configurations: Preview Step presents a consolidated view of your node setup.

• Saving and Exiting: Use the Complete button to save your changes and exit the node and return back to Canvas.

• Revisions: Use the Back button to return to any Step of modify node setup.

The Preview Step offers a user-friendly summary to manage and finalize node settings in Cortex.