Reply-To: <andy@areyoulocal.co.uk>
From: Andy Ballingall <andy@areyoulocal.co.uk>
To: "'Achilleus Mantzios'" <achill@matrix.gatewaynet.com>,
	"'codeWarrior'" <gpatnude@hotmail.com>
Cc: <pgsql-sql@postgresql.org>
Subject: Re: idea for a geographically distributed database: how best
Date: Thu, 17 Nov 2005 17:05:53 -0000
Organization: Areyoulocal Ltd.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcXrlt8ReAul3PHYTy2HLGQVKnRh6gAAcfug
In-Reply-To: <Pine.LNX.4.44.0511171917200.8800-100000@matrix.gatewaynet.com>
Message-ID: <ECOWS01MJ3fvr9FFf700003bba7@smtp-out1.blueyonder.co.uk>


>Andy, i agree with what codeWarrior says.
But if you are interested in replication, dbmirror is very elegant
(altho not as trendy) simple, and highly customizable replication 
solution.

I have heavily modified dbmirror to even support
Asynchronous Conditional row grained 
Foreign key dependency Traversal oriented 
Lazy Replication!!!
(which ofcourse nobody wants :)


I'll go and check it out, so even if I don't want to use it, I'll at least
know what it means! 

(I considered suggesting using an acronym for it, but 'ACRGFKDTOLR' made my
lips bleed when I tried to say it).

Thanks,
Andy


> 
> 
> 
> 
> "Andy Ballingall" <andy@areyoulocal.co.uk> wrote in message 
> news:ECOWS04Mp8nkfZyufzT00010fe4@smtp-out4.blueyonder.co.uk...
> > Hello,
> >
> > I've got a database for a website which is a variant of the 'show stuff 
> > near
> > to me' sort of thing.
> >
> > Rather than host this database on a single server, I have a scheme in
mind
> > to break the database up geographically so that each one can run 
> > comfortably
> > on a small server, but I'm not sure about the best way of implementing
it.
> >
> > Here's the scheme:
> >
> > --------------------------------
> > Imagine that the country is split into an array of square cells.
> > Each cell contains a database that stores information about people who 
> > live
> > in the area covered by the cell.
> >
> > There's one problem with this scheme. What happens if you live near the 
> > edge
> > of a cell?
> >
> > My solution is that any inserted data which lies near to the edge of
cell 
> > A
> > is *also* inserted in the database of the relevant neighbouring cell - 
> > let's
> > say cell B.
> >
> > Thus, if someone lives in cell B, but close to the border with cell A,
> > they'll see the data that is geographically close to
> > them, even if it lies in cell A.
> >
> > --------------------------------
> >
> > Is this a common pattern?
> >
> > I could, of course, simply find every insert, update and delete in the
> > application and alter the code to explicitly update all the relevant
> > databases, but is there a more elegant way of simply saying: "Do this
> > transaction on both Database A and Database B" monotonically?
> >
> > I've had a look at some replication solutions, but they all seem to 
> > involve
> > replicating an entire database. The advantage of my scheme is that if I 
> > can
> > distribute my application over large numbers of small servers, I'll end
up
> > with more bangs for the buck, and it'll be much easier to manage growth
by
> > managing the number of servers, and number of cells hosted on each
server.
> >
> > Thanks for any suggestions!
> > Andy Ballingall
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: Have you checked our extensive FAQ?
> >
> >               http://www.postgresql.org/docs/faq
> > 
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
> 

-- 
-Achilleus


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org


-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.3/173 - Release Date: 16/11/2005