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

Расширяем кругозор за пределы Neo4j и учимся честно отказываться от графа, когда он не нужен.

Графовых баз много, и они делятся на два больших семейства — property graph (как Neo4j) и RDF (триплеты «субъект–предикат–объект»); ни одна модель не универсальна.

Весь курс мы изучали Neo4j, и легко решить, будто «граф = Neo4j». Это не так: графовых баз целое семейство, и они различаются не только названием, но и самой моделью данных и языком запросов. Понимать ландшафт полезно по двум причинам. Во-первых, чтобы осознанно выбирать инструмент: для графа знаний с онтологиями уместнее RDF, а не property graph. Во-вторых, чтобы видеть, насколько переносим ваш навык: Cypher давно вышел за пределы Neo4j. И венчает урок самая взрослая тема всего курса — честный разговор о том, когда граф брать не надо. Умение сказать «здесь хватит обычной таблицы» отличает инженера от энтузиаста.

Семейство property graph

Это мир, к которому относится Neo4j: узлы со свойствами, типизированные связи. Помимо Neo4j сюда входят:

  • Apache TinkerPop / Gremlin — не база, а стандарт обхода и язык Gremlin (императивный: «шагни по ребру, отфильтруй, собери»). Его поддерживают JanusGraph, Amazon Neptune, OrientDB.
  • Amazon Neptune — управляемый облачный граф, понимает и property graph (Gremlin/openCypher), и RDF (SPARQL).
  • ArangoDB, OrientDB — мультимодельные базы, где граф — одна из моделей наряду с документами.

Семейство RDF и SPARQL

RDF (Resource Description Framework) описывает данные как триплеты: (субъект, предикат, объект). Это родной формат семантического веба и больших графов знаний. Запросы пишут на SPARQL. RDF силён в стандартизации, онтологиях и связывании данных между организациями (linked data), но многословнее property graph для прикладной разработки.

property graph:  (Москва)-[:СТОЛИЦА]->(Россия)
RDF-триплет:     <Москва> <столица> <Россия>

Ключевая разница в гранулярности. В property graph «узел» — это богатый объект со свойствами, и у связи тоже могут быть свойства. В RDF атомарная единица — один факт-триплет; чтобы описать человека с именем и годом рождения, вы пишете несколько триплетов про один и тот же субъект. Это делает RDF многословнее для прикладной CRUD-разработки, но зато безупречно стандартизованным: на нём строят онтологии, связывают данные между организациями (linked data) и описывают смысл данных машиночитаемо. Поэтому грубое правило выбора такое: продуктовое приложение со связями — обычно property graph (Neo4j); большой граф знаний с онтологиями и обменом данными между системами — часто RDF.

openCypher и стандартизация

Cypher оказался настолько удачным, что его открыли как openCypher, и его диалекты поддерживают другие базы. А с 2024 года появился ISO-стандарт GQL — первый международный стандарт языка графовых запросов, идейный наследник Cypher. Так что навык Cypher переносится шире, чем на один Neo4j.

Это важная новость для вашей карьеры. Появление GQL ставит Cypher в один ряд с SQL: как SQL стал общим языком реляционных баз поверх вендоров, так GQL претендует стать общим языком графов. Уже сейчас openCypher понимают Amazon Neptune, Memgraph и другие, а GQL закрепляет синтаксис международным стандартом. Практический вывод: MATCH, паттерны со стрелками, WHERE, RETURN, которые вы освоили в этом курсе, — это не «знание одного продукта», а переносимый навык работы с графами вообще.

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

Самый честный урок курса. Граф — не серебряная пуля. Откажитесь от него, если:

  • Связей мало или они мелкие. Если данные плоские и обходов нет — реляционная база проще и дешевле.
  • Главное — агрегаты по колонкам. «Суммы и средние за период» — это OLAP/колоночные базы (ClickHouse, витрины), не граф.
  • Нужен полнотекстовый поиск. Тут Elasticsearch/поисковый движок, а не обход.
  • Простой CRUD одной сущности. Лишняя СУБД ради «таблицы пользователей» — усложнение без выгоды.
  • Команда не готова. Новая модель данных, язык и эксплуатация — реальная цена; она должна окупаться задачей.

Как работает под капотом (выбор)

Решение «граф или нет» сводится к одному: насколько в задаче доминируют обходы связей. Граф окупается, когда вы регулярно ходите на 2+ уровня по нерегулярным связям, ищете пути и считаете похожесть через соседей. Если же доступ к данным — это «возьми по ключу» и «сгруппируй по колонке», граф добавит сложности без выигрыша в скорости. Зрелые системы часто гибридны: граф под связи, реляционная/колоночная база под учёт и аналитику, поиск под тексты.

Частые ошибки

  • Брать граф «потому что модно». Без доминирующих обходов выгоды не будет.
  • Путать RDF и property graph. Это разные модели; Neo4j — property graph, SPARQL — про RDF.
  • Считать Cypher привязанным к Neo4j. openCypher и стандарт GQL делают навык переносимым.
  • Гнать в граф аналитику и полнотекст. Для них есть свои зрелые инструменты.

Итоги

  • Две большие модели: property graph (Neo4j, Neptune, Gremlin-базы) и RDF (SPARQL, графы знаний).
  • Cypher переносим: есть openCypher и международный стандарт GQL.
  • Граф окупается, когда доминируют обходы связей, пути и похожесть через соседей.
  • Для агрегатов, полнотекста и простого CRUD честнее другие базы; зрелые системы — гибридны.
Проверьте себя
1. Чем модель RDF отличается от property graph?
AНичем
BRDF описывает данные триплетами (субъект–предикат–объект) и запрашивается SPARQL, а property graph — узлы со свойствами и связи
CRDF быстрее всегда
Dproperty graph не поддерживает связи
2. В каком случае граф, скорее всего, НЕ нужен?
AПоиск кратчайшего пути
BГлавная задача — агрегаты и суммы по колонкам за период
CРекомендации через общих соседей
DАнтифрод-кольца
3. Что верно про переносимость навыка Cypher?
ACypher работает только в Neo4j
BЕсть openCypher и международный стандарт GQL, поэтому навык переносим на другие графовые базы
CCypher устарел
DCypher — это диалект SQL