Рейтинг Open Source Графовых СУБД для AdTech
Для задач 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)
- Qdrant + Graph DB = GraphRAG / Semantic Search:
- Сегментация пользователей часто требует поиска не только по связям (“кто кликал то же, что и я”), но и по похожести векторов (“чей профиль похож на мой”).
- Memgraph и **Neo4j имеют встроенные модули для работы с векторами, но так как у вас уже есть Qdrant, вам нужна база, которая *не пытается заменить Qdrant*, а позволяет хранить ID векторов в узлах графа.
- NebulaGraph** позволяет хранить embedding в свойствах узла, но поиск лучше делегировать Qdrant.
- Trino:
- Вам захочется делать SQL-запросы сразу к ClickHouse (события) и Графу (профиль).
- У Neo4j и NebulaGraph есть коннекторы, позволяющие Trino (через JDBC или нативные коннекторы) запрашивать данные. Это мощнейшая связка для аналитиков. Отдельно нативного конектора к Trino пока не найти, но скоро может появится поддержка iceberg https://github.com/vesoft-inc/nebula/discussions/5902 или пока можно использоваться связку через Spark.
- 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 как более легкой альтернативы и применять их не на одном большом графе например, а на нескольких малых в реальном времени, а готовые расчеты уже хранить в привычных местах.
Еще можно почитать: