Universal Dependencies представляет собой современный международный стандарт синтаксической разметки естественного языка, используемый для построения унифицированных лингвистических текстовых корпусов (treebank) для различных языков. Основной единицей хранения данных в UD является предложение, представленное в виде дерева зависимостей, где вершинами выступают токены, а рёбрами — синтаксические отношения между ними. На данный момент Universal Dependencies включает более 150 языков и сотни размеченных корпусов, активно применяемых в задачах компьютерной лингвистики, машинного перевода, информационного поиска и обработки естественного языка.

Стандартным форматом хранения данных в Universal Dependencies является формат CoNLL-U (Computational natural language learning, universal) — текстовый табличный формат, в котором каждый токен предложения описывается набором атрибутов: лексемой, частью речи, морфологическими признаками, идентификатором родительского токена и типом синтаксической зависимости. Несмотря на простоту, переносимость и удобство ручной обработки, формат CoNLL-U обладает рядом ограничений при работе с крупными корпусами данных. Текстовое представление требует последовательного чтения файлов, усложняет выполнение сложных запросов по синтаксическим структурам и не обеспечивает эффективной навигации по графу зависимостей.

С точки зрения структуры данных текстовый корпус Universal Dependencies естественным образом представляет собой ориентированный граф или дерево зависимостей. Каждый токен может быть интерпретирован как вершина графа, а синтаксическая связь между токенами — как ориентированное ребро с набором атрибутов. В связи с этим использование графовых баз данных представляется перспективным подходом к хранению и обработке UD-корпусов. Графовые СУБД обеспечивают эффективное выполнение запросов обхода (traversal-запросов), поиск синтаксических паттернов, анализ связности и обработку сложных зависимостей между элементами предложения.

Дополнительную актуальность данному подходу придаёт рост объёмов лингвистических корпусов. Крупнейшие текстовые корпуса Universal Dependencies содержат миллионы токенов и десятки миллионов связей между ними, что создаёт повышенные требования к производительности систем хранения и скорости выполнения запросов. Традиционные реляционные базы данных и файловое хранение CoNLL-U не всегда обеспечивают достаточное удобство и эффективность при выполнении задач синтаксического анализа, поиска зависимостей фиксированной глубины и корпусной аналитики.

Цель работы — провести сравнительный анализ современных графовых систем управления базами данных с точки зрения их применимости к хранению и обработке Universal Dependencies.

Краткий обзор баз данных для анализа

Neo4j является одной из наиболее распространённых графовых СУБД, использующих модель графа свойств. Система ориентирована на эффективную обработку связей между объектами и выполнение запросов обхода графа. В качестве языка запросов используется Cypher, позволяющий декларативно описывать шаблоны графовых структур. Более подробную информацию можно посмотреть в документации [1]. На момент написания статьи количество фиксированных изменений в репозитории базы — более 81 тыс., количество ответвлений репозитория — 2,6 тыс., количество звёзд — 16,5 тыс. [2].

Memgraph представляет собой высокопроизводительную графовую СУБД, ориентированную на обработку данных в оперативной памяти. Система совместима с языком запросов Cypher и поддерживает выполнение операций обхода графа в реальном времени. Архитектурные особенности Memgraph обеспечивают высокую скорость обработки графовых запросов и низкие задержки при работе с динамически изменяемыми данными [3]. На момент написания статьи количество фиксированных изменений в репозитории базы — чуть менее 5 тыс., количество ответвлений репозитория — 225, количество звёзд — 4 тыс. [4].

ArangoDB относится к классу многомодельных систем управления базами данных и поддерживает одновременно документную, графовую и ассоциативную модели хранения. Система использует собственный язык запросов AQL, объединяющий средства работы с документами и графами. ArangoDB также поддерживает кластеризацию и распределённое хранение данных. Подробнее архитектура ArangoDB описана в [5]. Количество фиксированных изменений в репозитории — более 52 тыс., количество ответвлений репозитория — 881, количество звёзд — более 14 тыс. [6].

TigerGraph представляет собой распределённую графовую СУБД, предназначенную для обработки сверхкрупных графов и аналитических задач высокой сложности. Система поддерживает параллельное выполнение операций обхода графа и использует собственный язык запросов GSQL. Основными преимуществами TigerGraph являются высокая масштабируемость и возможность эффективной обработки графов с миллиардами вершин и рёбер. Более подробное архитектурное описание TigerGraph приведено в [7]. Исходные коды базы не являются публично доступными.

