Re: Dream Server? - Mailing list pgsql-general
From | Medi Montaseri |
---|---|
Subject | Re: Dream Server? |
Date | |
Msg-id | 3C62F7BC.124D3E23@cybershell.com Whole thread Raw |
In response to | Dream Server? ("Gavin M. Roy" <gmr@justsportsusa.com>) |
List | pgsql-general |
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@CyberShell.com Unix Distributed Systems Engineer HTTP://www.CyberShell.com CyberShell Engineering -------------------------------------------------------------------------
pgsql-general by date: