I think that you are expecting to use MPI datatypes as *the only*
meta-data that you're going to store in your DBMS, and expect to use
MPI (and some query language ?) as a replacement for SQL. (The MPI
giving all of the data typing and layout information).
I hadn't even considered that at all, because MPI is not SQL, and
isn't designed to be. I was assuming that you had to solve the
meta-data problem anyway, whereas you seem to hope that MPI is going
to do it all for you !
However, even considering that, I still disagree with some of your
conclusions.
> > How many parallel DBMS systems do you believe will be written ?
> > ten, a hundred, a thousand, ten thousand ?
>
> The question is how many applications will be written to interface them,
> including O/S software. The choices will be Parallel SQL, OLE, and MPI.
>
> - SQL has the capability I am pressing you for.
> - OLE is a common object approach, any player must be linked to
> the object library module for that datatype.
>
> MPI will be useless for this task unless it can instantiate foriegn
> types. Same with parallel archival storage systems.
I still don't think this is true. The user application which consumes
the data has semantic knowledge of the data it expects to see, it
understands the layout it wants the data to have in its store, and it
can express that information to MPI. Therefore there is nothing needed
here beyond what MPI can already do.
Pushing one step further, to your visualisation example. Here we
assume that the visualiser doesn't know a priori the type/layout of
the data. So it gets from somewhere the type signature of the
data.
Now it has the following task to perform (and this is what you seem to
expect MPI to do magically, and I don't believe it can.)
It must scan the type signature and generate a layout, so that it can
receive the data *and* know where the data is in its store. It's up to
the visualisation program to do this (*not* MPI), because the
visualisation program knows how it wants the data layed out in its
store (MPI doesn't and can't). (For instance the vis program might
want it layed out with all the doubles in one store area, all the ints
in another, and so on, or altrenatively it might want them all layed
out contiguously with natural machine alignment, or it might just want
them all layed out contiguously with no alignment constraints. Any of
these possibilities seem plausible).
If the vis program doesn't control the layout in store, how can it use
the data, since it doesn't know where it is ?
(Of course one answer to this question is to provide another set of
routines which let you gain access to the data. My guess is that this
is what embedded SQL looks like, and why you say that "SQL already has
this").
> MPI will be useless for this task unless it can instantiate foriegn
> types.
I think the problem is what you mean by "instantiate foreign
datatypes". You seem to want MPI to do much more than just message
passing (it is Message Passing Interface, after all !). As far as I
can make out you want to be able to have MPI allocate storage for you
and manage access to data, so that your visualisation example could
look something like
receive type description
receive data that matches the type
foreach component in the the type
if (type component is one I understand)
get pointer to component data
display the data
end if
end for
free the data
I think this is getting beyond what MPI should be doing. (Though it
may be a noble thing for someone else to build on top of MPI).
However, I may be completely off beam, since I haven't seen any
proposal for the access functions which are clearly required if you're
going to be able to locate any data inside an MPI created chunk.
-- Jim
James Cownie
BBN UK Ltd
Phone : +44 117 9071438
E-Mail: jcownie@bbn.com