Amazon Web Services Neptune является управляемой облачной графовой СУБД, предоставляемой в инфраструктуре Amazon Web Services. Система поддерживает несколько моделей графовых данных и различные языки запросов, включая Gremlin и SPARQL. Neptune обеспечивает автоматическое масштабирование, резервирование данных и отказоустойчивость, что делает систему пригодной для промышленного применения. Список добавленных функций можно посмотреть в истории обновлений базы [8]. Исходные коды базы не являются публично доступными.

JanusGraph представляет собой распределённую графовую систему управления базами данных с открытым исходным кодом, ориентированную на обработку графов большого объёма в промышленных средах. Система совместима с языками запросов Gremlin (через фреймворк для вычислений Apache TinkerPop) и поддерживает выполнение операций обхода графа на кластерах с горизонтальным масштабированием. Архитектурные особенности JanusGraph обеспечивают высокую доступность и отказоустойчивость за счёт использования внешних бэкенд-хранилищ (Cassandra, HBase, Bigtable) и поисковых движков (Elasticsearch, Solr). В отличие от систем с нативным графовым хранением, JanusGraph отделяет управление графом от физического хранения данных, что позволяет обрабатывать графы с миллиардами вершин и рёбер, но вносит дополнительные накладные расходы на сетевые взаимодействия между компонентами. Документация системы JanusGraph доступна в [9]. Количество фиксированных изменений в репозитории — более 7,3 тыс., количество ответвлений репозитория — 1,2 тыс., количество звёзд — более 5,8 тыс. [10].

Сравнение баз данных

Общая аналитическая таблица

Корпуса Universal Dependencies обладают характерной особенностью, существенно отличающей их от типичных промышленных графовых нагрузок. Даже для наиболее полно представленных языков, таких как русский или чешский, размер аннотированного корпуса не превышает 1 ГБ. Для большинства языков объёмы оказываются ещё скромнее. Это принципиально меняет требования к архитектуре хранения данных.

В классических сценариях использования графовых баз данных — социальные сети, рекомендательные системы, графовые нейронные сети (Graph neural network, GNN) — объёмы измеряются терабайтами, и полное размещение графа в оперативной памяти становится экономически нецелесообразным или технически невозможным. Поэтому большинство коммерческих СУБД, включая Neo4j и Amazon Neptune, используют дисковое хранение с кэшированием наиболее часто используемых данных в оперативной памяти. Такой подход оправдан для больших графов, но вносит неизбежные накладные расходы: управление страницами, синхронизацию кэша и диска, предсказание паттернов доступа.

В случае с UD ситуация прямо противоположная. Поскольку весь корпус легко помещается в оперативную память даже на скромных вычислительных ресурсах (современные ноутбуки и серверы начального уровня оснащаются 16–32 ГБ RAM), использование дискового хранения становится не только избыточным, но и вредным. Дисковые операции вносят задержки на порядки выше, чем доступ к памяти, а механизмы кэширования добавляют архитектурную сложность без реальной необходимости.

Таким образом, для UD предпочтительны базы данных in-memory, которые полностью размещают граф в оперативной памяти и выполняют все операции непосредственно над данными в RAM. Такой подход обеспечивает минимальные задержки при обходах графа и полностью устраняет проблему узких мест, связанных с вводом-выводом. Из рассматриваемых систем архитектуру in-memory предлагает Memgraph. TigerGraph также обладает высокой производительностью, но её архитектура ориентирована на распределённую обработку больших данных и не даёт преимуществ на малых объёмах. Neo4j, ArangoDB, JanusGraph и Neptune являются преимущественно дисковыми системами.

Характер работы с UD-данными также существенно отличается от типичных OLTP-сценариев. Процесс загрузки корпуса в базу данных происходит, как правило, однократно — на этапе инициализации исследовательской среды. После этого все последующие операции носят исключительно аналитический характер: обход синтаксических деревьев, поиск определённых паттернов зависимостей, подсчёт статистики по типам связей, сравнение языковых структур. Запись новых данных либо отсутствует, либо происходит крайне редко (например, при добавлении вручную размеченных предложений).

