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

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

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

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

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

Получить всех "ключевых контактов" людей из компаний, которые являются "клиентами" из "xyz limited"
Получить всех других "акционеров" компаний, где "john" является акционером.
Получите все "ключевые контакты" с людьми, которые являются "клиентами" с "abc limited" и являются клиентами "доверять нам ограниченным банком".

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

Ответ 1

Майк,

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

MongoConnector использует механизм реплики для реализации синхронизации. По сути, вы контролируете MongooDB OpLog и реализуете обратные вызовы для любых upserts (обновление или вставка) и удаляет. Эта реализация называется "DocumentManager" в MongoConnector. Мы завершили внедрение Neo4jDocumentManager.

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

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

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

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