Re: multimaster - Mailing list pgsql-general

From Tino Wildenhain
Subject Re: multimaster
Date
Msg-id 4663F5D9.40809@wildenhain.de
Whole thread Raw
In response to Re: multimaster (was: Slightly OT.)  ("Alexander Staubo" <alex@purefiction.net>)
Responses Re: multimaster  ("Alexander Staubo" <alex@purefiction.net>)
List pgsql-general
Alexander Staubo schrieb:
> On 6/1/07, Andrew Sullivan <ajs@crankycanuck.ca> wrote:
>> These are all different solutions to different problems, so it's not
>> surprising that they look different.  This was the reason I asked,
>> "What is the problem you are trying to solve?"
>
> You mean aside from the obvious one, scalability?
>
> The databases is becoming a bottleneck for a lot of so-called "Web
> 2.0" apps which use a shared-nothing architecture (such as Rails,
> Django or PHP) in conjunction with a database. Lots of ad-hoc database
> queries that come not just from web hits but also from somewhat
> awkwardly fitting an object model onto a relational database.

...

> the single server, but I would hope that there would, at some point,
> appear a solution that could enable a database to scale horizontally
> with minimal impact on the application. In light of this need, I think
> we could be more productive by rephrasing the question "how/when we
> can implement multimaster replication?" as "how/when can we implement
> horizontal scaling?".
>
> As it stands today, horizontally partitioning a database into multiple
> separate "shards" is incredibly invasive on the application
> architecture, and typically relies on brittle and non-obvious hacks
> such as configuring sequence generators with staggered starting
> numbers, omitting referential integrity constraints, sacrificing
> transactional semantics, and moving query aggregation into the app
> level. On top of this, dumb caches such as Memcached are typically

Did you have a look at BizgresMPP?

Especially for your shared-nothing approach it seems to be a better
solution then just replicating everything.

Regards
Tino

pgsql-general by date:

Previous
From: PFC
Date:
Subject: Re: Numeric performances
Next
From: Gregory Stark
Date:
Subject: Re: debugging C functions