Re: Scalability Design Questions

From: novnov <novnovice(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Scalability Design Questions
Date: 2007-09-09 16:11:17
Message-ID: 12580273.post@talk.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


OK, this has been very informative and I'd like to thank the three of you.

Asynchronous replication to readonly slaves is something I will look into.
I've never touched posgtres replication; and Scott mentioned that he was not
familiar with PGCluster, so there must be some other replication system he's
referencing, maybe Slony-I?

Trevor Talbot-2 wrote:
>
> On 9/8/07, novnov <novnovice(at)gmail(dot)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 :(
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
>

--
View this message in context: http://www.nabble.com/Scalability-Design-Questions-tf4406693.html#a12580273
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Christian Schröder 2007-09-09 16:41:46 Re: Query with "like" is really slow
Previous Message Tom Lane 2007-09-09 14:54:27 Re: Checking is TSearch2 query is valid