Этот паттерн нагрузки имеет два важных следствия. Во-первых, требования к производительности записи минимальны. База данных не обязана поддерживать высокоинтенсивные операции вставки, обновления или удаления. Во-вторых, и это более существенно, нет необходимости в строгих гарантиях согласованности типа линейной или сериализуемой изоляции транзакций. Для аналитических задач на статичных или редко изменяющихся данных вполне достаточно модели Eventual Consistency, в которой все реплики в конечном счёте приходят к согласованному состоянию, но в конкретный момент времени могут незначительно различаться.

Отсутствие жёстких требований к согласованности открывает возможности для использования архитектур, которые были бы неприемлемы в банковских или финансовых приложениях. В частности, становится возможным развёртывание множества независимых реплик с асинхронной синхронизацией или даже с отсутствием синхронизации в реальном времени (например, загрузка каждой реплики независимо из внешнего источника при инициализации).

Из рассматриваемых систем большинство (Neo4j, ArangoDB, JanusGraph) предоставляют полную ACID-поддержку с сильной согласованностью, что для UD-сценария является избыточным и потенциально замедляющим фактором. Memgraph, напротив, позволяет настраивать уровень согласованности и эффективно работает в режимах, не требующих строгих гарантий.

Ключевым требованием, вытекающим из описанного выше паттерна нагрузки, является необходимость эффективной параллельной аналитики. Поскольку объём данных невелик, а аналитических запросов может выполняться много (например, перебор различных лингвистических гипотез, параллельная обработка нескольких языков), возникает естественное желание масштабировать вычислительные ресурсы горизонтально.

Оптимальная архитектура для такого сценария предполагает, что на каждом узле кластера одновременно размещаются две компоненты: полная реплика графовых данных и воркер-процесс (worker), исполняющий аналитический код. Такой подход позволяет проводить вычисления локально, без передачи данных по сети между узлами. Воркер обращается к локальной реплике, выполняет необходимые обходы графа и возвращает результат. Поскольку данные не покидают узел, устраняются задержки, связанные с сетевым вводом-выводом, и повышается общая пропускная способность системы пропорционально количеству узлов. Есть два основных способа организации такой архитектуры.

Первый способ — использование федеративных реплик. Система разворачивается с несколькими независимыми экземплярами базы данных, каждый из которых содержит полную копию данных. Загрузка данных в каждую реплику может происходить независимо — например, из внешнего источника, такого как Kafka или объектное хранилище. Воркеры подключаются к «своей» реплике и выполняют анализ. Преимуществом этого подхода является полная независимость узлов (выход из строя одного из них не влияет на работу остальных), а недостатком — необходимость синхронизации данных между репликами при обновлениях. Но, как отмечалось выше, для UD-сценария с редкими записями эта проблема решается простым перезапуском загрузки.

Второй способ — использование распределённой СУБД с поддержкой параллельных запросов. В этом случае управление распределением данных и координацией запросов берёт на себя сама база данных. Это удобно, но накладывает дополнительные ограничения: как правило, требуется централизованный координатор, а запросы могут выполняться не на всех узлах одновременно. Кроме того, распределённые СУБД обычно предполагают шардирование данных (то есть разбиение графа на части), а не полные реплики на каждом узле, что увеличивает сетевой трафик при обходах, затрагивающих несколько шардов. Другой проблемой такого подхода является ограничение количества узлов в кластере базы, например в Neo4j это 20 реплик.

Для UD-сценария первый подход (независимые федеративные реплики) представляется более предпочтительным, поскольку он проще, прозрачнее и даёт исследователю полный контроль над распределением нагрузки. Из рассматриваемых систем этот подход наилучшим образом поддерживают Memgraph (через интеграцию с Kafka и возможность создания независимых реплик) и, с оговорками, TigerGraph. Neo4j с архитектурой Fabric требует централизованного координатора, а JanusGraph и ArangoDB ориентированы на шардирование, а не на полные реплики.

Несмотря на то, что архитектура in-memory является предпочтительной для UD-сценария, она создаёт уязвимость: при падении узла (сбой питания, ошибка программного обеспечения, плановое обновление) все данные, хранившиеся в оперативной памяти, теряются. Для исследовательского проекта потеря размеченного корпуса может быть неприемлема, особенно если загрузка данных была трудоёмкой или данные были получены в результате длительных вычислений.

