Pull to refresh
Comments 45
А он может искать пути только по определенным связям?
Например используя только «IN», но избегая «MARRIED»?
Что же плохого? Вы можете делать множество связей разных типов и искать для конкретных задач, только по заданным.
В какой-нибудь конкретной задаче может понадобиться поиск по нескольким связям.
Пример с потолка: родственные связи (родитель, ребёнок, брат) и поиск всех родственников до Nого колена.
Ну вот в статье этого не оражено, и в документации сходу не находится.
Какие параметры поиска путей есть?
А с какими объемами данных приходилось работать используя эту субд?
Лично мне приходилось пока работать с данными порядка тысяч узлов/связей. Но по уверениям разработчиков база может работать с несколькими миллиардами узлов, связей, параметров на одной машине, а так же может быть масштабирована на множество машин.
Порядка 27 млн связей и нод, но ноды и связи без свойств, только идентификаторы. По идентификаторам нод и связей создавался индекс Lucene. Размер идентификатора порядка 30-40 байт в виде NODE_TYPE.Размер на диске (база+индексы) ~16 гигабайт. Импорт выполняется из JSON с использованием BatchInserter примерно за 40 минут, но с проверкой существования в базе идентификатора, т.е. импорт без такой логики будет быстрей.
приятная новость,
когда я изучал рынок NoSQL, neo4j не имела драйвера РНР и я ее отбросил на потом…
видно это потом уже настало :()
Графовые БД — это очень и очень круто, просто руки чешутся попробовать, но:

1. Как там насчет пакетного сохранения данных, транзакций?
2. Бенчмарки есть?
3. Что с масштабированием?
4. Как ведет себя с большими объемами данных?
1. Транзакции есть. Может быть в следующих статьях получится написать об этом.
2. Тут многое зависит от задачи, но очевидно, что она очень быстра по сравнению с SQL, в тех случаях когда данные легко описываются графом и имеют много связей. Конкретных цифр у меня нет. Кому интересна тема, есть презентация www.slideshare.net/thobe/nosqleu-graph-databases-and-neo4j там есть некоторые цифры.
3, 4. Как выше я отмечал в комментарии, производители заверяют о хорошем механизме масштабирования на множество машин и быструю работу с большими объёмами.
> Как выше я отмечал в комментарии, производители заверяют о хорошем механизме масштабирования на множество машин и быструю работу с большими объёмами

Да что вы говорите)
Графовые базы данных с поддержкой алгоритмов траверсинга (поиск кратчайшего пути и пр.) в принципе не масштабируются горизонтально. Neo4J тут не исключение.

Если траверсинг не нужен и нужен только поиск на глубину одной связи, то масштабироваться горизонтально просто. Пример — FlockDB.

Neo4J умеет лишь реплицироваться, и то только в версии с коммерческой лицензией. Master-Master там или Active-Passive я не помню, подозреваю последнее.
Спасибо за полезный комментарий. Я лишь сказал, что разработчики написали на своём сайте neo4j.org/learn/
У меня нет опыта в масштабировании Neo4J, поэтому если вы знаете об этом на личном опыте, было бы интересно послушать в развернутом виде.
"""
свойство может быть только одим из двух типов: строкой или числом.
"""
что, даже дат нету?
в PHP драйвере нет, даты можно хранить в timestamp, если же говорить о использовании neo4j в Java, а именно на нём он написан, то там можно хранить данные любых типов, доступных в Java.
А… таки строки и числа — это ограничения пхп!
Чтоли бы как-нить акцентиоовали на этом в тексте, а то натурально, на всю базу тень бросет.
Я даже думаю, что это ограничение не PHP, а REST интерфейса.
ну это как-то сомнительно, либо крайне неадекватно.
таки нету.
поддерживаются только примитивы жавы: boolean, 8/16/32/64 int, 32/64 float, ucs16 char, ucs16 string
OSM не использует.
Просто есть модуль Neo4j Spatial, к которому дописали код, позволяющий быстро импортировать OSM данные.
Пробовали, API удобное, но получалось достаточно медленно (тестировали 1-2 года назад, может быть что-то поменялось уже)
медленные сами запросы, или графовые алгоритмы?
Запросы, естественно. Алгоритмы можно переписать — это не проблема. Сравнивали обычную Дейкстру на двух разных БД. Более того общались напрямую с Peter Neubauer и, к сожалению, даже после их рекомендаций скорость оставалась неприемлимой.
Так графовые алгоритмы же там «встроенные».
Тоесть, по построению, используют специально оптимизированную под это внутреннюю сруктуру данных.
Или вы и переписывали прямо в реализации базы?
Вы посмотрите код. Что там специального для Дейкстры? Только получение следующих нод из текущей, связанных отношением (отношение – «дорога» в данном случае). Естественно для этого пользовались функциями Neo4J.
Возможно ли автоматическое удаление связанных записей и ограничение количества связей для одной записи?
полагаю если возможно получить все связи одного нода, то на уровне кода можно сделать удаление связанных записей.
Меня интересует именно встроенная поддержка.
А вот если бы вы в примере с фильмами и актёрами использовали связи типа «out», то есть не «актёр снимался в таком-то фильме», а наоборот «в фильме снимались такие-то актёры» — в этом случае время поиска по графу изменилось бы?

Вообще, как выбирать направленность связи? Понимаю, что в зависимости от предметной области, но хотелось бы более развёрнутой информации на эту тему.

Почему спрашиваю? Потому что зацепило вот это предложение: «В тоже время между узлами могут быть множественные отношения направленные в обе стороны.»
Когда нужны двунаправленные связи? В каких ситуациях это даёт выигрыш?
По сути куда бы не была направлена связь, алгоритм обхода графа от этого не меняется соответственно и по скорости разница не заметна. Это нам даёт простор в написании самих запросов, как нам удобнее написать запрос: «актёр снимался в таком-то фильме», или «в фильме снимались такие-то актёры» так и делаем связь.
Опять же, 1-2 года назад были несколько файликов, которые хранили отдельно ноды, атрибутику, связи + Lucene, который индексировал всё что скажете и делал полнотекстный поиск. Легче всего взять примерчик и запустить это дело у себя — он создаст штук 10 файликов — там по названиям всё в общем-то понятно было.
А торжество изобретательской мысли по оптимизации хранения графов там увидеть можно?
Вот этого не помню честно говоря. Я тогда игрался с большим количеством графовых БД – не всё запомнил точно.
Only those users with full accounts are able to leave comments. Log in, please.