Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: Described is a query optimizer comprising a query tuner that performs actual execution of query fragments to obtain actual results during compilation time, and uses those actual results to select a query plan. The actual results may be combined with estimates for fragments that were not executed. The tree may be traversed in a top-down traversal, processing every node. Alternatively, the tree may be traversed in a bottom-up traversal, re-deriving data for higher nodes as each lower level is completed. A limit, such as a time limit or level limit, may be used to control how much time is taken to determine the execution plan.

Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: The disclosed architecture utilizes realtime continuous event processing (CEP) to address the use of a general input interface framework to import a dynamic set of event types (e.g., assets), and a declarative, expressive query model to implement monitoring and management tasks on an asset level. In one implementation, a realtime event processing system is provided, comprising a synchronization component configured to synchronize realtime event data and static event data of assets, and a realtime merge component configured to merge the synchronized realtime event data and static event data into a realtime event stream using one or more operators. The merged synchronized realtime event data and static event data is queriable as a single event type using a query to return related asset items.

Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: Methods, systems, and computer-readable media are disclosed for time-based event processing using punctuation events. A particular method includes receiving a first event object comprising a first validity start time and a first validity end time, where the first validity end time is initially undefined. A punctuation object is received after the first event object. The punctuation event object has a punctuation timestamp indicating a time subsequent to the first validity start time. The punctuation event object indicates that event objects to be received at the computer system after the punctuation event object have validity start times later than the time indicated by the punctuation timestamp. The method includes setting the first validity end time to a value later than or equal to the time indicated by the punctuation timestamp.

Abstract: The disclosed architecture leverages realtime continuous event processing (CEP) to address using a general input interface framework to import a dynamic set of event types (e.g., assets), and using a declarative, expressive query model to implement monitoring and management tasks on an asset level. This is in contrast to looking separately at single values from static databases and/or realtime streams as is common conventionally. The architecture uses the CEP data model to model assets as realtime event types. Thus, queries can be formulated per asset and not just per single stream. The architecture uses the query capabilities of CEP to formulate asset management and monitoring tasks as standing, declarative queries, and uses the input interface of a CEP platform to correlate data from different data sources with different dynamic properties.

Abstract: Methods, systems, and computer-readable media are disclosed for time-based event processing using punctuation events. A particular method includes receiving a first event object comprising a first validity start time and a first validity end time, where the first validity end time is initially undefined. A punctuation object is received after the first event object. The punctuation event object has a punctuation timestamp indicating a time subsequent to the first validity start time. The punctuation event object indicates that event objects to be received at the computer system after the punctuation event object have validity start times later than the time indicated by the punctuation timestamp. The method includes setting the first validity end time to a value later than or equal to the time indicated by the punctuation timestamp.

Abstract: Described is a query optimizer comprising a query tuner that performs actual execution of query fragments to obtain actual results during compilation time, and uses those actual results to select a query plan. The actual results may be combined with estimates for fragments that were not executed. The tree may be traversed in a top-down traversal, processing every node. Alternatively, the tree may be traversed in a bottom-up traversal, re-deriving data for higher nodes as each lower level is completed. A limit, such as a time limit or level limit, may be used to control how much time is taken to determine the execution plan.

Abstract: A method and system for transforming a query tree that includes more than one aggregator. The method includes identifying a first aggregator in the query tree, identifying a second aggregator that is located below the first aggregator in the query tree, and merging the second aggregator with the first aggregator to form a merged aggregator.