Re: Help - Does DSMS/Data stream fall under "DBMS design and implementation" category?

Jan Hidders wrote:
> Marshall wrote:
> > Jan Hidders wrote:
> > >
> > > The leading research project in that area is the Stanford Stream Data
> > > Manager:
> > >
> > > http://www-db.stanford.edu/stream/
> >
> > I read through the powerpoint slides for "Models and Issues". I was
> > quite surprised to see their model allows stream joins. It wasn't
> > altogether clear what the semantics are, but I suppose the papers
> > make that clear. I'm hard pressed to imagine how that's going to
> > work.
>
> In principle the semantics are simple. The input are two streams and
> the system produces an output stream that contains tuples from then
> join result as soon as (or a bit later) the system has received the two
> 'joinable' tuples in its input streams.

I agree that this is simple in principle. However, if I am understanding
correctly, this would seem to put some severe constraints on implementation and thereby scalability, which is one of the points of a DSMS. Specifically, if the first tuple of stream A can join with the last tuple of stream B, or vice versa, we need to store the entirety of both streams. Don't we? At which point it's just an insert-only relational table. Offhand I can't think of any logical differences between a stored stream and a table.

Other DSMS approaches I have read about or attended lectures on have limited the model to table-table or stream-table joins, thus eliminating the storage requirement. Often the use-case for such has been data streams that are too high volume or bandwidth to be stored.

Marshall Received on Wed Oct 04 2006 - 16:14:56 CEST