Sounds fascinating!

Do you have any specifics you could share?

Best,

CAM

Some engines can do trivial selections at millions of events per second while others do only 6-7x less. Joins are even more extreme, with some configurations about 20x better than others. The type of window (sliding or jumping) also affects performance quite a lot but does not affect all engines in the same way. In some challenging pattern matching queries, throughput was only about hundreds of events per second or the system couldn’t handle them.

Memory consumption varies wildly (e.g., from 50 MB to 15 GB) for the same query running in different engines. CPU utilization also varies and some engines are more bursty than others affecting average and worst case response times.

Overall, no engine (we tested) was the best in all scenarios but some were clearly ahead in most cases.

Different competitors in a deal commonly see it differently. And some deals are evaluated fairly, some not so much.

As for STAC — I don’t know a lot about it. And I find the website pretty hard to learn anything from. Outfits that don’t put any management names on a site often are a little shaky,

In theory, however, STAC’s goals sound quite worthy.

CAM

IBM’s Blue Gene/TD Financial case sounded like VWAP and other pretty standard tickstream stuff.

In other words, how complex are the event (patterns) you are outputting?

Caveat emptor, as usual.

Cheers

That is very surprising. Aleri always touted themselves as the most performant of the CEP engines. They widely proclaim that they were the only CEP vendor to submit themselves to Stac Research for benchmarking, and they have publicly challenged all comers.

I would be interested in the use case where Aleri was thrown out. I would have expected them to be thrown out because of usability issues, not because of performance.

My point on event programming, in the other post, were about PROGRAMMING. And even there I was just passing through vendor claims.

Seriously, I’m a huge believer in the theory that the best programming paradigm is usually the one that gives the best modularity. Two complications in that are:

1) It has to be best both for the “core” of the task and for the “other stuff” — UI, integration, etc.

2) This is a Goldilocks kind of test. Too much modularity can be almost as bad as too little. (Classic examples — debugging programs that rely too much on stored procedures, or almost anything to do w/ rules engines.)

Eric Brewer and folks here at Berkeley wrestled with the practical ramifications of this over many years, in part due to Eric’s experience building the Inktomi search engine. Papers worth reading on that front include Matt Welsh’s work on SEDA (”threads can’t scale, events win”), and Rob von Behren’s work on Capriccio (”threads win, events are a bad idea”).

For a long discussion of how the relational database vendors do it (answer: they do it every which way!) see our survey on database system architecture.