Для задач AdTech сегментации (профилирование пользователей, identity resolution, поиск look-alike аудиторий) набор требований к графовой базе данных специфичен: нужна высокая скорость операций чтения/записи (real-time bidding/serving) и горизонтальная масштабируемость (миллиарды событий и связей).

Учитывая популярность текущего стека (ClickHouse, Trino, Qdrant), идеальная графовая база должна уметь интегрироваться в аналитический контур (через Trino или прямые коннекторы) и дополнять ClickHouse (который хранит логи событий), взяв на себя хранение топологии связей.

Ниже представлен небольшой обзор и рейтинг Open Source решений на 2024-2025 год с фокусом на масштабируемость.

---

Рейтинг Open Source Графовых СУБД для AdTech

Разделим 12 решений на 3 эшелона по пригодности для высоконагруженной сегментации.

1 эшелон: Лидеры производительности и масштабирования (Native Distributed)

Эти базы изначально создавались для кластеров и больших объемов данных.

1. NebulaGraph

• Тип: Native Distributed Graph Database.
• Язык запросов: nGQL (SQL-подобный).
• Архитектура: Разделение Compute (GraphD) и Storage (StorageD). Shared-nothing.
• Плюсы для вас: Это топ-1 выбор для AdTech масштаба Tencent или Meituan. Спокойно переваривает сотни миллиардов вершин и триллионы ребер. Обеспечивает миллисекундный отклик при обходе графа (hops) на большую глубину.
• Минусы: Более крутая кривая обучения, чем у Neo4j. Сообщество меньше, но растет.
• Связь со стеком: Отлично дополнит ClickHouse (CH хранит атрибуты, Nebula — связи). Есть коннекторы для Spark/Flink. А через Spark можно дойти до Trino.

2. Dgraph

• Тип: Native Distributed Graph.
• Язык запросов: GraphQL (модифицированный DQL).
• Архитектура: Распределенная, использует BadgerDB (KV store) под капотом. Поддерживает шардинг и репликацию “из коробки” в open source версии.
• Плюсы: Горизонтальное масштабирование. Очень удобна для фронтенд-разработчиков благодаря GraphQL. Высокая пропускная способность.
• Минусы: Специфичный язык запросов, если вы привыкли к SQL/Cypher. В последние годы темпы разработки ядра немного снизились относительно конкурентов.

3. Memgraph

• Тип: In-Memory Graph Database (написана на C++).
• Язык запросов: Cypher (совместим с Neo4j).
• Архитектура: Работает в оперативной памяти (с возможностью сброса на диск).
• Плюсы: Самая быстрая для задач реального времени (вычисление фичей для RTB). Полная совместимость с экосистемой Neo4j (драйверы, протокол Bolt). Поддерживает Python/Rust процедуры. Отличная работа с Streaming данными (Kafka).
• Минусы: Ограничена объемом RAM (хотя есть disk-spill, это снижает скорость).
• Связь со стеком: Отлично стыкуется с моделями AI (Qdrant), так как позиционируется для “Graph AI”.

2 эшелон: Классика и Универсалы

4. Neo4j (Community Edition)

• Тип: Native Graph.
• Язык: Cypher (стандарт индустрии).
• Плюсы: Огромное сообщество, лучшая документация, куча плагинов (APOC).
• Главный минус для AdTech: Open Source версия (Community) ограничена одним узлом. Нет встроенного кластеризации и шардинга (доступно только в Enterprise за большие деньги). Для “технического задела на вырост” в Open Source варианте — это бутылочное горлышко.

5. ArangoDB

• Тип: Multi-model (Graph, Document, Key/Value).
• Язык: AQL (похож на SQL).
• Плюсы: Гибкость. Можно хранить сложные JSON-документы (как в Mongo) и связывать их.
• Минусы: При глубоких обходах графа (“друзья друзей друзей”) проигрывает специализированным Native Graph базам по скорости. Это компромиссное решение.

6. JanusGraph

• Тип: Layered Graph Database.
• Плюсы: Работает поверх мощных бэкендов (Cassandra, HBase, ScyllaDB) и использует Elasticsearch для индексации. Масштабируемость ограничена только бэкендом.
• Минусы: Очень “тяжелая” инфраструктура (JVM based). Сложна в настройке и эксплуатации. Медленнее на простых запросах из-за сетевых хопов между слоями. Часто считается “устаревающей” архитектурой по сравнению с Nebula/Dgraph.

7. Apache AGE (PostgreSQL Extension)

• Тип: Extension.
• Суть: Превращает PostgreSQL в графовую БД с поддержкой Cypher.
• Плюсы: Если вы знаете Postgres, вы знаете AGE. Не нужно новой инфраструктуры.
• Минусы: Производительность ограничена движком Postgres. Сложно масштабировать горизонтально на запись (проблема шардинга PG).

