Re: Dream Server?

The two tier architecture proposed here, consisting of a master and slave
seems to be the quickest way to get there. However writes handled by a
slave needs to be reported to the master for rebroadcast to all slaves. This
would create a wave in the system, or poor integrity in rapid writes
environment.

Of course an "application aware" scenario, where application connects to the
master for all writes could ease the situation. It effectively removes one hup
from
the data path. ie instead of client-slave-master-slaves, it does
client-master-slaves.
And for a do it yourselfer, one can have a trigger on a system table for
auto-updates.

What I was thinking is perhaps to modify the "Planner/Optimizer" so that this
layer would in addition to its current functionality, would assume the role of
a distributor, dispatcher, scheduler (or whatever other name), setting up a
"Modified Plan Tree" for the Executor. This "Plan Tree" would include a Node
information as well (a Remote Executor, think RPC). There would also need to
be an Intra-Node Advisory Communication Channel (perhaps more than one)
for load balancing and Lock management. I call this an Asymetric architecture.

Another approach would be to have the "Planner" only do the lock management
(in additon to its normal things), I call this "Almost Shared Nothing", and let
DNS
determine who is next.

Another approach would be to have a RAID (Redundant Array of Inexpensive
Databases, I know I'm overloading RAID) Virtual Database (think Virtual File
System),
where an abstraction layer would determine where to put the tables; on node-1
or
node-2 or both. Then either thru a discovery phase (client says, where do I
connect
for this query), or in a transparent mode, the server would pipe up with the
owner of
the data for the given query and simply facilitates the data movement.

The more I write the more I see how complicated this is....
Sorry about my random thoughts.....it reminds me of "Some write to say what
they
think and some write to think what they want to say...."

Aaaahhh.... I better get back to work.... day dreaming again...

Gregory Wood wrote:

> > That's something that I've dreamed about for some time. My rack of
> > load-balanced web servers scales efficiently, easily, and cheaply. I
> > need double the capacity? I buy more machines, and plug them in. If
> > there were a way of replicating PG data from one master to many slaves in
> > near-real-time, I could have a rack full of load-balanced database servers
> > right next to it - cheap, easy, and effective.
> >
> > Even though I've kept my mouth shut, I've wondered why more effort isn't
> > devoted to that.
>
> I'll second this. Replication is my/our number one (actually, aside from
> schemas, the only) needed new feature for PostgreSQL. If we could do updates
> to a master server and push all those changes to a bunch of slaves, my job
> would be incredibly easier. As it stands, we've had to restructure our data
> model so that we can spread information across a number of different
> machines.
>
> > Don't get the impression that I'm bad-mouthing the developpers - I'm
> > sure that they're taking care of priorities as best they can.
>
> Here here. PostgreSQL seems to have come a long way, even in the relatively
> short time I've been using it. I can't heap enough praise on those who give
> their time to improving it. But as a user, it's important to let the
> developers know what we want and/or need.
>
> Greg
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

--
-------------------------------------------------------------------------
Medi Montaseri medi(at)CyberShell(dot)com
Unix Distributed Systems Engineer HTTP://www.CyberShell.com
CyberShell Engineering
-------------------------------------------------------------------------