[OSM-dev] New database server

[Serge Wroclawski]

Jason,

You're not at all wrong about the issues with the server design.

This is something that's been well known and understood for several years:

   As the project grows, the cost of scaling on a single system will
not scale accordingly.

What I mean by that is, that it's not a linerar cost to buy a single
machine with linear scaling.

So if you are growing, it makes more economical (and technical) sense
to scale away, rather than building up.

What would this mean in the context of OSM?

It might mean something like moving the GPX data off the main
database. Or maybe having historical data on a slower database than
the current data.

It also includes things like aggressive caching and uausing tiled map
calls (something that Ian and I worked on, and Ian has a new
implementation of).

And there's room for more optimizations even then, but just these
would make an impact.

So why doesn't this happen? Frankly, because I think the project
doesn't have anyone who can act in the kind of technical leadership
role this would require.

Making these kinds of changes would require modifying (and testing)
the rails port, as well as possibly modifying cgimap (depending on
which calls were effected), and the database, and setting up the new
hardware, and coordinating with whatever hosting situation that would
be in, etc.

It's not something anyone can do, with the possible exception of the
sys-admins (who are both extremely overworked and volunteer).

This is why the org needs a structural change, to give someone the
authority and resources to oversee projects like this.

Without this, the OWG is stuck ordering more hardware.

- Serge