[OSM-dev] Is there a way to use simple schema without hstore

Andreas Kalsch andreaskalsch at gmx.de
Fri Nov 19 10:41:30 GMT 2010


Am 19.11.10 11:25, schrieb Frederik Ramm:
> Hi,
>
> 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 
> often...
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.
>
> Bye
> Frederik
>
>




More information about the dev mailing list