[OSM-dev] Is there a way to use simple schema without hstore
andreaskalsch at gmx.de
Fri Nov 19 10:41:30 GMT 2010
Am 19.11.10 11:25, schrieb Frederik Ramm:
> On 11/19/10 10:25, Andreas Kalsch wrote:
>> I am sure there are some good uses for hstore, but as soon as you use
>> it, you are waiting for something like a document-oriented database. I
>> ask myself: Why do I need normal columns when there is hstore?
> This is exactly what I was getting at. If you're driven by a desire for the pure, then you'd drop
> all the extra columns in the tables and have tags *only* in hstore. But it turns out that even if
> you go through the effort of adapting your mapnik style sheet to query the hstore columns, this
> doesn't perform well enough for proper tile rendering, so you re-add those columns that are used
Right, and on the long run, unification is the way to go. Unification vs. "Never change a running
system". And the second one wins in the context of a system that is running very well.
>>>> MongoDB, for example, unifies worlds by simply using JSON. I don't
>>>> have to manually parse things I do not need to parse.
>>> In turn, you will have a hard time getting the performance required
>>> for a planet-wide application out of MongoDB.
>> OK, can you explain further what the bottlenecks would be?
> I've never touched MongoDB, I've just heard people enthusiastically adopt MongoDB for OSM and then
> growing very quiet. I think you were involved in that thread (back in July)?
I don't know if I was involved in this discussion.
You can be sure, I would never want to change the OSM platform and I would never start a serious
discussion about that.
But it's only about concept. How does such a system look like - which are the weaknesses and
strengths? My time window is very stretched in the moment because of some basic decisions I have to
make in my project. I always like to think through alternatives, I mostly come back to the original
state, but with some new concepts.
> But to go back to your original problem - I have a similar situation where a plugin has been
> written for Osmosis 0.33 which doesn't work with 0.37 any more, and because I could not be
> bothered to fix that, I simply use two instances of Osmosis in a pipe - one 0.37 instance to
> handle the pbf and one 0.33 instance to interface with my plugin. Ugly but works.
I will check that out. Thanks.
More information about the dev