System Design Space
Граф знанийНастройки

Обновлено: 2 марта 2026 г. в 00:45

Neo4j: графовая база данных и архитектура

mid

Graph DBMS с property graph моделью: Cypher, constraints/indexes, кластерный read/write path и сценарии с плотными связями.

Источник

Wikipedia: Neo4j

История Neo4j, модель property graph и контекст применения графовых баз данных.

Открыть статью

Официальный сайт

Neo4j

Документация, продуктовые возможности и современные сценарии использования графовой платформы.

Открыть сайт

Neo4j - графовая СУБД (property graph), оптимизированная под хранение и обход связей. В системном дизайне её выбирают, когда связи между сущностями становятся центральной частью продукта: рекомендации, anti-fraud, знания о домене и identity/authorization графы.

История и контекст

2000-2007

Идея графовой СУБД и первый публичный релиз

Проект Neo4j развивается из практической потребности хранить и обрабатывать связанные данные; первый публичный релиз появляется в 2007 году.

2010-е

Рост production-применения

Neo4j закрепляется в сценариях рекомендаций, fraud detection и knowledge graph, где важно быстро проходить граф на несколько hops.

2020+

Cloud и кластерные практики

Развиваются облачные предложения и практики эксплуатации кластеров с разделением read/write трафика.

2023+

Graph + AI use cases

Расширяются сценарии hybrid graph/vector и интеграции с GenAI-пайплайнами для поиска связей и контекста.

Ключевые архитектурные элементы

Property Graph модель

Данные представлены как ноды, связи и свойства. Связи - first-class сущности, а не побочный эффект join-таблиц.

Cypher и pattern matching

Cypher оптимизирован для декларативного описания графовых паттернов и traversal-запросов с переменной глубиной.

Индексы и constraints

Уникальные ограничения и индексы помогают удерживать целостность данных и ускорять опорные точки traversal.

Кластер и роли узлов

Write-трафик маршрутизируется через leader, read-трафик можно масштабировать через follower/read replica.

Cypher, Pattern Matching и реляционная алгебра

Cypher-декларация графового паттерна может быть приведена к реляционной форме: цепочке JOIN, фильтрации (SELECT) и проекции (PROJECT). Ниже - пошаговая визуализация этого соответствия.

Cypher: pattern matching и реляционная алгебра

Один и тот же запрос можно читать как обход графа и как цепочку JOIN + SELECT + PROJECT над таблицами.

Графовый обход (pattern matching)

FOLLOWSFOLLOWSAUTHOREDAUTHOREDu-1001Useru-2042Useru-3007Userp-501Postp-777Post

Стартуем с якорной ноды пользователя `u-1001` через точечный lookup.

SELECT в `Users` по `user_id = 'u-1001'`.

Эквивалент в таблицах

Users

user_idname
u-1001Alice
u-2042Bob
u-3007Carol

Follows

follower_idfollowee_id
u-1001u-2042
u-1001u-3007

Posts

post_idauthor_idtopic
p-501u-2042graph
p-777u-3007caching

Cypher-запрос

MATCH (u:User {userId: "u-1001"})-[:FOLLOWS]->(f:User)-[:AUTHORED]->(p:Post)
WHERE p.topic = "graph"
RETURN DISTINCT p.postId, p.title;

Эквивалентный SQL

SELECT DISTINCT p.post_id, p.title
FROM users u
JOIN follows f ON u.user_id = f.follower_id
JOIN posts p ON f.followee_id = p.author_id
WHERE u.user_id = 'u-1001'
  AND p.topic = 'graph';

Приведение к реляционной алгебре

PROJECT{p.post_id, p.title} (
  SELECT{u.user_id='u-1001' AND p.topic='graph'} (
    (Users u JOIN_{u.user_id=f.follower_id} Follows f)
      JOIN_{f.followee_id=p.author_id} Posts p
  )
)

Как маппится модель

  • Label ноды -> таблица сущности (`User`, `Post`).
  • Тип связи -> таблица связей (`Follows`) или FK-колонка.
  • Pattern expansion `()-[:REL]->()` -> `JOIN` по ключам.
  • `WHERE` в Cypher -> операция `SELECT`, `RETURN` -> `PROJECT` (и `DISTINCT` при необходимости).

