Re: Scalability Design Questions - Mailing list pgsql-general

From Scott Marlowe
Subject Re: Scalability Design Questions
Date
Msg-id dcc563d10709081205i53868fc1y3fda596584b2a75b@mail.gmail.com
Whole thread Raw
In response to Re: Scalability Design Questions  (novnov <novnovice@gmail.com>)
Responses Re: Scalability Design Questions
List pgsql-general
On 9/8/07, novnov <novnovice@gmail.com> wrote:
>
> Yes, I realize that scaling must be a large and complicated topic. And that
> PostgresSQL is not as scaleable as Oracle etc.

Depends on how we're defining scalability.  :)

I didn't explicitly say that RAC will outscale postgresql.  It's just
one approach.  another approach is getting a bigger and faster server.
 It may well be that you can buy enough hardware for pgsql to outrun a
similarly priced RAC setup.  Counting how much oracle charges per
machine in a RAC cluster, it's not unreasonable to think so.

RAC isn't infused with magic pixie dust, there's a point at which
adding machines to a RAC cluster will no longer make the cluster
faster.  The SAN required for a RAC cluster is not cheap.

BTW, I assume you're talking about a transactional db, i.e. banking
type transactions.

> I know after reading your post that Postgres cannot match RAC. I'm still not
> sure if Postgres can operate a database from more than one box, at all.

There's been some work going on that I've seen mentioned to give
PostgreSQL a RAC like capability, but I don't think we'll see it real
soon.  for now, postgresql does single master multuple slave
asynchronous replication quite well.  multi-master synchronous, which
is what RAC basically does is not available.

It it quite possible that as hardware and pgsql get faster that all
the scaling you'll need can be provided by those two things.

How many transactions per second are you planning on?  Can you
partition your data to multiple servers?

> PGCluster on PGFoundry seems to be more about replication.

I'm not all that familiar with pgcluster.

pgsql-general by date:

Previous
From: Shelby Cain
Date:
Subject: Re: replacing Access/ Approach etc
Next
From: "Scott Marlowe"
Date:
Subject: Re: replacing Access/ Approach etc