Я использовал функции GeoSpatial от Mongo и могу предложить некоторые рекомендации, если вам нужна помощь с реализацией C # или javascript - я бы порекомендовал ее запустить, потому что она очень проста в использовании.Я узнаю все о Neo4j прямо сейчас и работаю над гибридным подходом, который использует преимущества как Mongo, так и Neo4j.Возможно, вы захотите связать документы в Mongo с узлами в Neo4j, используя идентификатор объекта Mongo.
Для моей гибридной реализации я храню профили и любые другие большие статические данные в Mongo.В Neo4j я храню отношения как друг и друг друга.Если я захочу проанализировать фильмы, то два друга, скорее всего, захотят посмотреть вместе (или на самом деле любые другие отношения, о которых я изначально не думал), сохраняя ссылку на идентификатор объекта, я могу просто добавить некоторый код, инструктирующий каждый узел выйти и схватитьсписок фильмов из соответствующего профиля.
Добавлено 2011-02-12:
Просто хотел развить эту «гибридную» идею, поскольку я создавал прототипы и реализовывалВ последнее время появилось еще несколько решений, в которых я использовал более одной базы данных.Мартин Фаулер называет это « Постоянство Полиглота ».
Я обнаружил, что я часто использую комбинацию реляционной базы данных, базы данных документов и графической базы данных (в моем случае это обычно SQL Server, MongoDB и Neo4j).Поскольку вопрос связан с моделированием данных в той же степени, что и с геопространственными, я подумал, что затрону этот вопрос здесь:
Я использовал Neo4j для организации сайта (аналогично идее гипермедиа в модели REST).), моделирование социальных данных и построение рекомендаций (часто основанных на социальных данных).В результате я, как правило, моделирую эту часть приложения, прежде чем приступить к программированию.
Я часто заканчиваю тем, что использую MongoDB для создания прототипа остальной части приложения, потому что он обеспечивает такой простой механизм персистентности.Мне нравится начинать разрабатывать приложения с пользовательским интерфейсом, так что в итоге все работает хорошо.
Когда я начинаю перемещать объекты из Mongo в SQL Server, обычно важен контекст - например, если у меня есть приложение, которое позволяет пользователям создавать ежедневные отчеты на основе периодически собираемых данных, может иметь смысл запускатьпроцедура, которая создает эти отчеты каждую ночь и сохраняет объекты ежедневных отчетов в Mongo, которые могут быть объединены в более крупные сводные отчеты по мере необходимости (очевидно, это не учитывает несколько особых случаев, но это не имеет отношения к делу) ... onс другой стороны, если пользователям необходимо получать отчеты по требованию, ограниченные очень конкретными периодами времени, может иметь смысл хранить все на сервере SQL и создавать эти отчеты по мере необходимости.
Тем не менее, и это заслуживает более интенсивного размышления, вот некоторые соображения, которые могут быть полезны:
- Обычно я пытаюсь сохранить сущности в реляционной базе данных, если обнаружу, что потянувобъект из базы данных [другими словами (в контексте реляционной базы данных) - запрос данных из базы данных, которая предоставляет данные, необходимые для генерации объекта или списка объектов, который удовлетворяет запрошенным параметрам], не требует значительной обработки (множественные объединенияНапример,
- Требуется ли соответствие ACID (кроме того: если у вас есть проблема с графиком, вы можете использовать Neo4j для этого)?Существуют базы данных документов с соответствием ACID, но есть причина, по которой Mongo не таков: Что на самом деле означает MongoDB, не совместимый с ACID?
Одно использование Mongo я видел в дикой природечто я считаю достойным упоминания - Hadoop использовался для вычисления больших хеш-таблиц, которые затем хранились в Mongo.Я полагаю, что аналогичный подход используется TripAdvisor для пользовательской настройки с точки зрения таргетинга предложений, рекламы и т. Д.