7. Neo4j REST API
POST {}
http://localhost:7474/db/data/node
PUT "Hello"
http://localhost:7474/db/data/node/1/properties/
message
POST {"to": "http://localhost:7474/db/data/node/2",
"type": "knows"}
http://localhost:7474/db/data/node/1/relationships
PUT "brave Neo4j"
http://localhost:7474/db/data/relationship/0/properties/
message
17. Встроенные алгоритмы
• Нахождение путей между вершинами
• Нахождение кратчайших путей между
вершинами
• Алгоритм Дейкстры (кратчайшее расстояние
между вершинами во взвешенном графе)
20. Преимущества
• Нет схемы
• Гибкая и мощная графовая модель данных
• Мощные средства обработки графов
Недостатки
• Нет схемы
• Нет распределенности
• Специфичная модель - подходит не для
каждой предметной области
21. Когда использовать?
Если модель предметной области - множество
узлов с разнородными данными и большим
количеством разнородных связей между ними.
Иначе: SQL удобнее.
И если все данные умещаются на одной
физической машине.
Иначе: другой NoSQL удобнее.
И если вам подойдет лицензия...
CAP теорема. C - Consistency - целостность данных. A - Availability - доступность данных. P - Partition Tolerance - возможность распределить данные между разными машинами в сети - единственный возможный способ хранить действительно большие объемы данных. Теорема - возможно реализовать лишь две "буквы" из CAP. Neo4j - на грани CA. Целостность достигается за счет полноценных транзакций. Доступность достигается за счет репликации - каждый клиент работает со своей копией данных (embed база).
Это не тот граф :)
Граф выглядит как-то так.
Математический граф - множество вершин и ребер между ними. Узлы и отношения. В Neo4j все отношения имеют явно заданный тип. В Neo4j все узлы и отношения могут иметь свойства - пары ключ-значение.
Обычное Java API. Явно создаются узлы и отношения между ними. Тип отношения - enum. База - embedded. Свойства - ключ-значение. Для отношений явно задается начальный и конечный узлы (подразумевается направленность связей). Буква "J" в названии говорит нам, что СУБД написана на Java.
Весьма продвинутое REST API. Входит в состав дистрибутива БД (на базе HTTP сервера Jetty). POST на /node создает новый узел. PUT на properties/<name> создает/обновляет свойство. POST на /relationships создает отношение. Права доступа никак не ограничены. Нет авторизации и аутентификации. Любой, кто получит доступ к REST может делать что угодно.
Сведения об узле выглядят так (сокращенно). Указаны URL для всех операций.
Красивая веб мордочка. Авторизации и аутентификации тоже нет. Хороший инструмент администратора.
Очень мощные настройки стилей. Можно отображать/расскрашивать узлы по-разному в зависимости от значения их свойств. Есть и плагин к Eclipse.
Существуют аналоги ORM (скорее OGM - Object Graph Mapping). Класс - узел. Свойство класса - свойство узла. Ссылки на другие объекты - отношения. Nodeid - служебная информация. Недостаток - графовая модель данных искуственно ограничивается. Сложно передать множество связей. Возникают проблемы при рефакторинге, т.к. полные имена классов хранятся в &quot;скрытых&quot; свойствах узлов. Теряется гибкость графовой модели.
&quot;Аналог&quot; JDBC для графовых БД. Графовых БД уже довольно много. Интересен Sail - Storage And Inference Layer для RDF. RDF (Resource Description Framework) - мощнейщий механизм описания данных (метаданных). Триплеты: субъект-предикат-объект. Основа семантического веба 5.0 Зашли в дебри графовых БД... Вернемся обратно к Neo4j.
Транзакции - есть. Выглядят и работают точно так же как в обычных SQL базах.
Индексы - отдельные сущности базы. Создаются явно (однако существует и &quot;автоиндекс&quot;). Индексироваться могут любые свойства узлов (и связей). Возможны полнотекстовые индексы. Результат поиска по индексу - id узлов. Движок - Apache Lucene.
Имеется мощный API для обхода графа. В данном случае: - начиная с данного узла и до конца графа - в ширину (сначала непосредственные потомки, затем &quot;внуки&quot; и т.д.) - включать все узлы, кроме начального - идти по связям типа KNOWS - в направлении ОТ текущего узла Обход графа - &quot;ленивый&quot;. Не строится список узлов, а вычисляется следующий узел в итераторе.
Взвешенный граф - связи между вершинами имеют вес (стоимость). В данном случае вес может определяться любым свойством связи.
Картинка из официальной документации. Классическая репликация. Каждый узел имеет полную копию всех данных. Apache ZooKeeper следит за доступностью серверов и управляет работой Load Balancerа.
Пустой слайд. Нет поддержки шардинга со стороны БД.
Типичное применение: социальные сети и графы &quot;друзей&quot;.
Полнофункциональные версии доступны только под &quot;вирусными&quot; GPL лицензиями. Их можно использовать ТОЛЬКО в GPL коде (Столлман торжествует!). Для проприетарных разработок - коммерческая лицензия.