3 эшелон: Нишевые и Новые игроки

8. HugeGraph (Baidu) — аналог JanusGraph, популярен в Китае, очень мощный, но документация местами страдает.
9. OrientDB — мультимодельная, была популярна, но сейчас развитие замедлилось.
10. FalkorDB — форк закрывшегося RedisGraph (Redis module). Очень быстрый, использует разреженные матрицы. Интересен, если уже есть Redis.
11. Cayley — написана на Go (Google), простая, работает с триплетами (Linked Data), но для сложной AdTech логики может не хватить функционала.
12. TerminusDB — интересная база с концепцией “Git для данных”, но специфична для версионирования знаний, а не высоконагруженной сегментации.

Сравнительная таблица (ТОП-7 для выбора)

СУБД	Язык запросов	Архитектура	Масштабирование (Open Source)	Скорость (Read/Traverse)	Сложность эксплуатации	Идеально для
NebulaGraph	nGQL (SQL-like)	Distributed Native	Отличное (Sharding+Replication)	🔥 Очень высокая	Средняя/Высокая	Big Data, AdTech, Fraud
Memgraph	Cypher	In-Memory (C++)	Вертикальное / Репликация	🚀 Топ-1 (Low Latency)	Низкая (как Docker)	Real-time features, Streaming
Dgraph	GraphQL	Distributed Native	Отличное	Высокая	Средняя	App Backend, 360 Customer View
Neo4j (CE)	Cypher	Native	Нет (только 1 нода)	Высокая (локально)	Низкая	R&D, малые проекты
ArangoDB	AQL	Multi-model	Хорошее (Cluster mode)	Средняя	Средняя	Гибридные данные (Docs+Graph)
JanusGraph	Gremlin	Layered (over NoSQL)	Бесконечное (зависит от Backend)	Низкая/Средняя	☠️ Высокая	Если уже есть HBase/Cassandra
Apache AGE	Cypher	Postgres Ext	Только Read Replicas	Средняя	Низкая (если знают PG)	Гибрид SQL + Graph

Интеграция с текущим стеком (Qdrant, Trino или ClickHouse)

1. Qdrant + Graph DB = GraphRAG / Semantic Search:
   • Сегментация пользователей часто требует поиска не только по связям (“кто кликал то же, что и я”), но и по похожести векторов (“чей профиль похож на мой”).
   • Memgraph и **Neo4j имеют встроенные модули для работы с векторами, но так как у вас уже есть Qdrant, вам нужна база, которая *не пытается заменить Qdrant*, а позволяет хранить ID векторов в узлах графа.
   • NebulaGraph** позволяет хранить embedding в свойствах узла, но поиск лучше делегировать Qdrant.

2. Trino:
   • Вам захочется делать SQL-запросы сразу к ClickHouse (события) и Графу (профиль).
   • У Neo4j и NebulaGraph есть коннекторы, позволяющие Trino (через JDBC или нативные коннекторы) запрашивать данные. Это мощнейшая связка для аналитиков. Отдельно нативного конектора к Trino пока не найти, но скоро может появится поддержка iceberg https://github.com/vesoft-inc/nebula/discussions/5902 или пока можно использоваться связку через Spark.

3. ClickHouse:
   • Паттерн: ClickHouse хранит “сырые” логи (миллиарды строк). Агрегаты и связи (User Graph) пересчитываются и заливаются в Графовую БД для быстрого lookup.
   • NebulaGraph** имеет Exchange (инструмент на основе Spark) для массовой заливки данных из Warehouse.

---

Итоговая рекомендация

Учитывая, что вы хотите Open Source и вам нужен технический задел (масштабирование) для AdTech:

🏆 Выбор №1: NebulaGraph

Это наиболее близкий аналог “ClickHouse в мире графов”.

• Почему:** Он создан для хранения миллиардов вершин (пользователей/устройств) и работы в кластере. У него shared-nothing архитектура, которая необходима для роста. Язык nGQL будет понятен вашим аналитикам, знающим SQL (ClickHouse/Trino).
• Для AdTech:** Идеально решает проблемы *Identity Resolution* (склеивание cookie, device_id, user_id и других атрибутов в единый граф) на больших объемах.

🥈 Выбор №2: Memgraph

Если ваши графы помещаются в память (сотни миллионов узлов, но не десятки миллиардов) и критична задержка (latency) менее 10 мс для *real-time* принятия решений.

• Почему:** Он безумно быстр. Он совместим с Cypher (легко нанимать людей или переезжать с Neo4j). Написан на C++, очень эффективен.
• Интеграция:** Идеально, если вы планируете стримить данные из Kafka, обновлять граф и сразу выдавать сегменты.

🥉 Выбор №3: Apache AGE (или ArangoDB)

