Re: Scalability Design Questions

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: novnov <novnovice(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Scalability Design Questions
Date: 2007-09-08 19:05:33
Message-ID: dcc563d10709081205i53868fc1y3fda596584b2a75b@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 9/8/07, novnov <novnovice(at)gmail(dot)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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2007-09-08 19:08:34 Re: replacing Access/ Approach etc
Previous Message Shelby Cain 2007-09-08 18:57:13 Re: replacing Access/ Approach etc