gis - especificaciones - estructura de datos en mongodb
NoSQL y datos espaciales (7)
¿Alguno de ustedes ha tenido alguna experiencia con el uso de bases de datos NoSQL (no relacionales) para almacenar datos espaciales? ¿Hay algún beneficio potencial (velocidad, espacio, ...) de usar dichas bases de datos para almacenar datos para, por ejemplo, una aplicación de escritorio (en comparación con el uso de SpatiaLite o PostGIS)?
He visto publicaciones sobre el uso de MongoDB para datos espaciales , pero estoy interesado en alguna comparación de rendimiento.
Actualmente, MongoDB usa geohashing con B-trees que será más lento que los R-trees de PostGIS (no puedo dar números exactos, me temo, pero hay mucha literatura teórica sobre las diferencias). Sin embargo, en estas diapositivas, http://www.slideshare.net/nknize/rtree-spatial-indexing-with-mongodb-mongodc , el autor habla sobre agregar R-trees a MongoDB y sharding sobre una clave geográfica. Usted habla sobre el uso de computadoras de escritorio, por lo que puede que no interese el geosharding, ya que los beneficios de sharding se sentirán más en conjuntos de datos masivos. En última instancia, probablemente se deba más a lo que quiere hacer con sus datos espaciales. Postgis tiene muchas más funciones y soporte para topología, rásteres, 3D, conversiones entre sistemas de coordenadas, por lo que si esto es lo que está buscando, PostGIS aún sería la mejor opción. Si está interesado en almacenar miles de millones de objetos espaciales y simplemente ejecuta Basic encuentra todos los puntos cerca / dentro de este punto según algunos criterios, entonces MongoDB es probablemente una muy buena opción.
Cassandra también es una opción para datos espaciales:
http://www.readwriteweb.com/cloud/2011/02/video-simplegeo-cassandra.php
Couchdb también tiene una extensión espacial simple
He estado almacenando datos espaciales con ZODB. Hay una ventaja de rendimiento inherente en el acceso a datos de archivos locales (spatialite) o unix socket (PostGIS) en comparación con las solicitudes TCP o HTTP (CouchDB, etc.), sin duda, pero tener un índice espacial hace la mayor diferencia. Estoy usando los mismos árboles R mencionados en el artículo de MongoDB, pero hay muchas buenas opciones. El conjunto de topología JTS tiene varios índices espaciales para Java.
Las bases de datos de gráficos como Neo4j encajan muy bien, sobre todo porque puede agregar diferentes esquemas de indexación dinámicamente a medida que avanza. Las cosas típicas que puede hacer en sus datos base son, por supuesto, la indexación 1D (por ejemplo, Timline o B-Trees) o cosas más divertidas como Hilbert Curves, etc., consulte el blog de Nick . Además, para ver algunas demostraciones en vivo, consulte la herramienta de escritorio GIS de código abierto AWE here , el gráfico indexado subyacente será visible alrededor de las 07:00.
MarkLogic (Enterprise NoSQL) proporciona funcionalidad espacial. Este producto NoSQL proporciona a las aplicaciones GIS la capacidad de combinar múltiples objetos en una sola entidad. Esto proporciona soporte para la gestión de relaciones entre contenido estructurado y no estructurado, procedencia e información de pedigrí sobre los datos, información histórica y de línea de tiempo, etc. en una sola entidad.
Tarantool admite el índice bidimensional espacial (RTREE) con la búsqueda, superposición, contenido y otros operadores espaciales más cercanos. Tarantool mantiene todo el conjunto de datos en la memoria RAM, por lo que es la única base de datos en memoria OSS con soporte de índice espacial. https://github.com/tarantool/tarantool/wiki/R-tree-index-quick-start-and-usage