Re: multimaster

alex(at)purefiction(dot)net ("Alexander Staubo") writes:
> 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?

I'd have to call that expectation "obviously WRONG."

It was *CERTAIN* that Slony-II, if it had turned out as good as the
*most optimistic hopes* were going, would have some substantial losses
of performance compared to a single DB instance due to the need to
apply locks across all nodes.

There would be *some* scalability gains to be had, but the primary
reason for looking for multimaster replication is that you need high
availability so badly that you are willing to give up performance to
get it.

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

Question: In what way would you expect an attempt to do
mostly-trying-to-be-transparent multimaster replication to help with
these issues you're bringing up?

Slony-II was trying to provide answers to various of those
"non-obvious hacks"; various of those things point at areas where it
would *have to* be somewhat slow.

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

Partitioning isn't multimaster replication; it's something worthy of
having a discussion independent of anything about MMR.
--
(reverse (concatenate 'string "ofni.sesabatadxunil" "@" "enworbbc"))
http://linuxdatabases.info/info/sap.html
"There are almost unlimited ways for making your programs more
complicated or bizarre" -- Arthur Norman