NoSQL y datos espaciales

Question

¿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 posts about using MongoDB for spatial data, pero estoy interesado en alguna comparación de rendimiento.

Answer 1

bases de datos de gráficos como Neo4j son una muy buena opción, especialmente ya que puede agregar diferentes esquemas de indexación dinámicamente sobre la marcha. 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 Nick's blog. 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.

Answer 2

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.

Answer 3

couchdb también tiene una extensión espacial sencilla

http://vmx.cx/cgi-bin/blog/index.cgi/category/CouchDB

Answer 4

Cassandra es también una opción para los datos espaciales:

http://www.readwriteweb.com/cloud/2011/02/video-simplegeo-cassandra.php

Answer 5

Actualmente, MongoDB utiliza geohashing con árboles B que será más lento que los árboles R 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 de agregar árboles R a MongoDB y fragmentar en 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.

Answer 6

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

Answer 7

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.