ГРАФОВАЯ БАЗА ДАННЫХ NEO4J ДЛЯ ПРОЕКТИРОВАНИЯ ВЫСОКОНАГРУЖЕННЫХ СИСТЕМ

Аннотация. В работе представлены особенности графовых баз данных, указаны ситуации, в которых целесообразным является переход от реляционных хранилищ к графовым. Рассмотрена наиболее популярная на сегодняшний день база Neo4j. Перечислены основные преимущества.

Ключевые слова: NoSQL, графовая база данных, Neo4j.

Многие системы и приложения сегодня относятся к категории высоконагруженных данными (data-intensive), в отличие от высоконагруженных вычислениями (computeintensive). При этом производительность процессора — просто ограничивающий фактор для этих приложений, а основная проблема заключается в объеме данных, их сложности и скорости изменения. Высоконагруженное данными приложение (DIA, data-intensive application) обычно создается из стандартных блоков, обеспечивающих часто требующуюся функциональность. Так, им нужно: хранить данные, чтобы эти или другие приложения могли найти их в дальнейшем (базы данных); запоминать результат ресурсоемкой операции для ускорения чтения (кэши); предоставлять пользователям возможность искать данные по ключевому слову или фильтровать их (поисковые индексы); отправлять сообщения другим процессам для асинхронной обработки (потоковая обработка) [4].

При создании приложения большинство разработчиков и не помышляют о создании с нуля новой подсистемы хранения, поскольку базы данных –инструмент, отлично подходящий для этой задачи. Но в жизни не все так просто. Существует множество систем баз данных с разнообразными характеристиками, поскольку у разных приложений — различные требования. Существует много подходов к кэшированию, несколько способов построения поисковых индексов и т. д. При создании приложения необходимо определиться с тем, с помощью каких инструментов и подходов лучше всего решать имеющуюся задачу.

Реляционная модель первой приходит на ум большинству разработчиков с опытом в области баз данных. С 1980-х годов именно реляционная модель стала занимать лидирующее положение среди средств хранения данных. Реляционные системы управления базами данных (РСУБД) основаны на теории множеств, в основе их реализации лежат двумерные таблицы, состоящие из строк и столбцов. Канонический способ взаимодействия с РСУБД – написание запросов на языке SQL (Structured Query Language).

Несмотря на то, что реляционные хранилища обеспечивают наилучшее сочетание простоты, устойчивости, гибкости, производительности, масштабируемости и совместимости, их показатели по каждому из этих пунктов не обязательно выше, чем у аналогичных систем, ориентированных на какую-то одну особенность. Однако универсальность реляционных СУБД перевешивала какие-либо другие недостатки. Сегодня ситуация несколько иная. Появившиеся так называемые NoSQL (Not only SQL, не только SQL) хранилища реализуют модели данных, имеющие существенные отличия от традиционной реляционной модели. Они создаются, чтобы расширить возможности баз данных (БД) в тех областях, где реляционная модель и SQL недостаточно гибки. Создатели таких БД среди множества преимуществ использования NoSQL-решений называют высокую производительность при использовании специфических моделей данных и легкость работы с ними [1].

Связи «многие-ко-многим» — важная характеристика различных моделей данных. Если в приложении связи между записями в основном «один-ко-многим» (данные структурированы в виде деревьев) или вообще отсутствуют, то вполне подойдет документная модель. Но по мере увеличения количества связей «многие-ко-многим» и роста сложности взаимосвязей внутри данных моделирование данных в виде графа будет более естественным. Графы состоят из двух типов объектов: вершин (vertice), известных также как узлы (node) или сущности (entity), и ребер (edge), известных также как связи (relationship) или дуги (arc). В виде графа можно смоделировать множество типов данных. Например, веб-графы, где вершины – веб-страницы, а ребра отражают HTML-ссылки на другие страницы. Наконец, дороги или железнодорожные сети, в которых вершины — перекрестки (узловые станции), а ребра соответствуют пролегающим между ними дорогам или железнодорожным линиям.

Neo4j – новый тип хранилищ данных NoSQL, получивший название графовая база данных. Отличительной особенностью таких баз данных является возможность рисовать их структуру на доске в виде прямоугольных блоков и соединяющих их линий. Всё, что можно изобразить в таком виде, можно сохранить в Neo4j. В Neo4j упор делается скорее на связи между значениями, чем на общие характеристики значений (как в коллекциях документов или в строках таблицы). Таким образом, совершенно разнородные данные можно хранить просто и естественно. Размер Neo4j невелик – настолько, что ее можно внедрить практически в любое приложение. С другой стороны, в Neo4j можно хранить десятки миллиардов узлов и столько же ребер. А учитывая поддержку репликации главный-подчиненный на много серверов, эта СУБД способна справиться с задачей любого размера [3].

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