Только если объем графа невелик, и вы хотите минимизировать зоопарк технологий, оставаясь в рамках “почти SQL” решений. Но для серьезного AdTech они не рекомендуется как *основное* хранилище графа пользователей.

Совет: Начните пилот (PoC) с NebulaGraph. Попробуйте загрузить туда выгрузку из ClickHouse и сравнить скорость выполнения запросов “найти всех пользователей, связанных через устройство X на глубину 3 шага” с тем, как это делается сейчас (вероятно, через JOINs в реляционке или CH). Если сложность эксплуатации Nebula покажется высокой, можно посмотреть в сторону Memgraph как более легкой альтернативы и применять их не на одном большом графе например, а на нескольких малых в реальном времени, а готовые расчеты уже хранить в привычных местах.

Еще можно почитать:

• Сравнение Memgraph и Neo4j bigdataschool.ru
• Сравнение Neo4j и TigerGraph (для понимания коммерческого рынка bigdataschool.ru
• Обзор графовых БД wiki.merionet.ru

Вот еще мысль и про языки немного. Если проект большой с единым графом для разных нужд, то NebulaGraph выглядит лучшим решением, но архитектурно можно выбрать много средних и малых графов. Для второго подхода хорошо Memgraph с его языком Cypher

---

1. Семейство Cypher (OpenCypher / ISO GQL)

Базы: *Neo4j, Memgraph, FalkorDB, Apache AGE.*

Cypher — это «SQL для графов». Это декларативный язык, использующий ASCII-арт для визуализации связей в коде (например, `(User)-[:CLICKS]->(Ad)`).

• Функциональность: Очень богатая. Поддерживает сложные паттерны (Pattern Matching), агрегации, пути переменной длины. В апреле 2024 года ISO утвердила стандарт GQL (Graph Query Language), который во многом основан на Cypher.
• Плюсы:
  • Интуитивность: Код читается как предложение на английском. Самая низкая кривая входа.
  • Экосистема: Стандарт де-факто. Если вы знаете Cypher, вы можете переключаться между Neo4j, Memgraph и AGE без переобучения.
  • Выразительность: Идеален для глубокой аналитики и поиска сложных паттернов (Fraud Detection).
• Минусы:
  • Изначально создавался для одноузловых систем. В распределенных системах (шардинг) некоторые конструкции Cypher могут быть сложны для оптимизации движком.
• Оценка для стека:
  • Memgraph/Neo4j: Работает идеально.
  • Apache AGE: Cypher оборачивается внутри SQL запросов Postgres, что немного громоздко, но функционально.
  • FalkorDB: Реализует подмножество Cypher, очень быстро благодаря Redis, но функционал беднее, чем у Neo4j.

2. Семейство Gremlin (Apache TinkerPop)

Базы: *JanusGraph, HugeGraph, OrientDB (частично), Azure CosmosDB.*

Gremlin — это императивный язык обхода графа (Traversals). Вы пишете не «что найти» (как в SQL/Cypher), а «куда идти» шаг за шагом.

• Функциональность: Тьюринговская полнота. Можно написать алгоритм любой сложности прямо внутри запроса. Это скорее язык программирования потоков данных, чем язык запросов.
• Плюсы:
  • Контроль: Вы точно указываете базе, как обходить граф. Это важно для сверхбольших графов (как в JanusGraph/HugeGraph), где неверный план запроса может “положить” кластер.
  • Абстракция: Работает поверх любой БД, поддерживающей TinkerPop.
• Минусы:
  • Сложность: Кривая обучения очень крутая. Код получается вербозным и сложным для отладки («write once, read never»).
  • Устаревание: С появлением стандарта ISO GQL популярность Gremlin падает. Для новых проектов в 2025 году его выбирают редко, если только не привязаны к JanusGraph.
• Пример AdTech: «Найти всех пользователей, кликнувших на этот баннер» на Gremlin будет длинной цепочкой вызовов методов (`g.V().has(‘Banner’...).out(‘CLICKS’)...`).

3. nGQL (NebulaGraph Query Language)

Базы: *NebulaGraph.*

Собственный язык Nebula, который синтаксически мимикрирует под SQL, но логически работает с графами.

• Функциональность: Заточена под распределенный Massive Parallel Processing (MPP).
• Плюсы:
  • SQL-подход: Разработчикам, привыкшим к MySQL/ClickHouse, синтаксис `GO FROM ... OVER ...` будет понятнее, чем Gremlin.
  • Скорость: Спроектирован так, чтобы не позволять писать «плохие» запросы, которые убивают распределенный кластер. Вынуждает думать о том, где лежат данные (VID).
  • Пайпы: Удобный синтаксис передачи результата одного шага в другой через `|` (как в Bash).
• Минусы:
  • Vendor Lock-in: Это не стандарт. Переехать с Nebula на другую базу потребует переписывания всех запросов.
  • Не поддерживает полную гибкость Pattern Matching, как Cypher (хотя добавили поддержку `MATCH`, она менее производительна, чем нативный `GO`).

4. DQL (ранее GraphQL+-)

Базы: *Dgraph.*

Это модифицированный GraphQL.

• Функциональность: Идеальна для API. Вы запрашиваете данные в формате JSON-дерева, и база возвращает JSON.
• Плюсы:
  • Frontend-first: Фронтендерам не нужен бэкенд-прослойка, они могут (теоретически) ходить в базу почти напрямую.
  • Работа с атрибутами: Поскольку Dgraph — это по сути распределенный Key-Value, DQL очень быстро достает атрибуты нод.
• Минусы:
  • Слабая аналитика: Графовые алгоритмы и сложные обходы (traversals) на DQL писать сложнее и менее эффективно, чем на Cypher/nGQL. Это язык выборки данных, а не язык аналитики графов.

5. AQL (ArangoDB Query Language)

Базы: *ArangoDB.*

Гибридный язык, объединяющий возможности SQL (JOINs), работы с JSON (как в Mongo) и графовых обходов.

• Функциональность: Одна из самых мощных среди “универсалов”. Позволяет в одном запросе сделать JOIN трех коллекций, отфильтровать JSON и пройтись по графу друзей.
• Плюсы: Гибкость.
• Минусы: Синтаксис `FOR u IN users FILTER ...` специфичен и многословен. Для чистых графовых задач (deep hopping) он медленнее нативных решений [ArangoDB vs Native Graph].

6. Другие / Устаревающие

• OrientDB (SQL-extended): Пытались расширить SQL для графов. Сейчас проект стагнирует, язык считается тупиковой ветвью эволюции по сравнению с Cypher/GQL.
• SQL Graph (MS SQL / PG SQL): В [статье про SQL Server](https://learn.microsoft.com/ru-ru/sql/relational-databases/graphs/sql-graph-sample?view=sql-server-ver17) показан синтаксис `MATCH`, который Microsoft внедрила в T-SQL. Это попытка “догнать” Cypher, оставаясь в рамках реляционной модели. Удобно, если вы намертво привязаны к MS SQL, но неудобно для сложной аналитики.
• Cayley (Gizmo/MQL): Очень нишевый язык на базе Go или JS. Для AdTech продакшена слишком экзотичен.

---

Сводная таблица сравнения

Язык	Базы данных	Порог входа	Для AdTech/High-load	Стандартность (2025)	Примечание
nGQL	NebulaGraph	Средний	Идеально (Tencent scale)	Низкая (Vendor specific)	Топ для сотен млрд связей и кластерной архитектуры.
Cypher	Memgraph, Neo4j, AGE	Низкий	Хорошо (Memgraph) / Средне (Neo4j)	Высокая (основа ISO GQL)	Самый удобный для аналитиков и Data Science.
DQL	Dgraph	Низкий (для Web-dev)	Хорошо (для OLTP)	Низкая	Лучший выбор, если граф — это бэкенд для UI.
Gremlin	JanusGraph, HugeGraph	Высокий	Отлично (если настроить)	Падает (Legacy)	Слишком сложен в поддержке, проигрывает современным языкам.
AQL	ArangoDB	Средний	Средне	Низкая	Хорош, если нужна “Document Store + Graph” в одном.

Итоговая рекомендация

1. Если приоритет — производительность на масштабе (AdTech, сегментация 100M+ пользователей):
   Вам нужен NebulaGraph и его nGQL.
• *Почему:* В AdTech сценариях (как у Meituan/Tencent) критичны latency на “хопах” (hops). nGQL архитектурно заставляет писать запросы так, чтобы они эффективно параллелились. Он менее удобен, чем Cypher, но более предсказуем в нагрузке.

2. Если приоритет — Real-time аналитика, ML-фичи и скорость разработки:
   Вам нужен Memgraph на Cypher.
• *Почему:* Вы получаете совместимость с самой популярной экосистемой (Neo4j), стандартный язык Cypher (легко найти специалистов) и скорость C++ in-memory движка.

3. Если приоритет — дешевое горизонтальное масштабирование “для бедных” (в хорошем смысле):
   Вам нужен Dgraph (DQL) или NebulaGraph.
• У Dgraph отличный шардинг из коробки и DQL закрывает 90% задач продуктовой разработки, но может буксовать на тяжелой аналитике.

От чего стоит отказаться:

• Neo4j Community: Язык Cypher прекрасен, но ограничения лицензии (отсутствие кластера) убьют проект на росте.
• JanusGraph/HugeGraph (Gremlin): В 2025 году начинать проект на Gremlin — это создавать себе технический долг, так как индустрия движется в сторону ISO GQL (Cypher Style).
• Apache AGE: Пока слишком сыро для High-load, проблемы с горизонтальным масштабированием Postgres никуда не деваются.