Раздел 39 · Neo4j и графовые базы

Другие графовые БД и когда граф не нужен

junior~15 мин

без входаВойди, чтобы отмечать прогресс, вести заметки и решать задачи в редакторе. войти

Раздел начинался с вопроса, почему таблицы плохо справляются со связями. Заканчиваем обратным: когда графовая база лишняя, и что ещё бывает кроме Neo4j. После урока про масштабирование ты знаешь, чем граф платит за свои сильные стороны. Теперь соберём картину целиком.

Кто ещё хранит графы

Neo4j самая известная графовая база, но не единственная. Коротко о соседях:

  • Memgraph. Хранит граф в памяти, понимает Cypher и протокол Bolt, поэтому драйверы Neo4j к нему подходят. Сильна там, где важна скорость на потоке данных.
  • JanusGraph. Распределённая графовая база с открытым кодом поверх хранилищ вроде Cassandra или HBase. Запросы пишут на Gremlin, а не на Cypher.
  • Amazon Neptune. Облачный сервис AWS, понимает Gremlin, openCypher и SPARQL.
  • TigerGraph. Распределённая база для аналитики на очень больших графах, свой язык GSQL.
  • ArangoDB. Многомодельная база: документы и графы в одном хранилище, язык AQL.
  • RDF-хранилища. Хранят тройки «субъект, предикат, объект» из урока про property graph и отвечают на запросы SPARQL. Их любят в науке и госсекторе, где важны общие словари и обмен данными.

Языки постепенно сходятся. В 2024 году вышел международный стандарт GQL, во многом выросший из Cypher. Запись SHORTEST и количество повторов в фигурных скобках, которые мы видели в уроках про пути, пришли в Cypher 25 именно оттуда. Есть и открытая спецификация openCypher, по которой Cypher реализуют другие базы.

Граф внутри PostgreSQL

Иногда графовая база не нужна, потому что граф прекрасно живёт в реляционной. Связи хранятся таблицами, как в уроке про сравнение с SQL, а обходы пишутся рекурсивными запросами WITH RECURSIVE. Для иерархий, деревьев категорий и коротких цепочек этого хватает с запасом. Есть и расширение Apache AGE, которое добавляет в PostgreSQL язык openCypher поверх тех же таблиц.

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

Когда граф не нужен

Признаки задачи, для которой графовая база лишняя:

  1. Вопросы про множества строк, а не про связи. Сумма продаж, средний чек, отчёт за квартал. Посмотри, как такой вопрос выглядит в Cypher:
MATCH (p:Person)
RETURN avg(p.born) AS avgBorn, min(p.born) AS oldest, max(p.born) AS youngest;
+----------------------------------------+
| avgBorn            | oldest | youngest |
+----------------------------------------+
| 1994.3333333333333 | 1985   | 2003     |
+----------------------------------------+

1 row

Ни одной стрелки в запросе. Граф здесь ничего не даёт, а на миллиардах строк колоночная база вроде ClickHouse посчитает такой итог в разы быстрее.

  1. Связи короткие и известны заранее. Заказ, его строки и покупатель: одно-два соединения по ключам. Реляционная база делает это десятилетиями и делает хорошо.
  2. Данные это поток простых записей. Логи, события, показания датчиков пишут миллионами и редко связывают между собой.
  3. Документы самодостаточны. Карточка товара со всеми характеристиками читается целиком, как в уроке про документные базы.
  4. Команда и инфраструктура. Новая база это ещё одна система, которую нужно мониторить, бэкапить и понимать. Если граф нужен в одном отчёте раз в месяц, проще выгрузить данные и посчитать.

И наоборот, граф оправдан, когда вопросы звучат как «через кого», «связан ли», «кратчайший путь», «что зависит от», когда глубина обхода заранее неизвестна, а связи сами несут данные. Именно такие вопросы ты решал весь раздел.

Что мы прошли

За 27 уроков ты:

  • узнал, почему связи бывают данными первого класса и что такое property graph;
  • поставил Neo4j и научился работать в cypher-shell и Browser;
  • выучил паттерны Cypher: CREATE, MERGE, MATCH, WHERE, OPTIONAL MATCH, SET, REMOVE, DELETE;
  • ходил по графу на несколько шагов, по путям переменной длины и кратчайшим путям;
  • считал итоги через count, collect и WITH;
  • защищал данные ограничениями и ускорял поиск индексами;
  • проектировал модель, грузил CSV, писал код с драйверами и управлял транзакциями;
  • увидел, где граф сильнее таблиц, а где нет.

Попробуй сам

Песочница в последний раз. Сравни два запроса: в первом нет ни одной связи, во втором вся суть в связях.

Подумай, какой из двух запросов было бы проще и быстрее выполнить в PostgreSQL. Потом найди в своём рабочем или учебном проекте один вопрос, который ты бы теперь задал графу.

Проверь себя

Задание

Дальше

Раздел закончен. Если хочется глубже, возвращайся к уроку про Graph Data Science и пробуй алгоритмы на своих данных, а для сравнения с таблицами пригодится раздел про PostgreSQL, где разобраны рекурсивные запросы.

домашка

Домашка