Используя MongoDB в качестве нашей основной базы данных, я должен использовать отдельную базу данных графа для реализации отношений между сущностями?

Question

В настоящее время мы внедряем CRM-подобное решение внутри компании для профессиональной фирмы.В связи с характером хранимой информации и различными значениями и ключами информации мы решили использовать базу данных для хранения документов, так как она идеально подходила для целей (в данном случае мы выбрали MongoDB).

Как частьэтого CRM-решения мы хотим хранить отношения и ассоциации между организациями, например, хранение информации о конфликтах интересов, акционерах, доверенных лицах и т. д. Чтобы связать все эти объекты наиболее эффективным образом, мы определили, что необходима центральная модель «отношений»Все отношения должны иметь прикрепленную к ним информацию истории (даты начала и окончания), а также различные метаданные;например, отношения с акционерами также будут содержать количество принадлежащих акций.

Поскольку традиционные решения СУБД не удовлетворяли нашим прежним потребностям, их использование в нашей текущей ситуации нецелесообразно.Я пытаюсь определить, является ли использование графической базы данных более уместным в нашем случае, или действительно ли уместно использовать только встроенную реляционную информацию mongo.

Информация об отношениях будет использоваться довольносильно по всей системе.Пример некоторых информационных запросов, которые мы хотим выполнить:

• Получить всех «ключевых контактов» людей из компаний, которые являются «клиентами» «xyz limited»
• Получить вседругие «акционеры» компаний, в которых «Джон» является акционером
• Получить всех «ключевых контактных лиц» лиц, которые являются «клиентами» abc limited и клиентами «trust us bank limited»

Учитывая эту «древовидную» структуру отношений, является ли использование базы данных графов (такой как Neo4j) более подходящим?

Answer 1

Mike

вы должны иметь возможность хранить данные о ваших отношениях в базе данных графа. Его высокая производительность при обходе больших графиков происходит из локальности, то есть вы не выполняете запросы глобально, а скорее запускаете набор узлов (которые равны документам в вашем случае, которые ищутся по индексу. Вы можете даже сохранить start-node- идентификаторы для быстрого доступа в ваших документах Монго). Оттуда вы можете проходить произвольно большие пути в постоянное время (относительно размера набора данных).

Каковы ваши другие требования (например, размер набора данных, число одновременных обращений и т. Д., Сложность отношений / графа).

Ваши запросы действительно хорошо подходят для графической базы данных и легко выражаются в ее терминах.

Я бы посоветовал вам просто взять GraphDB, например, neo4j, и быстро прокрутить свой домен, чтобы проверить общую выполнимость, а также найти дополнительные вопросы, на которые вы хотели бы ответить, прежде чем инвестировать во вторую технологию.

P.S. Если вы еще не начали, вы могли бы также использовать чистый подход graphdb, так как графовые базы данных - это расширенный набор баз данных документов. И в любом случае вы предпочитаете говорить о домене, а не просто общие документы. (Например, structr - это CMS, построенная поверх Neo4j).

Answer 2

Документы в MongoDB очень похожи на узлы в Neo4j, за исключением отношений. Они оба содержат свойства ключ-значение. Если вы уже сделали выбор в пользу MongoDB, вы можете использовать Neo4j для хранения отношений, а затем связать хранилища в вашем приложении. Если вы выбираете новую технологию, вы можете использовать Neo4j для всего, так как узлы могут хранить данные свойств так же, как и документы.

Что касается отношений, Neo4j отлично подходит. У вас есть график, а не связанные документы. Использование базы данных графов здесь имеет смысл, и примеры запросов имеют граф, написанный на них.

Честно говоря, лучший способ выяснить, что работает для вас, это сделать PoC - низкая стоимость, высокая стоимость.

Отказ от ответственности: я работаю в Neo Technology.

Answer 3

В итоге мы использовали оба, мы внедрили поисковую систему для транспортной сети.

Попытка реализовать отношения в MongoDB может стать громоздкой, если вы выйдете за 1 или 2 «ссылки». По сути, вы будете хранить объекты в массиве, и если вы хотите реализовать двунаправленные отношения, то вы должны реализовать две отдельные ссылки. В Mongo «указатель» на сущность (или «ссылка») - это просто другое текстовое свойство (которое можно интерпретировать по-разному), это не объект первого класса, как отношение в Neo4j.

Поэтому мы решили использовать Neo4j для хранения отношений и MongoDB для хранения всего остального. Задача состояла в том, чтобы синхронизировать два магазина.

Мы используем 10gen лабораторный проект под названием «MongoConnector», который является механизмом для синхронизации MongoDB с другим хранилищем. Проект в настоящее время не поддерживается, но код доступен:

http://blog.mongodb.org/post/29127828146/introducing-mongo-connector

MongoConnector использует механизм реплики для реализации синхронизации. По сути, вы отслеживаете OpLog MongoDB и реализуете обратные вызовы для любых изменений (обновления или вставки) и удаления. Эта реализация называется «DocumentManager» на языке MongoConnector. Мы закончили реализацию Neo4jDocumentManager.

Что касается запроса, мы обнаружили, что Neo лучше подходит для запросов типа «друг друга», тогда как MongoDB лучше подходит для запросов общего назначения, т.е. по каждому полю или диапазону запросов, связанных с датами.

Я планировал поговорить и написать в блоге, но пока не дошел:

http://www.meetup.com/graphdb-boston/events/91703472/

У этого решения есть недостатки, такие как отсутствие синхронизации в случае остановки процесса или медленная синхронизация (не в реальном времени).

Answer 4

остаться с mongodb. Две причины - 1. лучше оставаться в одном домене, если вы можете уменьшить сложность, и 2. mongodb отлично подходит для запросов и требует меньше работы, чем, например, redis.