Showing posts with label relational model. Show all posts
Showing posts with label relational model. Show all posts

Monday, July 23, 2012

DEBS 2012 - on Dave Maier's keynote, frames, and fragmantation



I have arrived home 49 hours later than planned,  in Sunday early morning instead of Friday early morning, due to a malfunction of the aircraft which required to replace a part, and a combination of the fact the the airline ELAL, does not fly in Saturday, thus, although the aircraft has been fixed in Friday, it was too late to take-off,  and the German liking to paperwork and red tape, which inflicted a long process of releasing this part from the German custom on Friday, and also delayed the takeoff on Saturday night -- since half of the passengers dropped out and found alternative ways to fly,  the aircraft was half empty, and the crew let people occupy the business class,  however, it turns out that the German authorities inspected the aircraft and found out that the number of people in the business class does not match the flight authorization request and wanted that the paperwork will be done again,  so after some minutes of trying to convince them. the crew asked all passengers moved to the business class to return to their seats until after the takeoff.  We in Israel has the completely opposite mentality, we are good in improvising, and find that doing things by the book is boring.  I must also say that ELAL treated us much better than a similar case I had in Delta Airlines,  which caused me not to fly Delta. 

Anyway -- back to DEBS 2012.  The organizers quickly assembled all presentations, and they can be found on the conference's website.   There are also pictures from the conference posted on Facebook, you can read through the presentations and find anything you are interested at.

I'll concentrate in the keynote of the third day - Dave Maier.  Dave is a senior figure in the database community, and got involved in recent years also in data streams research, he is also involved in related work with Microsoft.    

Dave gave an interesting talk whose title was:  "capturing episodes - may the frame be with you".  The rationale is that the notion of window in stream processing is too limited and the event stream is partitioned according to slices of times or event count,  but in different cases there is a need to slice the event stream differently,  such as: as long as an episode holds.    

While the notion of frame is indeed a useful abstraction if we take the pure data stream management primitives as given,  it seems that the fragmentation that exists due to people's starting point, results in duplicating work within different sub-communities, without being aware of work in other sub-communities.  More specifically, I think that the notion of frame has strong  relation to the notion of context that we have introduced, furthermore, I have written before that the notion of context also makes  the concept of punctuation redundant., The notion of punctuation also  came from Dave Maier (with his student Peter Tucker).

I am going to get deeper into Dave's paper and make more thorough comments on the relationship between "context" and "frame"  (and can add "fluent" in event calculus as a third term for comparison).  I also sent Dave some material on context (following a corridor chat), and he mentioned it during his talk. 

One of the good things that the relational model brought to the database community, was that it was accepted as a starting point (years before the standard approved),  and then let the research community focus on doing absolute new work, instead of relative new work,  which was one of the reasons to the big influence of the research community on reality in the database area.    We should strive to do the same in the event processing domain -- more later.  

Saturday, March 28, 2009

What the event processing discipline can learn from other disciplines ?


This is a picture of the Bahai Gardens, one of the famous sites in my home-city Haifa, the Bahai religion is an interesting one, more modern than most religions (I myself am agnostic and do not practice any religion, so this is not meant to be an endorsement), the Bahai people see Haifa as one of their holy sites and invest a lot in the city, this week they have a major celebration. I have returned to Haifa after my short trip abroad, in which I have given four times the same talk about "event processing - the next generation" (I'll post in on the web soon). One of the discussion points have been what can the event processing discipline (complex or not) learn from other disciplines that succeeded. Coming from a database background, it is always interesting to me to make a comparison there. When relational databases started to become products in the early 1980-ies, I have been a database practitioner with experience in several DBMS products, and in the beginning I looked at the relational model without much respect, it seemed to me to be over-simplification that gives up semantics and creates a lot of anomalies. However, the simplicity has been the main benefit. The relational model has won, and also created a big research community around it that concentrated forces around a single model and developed query optimizations, more semantic abstractions on top of it and some other stuff. The fact that there has been a substantial brain power dedicated towards a single direction was a contribution to success. The fact that was not a critical mass of work around object-based databases contributed to the fact that its success has been modest. What can we learn from that in the "event processing" discipline ? We need to strive to find the formal model that will be the basis for concentrating the community around. The model is not extension to the relational model, since this extension will loose the main benefit of the relational model -- simplicity. There are several relational algebras around, but all of them do not meet the simplicity criterion, on the contrary -- they are quite complex. So it is still a major challenge for the community. More on that and possible directions -- in subsequent postings.