Re: [OSM-talk-fr] Benchmark d'import osm - Etait beta est de retour...
On 31 mars 2010, at 20:02, Emilie Laffray wrote: On 31/03/2010 18:11, Steven Le Roux wrote: Puisqu'on parle de performance, quelqu'un aurait essayé d'importer le format osm vers une base nosql genre cassandra/HBase ? Je ne suis pas sure que ca soit utile. Après tout, je ne crois pas que les bases nosql aient un support spatial a la base. J'ai lu récemment que mongoDB venait d'ajouter le support du geospatial indexing : http://www.mongodb.org/display/DOCS/Geospatial+Indexing Vlad.___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Benchmark d'import osm - Etait beta est de retour...
Il y a aussi un plugin GeoCouch pour CouchDB, présenté au FOSS4G l'an dernier... http://vmx.cx/cgi-bin/blog/index.cgi/category/CouchDB F. 2010/4/2 Vladimir Vyskocil vladimir.vysko...@gmail.com: On 31 mars 2010, at 20:02, Emilie Laffray wrote: On 31/03/2010 18:11, Steven Le Roux wrote: Puisqu'on parle de performance, quelqu'un aurait essayé d'importer le format osm vers une base nosql genre cassandra/HBase ? Je ne suis pas sure que ca soit utile. Après tout, je ne crois pas que les bases nosql aient un support spatial a la base. J'ai lu récemment que mongoDB venait d'ajouter le support du geospatial indexing : http://www.mongodb.org/display/DOCS/Geospatial+Indexing Vlad. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Benchmark d'import osm - Etait beta est de retour...
2010/3/31 Marc Sibert m...@sibert.fr Emilie Laffray a écrit : Quelqu'un a fait des essais sur SQLLite3, et ce n'était pas concluant du tout. Ça souffrait de sérieux ralentissement rien que sur un pays (l'Allemagne). Emilie Laffray Ben sur la France (prise à geofabrik.de) ça marche pas mal. Comme je l'écrivais, je fais les inserts sans index avec un mode de Sqlite3 qui ne garantit pas l'intégrité de la base en cas de shutdown violent, mais là qu'importe. Je rajoute donc les index (classiques et géographiques) après puis je finis par un analyse (calculs de statistiques sur les données pour optimiser les plans d'exécutions). Avec un AMD 1800, 1 Go de RAM (quasiment pas utilisée), et un disque local 250 Go : un PC de bureau quoi. Comme, en plus, il s'agit pas seulement de Sqlite3, mais de l'extension Spatialite, j'hérite de plein de fonctions spatiales et de conversions pubSpatialite inclut les librairies PROJ.4 latest version (4.6.1), GEOS latest version (3.1.1), SQLite's latest version (3.6.16))/pub Merci pour vos retours, Interessant. Je serais curieuse de savoir quel type de performance tu obtiens. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Benchmark d'import osm - Etait beta est de retour...
Puisqu'on parle de performance, quelqu'un aurait essayé d'importer le format osm vers une base nosql genre cassandra/HBase ? 2010/3/31 Marc Sibert m...@sibert.fr Emilie Laffray a écrit : Quelqu'un a fait des essais sur SQLLite3, et ce n'était pas concluant du tout. Ça souffrait de sérieux ralentissement rien que sur un pays (l'Allemagne). Emilie Laffray Ben sur la France (prise à geofabrik.de) ça marche pas mal. Comme je l'écrivais, je fais les inserts sans index avec un mode de Sqlite3 qui ne garantit pas l'intégrité de la base en cas de shutdown violent, mais là qu'importe. Je rajoute donc les index (classiques et géographiques) après puis je finis par un analyse (calculs de statistiques sur les données pour optimiser les plans d'exécutions). Avec un AMD 1800, 1 Go de RAM (quasiment pas utilisée), et un disque local 250 Go : un PC de bureau quoi. Comme, en plus, il s'agit pas seulement de Sqlite3, mais de l'extension Spatialite, j'hérite de plein de fonctions spatiales et de conversions pubSpatialite inclut les librairies PROJ.4 latest version (4.6.1), GEOS latest version (3.1.1), SQLite's latest version (3.6.16))/pub Merci pour vos retours, -- Marc ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB ste...@le-roux.info 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Benchmark d'import osm - Etait beta est de retour...
On 31/03/2010 18:11, Steven Le Roux wrote: Puisqu'on parle de performance, quelqu'un aurait essayé d'importer le format osm vers une base nosql genre cassandra/HBase ? Je ne suis pas sure que ca soit utile. Après tout, je ne crois pas que les bases nosql aient un support spatial a la base. Je ne suis pas convaincue par l'utilisation d'une base nosql car la logique derrière tout ca n'est pas aussi simple et pour utiliser cela de manière utile, il faut bien maitriser. Je ne sais pas si ca aurait un quelconque avantage a moins d'avoir cela sur le serveur principal (et la serie de clusters associes). Il faut voir. Je serais curieuse de voir le résultat et surtout de savoir si ca apporte vraiment quelque chose. Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Benchmark d'import osm - Etait beta est de retour...
Emilie Laffray wrote: On 31/03/2010 18:11, Steven Le Roux wrote: Puisqu'on parle de performance, quelqu'un aurait essayé d'importer le format osm vers une base nosql genre cassandra/HBase ? Je ne suis pas sure que ca soit utile. Après tout, je ne crois pas que les bases nosql aient un support spatial a la base. Je ne suis pas convaincue par l'utilisation d'une base nosql car la logique derrière tout ca n'est pas aussi simple et pour utiliser cela de manière utile, il faut bien maitriser. Je ne sais pas si ca aurait un quelconque avantage a moins d'avoir cela sur le serveur principal (et la serie de clusters associes). Il faut voir. Je serais curieuse de voir le résultat et surtout de savoir si ca apporte vraiment quelque chose. d'apres ce que j'ai compris ca s'adapte bien aux structure de données dont le contenu est variable. Du coup j'imagine que ca pourrait coller avec les donnes OSM dans la mesure ou la plupart des attributs d'un node ou d'une way sont optionnels (et qu'on peut même rajouter un nouvel attribut a tout moment) Pour les clusters, apparement les base noSQL sont plutot performante des qu'il y a pas mal de serveurs, donc ca pourrait coller aussi. Surtout qu'a priori il n'y a pas (ou il y a moins) de goulet d'etranglement sur les ecritures en base. Qui sont traditionnelement un peut le facteur limitant. Enfin tout ca c'est de la theorie. J'espere essayer la pratique ce WE. -- JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Benchmark d'import osm - Etait beta est de retour...
là où je m'interroge c'est sur les performances d'un postgis par exemple. Quelle est sa limite ? Imaginons que je doive concevoir un service faisant de la recherche géographique... jusqu'où monte postgis ? idem en indexation... Donc si qq'un a déjà benché, je suis prenneur :) 2010/3/31 julien balas jul...@krilin.org Emilie Laffray wrote: On 31/03/2010 18:11, Steven Le Roux wrote: Puisqu'on parle de performance, quelqu'un aurait essayé d'importer le format osm vers une base nosql genre cassandra/HBase ? Je ne suis pas sure que ca soit utile. Après tout, je ne crois pas que les bases nosql aient un support spatial a la base. Je ne suis pas convaincue par l'utilisation d'une base nosql car la logique derrière tout ca n'est pas aussi simple et pour utiliser cela de manière utile, il faut bien maitriser. Je ne sais pas si ca aurait un quelconque avantage a moins d'avoir cela sur le serveur principal (et la serie de clusters associes). Il faut voir. Je serais curieuse de voir le résultat et surtout de savoir si ca apporte vraiment quelque chose. d'apres ce que j'ai compris ca s'adapte bien aux structure de données dont le contenu est variable. Du coup j'imagine que ca pourrait coller avec les donnes OSM dans la mesure ou la plupart des attributs d'un node ou d'une way sont optionnels (et qu'on peut même rajouter un nouvel attribut a tout moment) Pour les clusters, apparement les base noSQL sont plutot performante des qu'il y a pas mal de serveurs, donc ca pourrait coller aussi. Surtout qu'a priori il n'y a pas (ou il y a moins) de goulet d'etranglement sur les ecritures en base. Qui sont traditionnelement un peut le facteur limitant. Enfin tout ca c'est de la theorie. J'espere essayer la pratique ce WE. -- JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB ste...@le-roux.info 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Benchmark d'import osm - Etait beta est de retour...
On 31/03/2010 22:48, Steven Le Roux wrote: là où je m'interroge c'est sur les performances d'un postgis par exemple. Quelle est sa limite ? Imaginons que je doive concevoir un service faisant de la recherche géographique... jusqu'où monte postgis ? idem en indexation... Donc si qq'un a déjà benché, je suis prenneur :) Une requête de reverse geocoding sur le serveur du boulot prend environ 50ms. Dans la table des routes, il y a 28M de lignes. Les autres tables comme les POI sont beaucoup plus petites. La relative lenteur de la requête s'explique par l'utilisation autre que des polygones. Quand tu utilises des polygones partout, tu descend très vite. Avec la configuration serveur que l'on a au bureau, on a estime être capable de prendre environ 800 requêtes seconde. Postgis tient bien la route et après il y a toujours moyen d'optimiser avec des index partiels selon ce que tu recherches et des partitions de table (très très efficace). De plus, manipuler des polygones est très performant (a condition qu'ils fassent une taille raisonnable) du fait de la mise en mémoire des géométries. C'est vraiment une question de configuration de Postgres sur pas mal de points pour avoir de bonnes performances. Des choses comme un index clustering peut sérieusement aider les performances en IO. Postgis 1.5 a pas mal d'optimisations supplémentaires sur des choses comme ST_intersects, ST_Union (1.4+) etc... Apres c'est sur tu peux tuer le serveur avec certaines requêtes :) Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
