Reply-To: <andy@areyoulocal.co.uk>
From: Andy Ballingall <andy@areyoulocal.co.uk>
To: <dave.bath@unix.net>,
	<pgsql-sql@postgresql.org>
Subject: Re: idea for a geographically distributed database: how best to
	implement?
Date: Tue, 22 Nov 2005 13:22:35 -0000
Organization: Areyoulocal Ltd.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-reply-to: <200511221102.49528.dave.bath@unix.net>
Thread-Index: AcXu97kdE8RojhDTQ+Ogp1L9qy4H+AAZxaCQ
Message-ID: <ECOWS01MpB9pbKWZfEA0000693e@smtp-out1.blueyonder.co.uk>


David Bath wrote:
> There are a couple of philosophical perspectives I've come across in
> previous
> work with cadastral data that may be useful...[snipped]

Thanks, David

In this particular application, structures such as postcode sectors,
administrative boundaries etc. are not really of much importance, as most
stuff is a simple coordinate based searches. Even with the problem
partitioned into disjoint regions, within each region, the search remains
trivial, as all the data that the user is allowed to access will be stored
with that region (this includes data replicated from neighbouring regions).

In this context, the interesting task isn't so much the actual database
searching, or the exact definition of the disjoint regions.

The interesting task is to define a system which can dynamically remap the
hosting of regions to specific servers, so that no one server gets too busy.
As demand grows, I simply plug in more 4 blades and press the 'reconfigure'
button (Sorry - I was dreaming for a moment...)

The only limiters are the number of servers available and the activity
within a single region (which must be servable by a single server), but
given the highly localised nature of the application, the regions can be
very small, and I don't expect to ever see a region with more than 1GB of
data - the aim being for all the data to be resident in RAM.

So far, I've already seen some issues. I've been looking at slony-1 to
handle the replication between adjacent regions, and not only is it
asynchronous (I was hoping otherwise...slony-2 seems a long way off), but
changing the db schema has ramifications too. (I.e. changing the schema
means redefining each replication). Still - no show stoppers yet.

Thanks for your insights,

Andy