[Этот пост был изначально написан Майклом Голодом]
Обработка подключенных доменов с помощью «Правильного инструмента для работы»
Сара Мей
недавно написала отличное сообщение в блоге, описывающее проблемы, с которыми она и ее коллеги столкнулись при управлении данными с высокой степенью связи с использованием баз данных документов.
Базы данных документов (как и другие ориентированные на агрегаты базы данных ) хорошо справляются с хранением одного представления агрегированной сущности, но пытаются справиться с вариантами использования, которые требуют нескольких различных представлений домена. Обработка соединений между документами имеет тенденцию быть запоздалой мыслью, которая не очень хорошо отражается в модели совокупных данных.
Примеры использования в реальном мире
Сара рассказала, как она работала над приложением для телешоу в 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 и предложили свою помощь в то время — но теперь ландшафт изменился, и графические базы данных стали спорными. выбор.
Суди за себя
Если вы работаете в домене с богато связанными данными, мы рекомендуем вам попытаться смоделировать его как график и управлять им с помощью базы данных графиков. Для получения дополнительной информации о том, как это работает, не стесняйтесь обратиться к свободно доступной книге « Графические базы данных » О’Рейли.
Также предложение о поддержке диаспоры по-прежнему действует! Мы рады помочь, поэтому, пожалуйста, свяжитесь с нами, если вы заинтересованы. Вы также можете следить за
обсуждением с Сарой в Твиттере. Не стесняйтесь прыгать!