Поэтому важно, чтобы либо база данных in-memory поддерживала устойчивое хранение — периодическую запись состояния на диск (снепшот) и ведение журнала изменений (упреждающая журнализация), — либо состояние полностью хранилось во внешней системе. Это позволяет после перезапуска восстановить состояние базы без необходимости повторной загрузки всего корпуса из внешнего источника. Memgraph реализует оба механизма: система автоматически создаёт снимки состояния с настраиваемой периодичностью и ведёт журнал упреждающей записи. В случае аварийного завершения работы Memgraph при следующем запуске восстанавливает последнее согласованное состояние из снепшота и применяет изменения из журнала. TigerGraph также имеет механизмы устойчивости, но они строятся на распределённой архитектуре и требуют развёртывания нескольких узлов. Neo4j, ArangoDB и JanusGraph, будучи дисковыми системами, по определению сохраняют данные на диске, но за это приходится платить производительностью.

Наконец, важным практическим аспектом является простота разработки. Наличие объектно-графового маппера (Object graph mapper, OGM), позволяющего описывать вершины и рёбра как классы и работать с ними через знакомые паттерны, существенно ускоряет разработку и снижает порог входа. Среди рассматриваемых систем только у TigerGraph нет развитой поддержки OGM.

Использование предлагаемой схемы для машинного обучения

Предлагаемая архитектура, объединяющая графовую базу данных in-memory Memgraph и библиотеку Stanza для парсинга CoNLL‑U, также будет эффективно работать с алгоритмами машинного обучения. Выбранная топология с множеством независимых реплик, содержащих полные копии графа синтаксических зависимостей, и локальных воркеров-обработчиков на каждом узле обеспечивает максимальную пропускную способность при выполнении вычислительно интенсивных задач.

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

Статичный характер UD-корпусов (однократная загрузка с последующим отсутствием изменений) создаёт благоприятные условия для предварительного вычисления и кэширования признаков. Структуры синтаксических деревьев могут быть заранее преобразованы в необходимую форму и сохранены в оперативной памяти, что существенно ускоряет как обучение, так и этап предсказания. Природа in-memory системы Memgraph обеспечивает мгновенный доступ к любым вершинам и их контексту, что особенно важно для задач, требующих многократных итеративных обходов графа.

Кроме того, интеграция Memgraph с Apache Kafka предоставляет встроенный механизм для построения конвейеров потокового обучения. Новые размеченные предложения могут поступать через поток, обновлять граф на одной из реплик, а асинхронный механизм распространения изменений гарантирует, что все воркеры в конечном счёте получат актуальные данные без блокировок и простоев. Это позволяет строить адаптивные модели, которые могут быть дообучены по мере расширения корпуса.

Архитектура также эффективна для обучения моделей на небольших выборках, где критически важно быстрое извлечение релевантных паттернов из графа. Локальность вычислений в сочетании с хранением in-memory позволяет выполнять все операции максимально быстро, что делает предложенную топологию пригодной для сценариев интерактивного анализа и экспериментирования с гиперпараметрами.

Таким образом, выбранная топология не только решает задачи хранения и анализа синтаксических зависимостей Universal Dependencies, но и представляет собой оптимальную платформу для применения методов машинного обучения на графовых данных, обеспечивая максимальную пропускную способность и эффективное использование вычислительных ресурсов.

Заключение

Проведённый анализ шести графовых систем управления базами данных — Neo4j, ArangoDB, Memgraph, JanusGraph, Amazon Neptune и TigerGraph — позволил оценить их пригодность для решения задач, связанных с хранением и обработкой лингвистических корпусов в формате Universal Dependencies. На основе специфических требований, вытекающих из природы UD-данных, были сформулированы ключевые критерии выбора: объём корпусов (не более 1 ГБ) делает предпочтительной архитектуру in-memory; аналитический характер нагрузки и редкая запись позволяют использовать модели слабой согласованности; оптимальная архитектура предполагает наличие множества независимых реплик с полными копиями данных и локальными воркерами-обработчиками; дополнительные требования включают устойчивое хранение (снепшоты, упреждающая журнализация), интеграцию с внешними источниками данных, поддержку Cypher и развитую экосистему с наличием объектно-графового маппера.

Сравнительный анализ показал, что большинство рассматриваемых систем изначально проектировались для иных сценариев использования. Neo4j, являясь отраслевым стандартом и обладая наиболее зрелой экосистемой, страдает от архитектуры on-disk и ограниченности горизонтального масштабирования. ArangoDB предоставляет мультимодельную гибкость и бесплатное шардирование, но цена за это —снижение производительности графовых обходов из-за надстройки графа поверх документной модели. JanusGraph ориентирована на промышленные масштабы, но её избыточная сложность и высокие операционные затраты делают систему непригодной для исследовательских проектов на малых данных. Amazon Neptune и TigerGraph являются промышленными базами данных, которые также заточены под большие объёмы и работу с диском.

