NoSQL 和空间数据
你们中有人有过使用NoSQL（非关系型）数据库存储空间数据的经验吗？使用此类数据库来保存桌面应用程序的数据（与使用 SpatiaLite 或 PostGIS 相比）是否有任何潜在的好处（速度、空间……）？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
你们中有人有过使用NoSQL（非关系型）数据库存储空间数据的经验吗？使用此类数据库来保存桌面应用程序的数据（与使用 SpatiaLite 或 PostGIS 相比）是否有任何潜在的好处（速度、空间……）？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（7）
像 Neo4j 这样的图形数据库非常适合，特别是当您可以动态添加不同的索引方案时。您可以对基础数据执行的典型操作当然是一维索引（例如 Timline 或 B-Trees）或更有趣的操作，例如希尔伯特曲线等，请参阅 此处，底层索引图是时间 07:00 左右可见。
graphs databases like Neo4j are a very good fit, especially as you can add different indexing schemes dynamically as you go. Typical stuff you can do on your base data is of course 1D indexing (e.g. Timline or B-Trees) or funkier stuff like Hilbert Curves etc, see Nick's blog. Also, for some live demonstration, look at the AWE open source GIS desktop tool here, the underlying indexed graph being visible around time 07:00 .
目前，MongoDB 使用 B 树进行地理散列，这比 PostGIS 的 R 树慢（恐怕我无法给出确切的数字，但有大量关于差异的理论文献）。但是，在这些幻灯片中， http://www.slideshare.net /nknize/rtree-spatial-indexing-with-mongodb-mongodc 作者讨论了将 R 树添加到 MongoDB 并在地理键上进行分片。您谈论的是桌面使用，因此地理分片可能不会引起您的兴趣，因为分片的好处在海量数据集上会更明显。
最终，它可能更多地取决于您想要如何处理空间数据。 Postgis 具有更多的功能并支持拓扑、栅格、3D、坐标系之间的转换，因此如果这就是您所寻找的，PostGIS 仍然是最佳选择。如果您有兴趣存储数十亿/万亿的空间对象，并且只是根据某些标准运行基本查找该点附近/内部的所有点，那么 MongoDB 可能是一个非常好的选择。
Currently, MongoDB uses geohashing with B-trees which will be slower than the R-trees of PostGIS (I can't give exact numbers, I'm afraid, but there is plenty of theoretical literature on the differences). However, in these slides, http://www.slideshare.net/nknize/rtree-spatial-indexing-with-mongodb-mongodc the author talks about adding R-trees to MongoDB and sharding on a geo key. You talk about desktop use, so geosharding may not be of interest, as sharding's benefits will be felt more on massive datasets.
Ultimately, it probably comes down more to what you want to do with your spatial data. Postgis has vastly more functions and support for topology, rasters, 3D, conversions between coordinate systems, so if this is what you are looking for, PostGIS would still be the best option. If you are interested in storing billions/trillions of spatial objects and just running basic find all points near/inside this point based on some criteria, then MongoDB is likely a very good choice.
Couchdb 还有一个简单的空间扩展
http://vmx.cx/cgi- bin/blog/index.cgi/category/CouchDB
Couchdb also has a simple spatial extension
http://vmx.cx/cgi-bin/blog/index.cgi/category/CouchDB
我一直使用 ZODB 存储空间数据。与 TCP 或 HTTP 请求（CouchDB 等）相比，访问本地文件数据（spatialite）或 unix 套接字（PostGIS）当然有一些固有的性能优势，但拥有空间索引会带来最大的区别。我使用 MongoDB 文章中提到的相同 R 树，但还有很多不错的选择。 JTS 拓扑套件具有 Java 的各种空间索引。
I've been storing spatial data with ZODB. There's some inherent performance advantage in accessing local file data (spatialite) or unix socket (PostGIS) compared to TCP or HTTP requests (CouchDB etc), surely, but having an spatial index makes the biggest difference. I'm using the same R-trees mentioned in the MongoDB article, but there are plenty of good options. The JTS topology suite has various spatial indexes for Java.
Cassandra 也是空间数据的一个选项：
http://www. readwriteweb.com/cloud/2011/02/video-simplegeo-cassandra.php
Cassandra is also an option for spatial data:
http://www.readwriteweb.com/cloud/2011/02/video-simplegeo-cassandra.php
Tarantool 支持具有最近邻搜索、重叠、包含和其他空间运算符的空间二维索引 (RTREE)。 Tarantool 在 RAM 中维护整个数据集，使其成为唯一支持空间索引的 OSS 内存数据库。
https://github.com/tarantool/tarantool /wiki/R-tree-index-快速启动和使用
Tarantool supports spatial two-dimensional index (RTREE) with nearest neighbor search, overlaps, contains, and other spatial operators. Tarantool maintains the entire data set in RAM, making it the only OSS in-memory database with spatial index support.
https://github.com/tarantool/tarantool/wiki/R-tree-index-quick-start-and-usage
MarkLogic（企业NoSQL）提供空间功能。这一 NoSQL 产品为 GIS 应用程序提供了将多个对象合并为一个实体的能力。这为在单个实体中管理跨结构化和非结构化内容、有关数据的出处和谱系信息、历史和时间线信息等的关系提供了支持。
MarkLogic(Enterprise NoSQL) provides spatial functionality. This NoSQL product provides GIS applications the ability to conflate multiple objects into one entity. This provides support for managing relationships across structured and unstructured content, provenance and pedigree information about the data, historic and timeline information, etc. in a single entity.