Комментарии 45
А он может искать пути только по определенным связям?
Например используя только «IN», но избегая «MARRIED»?
Например используя только «IN», но избегая «MARRIED»?
да
плохо.
А с какими объемами данных приходилось работать используя эту субд?
Лично мне приходилось пока работать с данными порядка тысяч узлов/связей. Но по уверениям разработчиков база может работать с несколькими миллиардами узлов, связей, параметров на одной машине, а так же может быть масштабирована на множество машин.
Порядка 27 млн связей и нод, но ноды и связи без свойств, только идентификаторы. По идентификаторам нод и связей создавался индекс Lucene. Размер идентификатора порядка 30-40 байт в виде NODE_TYPE.Размер на диске (база+индексы) ~16 гигабайт. Импорт выполняется из JSON с использованием BatchInserter примерно за 40 минут, но с проверкой существования в базе идентификатора, т.е. импорт без такой логики будет быстрей.
приятная новость,
когда я изучал рынок NoSQL, neo4j не имела драйвера РНР и я ее отбросил на потом…
видно это потом уже настало :()
когда я изучал рынок NoSQL, neo4j не имела драйвера РНР и я ее отбросил на потом…
видно это потом уже настало :()
Графовые БД — это очень и очень круто, просто руки чешутся попробовать, но:
1. Как там насчет пакетного сохранения данных, транзакций?
2. Бенчмарки есть?
3. Что с масштабированием?
4. Как ведет себя с большими объемами данных?
1. Как там насчет пакетного сохранения данных, транзакций?
2. Бенчмарки есть?
3. Что с масштабированием?
4. Как ведет себя с большими объемами данных?
1. Транзакции есть. Может быть в следующих статьях получится написать об этом.
2. Тут многое зависит от задачи, но очевидно, что она очень быстра по сравнению с SQL, в тех случаях когда данные легко описываются графом и имеют много связей. Конкретных цифр у меня нет. Кому интересна тема, есть презентация www.slideshare.net/thobe/nosqleu-graph-databases-and-neo4j там есть некоторые цифры.
3, 4. Как выше я отмечал в комментарии, производители заверяют о хорошем механизме масштабирования на множество машин и быструю работу с большими объёмами.
2. Тут многое зависит от задачи, но очевидно, что она очень быстра по сравнению с SQL, в тех случаях когда данные легко описываются графом и имеют много связей. Конкретных цифр у меня нет. Кому интересна тема, есть презентация www.slideshare.net/thobe/nosqleu-graph-databases-and-neo4j там есть некоторые цифры.
3, 4. Как выше я отмечал в комментарии, производители заверяют о хорошем механизме масштабирования на множество машин и быструю работу с большими объёмами.
> Как выше я отмечал в комментарии, производители заверяют о хорошем механизме масштабирования на множество машин и быструю работу с большими объёмами
Да что вы говорите)
Графовые базы данных с поддержкой алгоритмов траверсинга (поиск кратчайшего пути и пр.) в принципе не масштабируются горизонтально. Neo4J тут не исключение.
Если траверсинг не нужен и нужен только поиск на глубину одной связи, то масштабироваться горизонтально просто. Пример — FlockDB.
Neo4J умеет лишь реплицироваться, и то только в версии с коммерческой лицензией. Master-Master там или Active-Passive я не помню, подозреваю последнее.
Да что вы говорите)
Графовые базы данных с поддержкой алгоритмов траверсинга (поиск кратчайшего пути и пр.) в принципе не масштабируются горизонтально. Neo4J тут не исключение.
Если траверсинг не нужен и нужен только поиск на глубину одной связи, то масштабироваться горизонтально просто. Пример — FlockDB.
Neo4J умеет лишь реплицироваться, и то только в версии с коммерческой лицензией. Master-Master там или Active-Passive я не помню, подозреваю последнее.
Спасибо за полезный комментарий. Я лишь сказал, что разработчики написали на своём сайте neo4j.org/learn/
У меня нет опыта в масштабировании Neo4J, поэтому если вы знаете об этом на личном опыте, было бы интересно послушать в развернутом виде.
У меня нет опыта в масштабировании Neo4J, поэтому если вы знаете об этом на личном опыте, было бы интересно послушать в развернутом виде.
Вот видео с прошлогодней конференции в Киеве
Выступает разработчик этой БД
jeeconf.com/archive/jeeconf-2011/materials/graph-db/
Выступает разработчик этой БД
jeeconf.com/archive/jeeconf-2011/materials/graph-db/
"""
свойство может быть только одим из двух типов: строкой или числом.
"""
что, даже дат нету?
свойство может быть только одим из двух типов: строкой или числом.
"""
что, даже дат нету?
Интересно, а к ГИС применять это пробовали?
OSM вроде бы использует.
ага.
вот тут ужасного качества видео презентация:
www.youtube.com/watch?v=I0bTa5Kp7Wg
вот тут слайды:
www.oscon.com/oscon2011/public/schedule/detail/19822
вот тут ужасного качества видео презентация:
www.youtube.com/watch?v=I0bTa5Kp7Wg
вот тут слайды:
www.oscon.com/oscon2011/public/schedule/detail/19822
OSM не использует.
Просто есть модуль Neo4j Spatial, к которому дописали код, позволяющий быстро импортировать OSM данные.
Просто есть модуль Neo4j Spatial, к которому дописали код, позволяющий быстро импортировать OSM данные.
Пробовали, API удобное, но получалось достаточно медленно (тестировали 1-2 года назад, может быть что-то поменялось уже)
медленные сами запросы, или графовые алгоритмы?
Запросы, естественно. Алгоритмы можно переписать — это не проблема. Сравнивали обычную Дейкстру на двух разных БД. Более того общались напрямую с Peter Neubauer и, к сожалению, даже после их рекомендаций скорость оставалась неприемлимой.
Возможно ли автоматическое удаление связанных записей и ограничение количества связей для одной записи?
я просто оставлю это тут http://en.wikipedia.org/wiki/Graph_database
А вот если бы вы в примере с фильмами и актёрами использовали связи типа «out», то есть не «актёр снимался в таком-то фильме», а наоборот «в фильме снимались такие-то актёры» — в этом случае время поиска по графу изменилось бы?
Вообще, как выбирать направленность связи? Понимаю, что в зависимости от предметной области, но хотелось бы более развёрнутой информации на эту тему.
Почему спрашиваю? Потому что зацепило вот это предложение: «В тоже время между узлами могут быть множественные отношения направленные в обе стороны.»
Когда нужны двунаправленные связи? В каких ситуациях это даёт выигрыш?
Вообще, как выбирать направленность связи? Понимаю, что в зависимости от предметной области, но хотелось бы более развёрнутой информации на эту тему.
Почему спрашиваю? Потому что зацепило вот это предложение: «В тоже время между узлами могут быть множественные отношения направленные в обе стороны.»
Когда нужны двунаправленные связи? В каких ситуациях это даёт выигрыш?
По сути куда бы не была направлена связь, алгоритм обхода графа от этого не меняется соответственно и по скорости разница не заметна. Это нам даёт простор в написании самих запросов, как нам удобнее написать запрос: «актёр снимался в таком-то фильме», или «в фильме снимались такие-то актёры» так и делаем связь.
А что там у неё унутре?
Как хранятся данные?
Как хранятся данные?
Опять же, 1-2 года назад были несколько файликов, которые хранили отдельно ноды, атрибутику, связи + Lucene, который индексировал всё что скажете и делал полнотекстный поиск. Легче всего взять примерчик и запустить это дело у себя — он создаст штук 10 файликов — там по названиям всё в общем-то понятно было.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Графовая база данных Neo4j в PHP