Re: multimaster

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Alexander Staubo <alex(at)purefiction(dot)net>
Cc: Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-general(at)postgresql(dot)org
Subject: Re: multimaster
Date: 2007-06-01 18:50:09
Message-ID: 46606A61.3090300@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alexander Staubo wrote:
> On 6/1/07, Andrew Sullivan <ajs(at)crankycanuck(dot)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?

Multimaster doesn't give you scalability (at least not like a lot of
people think it does).

>
> 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.
>

Databases are a bottleneck when you get a bunch of so called web 2.0
developers thinking they know an inch about databases.

What you are basically saying below is... web 2.0 developers such as
rails developers have so fundamentally broken the way it is supposed to
be done, we should too...

Not too convincing.

>
> 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
> layered to avoid hitting the database in the first place.
>
> Still, with MySQL and a bit of glue, guys like eBay, Flickr and
> MySpace are partitioning their databases relatively successfully using
> such tricks. These guys are not average database users, but not they
> are not the only ones that have suffered from database bottlenecks and
> overcome them using clever, if desperate, measures. Cal Henderson (or
> was it Stewart Butterfield?) of Flickr has famously said he would
> never again start a project that didn't have a partitioning from the
> start.
>
> I would love to see a discussion about how PostgreSQL could address
> these issues.
>
> Alexander.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org/
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Gregory Stark 2007-06-01 18:51:26 Re: invalid memory alloc after insert with c trigger function
Previous Message Teodor Sigaev 2007-06-01 18:42:00 Re: warm standby server stops doingcheckpointsafterawhile