So, as I mentioned in a news item, Microsoft has announced plans for a "R2" release of SQL Server 2008 sometime in the first half of next year (CTP to be availabe in the second half of this year). As part of that announcement, they announced a low level event processing engine they are currently calling the Complex Event Processor - or CEP. I wanted to take a quick (very quick for now) look at this new service.
The CEP is, as implemented today (and I see no reason this would change), a separate service much as Reporting Services and Analysis Services are. What's different with the CEP is that you attached a streamed data feed (via an adaptor I'll discuss shortly) to the CEP, and bind LINQ based queries to that stream. The CEP then emits streams that are the product of event analysis. Before we get into how it works, let's start with what kind of situation this might be used for, so you have a bit of context as to where this fits in.In this age of event driven architectures, you might think of this as simply being a trigger based model reacting to certain conditions in the database. The goal, however, is much more intense than anything as mundane as a trigger is going to handle. Instead, the SQL Server team is looking to address a highly reactive (as in so senstive that it seems proactive) model to fire events within perhaps tens of milliseconds after an event is noticed. To do this, they watch a stream of data passing through rather than wait until the storage of that data has been sorted out. Examples of where such high needs exist might be something like:
- Alerts or power changes on power management systems: Noticing a spike in power demands and firing events that increase power generation
- Triggering program trading when a series of sales or buys are detecting in a trading stream
- Noticing that readings from a pump flow meter have fallen below an acceptable level (you might want to react fast if that's a sewer pump!)
These are, of course, just quick a dirty examples.
On to the architecture a bit.....
OK, so what's been shown is pretty minimal at this point, and, since I'm writing this from TechEd, I don't have the tools to put up fancy graphics, but it works pretty much like this:
- An adaptor (written any any .NET language, such as C#, VB.NET, or F#, and using a related SDK) is registered with the CEP service. This adaptor applies necessary filter definitions and connectivity to the CEP engine.
- The CEP engine uses the adaptor(s) to analyze the stream and apply filters. These filters look for conditions to be met to fire events, and can be based on an instance or on an aggregation (say, a sum or average) of stream data over a sliding or "hopping" window of time.
- The CEP emits a stream of results using an adaptor (again written in a .NET language using a special SDK).
I suspect I'll write more on this one more toward the end of the year when the CTP is out and I have some time to slog through some examples with my own hands. In the mean time, it's something to be aware of on the development horizon when thinking about future needs and possible architectures.
| < Prev | Next > |
|---|
