define table <table-id> (<attribute-name> <type> {, <attribute-name> <type>}*)
{ from ('parameterName'='value')+ }?
Event tables allow users you to store, retrieve and and process events in a database table-like structure. These are designed for use cases usecases where events need to be extracted from the stream and accumulated over a long period for real-time (or later non real-time) batch processing, such as performing comparisons with the incoming event stream or feeding them it to BAM.
Unlike in windows which are predefined tables, event tables can have more sophisticated storage and retrieval criteria and a . A single event table can be used in multiple SiddhiQL expressions. Depending Depending on the requirements, an event table can be defined either in-memory or in a relational database. CEP CEP supports event tables for widely used databases such as MySQL.
...
In-memory database event tables
These are created in memory which will be fast and therefore, are faster and easier to define. Following example shows a definition for of an in-memory event table.
define table cseEventTable (symbol string, price int, volume float);
Relational
...
database event tables
Two types of relational databases are currently supported by Siddhi .as follows:
MySQL
H2
The following example shows defining how to define a table with table id 'cseEventTable
' which actually . It stores events in a relational database named 'cepdb' inside a table named 'cepEventTable
'.
define table cseEventTable (symbol string, price int, volume float) from ('datasource.name'='cepDataSource', 'database.name'='cepdb', 'table.name'='cepEventTable')
CEP supports caching for relational database tables with a few different algorithms. To change the algorithm, the users can you use the optional 'caching.algorithm
' parameter when defining the table as follows:
define table cseEventTable (symbol string, price int, volume float) from ('datasource.name'='cepDataSource', 'database.name '='cepdb', 'table.name'='cepEventTable', 'caching.algorithm'='LRU')
...
Info | ||
---|---|---|
| ||
Currently At the moment, there are three cache management algorithms supported by CEP . Those areas follows:
Note that specifying an algorithm is optional and when the user doesn't specify an algorithm, caching gets disabled. |
Optionally,
...
In addition, it is also possible to you can define a cache size using cache.size
parameter when defining the table as follows:
define table cseEventTable (symbol string, price int, volume float) from ('datasource.name'='cepDataSource', 'table.name'='cepEventTable', 'caching.algorithm'='LRU', 'cache.size'='10000')
In addition, you can also define a relational database event table with a user-provided SQL query as follows. This can be is used when the created table needs to be customized, such as having a primary key etc.
define table cseEventTable (symbol string, price int, volume float) from ('datasource.name'='cepDataSource', 'database.name'='cepdb', 'table.name'='cepEventTable' , 'create.query'='CREATE TABLE cepEventTable (symbol VARCHAR(40), price DECIMAL, volume BIGINT )')
Info | ||
---|---|---|
| ||
The ' |
Info | ||
---|---|---|
| ||
Note that from CEP 3.1.0 onwards, the parameter |
Info | ||
---|---|---|
| ||
The table id can be different from the table name, and Siddhi will always refer to the table id defined here. However, the table id cannot be same as an already existing stream id, since syntactically both are considered in the same manner in the query language. |