Re: [HACKERS] CFH: Mariposa, distributed DB

On Mon, Feb 07, 2000 at 04:23:06PM -0500, Bruce Momjian wrote:
> > This is a Call For Hackers:
> >
> > Some time ago, I floated a little discussion on this list about doing
> > some distributed database work with PostgreSQL. The project got back
> > burnered at work, but now has a timeline for needing a solution "this
> > summer." Recent discussions on this list about Postgres's historical
> > object roots got me back to the Berkeley db sites, and reminded me about
> > Mariposa, which is Stonebraker's take on distributed DBs.
> >
> > http://s2k-ftp.cs.berkeley.edu:8000:8000/mariposa/
> >
>
> I have looked at the code. I have files that show all the diffs they
> made to it and they have some new files. It was hard for me to see what
> they were doing. Looks like they hacked up the executor and put in some
> translation layer to talk to some databroker. It seems like an awfully
> complicated way to do it. I would not bother getting it to run, but
> figure out what they were trying to do, and why, and see how we can
> implement it. My guess is that they had one central server for each
> table, and you went to that server to get information.
>

Actually, this being an academic project, there's lots of design
documents about how it's _supposed_ to work. Stonebraker calls in an
'agoric' distributed database, as in agora, market. The various db
servers offer tables (or even specific views on tables) 'for sale', and
bid against/with each other to provide the data to clients requesting
it. The idea behind it is to us a micro-economic market model to do
your distributed optimizations for you, rather than have the DBAs decide
what tables go where, what tables need to be shadowed, etc. The win is
supposedly massive scaleability: they Cohera site talks about 10000s
of servers.

As I said, I've been doing the compare existing source code thing,
but thought working code might be more revealing, and give my project
manager something to see progress on ;-) Your right, though, that the
most productive way to go, in the long run, might be to reimplement what
they've described, in the current pgsql tree, using the Mariposa source
as an example implementation.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm(at)rice(dot)edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005