Another SQL Based Vendor
There seems to be faith in the SQL based approach to stream processing. Here’s another vendor with a variation on the same concept: SQL stream. I wish them the best of luck!
Now we have a number of SQL based approaches. Quickly, can you tell the difference between Coral8, StreamBase, Aleri, Esper and Oracle’s tools (whatever brand name they have currently)? It seems that the language concept is more or less the same. I know, the vendors are unlikely to agree, citing features which are unique to them. That is certainly true for a specific problem for which one of these tools might be preferable over another.
But still, for the prospective customer, the difference is not in the languages as such. But in everything that surrounds them. The execution engines, tools, user interfaces, fancy dashboards. Not to forget soft factors as quality of support and perceived company stability.
It’s interesting to see that so many vendors go for the SQL based approach as there are many voices in the community that really don’t think SQL is a good idea for event processing. Some bloggers are a bit subtle about their opinions (company politics perhaps?) but others more independent are rather clear where they stand. For example, David Luckham, the father of the whole complex event processing field, writes in:
The features for defining event patterns have improved, although I do wish some of them would shovel SQL below decks and provide higher level event pattern definition languages!
I both agree and disagree.
First, the SQL based tools today are really good at what they are used for. And that is NOT event processing. It is marketed as such, but it’s actually DATA STREAM processing. Which is sounds similar, but is not event processing. For stream processing purposes, SQL rocks! For event processing, it can be make to do the job. But not in a natural way.
Personally I think that you need a better way to do EVENT processing than SQL. Using a query/poll based (SQL) concept and tweaking that into submission to handle event processing might not be the best option for processing in a event driven world.
I’ll repeat: Data stream processing is NOT event stream processing!
But as always, the users are always right. If they prefer SQL. Then SQL it is. We’ll see when the market is mature enough to start doing real event processing instead of todays stream processing.
The weird thing is that in the early days, say 2004 or so, many of the vendors actually marketed their tools as data stream processing tools. Then somehow marketing took over and decided that they should market the same tools as event processing tools instead. So in many eyes they now have a lousy event processing tool instead of an incredible data stream processing tool. The products are more or less the same though. Only marketing changed as I can see it. Confusing.
Anyway, that’s in theory. Maybe the users really don’t care is the vendors call it CEP, the CEP label seems to be stuck to so many things so it starts to mean "any kind of data processing which is not like traditional database processing"
Marco,
I’d like to dispute your characterization of Aleri’s CEP platform as “an SQL-based approach”. And I’d like to agree with you that SQL is not a good fit for certain types of event processing/analysis. Aleri’s primary “EPL” is an XML-based language for defining the dataflow and applying standard operators. We then have a scripting language that we call SPLASH that is used to define custom operators and do pattern matching on events. Pattern matching, in particular, can be difficult to do in SQL – which is why we don’t try. For certain types of data operations, an SQL-style operation, like a filter, join, or aggregation (group by) is very well suited. For others, you need the type of imperative control that a scripting language like SPLASH gives you.
Jeff
P.S. Let’s move beyond the debate over what is CEP and what isn’t – it’s getting old and I don’t see it accomplishing anything. Rather than debating labels, lets talk about functionality and how to different architectures take different approaches to solving problems when it comes to analyzing data streams and event data.
Jeff
Well, I agree. It’s a bit unfair to toss in Aleri in the same camp as the others. But on the other hand, StreamBase has two ways of doing things too, the GUI and SQL.
So maybe its more correct to say that it’s the SQL aspect of these systems I had in mind. But they can be used in other ways too. Of which I think SPLASH is actually the most interesting one….
You define CEP so that only your product does it. They define CEP so that their products are do it better. A certain consultant, who shall remain nameless, defines it so that he is the only one on earth qualified to talk about it. Sorry to say, sir, but all of you are using CEP for marketing.
Well… I agree…
It’s pointless to argue what CEP is and what it is not. These TLAs have their own life independently what their meaning was from the begining. And as Jeff said, there’s more interesting things to talk about. I hereby declare the “That’s not CEP” issue dead. Everyone can do CEP in their own ways and CEP will mean different things to different people in a couple of years anyway.
What is interesting tough is that CEP can be done with many different approaches…
Hans, you have a point there. Let’s focus on telling what we have and how it fits into the big picture. All vendors are solving problems in more or less the same area with different approaches which all have their strengths and weaknesses.
That would be more interesting to sort out. I’ll start this by trying to position ruleCore in the world of CEP in my nest post. We are good at some stuff and bad at some other stuff, so are the others. I think the users really don’t care if a solution is “pure CEP” or not. If it solves their problems, users tend to be happy…
@Hans
I beg to differ with your assertion that I “define CEP so that only [my] product does it”. Au contraire. I take a very wide view of CEP and believe that most, if not all, products that claim to do CEP in fact do – in some form or another. Sort of the opposite view of those that seem intent on defining it very narrowly. Do we try to leverage the interest in CEP for marketing purposes? You bet. Unabashedly.
I think all vendors which are developing software that are doing some kind of real-time processing of data/events are using the “CEP brand” for marketing. It really does not matter from a marketing point of view if a product is “pure CEP” or “real CEP”. It the customers understand what is special about the products by sticking the CEP label to it, then it will be done.
The term CEP seems to be used to call everything that does some kind of instant processing of pieces of data. These TLAs seems to have their life of their own. If everyone talks about CEP and uses it to describe different kind of software, then it’s just best to go with the flow and redefine CEP to mean a broader category of software.
It is not long before ESB and message oriented middleware have the CEP sticker attached to them. “Now with CEP” will be seen on lots of stuff soon.
My guess is that CEP will gradually start to mean a very wide range of real-time processing software.
(The real-time people just hate when I use the term real-time in that way, what I just described is not real-time!
)
Hi Marco. I totally agree. The term CEP is being used as a roof for all sorts of event processing products; making discussions on labels as a big issue is a waste of time, marketing labels are not important, substance is much more important.
cheers,
Opher