Статьи

Почему графовые базы данных – лучший инструмент для обработки связанных данных, как в диаспоре

[Этот пост был изначально написан Майклом Голодом]

Обработка подключенных доменов с помощью «Правильного инструмента для работы»

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

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

Примеры использования в реальном мире

Сара рассказала, как она работала над приложением для телешоу в Pivotal, и обсудила последствия моделирования и управления данными, которые возникли, когда изменился сценарий использования приложения.

То же самое применимо при работе над проектом Diaspora, который начинался как приложение Ruby on Rails с использованием MongoDB.

Для обоих проектов эти требования вызвали трудности с выбранной моделью данных и базой данных, что привело к переходу на PostgreSQL. Была выбрана реляционная база данных, поскольку она позволила вернуть некоторую точность в модели.

К сожалению, это происходит за счет обработки запросов с большим количеством JOINS, которые могут вызвать проблемы с производительностью.

К счастью, существует модель данных, которая охватывает богатые связи между объектами вашего домена: графовые базы данных.

Живой график данных моделей диаспоры и телешоу

Чтобы показать, как графическая база данных будет обрабатывать эти сценарии использования, мы создали две модели данных в реальном времени для социальной сети, такой как Diaspora и TV-Show . Для этого мы создали небольшой примерный набор данных и затем представили сценарии использования, которые она упомянула, как набор поисковых запросов графа с языком запросов графа Cypher . Эти GraphGists позволяют легко обсуждать моделирование и оперативно исследовать набор данных и варианты использования и обеспечивают хорошую отправную точку для вашего собственного (раздвоенного) варианта модели предметной области.

Пример графической модели — телешоу

Чтобы быстро разработать модели, мы используем типичные шаблоны, которые мы ищем на графике при ответе на описанные варианты использования. Мы называем это удобством для доски 🙂

Шоу, сезоны и эпизоды

 (:TVShow)-[:HAS_SEASON]->(:Season)-[:HAS_EPISODE]->(:Episode)

Персонажи, сыгранные актерами, показанными в эпизоде

(:Episode)  -[:FEATURED_CHARACTER]->(:Character),

(:Character)<-[:PLAYED_CHARACTER ]- (:Actor)

Пользователи пишут обзоры для отдельных эпизодов

(:User)-[:WROTE_REVIEW]->(:Review)<-[:HAS_REVIEW]-(:Episode)

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

Перечисление всех эпизодов (фильмография) актера через эпизоды и шоу

MATCH

(actor:Actor)-[:PLAYED_CHARACTER  ]->(character),

(character) <-[:FEATURED_CHARACTER]- (episode),

(episode)-[*]->(show:TVShow)

WHERE actor.name = "Josh Radnor"

RETURN show.name, episode.name, character.name

Пожалуйста, проверьте это более подробно в модели живого графа.

Пример графической модели — социальная сеть

Пользователи, друзья, посты

 (:User)-[:FRIEND]->(:User)-[:POSTED]->(:Post)

Посты, комментарии и комментаторы

 (:User)-[:POSTED]->(:Post)<-[:COMMENTED]-(:User)

Пользователи любят посты

 (:User)-[:LIKED]->(:Post)

Найти сообщения от друзей Рэйчел

MATCH (u:User)-[:FRIEND]-(f)-[:POSTED]->(post)

WHERE u.name = "Rachel Green"

RETURN f.name AS friend, post.text as content

Список людей, которые прокомментировали сообщения от друзей Рэйчел

MATCH (u:User)-[:FRIEND]-(f)-[:POSTED]->(post)<-[:LIKED]-(liker)

WHERE u.name = "Rachel Green"

RETURN f.name AS friend, post.text as content,
 COLLECT(liker.name) as liked_by

Пожалуйста, проверьте это более подробно в модели живого графа .

Граф Базы данных как нишевая технология?

Как видите, моделирование этих сценариев использования невероятно легко с помощью графической базы данных. Так почему они не были рассмотрены? Цитировать из статьи:

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

Это интересное наблюдение, поскольку Neo4j является наиболее широко используемой графовой базой данных и работает в производственных установках уже более 10 лет. У Neo Technology более 100 платящих клиентов (30 из которых — компании Global 2000), а десятки тысяч пользователей сообщества развернули Neo4j в качестве базы данных для поддержки производственных приложений. Отрасли этих вариантов использования охватывают все: от управления сетями, игр, социальных сетей, финансов, поиска работы до логистики и сайтов знакомств.

Мы можем понять, почему некоторые люди чувствовали, что графические базы данных были нишевой технологией в 2010 году, когда Диаспора была запущенамы фактически поддержали Диаспору на Kickstarter и предложили свою помощь в то время — но теперь ландшафт изменился, и графические базы данных стали спорными. выбор.

Суди за себя

Если вы работаете в домене с богато связанными данными, мы рекомендуем вам попытаться смоделировать его как график и управлять им с помощью базы данных графиков. Для получения дополнительной информации о том, как это работает, не стесняйтесь обратиться к свободно доступной книге « Графические базы данных » О’Рейли.

Также предложение о поддержке диаспоры по-прежнему действует! Мы рады помочь, поэтому, пожалуйста, свяжитесь с нами, если вы заинтересованы. Вы также можете следить за
обсуждением с Сарой в Твиттере. Не стесняйтесь прыгать!