Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

define table <table-id> (<attribute-name> <type> {, <attribute-name> <type>}*)
from ('parameterName'='value')+ }?  

Event tables allow users to store, retrieve and  process events in a database table-like structure. These are designed for use cases where events need to be extracted from the stream and accumulated over a long period for real-time or later batch processing, such as performing comparisons with the incoming event stream or feeding them to BAM. 

Unlike in windows which are predefined, event tables can have more sophisticated storage and retrieval criteria and a single event table can be used in multiple SiddhiQL expressions.   Depending on the requirements, an event table can be defined either in-memory or in a relational database.  CEP supports event tables for widely used databases such as MySQL.

...

Info
titleNote

Currently there are three cache management algorithms supported by CEP. Those are:

  1. Basic size-based algorithm: events are cached on a FIFO manner. The oldest event will be dropped when the cache is full.
  2. LRU (Least Recently Used): least recently used event will be dropped when the cache is full.
  3. LFU (Least Frequently Used): least frequently used event will be dropped when the cache is full.

Note that specifying an algorithm is optional and when the user doesn't specify an algorithm, the basic algorithm will be used by default.

 

Optionally you can define a cache size when defining the table as follows using 'cache.size' parameter:

define table cseEventTable (symbol string, price int, volume float) from ('datasource.name'='cepDataSource', 'database.name'='cepdb', 'table.name'='cepEventTable', 'caching.algorithm'='LRU', 'cache.size'='10000')

In addition, it is also possible to define a relational database event table with a user-provided SQL query as follows. This can be used when the created table needs to be customized, such as having a primary key etc.

...