Однако использование графов не ограничивается подобными однородными данными: графы предоставляют ничуть не меньшие возможности хранения различных типов объектов в одном хранилище данных. Например, Facebook поддерживает единый граф с множеством различных типов вершин и ребер: вершины означают людей, местоположения, события, входы в систему и написанные пользователями комментарии; ребра указывают, какие люди являются друзьями, где произошел конкретный вход в систему, кто какое сообщение прокомментировал, кто какое мероприятие посетил и т. д. [4]

Neo4j – это надежная, масштабируемая и высокопроизводительная графовая база данных графиков. Графовые базы данных графиков интерпретируются для надежности данных. Хотя представление графа в Neo4j не совсем то же самое, что и традиционный список смежности, оно позволяет быстро перемещаться по графу только с помощью указателей вместо того, чтобы искать их в глобальном индексе. Для того, чтобы база данных была надежной и оставалась в согласованном состоянии при наличии параллелизма и сбоев программного и аппаратного обеспечения, системы управления базами данных должны обеспечивать поддержку транзакций. Neo4j не только предоставляет эту поддержку, но, в отличие от многих других баз данных NoSQL, требует, чтобы каждая операция выполнялась в контексте транзакции. База данных является ACID-совместимой. Термин ACID – это акроним для Atomicity, Consistency, Isolation, Durability (атомарность, согласованность, изолированность и устойчивость), которые являются самыми фундаментальными целями для большинства систем управления базами данных. Атомарные операции либо происходят полностью, либо вообще не происходят. База данных все время находятся в постоянном состоянии; например, когда узел удаляется, но все еще имеет отношения, база данных будет отвергать такое изменение и откатывать всю транзакцию. Изменения, выполненные транзакциями, которые еще не были совершены, не видны другим, одновременно выполняемым транзакциям. Наконец, после совершения транзакции изменения постоянно сохраняются на долговечном носителе (жесткий диск).

Для достижения максимальной производительности в Neo4j существует два типа кэширования: файловый кэш (file buffer cache) и объектный кэш (object cache). Первый кэширует данные с жесткого диска, целью чего является увеличение скорости чтения/записи на жесткий диск. Второй кэш хранит в себе различные объекты графа: вершины, ребра и свойства в специальном оптимизированном формате для увеличения производительности обходов графа. Также Neo4j поддерживаются алгоритмы обхода графов, в том числе можно сделать обход в ширину до заданного уровня, что как раз и необходимо для решения задачи поиска соседних вершин [1].

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

Некоторые особенности делают Neo4j очень популярным среди разработчиков, архитекторов и администраторов баз данных:

–Cypher, язык декларативных запросов, аналогичный SQL, но оптимизированный для графов. Он также используется для отображения графов.

Рисунок 1. Запрос по применению фильтра поиска по году выхода фильма на языке Cypher

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

–Возможность представления полуструктурированных данных: данные, которые не попадают в естественную структуру, могут быть легко представлены в базе данных графа.

Neo4j – NoSQL база данных, использование которой оптимально, когда для представления информации оптимально использовать графы, состоящие из вершин и ребер, когда количество этих вершин исчисляется от десятков тысяч до миллиардов, если важна скорость динамических изменений, происходящих в базе, и скорость реакции на запрос, а также если количество связей «многие-ко-многим» велико, и структура взаимосвязи сложна и неоднородна.

Список литературы:

1. Бартенев М.В., Вишняков И.Э. Использование графовых баз данных в целях оптимизации анализа биллинговой информации. Инженерный журнал: наука и инновации, 2013
2. Braimniotis M. A Transformation from ORM Conceptual Models to Neo4j Graph Database, 2017. – 91с.
3. Картер Ж., Редмонд Э., Уилсон Д.Р. Семь баз данных за семь недель. Введение в современные базы данных и идеологию NoSQL. – М.: ДМК Пресс, 2013. – 384с.
4. Клеппман М. Высоконагруженные приложения. Программирование, масштабирование, поддержка.— СПб.: Питер, 2018. – 740с.