[postgis-users] Best way to

Paul Ramsey pramsey at refractions.net
Mon Nov 19 13:06:55 PST 2007


louvy.joseph at gmail.com wrote:
> We are developing a solution using geoserver with postgis postresql 
> server. Out database is going to be huge and our projection is that 
> number of simultaneous users will be too huge to be handled by single 
> database.

And you think you're going to bottleneck at the database? :) Better 
check out Geoserver more closely. :)

> What are the best practices currently available to handle this? Please 
> do comment  on  some of the open  thoughts we have:
> 
> 1) Does it make sense to split the database based on geography? For 
> example, single database for each continent or a country. But we have 
> concerns on changes needed to our client for handling the region 
> boundaries and the features crossing region boundaries.

If your features are going to be crossing boundaries, then no, 
partitioning on geography is not wise. There are probably other 
variables you can partition on. Anything that has a hard non-overlapping 
domain is a candidate (user id, for example).

> 2)  We are also thinking of multi-master replication solutions. Can 
> somebody give opinion of a) Postgres-R  b)  PgCluster  c) Bucardo - d) 
> Sequoia ? Which of them is stable? Which is more mature and has more 
> community? Which is better: synchronous versus asynchronous replication?

None of the multi-master technologies for postgres are particularly 
mature. But there is no guarantee you actually need multi-master. Having 
a single update server and multiple query servers might serve just as well.

> 3) BTW, how many users a single postgres database instance (say on a 
> 2GHz Pentium 2GB memory system) can handle?

This depends entirely on what they are doing, so an answer is not 
possible with this much information.

P.

-- 

   Paul Ramsey
   Refractions Research
   http://www.refractions.net
   pramsey at refractions.net
   Phone: 250-383-3022
   Cell: 250-885-0632



More information about the postgis-users mailing list