DEBS08(3) - Continuous Queries
Posted by Paul Vincent
Next from the Distributed Event Based Systems conference: the CQL tutorial by Dieter Gawlick and Shailendra Mishra, covering Oracle’s version of a continuous query language [*1]. What was interesting was their defense of the claim that “your database server can do your CEP” [*2], supposedly reinforced by the observation that “you get all the (usual) DB management functions for free” [*3]. The traditional 3-tier, database-persistence-as-a-core-service, architectural design pattern is of course perfectly fine for, er, moderate-to-high latency projects with stovepipe services requiring minimal changes over their lifetime. Indeed, many current CEP applications augment, rather than replace, such existing architectures. But presumably you also have to consider run-time performance effects [*4] on your operational data store. Also some CQL examples display impressive contempt for the KISS principle - being of such complexity that they will undoubtedly frighten small children as well as experienced DBAs. Maybe Oracle will plan some nifty design tool for their CQL implementation, and if so, this would surely be a good topic for some future DEBS conference…
Of course, “real” ESP and CEP engines also support continuous queries - TIBCO BusinessEvents included; hence at least one answer to Hans Gilde’s recently asked question on why rule-based (monitoring) systems do not include some SQL-based Event Processing Language is: actually some already do).
Notes.
[1] Probably, at some point, EPTS will need to publish a comparison of all the different CQL implementations and their semantics. After that, we can discuss”standardization”… one gets the impression that Oracle would prefer to claim that their implementation *is* the de facto standard, but unlike their SQL implementation they likely don’t have anywhere near the installed base for CQL to justify such a claim.
[2] Note that a continuous query is not the same as CEP. A continuous query running against a high-latency database, for example, may just buy you a more efficient trigger representation.
[3] Presumably, not literally…
[4] I saw these cartoons in a blog recently and thought their similarity to CQL / database issues to good to pass up!
Complex Event Processing (CEP), Meetings and events, Queries | 03 July 2008 |
4 Comments
Other Links to this Post
-
Oracle minus Esper equals opportunity for TIBCO! « Hans Gilde’s weblog — July 3, 2008 @ 11:16
-
Complex Event Processing (CEP) Blog » DEBS08(6) - Model-Driven Eventing — July 7, 2008 @ 16:04
RSS feed for comments on this post. TrackBack URI
By Hans, July 3, 2008 @ 09:36
Hmm… well continuous queries are a start, but streaming SQL goes beyond the idea of the kind of continuous queries you’re talking about (when they call it a continuous query language, they don’t meant that it does a query for every incoming event).
So I still think that you guys could support a more broad range of requirements by including an actual streaming SQL language. Would this earn you enough additional revenue to be worth the investment? I have no idea.
By vincent, July 3, 2008 @ 23:28
“…a continuous query language, they don’t meant that it does a query for every incoming event…”. True, it means a query result is updated (potentially) for every incoming event.
BE’s QueryAgent provides “streaming SQL” operations, providing ESP capabilities to the BusinessEvents distributed CEP framework, augmenting the rule capabilities and state model capabilities. We should probably post some more on this later…
See also comments on Hans’ blog - http://hansgilde.wordpress.com/2008/07/03/oracle-minus-esper-equals-opportunity-for-tibco/#comment-228