Дизайн категорий в Neo4j, отношения корневых узлов и отношения к индексированным узлам

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

Я рассматриваю несколько подходов:

  1. Узлы индексированных категорий. Создайте узлы для каждой категории и создайте auto_index для category_name. Затем создайте отношения «isCategoryOf» между каждым из моих узлов продукта и их соответствующими узлами категорий.

  2. Типы отношений отдельных категорий. Создайте соответствующие отношения «isCategoryGames», «isCategoryFood», «isCategoryLifestyle» и т. д. между продуктами и корневым узлом.

  3. Хранение категорий как свойства одного типа отношения. Создайте отношения «isCategory» между узлами продукта и корневым узлом и сохраните их соответствующие типы категорий в свойстве отношения, например. отношение "isCategory" {categoryName:"food"}

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


neo4j graph-databases
person MonkeyBonkey    schedule 12.03.2013    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Если вы присоедините к корневому узлу миллионы узлов, вы сделаете корневой узел суперузлом. Это может быть проблематично.

Общая концепция Варианта 1 многообещающая. Если вы моделировали еду, у вас могут быть узлы со свойством имени, например «Орехи», «Молочные продукты», «Десерты», «Продукты», и свойством типа «Категория». Затем у вас будут другие узлы со свойством имени, например «Вишневый чизкейк», с исходящими ребрами «категории» к узлам «Молочные продукты» и «Десерты».

Будет ли эта структура достаточно производительной, зависит от ваших запросов. Если у вас есть широкие категории, такие как «еда», вы можете получить суперузел, и вы будете линейно сканировать связанные узлы, чтобы найти узел с заданным свойством. Линейное сканирование тысяч элементов может быть достаточно быстрым для ваших целей, но сканирование 1 миллиона элементов может оказаться недостаточным.

Чтобы выяснить это, я бы порекомендовал создать быстрый прототип, в котором вы генерируете несколько случайных узлов продукта и категории, а затем соединяете каждый узел продукта со случайным числом узлов категории. Индексация узлов продукта и категории по имени поможет вам найти отдельные продукты или категории, но именно обходы вызовут проблемы с производительностью, если вы попадете в суперузлы. Поэкспериментируйте с несколькими обходами Gremlin или запросами Cypher, которые, по вашему мнению, могут быть наиболее проблематичными. Попробуйте увеличить количество узлов с 1K, 10K, 100K и 1M с пропорциональным количеством ребер. Как меняется время обхода/запроса?

person Bobby Norton    schedule 13.03.2013