Oracle International Corporation

Unmesh Anil Deshmukh

Anand Madihalli Srinivasan

Vikram Shukla

Sandeep Bishnoi

Hoyong Park

Prabhu Thukkaram

Alexandre De Castro Alves

Jeffrey Toillion

Ashish Mahendru

Yogesh Bedekar

Shailendra Mishra

Prathab Kali

A method may include receiving a continuous query identified by an archived relation associated with an application. The method may also include generating a physical query plan. Additionally, the method may include constructing a structured query language (SQL) equivalent expression corresponding to an attribute utilized by the operator and/or constructing an output SQL expression for the identified operator based at least in part on the SQL equivalent expression. Additionally, the method may include constructing the archiver query for the identified operator based at least in part on the output SQL expression. Further, the method may include executing the archiver query to obtain a result set of data records related to the application and/or generating a snapshot output of one or more data values related to the application based at least in part on the result set of data records.

Generation of archiver queries for continuous queries over archived relations

A continuous query identified by an archived relation of an application may be received. A physical query plan may be generated for the continuous query and/or a child operator plan may be identified. A buffer operator may be inserted between the child operator and its parent operator and/or the event information from the child operator may be stored in the buffer operator. A query operator may be identified in the physical query plan. It may be determined that the query operator identified in the physical query plan is a same type as a second query operator in a second continuous query concurrently executing. Further, a combined query plan may be generated based at least in part on the query operator identified in the physical query plan being the same type as the second query operator in the second continuous query.

Operator sharing for continuous queries over archived relations

Systems and methods for query decomposition for scalability of continuous query processing are disclosed. In some examples, it is determined whether a query is fully stateful. If it is, the query may be divided into two functions, an aggregate function and a global function. The aggregate functions may be distributed across multiple distributed nodes and executed in parallel. The global function may then receive the results from the distributed nodes and join the results to achieve the fully stateful result.

Query decomposition for scalability of continuous query processing

An event processing system is disclosed that processes events of an event stream and performs the recovery of events during system failure. The recovery of events is performed by generating output sequence numbers for each deterministic output event generated by the event processing system. In an embodiment, the event processing system determines a current output sequence number of a most recently transmitted output event in a output stream of events, a last output sequence number of an output event corresponding to a most recently processed batch of input events and determines a set of one or more output events of the output stream to be transmitted based on the current sequence number and the last output sequence number. The event processing system then transmits the output events related to the application.

Event batching, output sequencing, and log based state storage in continuous query processing

Techniques for managing continuous queries that include subqueries are provided. In some examples, a continuous query that includes at least a subquery may be identified. Additionally, the subquery may be processed to obtain a first result or generate a logical subquery plan. Further, in some instances, the continuous query may then be processed based at least in part on the first result from the subquery or by merging a logical continuous query plan with the logical subquery plan. This may result in obtaining a second result via querying a data source with the continuous query that is based at least in part on the first result from the subquery and/or the merged plans.

Managing continuous queries in the presence of subqueries

Techniques for counting event changes with archived relations are provided. In some examples, a query that identifies at least a data object may be identified. Additionally, the query may be evaluated against historical data associated with the data object. Additionally, in some instances, a listening service may be registered with the data object. Further, the query may be evaluated based at least in part on the data object and the historical data.

Processing events for continuous queries on archived relations

An event processing system is disclosed that processes events of an event stream, performs the recovery of events during system failure and preserves the state of the system reliably and accurately while achieving desired system performance. In an embodiment, the event processing system processes a first batch of events of a continuous input stream of events using a continuous query and generates an output stream of events related to an application. The event processing system identifies one or more operators of the continuous query and determines that an operator is a journaled operator. The event processing system generates a journaled snapshot of a current state of the system based on execution of the journaled operator on at least the first batch of events and stores the journaled snapshot of the current state of the system.

Some event ordering requirements can be determined based on continuous event processing queries. Other event ordering requirements can be determined based on distribution flow types being used to distribute events from event streams to node executing the queries. Events from event streams can be ordered according to ordering semantics that are based on a combination of all of these event ordering requirements. Additionally, virtual computing nodes can be associated with constraints, and computing processors can be associated with capabilities. Virtual computing nodes for processing event streams can be assigned to execute on various computing processors based on both these constraints and capabilities. Additionally, for each of several events in an event stream, a ratio between a total latency and a communication latency can be for determined. Based on an average of these ratios, a quantity of reducing nodes that will be involved in a map-reduce operation can be selected.

Scaling event processing using distributed flows and map-reduce operations

Techniques for managing continuous queries with archived relations are provided. In some examples, a query that includes at least a data stream may be identified. Additionally, the query may be initialized with at least a portion of historical data. Further, in some instances, the query may be evaluated based at least in part on the data stream and the portion of the historical data.

Managing continuous queries with archived relations

Techniques for managing configurable data windows for streams and/or archived relations are provided. In some examples, a query that identifies at least a data stream or an archived relation may be identified. Additionally, a configurable window size may be identified. In some instances, the query may be initialized with at least a portion of the historical data based at least in part on the window size. Further, the query may be evaluated based at least in part on the data stream and the portion of the historical data.

Growing community of inventors

Nagpur, India

Unmesh Anil Deshmukh