Наиболее сбалансированным решением, которое наилучшим образом соответствует сформулированным критериям, является Memgraph. Архитектура in-memory этой системы позволяет полностью разместить UD-корпус в оперативной памяти, обеспечивая минимальные задержки при обходах синтаксических деревьев. Поддержка горизонтального масштабирования с независимыми репликами, каждая из которых содержит полную копию данных, соответствует оптимальному паттерну размещения аналитического кода непосредственно на узле с данными. Интеграция с Apache Kafka предоставляет механизм независимой загрузки реплик из внешнего источника, что упрощает федеративную архитектуру. Механизмы устойчивого хранения (снепшоты, упреждающая журнализация) гарантируют восстановление состояния после перезапуска без необходимости повторной загрузки корпуса. Полная совместимость с языком Cypher обеспечивает переносимость запросов и снижает порог входа, а официальная библиотека GQLAlchemy предоставляет развитую поддержку Python с объектно-графовым отображением.

Вместе с тем необходимо отметить, что представленный анализ носит теоретический характер и основан на изучении документации, отраслевых обзоров и результатов независимых тестов, выполненных в иных контекстах. Для получения окончательного и обоснованного заключения о производительности каждой из рассмотренных систем применительно к конкретной задаче Universal Dependencies требуется проведение дополнительного нагрузочного тестирования. В рамках такого исследования необходимо выполнить нагрузочное тестирование каждой графовой СУБД по отдельности в фиксированном, строго контролируемом окружении. Только на основе количественных результатов такого нагрузочного тестирования можно будет сделать окончательный вывод о том, какая из систем действительно обеспечивает наилучшую производительность и наиболее эффективно использует ресурсы для задач Universal Dependencies. Подробнее нагрузочное тестирование графовых баз данных описано в [11; 12].

Литература:

1. Clustering. — Текст: электронный // neo4j.com: [сайт]. — URL: https://neo4j.com/docs/operations-manual/current/clustering/ (дата обращения: 18.05.2026).
2. Neo4j. — Текст: электронный // github.com: [сайт]. — URL: https://github.com/neo4j/neo4j (дата обращения: 16.05.2026).
3. How high availability works in Memgraph. — Текст: электронный // memgraph.com: [сайт]. — URL: https://memgraph.com/docs/clustering/high-availability/how-high-availability-works (дата обращения: 16.05.2026).
4. Memgraph. — Текст: электронный // GitHub: [сайт]. — URL: https://github.com/memgraph/memgraph (дата обращения: 15.05.2026).
5. Cluster deployments. — Текст: электронный // ArangoDB Documentation: [сайт]. — URL: https://docs.arango.ai/arangodb/stable/deploy/cluster/ (дата обращения: 18.05.2026).
6. ArangoDB. — Текст: электронный // GitHub: [сайт]. — URL: https://github.com/arangodb/arangodb (дата обращения: 18.05.2026).
7. TigerGraph: A Native MPP Graph Database. — Текст: электронный // arxiv.org: [сайт]. — URL: https://arxiv.org/pdf/1901.08248 (дата обращения: 21.05.2026).
8. Changes and Updates to Amazon Neptune. — Текст: электронный // aws.amazon.com: [сайт]. — URL: https://docs.aws.amazon.com/neptune/latest/userguide/doc-history.html (дата обращения: 17.05.2026).
9. Architectural Overview. — Текст: электронный // janusgraph.org: [сайт]. — URL: https://docs.janusgraph.org/getting-started/architecture/ (дата обращения: 14.05.2026).
10. JanusGraph. — Текст: электронный // GitHub: [сайт]. — URL: https://github.com/JanusGraph/janusgraph (дата обращения: 14.05.2026).
11. Robert Campbell McColl, David Ediger, Jason Poovey, Dan Campbell and David A. Bader A Performance Evaluation of Open Source Graph Databases // Proceedings of the first workshop on Parallel programming for analytics applications. — 2014. — № 14. — С. 11–18.
12. Timothy G. Armstrong, Vamsi Ponnekanti, Dhruba Borthakur and Mark Callaghan LinkBench: a Database Benchmark Based on the Facebook Social Graph // SIGMOD '13: Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data. — 2013. — № 1. — С. 1185–1196.