Moin, On Sun, Sep 05, 2010 at 06:38:12PM +0200, Josias Polchau wrote: > Datenbank: > Ich bin aus eigener Erfahrung für Postgres/Postgis. es ist sehr schnell > auch mit großen Datenmengen
Ganz ehrlich - fuer sowas wie die XAPI ist die postgres zu langsam. Ich wuerde da eher sowas wie die TRAPI nehmen und aufbohren, bzw mal drueber nachdenken in C oder aehnlichem eine OSM-DB zu bauen. SQL DBs passen nicht wirklich schoen zu den OSM Daten. Das Problem mit der TRAPI sind die vielen kleinen files und perl als interpretersprache die nicht wirklich super fuer die bit ops ist (Ich bin sonst schon ein perl fan) > Hat jemand andere Vorschläge oder Argumente? immer her damit. s.o. Ich finde das Thema OSM binary file format spannend. Die google protocol buffers sind ideal fuer das was wir da machen muessten. Wichtig ist das zeugs auf der platte KLEIN zu halten damit main memory gut ausgenutzt wird. Wichtig ist auch das der import schnell geht, so das fritzchen mueller das auch mal schnell auf seiner kiste machen kann. Deshalb habe ich mal mit einem parallelisierten OSM XML file reading rumgespielt d.h. beliebig viele cores dafuer zu nutzen (Wenn das bunzip single threaded ist kann man durchauf 6-8 Cores beschaeftigen). Klappt soweit ganz gut. Die frage ist nur wie man jetzt das ganze XML in eine Datenbank verbuddelt - Da habe ich erste experimente mit integer compression und string deduplication gemacht - nen bischen wie die google protocol buffers (ohne die zu kennen) bis ich dann ueber die osm binary file implementierung gestolpert bin. Flo -- Florian Lohoff [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