High-Level Architecture

Ниже high-level контур Neo4j в продуктовой системе: слой приложений, Cypher execution path, графовое хранение с индексами и кластерные механики для read/write нагрузки.

Applications and query API
BoltHTTP APICypherNeo4j Browser
Layer transition
Routing and query planning
ParserPlannerRuntimeCost-based optimization
Layer transition
Graph model
NodesRelationshipsPropertiesLabels + types
Layer transition
Storage and indexes
Page cacheNative storageB-tree/RANGE indexesFull-text indexes
Layer transition
Cluster and replication
RaftLeader/FollowerRead replicasFailover
Layer transition
Operations
BackupsSecurityMonitoringSchema constraints

System view

Neo4j is typically used as a graph-native operational store when relationships and multi-hop traversals are first-class requirements.

Graph-native patterns

Multi-hop traversalsPattern matchingRelationship-first modeling

Consistency and integrity

ACID transactionsUniqueness constraintsSchema indexes

System design fit

RecommendationsFraud and risk graphsKnowledge graph / GraphRAG

Read / Write Path через компоненты

Диаграмма объединяет write и read path с пояснениями: как Cypher-запросы маршрутизируются, выполняются и становятся видимыми клиенту в кластере Neo4j.

Read/Write Path Explorer

Интерактивный разбор прохождения Cypher-запросов через компоненты Neo4j.

1
Client Query
CREATE MERGE SET
2
Router
leader routing
3
Cypher Runtime
plan + execute
4
Raft Commit
tx log
5
Visible State
indexes + cache
Write path: транзакция идет через leader, коммитится в журнал и реплицируется в кластер перед подтверждением.

Write path

  1. Приложение отправляет Cypher write-команду на Neo4j endpoint (Bolt/HTTP).
  2. Роутер кластера направляет запись на leader, чтобы сохранить сериализуемый порядок коммитов.
  3. Leader выполняет запрос, пишет tx log и реплицирует изменения через Raft на followers.
  4. После подтверждения кворума транзакция коммитится, индексы и cache отражают новое состояние.

Когда выбирать Neo4j

Хорошо подходит

  • Системы с высокой плотностью связей: social graph, рекомендации, fraud/risk analysis.
  • Knowledge graph и GraphRAG-сценарии, где важны связи и explainability.
  • Запросы с многошаговым traversal (1..N hops), которые дорого делать через SQL join-цепочки.
  • Домены, где модель связей часто эволюционирует и нужна гибкость схемы.

Стоит избегать

  • Простые CRUD-сценарии без сложных связей и графовых обходов.
  • Чисто аналитические OLAP-нагрузки на огромных колонночных датасетах.
  • Системы, где команда не готова к graph modeling и профилированию traversal-запросов.
  • Сценарии, где основной bottleneck - массовые append-only логи, а не связи между сущностями.

Практика: DDL и DML

Ниже практические примеры Cypher-команд: от constraints/indexes (DDL) до MERGE/MATCH traversal-запросов (DML).

Примеры DDL и DML в Neo4j

DDL управляет ограничениями и индексами, DML моделирует граф и выполняет traversal-запросы.

DDL в Neo4j задает структурные гарантии и ускоряет чтение: uniqueness constraints, range/full-text индексы.

Уникальность бизнес-ключа для User

Cypher: CREATE CONSTRAINT

Гарантирует целостность графа и предотвращает дубли для userId.

CREATE CONSTRAINT user_id_unique IF NOT EXISTS
FOR (u:User)
REQUIRE u.userId IS UNIQUE;

Range index для частых фильтров по дате

Cypher: CREATE RANGE INDEX

Ускоряет фильтрацию и сортировку по createdAt.

CREATE RANGE INDEX post_created_at_idx IF NOT EXISTS
FOR (p:Post)
ON (p.createdAt);

Full-text индекс для контентного поиска

Cypher: CREATE FULLTEXT INDEX

Комбинирует graph traversal с полнотекстовым поиском по title/body.

CREATE FULLTEXT INDEX post_content_ft IF NOT EXISTS
FOR (p:Post)
ON EACH [p.title, p.body];

Связанные материалы

Связанные главы

Чтобы отмечать прохождение, включи трекинг в Настройки

System Design Space

© 2026 Александр Поломодов