данных Neo4j: частные, принадлежащие узлы, богатые отношения, замки

Question

Версии, используемые: Neo4j 3.0.6 с Спринг-данные Neo4j 4.2.0.M1 для отображения POJO

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

Требования:

• видеофильма динамический список метаданных (метаданными имеет 3 свойства: 'ключ', 'значение', 'локали). Количество метаданных для фильма неизвестно заранее, и не являются возможными ключами. Они должны быть отделены от других технических свойств фильма, поскольку они локализованы и рассматриваются как бизнес-данные.
• Метаданные принадлежат фильму и всегда доступны из фильма. Они не могут быть разделены с другими фильмами
• быстрого извлечения запросов должно быть возможным по метаданным значения

Movie пример метаданных:

Movie metadata 
    locale 'en_GB': 
    title: 'Jurassic Park' 
    description: 'description in english' 
    locale 'fr_FR': 
    description: 'description en francais' 
    locale 'none': 
    actor: 'Jeff Goldblum' 

Раствор А

• Один узел в метаданные (с 3 свойствами на узел: 'ключ', 'значение', 'локаль')
• Минус: частной концепция быть реализован (удаление бесхозных узлов метаданных будут управляться вручную, так как не поддерживается пружинные данные Neo4j/Neo4j-ОГМ)

Раствор B

• Один уникальный узел на местности (с 1 свойством: «локали») (например: «en_GB»)
• Метаданные, как богатые отношения (с 2 Проперти отношений эс: «ключ», «значение»)
• Минуса: создать отношения, замок необходимо принимать на Locale узле

ли кто-то имеет опыт относительно решения B? Насколько плохо нужно блокировать узел, который будет использоваться миллионами других узлов? Какое влияние оказывает на производительность и масштабируемость? ?

У кого-то есть лучшее решение для моделирования?

Answer 1

Т.Л., доктор: идти с подходом А. Не заморачиваться с сиротами :Locale узлов для периодической очистки, за исключением, что они не будут иметь никакого влияния на производительность запросов.

Ваш подход «А» на сегодняшний день является лучшим решением. Вам нужно переместить эти данные с узла :Movie, вы правы, потому что это должна быть либо вложенная Карта, либо список карт, ни один из которых не поддерживается свойствами узла. Для хранения вы можете преобразовать их в карту списков, но это будет очень сложно запросить, а тем более - быстрее. Ваша озабоченность по поводу «осиротевших» узлов несущественна; это будет влиять на производительность запросов и размер данных тривиально, если вообще, и невероятно легко очистить периодически, чтобы облегчить ваш разум в любом случае.

MATCH (x:Locale) WHERE NOT (x) <- [:METADATA] -() DETACH DELETE x 

Выполняйте это раз в месяц, или даже никогда, это действительно не сильно повлияет на вас. Ваш запрос уже ограничен остальной частью пути, поэтому, если не осиротевшие :Locale узлы будут превосходить по размеру прикрепленные, по существу, вы добавляете лишь небольшой процент к тому, что, скорее всего, самый большой набор в вашем запросе, который также будет удален по операции запроса на первом проходе.

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

Answer 2

Вы можете просто хранить «метаданные» непосредственно как свойства каждого Movie узла (не прибегая к key и value). Это самый простой подход, который позволяет избежать проблем с блокировкой и минимизирует количество узлов и требуемых отношений. Вы можете в любое время добавить дополнительные свойства к узлу. Этот подход также позволит вам добавлять индексы для определенных свойств Movie, которые вам нужно быстро получить при отправке запросов.

Например:

CREATE (m:Movie {id: 123, title: 'Men in black', director: 'Barry Sonnenfeld'}); 

[UPDATE]

Если вам нужно держать «метаданные» чисто отделенные от ваших «данных», и вы также должны быть в состоянии локализовать метаданные (включая спецификация свойства locale), то вы можете связать каждый узел Movie с одним узлом Metadata для каждого языкового стандарта. A Metadata узел будет напрямую содержит все свойства метаданных для одного языкового стандарта для определенного узла Movie.

Cypher может использоваться для выполнения «каскадных удалений». Например:

MATCH (m:Movie {id: 123}) 
OPTIONAL MATCH p=(m)-->() 
DELETE p;