L'un de vous a-t-il déjà utilisé des bases de données NoSQL (non relationnelles) pour stocker des données spatiales? Existe-t-il des avantages potentiels (vitesse, espace, ...) d'utiliser de telles bases de données pour stocker des données, par exemple, pour une application de bureau (par rapport à SpatiaLite ou PostGIS)?
J'ai lu des articles sur l'utilisation de MongoDB pour les données spatiales , mais je suis intéressé par une comparaison des performances.
graphiques de bases de données comme Neo4j sont un très bon ajustement, d'autant plus que vous pouvez ajouter différents schémas d'indexation de manière dynamique, comme vous allez. Typique de choses que vous pouvez faire sur votre base de données est bien sûr 1D indexation (par exemple Timline ou B-Arbres) ou funky des trucs comme Hilbert Courbes etc, voir Nick blog. Aussi, pour une démonstration en direct, regarder la CRAINTE SIG open source un outil de bureau ici, le sous-jacent indexé graphique étant visible autour de l'heure 07:00 .
Actuellement, MongoDB utilise geohashing avec les B-arbres, qui sera plus lente que la R-arbres de PostGIS (je ne peux pas donner le nombre exact, j'ai peur, mais il y a beaucoup de littérature théorique sur les différences). Cependant, dans ces diapositives, http://www.slideshare.net/nknize/rtree-spatial-indexing-with-mongodb-mongodc l'auteur parle de l'ajout de R-arbres de MongoDB et de la fragmentation sur un geo clé. Vous parlez d'une utilisation de bureau, de sorte geosharding peut-être pas d'intérêt, comme la fragmentation, les avantages se feront sentir plus sur de vastes ensembles de données. En fin de compte, il est probablement en baisse de plus de ce que vous voulez faire avec vos données spatiales. Postgis a beaucoup plus de fonctions et de soutien pour la topologie, les rasters, la 3D, les conversions entre les systèmes de coordonnées, donc si c'est ce que vous cherchez, PostGIS serait encore la meilleure option. Si vous êtes intéressé dans le stockage des milliards de/des milliers de milliards d'objets géographiques et juste en cours d'exécution de base de trouver tous les points près de/à l'intérieur de ce point en fonction de certains critères, puis MongoDB est probablement un très bon choix.
J'ai stocké des données spatiales avec ZODB. L'accès aux données de fichiers locaux (spatialite) ou aux sockets unix (PostGIS) présente des avantages en termes de performances par rapport aux requêtes TCP ou HTTP (CouchDB, etc.), mais le fait d'avoir un index spatial fait toute la différence. J'utilise les mêmes arbres R mentionnés dans l'article de MongoDB, mais il y a beaucoup de bonnes options. La suite de topologies JTS comporte divers index spatiaux pour Java.
Cassandra est également une option pour les données spatiales:
http://www.readwriteweb.com/cloud/2011/02/video-simplegeo-cassandra.php
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
