Term | Description |
query | A self-contained processing unit. It partitions incoming events according to a key and then independently processes the events in each partition. Processing involves watching for an event pattern and then executing a block of procedural code when that pattern is found. |
input | An event type that a query operates on. An input definition specifies an event type plus details that indicate how to partition incoming events and what state, or event history, is to be held. |
key | A query key identifies one or more fields in the events being operated on. Each input definition must specify the same key. |
partition | A partition contains a set of events that all have the same key value. One or more windows contain the events added to each partition. |
window | For each input, a window contains the events that are current. The query operates on only current events. |
latest event | The latest event is the event that was most recently added to a partition. |
set of current events | The events that are in the window(s) of a partition. |
pattern | Specification of the event or sequence of events or aggregation that you are interested in. A pattern can include conditions and operators. |
match set | A match set is the set of events that matches the specified pattern. A match set always includes the latest event. |
parameterization | A query definition that specifies parameters is a parameterized query. An instance of a parameterized query is referred to as a parameterization. |
source timestamp | The time an event occurred at its source. This may be before it is processed if there is some delay or disruption in delivering the event from the source to the query runtime. This will be data in one or more fields of an input event. Queries can use the source timestamp if an action is provided to obtain the source timestamp in the correct form. See Using source timestamps of events. |
heartbeat event | An event that a query uses to determine when communication with a data source is working correctly, and it has not missed any events that are delayed. With heartbeat events, received input events can be processed as they are considered definitive. Without these, the query runtime needs to wait for the input's wait time specified in the query definition to ensure it avoids missing delayed events. |
definitive time | The point in time for which the query runtime has been told that it can assume it has received all the events it is going to receive. All events at or before this point in time are considered definitive and can be used to evaluate the query. This applies when using the source timestamp functionality. |