我使用过 Mongo 的 GeoSpatial 功能，如果您需要 C# 或 javascript 实现方面的帮助，我可以提供一些指导——我建议您开始使用它，因为它非常易于使用。我现在正在学习有关 Neo4j 的所有知识，并且正在研究一种利用 Mongo 和 Neo4j 的混合方法。您可能希望使用 Mongo 对象 ID 将 Mongo 中的文档交叉引用到 Neo4j 中的节点。
对于我的混合实现，我将配置文件和任何其他大型静态数据存储在 Mongo 中。在 Neo4j 中，我存储了朋友和朋友之类的关系。如果我想分析两个朋友最有可能一起看的电影（或者我最初没有想到的任何其他关系），通过保留该对象 ID 引用，我可以简单地添加一些代码，指示每个节点出去抓取来自相关配置文件的电影列表。
2011 年 2 月 12 日添加：
只是想跟进这个“混合”想法，因为我最近创建了原型并实施了更多解决方案，最终我使用了多个数据库。Martin Fowler 将此称为“多语言持久性”。
我发现我经常使用关系数据库、文档数据库和图形数据库的组合（在我的情况下，这通常是 SQL Server、MongoDB 和 Neo4j）。由于这个问题与数据建模和地理空间相关，我想我会在这里谈一谈：
我使用 Neo4j 进行站点组织（类似于 REST 模型中的超媒体概念）、对社交数据进行建模和构建推荐（通常基于社交数据）。因此，我通常会在开始编程之前对应用程序的这一部分进行建模。
我经常最终使用 MongoDB 对应用程序的其余部分进行原型设计，因为它提供了如此简单的持久性机制。我喜欢开始开发带有用户界面的应用程序，所以最终效果很好。
当我开始将实体从 Mongo 移动到 SQL Server 时，上下文通常很重要——例如，如果我有一个应用程序允许用户根据定期收集的数据构建每日报告，那么运行一个构建这些报告的过程可能是有意义的每晚并在 Mongo 中存储每日报告对象，这些对象可以根据需要组合成更大的聚合报告（显然这没有考虑一些特殊情况，但这与重点无关）......另一方面，如果用户需要在非常特定的时间段内提取按需报告，将所有内容保留在 SQL Server 中并根据需要构建这些报告可能是有意义的。
也就是说，这值得更深入的思考，这里有一些可能会有所帮助的注意事项：
- 如果我发现从数据库中提取实体[换句话说（在关系数据库的上下文中）-从提供生成实体或列表所需的数据的数据库中查询数据，我通常会尝试将实体存储在关系数据库中满足请求参数的实体] 不需要大量处理（例如，多个连接）
- 您是否需要 ACID 合规性（除此之外：如果您有图形问题，您可以利用 Neo4j 来解决这个问题）？有符合 ACID 的文档数据库，但 Mongo 不符合是有原因的：MongoDB 不符合 ACID 的真正含义是什么？
我在野外看到的 Mongo 的一种用途，我认为值得一提 - Hadoop 被用于计算大量哈希表，然后将这些哈希表存储在 Mongo 中。我相信 TripAdvisor 会使用类似的方法在定位优惠、广告等方面进行基于用户的定制。