[Tile-serving] [osm2pgsql] Conversion to C++ (#187)

[Paul Norman]

I've had some questions about the multi-backend, so here are a couple of use cases. When I speak of a database, it could be on the same database cluster (server), or different ones. Most applications will use different database servers.

* Using a single server and set of middle tables to update multiple rendering databases with the same style. This uses osm2pgsql to do client-space replication. It's probably not suited for very large numbers of rendering servers as it would stop all updates if any one of the servers is down, but for a small number of servers, it's a way to easily update all of them at once. 

  The primary benefit is not having the middle on all rendering servers, eating up disk space, increasing the size of their working set, and generally increasing costs and decreasing speed. A secondary benefit is not doing geometry construction work on each rendering db server so they can be dedicated to rendering.

* Using a single server and set of middle tables to update multiple rendering databases with different styles.

  Although generally you're better off merging styles, if you have two incompatible or radically different ones, this is of benefit. Similarly, it allows the load to be split.

* Using a single server and PostgreSQL replication. By splitting the middle tables off, you don't have to replicate them, reducing the requirements on all the slave servers. This would work with a *large* number of slave servers, if PostgreSQL replication is set up correctly. 

  The benefits are the same as the client-side replication, but comes with different implications for redundancy, and is probably harder to set up.

* Running a rendering DB and gazetteer DB off of the same middle tables. This is untested, but *should* work. Obviously, not an option for high loads where you want each set of tables on their own server, but for testing, an interesting option.

---
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/osm2pgsql/pull/187#issuecomment-57345269
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20140930/29343317/attachment.html>