On 9/8/07, novnov <novnovice@gmail.com> wrote:
> But basically, it seems that the answer to one of my questions is that there
> is currently no way with postgres to spread a single database over multiple
> servers, ala a loadbalanced apache cluster, where requests are forwarded to
> different boxes.
Actually, that's essentially the same thing. Whether it's the front
end or middleware, something splits the requests apart before they're
processed.
The asynchronous replication to readonly slaves Scott mentioned
earlier would be roughly equivalent to having several identical apache
boxes that have their own local copies of files that you periodically
rsync/ftp/whatever to them from a single place. Partitioning data
would be roughly equivalent to having one apache box for images, one
for ads, etc.
From what I've seen people mention of RAC, it provides strong
guarantees about server consistency -- all of them have the changes or
none of them do -- but you need to go to great effort to achieve the
same thing on a set of apache boxes too. I mean, you don't have each
box accepting file uploads via the web and assume the others will
magically see the same file at exactly the same time, right? Unless,
of course, you're using them purely for CPU reasons and have a single
shared storage pool.
Whatever is splitting the requests may do it on a "session" level too,
which makes it easier for the backend clusters. E.g. if a given user
always hits a given apache box, that file upload situation isn't a
problem as long as you can rsync faster than the sessions time out.
Often you need to load balance this way anyway if you have a web app
using an internal notion of sessions -- session data isn't replicated
to other apache boxes. (If you need it to be replicated, you're
already in special design territory, not just easy load balancing.)
It all varies depending on the details of what you're doing. Even
that seemingly straightforward question isn't specific enough :(