Увеличивает ли добавление ребер в Neo4j обработку, необходимую для всех запросов?

Я пытаюсь разработать схему базы данных для Neo4j. Есть несколько способов сделать это. Я мог бы поместить данные как 1) свойства узла или 2) как ребра, указывающие на узел. Второй вариант намного мощнее с точки зрения того, как я могу запрашивать данные, и предпочтительнее, поскольку он не создает недостатков в производительности.

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

Есть ли здесь какие-то методы оптимизации?

Сколько памяти используют ребра и свойства?


neo4j graph-databases graph-traversal graph-theory database-optimization
person Joshua Zeidner    schedule 01.11.2017    source источник
comment
Имейте в виду, что различные типы ребер (и направления) помогают снизить сложность. Если у вас есть 100 ребер типа A и 2 ребра типа B из узла, запрос только ребер типа B не будет проходить через ребра типа A. Точно так же запрос ребер в одном направлении не будет проходить по ребрам, идущим в другом направлении.   -  person InverseFalcon    schedule 01.11.2017
comment
Итак, скажем, в вашем примере у меня была одна БД со 100 типом A и другая БД (та же схема) с 1 000 000 типа A. Будет ли запрос типа B (как вы описываете) медленнее во второй БД?   -  person Joshua Zeidner    schedule 01.11.2017
comment
Нет, количество несовпадающих отношений не повлияет на запрос. Должен существовать механизм сопоставления, который учитывает отношения только желаемого типа и направления, и на него не будет влиять любое количество несовпадающих отношений.   -  person InverseFalcon    schedule 02.11.2017
comment
это, безусловно, тот ответ, который я ищу, и я благодарен за это, за исключением слова «должен». Мы не уверены, что именно так работает Neo4j?   -  person Joshua Zeidner    schedule 02.11.2017
comment
Я полагаю, что есть изменения в том, как отношения оцениваются из узла в зависимости от количества отношений. В последний раз я проверял, что порог равен 50. Ниже этого значения итерация отношений будет проверять тип и направление (перед расширением). Над этим будет использоваться сопоставление. Вы можете проверить это самостоятельно, довольно легко создать узел и запустить пару запросов, чтобы добавить 100 000 отношений за один раз (используйте UNWIND range(1,100000) as index перед созданием отношений), затем добавьте несколько других и запросите несколько . Низкое количество попаданий в БД, малое время выполнения.   -  person InverseFalcon    schedule 02.11.2017

Ответы (1)


arrow_upward
1
arrow_downward

Я постараюсь ответить на ваши вопросы один за другим.

  1. Будет ли количество ребер замедлять запросы, даже если эти ребра не участвуют в запросе?

    Да, только если ваш запрос увеличил количество количества элементов. А использование разных лейблов может ускорить поиск. Поэтому убедитесь, что вы хорошо спроектировали свою схему.

  2. Есть ли здесь какие-то методы оптимизации?

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

  3. Сколько памяти используют ребра и свойства?

    из блога мы можем узнать размер хранилища каждый из них занимает.

    Узлы - 14Б

    Отношения(ребра) - 33Б

    Недвижимость - 41Б

Надеюсь это поможет!

person techie95    schedule 01.11.2017
comment
Сам запрос не будет пересекать ребра, которые меня не интересуют. Хотя ваш ответ расширил мои знания, он на самом деле не касался вопроса напрямую. Если у меня есть ребра, которые будут пройдены в запросе, могут ли они каким-то образом повлиять на производительность? - person Joshua Zeidner; 01.11.2017
comment
Да. Попробуйте обозначить их уникальным образом. Тогда производительность можно улучшить. - person techie95; 02.11.2017