Графовые базы данных — белые вороны в стае баз данных NoSQL. Причиной разработки большинства баз данных NoSQL стала необходимость работать на кластерах, которая привела к агрегатно-ориентированным моделям больших записей с простыми связями. Графовые базы данных появились как решение другой проблемы и поэтому имеют противоположную модель — маленькие записи со сложными связями, как показано на рис. 1.
В таком контексте этот граф — не диаграмма, а структура данных с узлами, соединенными ребрами.
Рис. 1. Пример графовой структуры
На рис. 1 показана веб-информация с очень маленькими узлами и многочисленными связями между ними. Работая с этой структурой, мы можем задавать вопросы вроде “найти книгу в категории “Базы данных”, написанную кем-то, чей друг мне нравится”.
Графовые базы данных специально предназначены для хранения такой информации — но в более крупном масштабе, чем можно показать на диаграмме. Они идеально подходят для хранения любых данных, связанных со сложными отношениями, например, социальных сетей, товарных предпочтений или правил приема на работу.
Фундаментальная модель данных графовых баз очень простая: узлы, соединенные ребрами (которые называют также дугами). Помимо этой существенной характеристики, существует много вариаций в моделях данных — в частности, в том, какие механизмы используются для хранения узлов и ребер. Например, база FlockDB, представляет собой простую совокупность узлов и ребер без какого-либо механизма для дополнительных атрибутов, Neo4J позволяет присоединять Java-объекты в качестве свойств узлов и ребер в неструктурированном виде; a Infinite Graph хранит Java-объекты, являющиеся экземплярами подклассов таких встроенных типов, как узлы и ребра.
Как только вы построите граф узлов и ребер, графовая база данных позволит вам послать запрос к сети, способной выполнять операции над запросами, относящимися к таким графам. В этом проявляется важное различие между графовыми и реляционными базами данных. Несмотря на то что реляционные базы данных могут реализовывать связи с помощью внешних ключей, операции соединения требуют навигации, которая может оказаться затратной. Следовательно, в моделях данных с большим количеством связей производительность упадет.
В графических базах данных обход узлов требует очень небольших затрат. В основном это объясняется тем, что графовые базы данных переносят большую часть работы, связанной с навигацией по связям, с момента запроса на момент вставки. Это естественно оправдывает себя в ситуациях, когда производительность запроса важнее скорости вставки.
Большую часть времени вы ищете данные, перемещаясь по ребрам сети с запросами вроде “назовите мне всех, кто любит Анну и Барбару”. Однако вам необходима
отправная точка, поэтому некоторые узлы могут быть индексированы атрибутом, например идентификатором. Таким образом, вы можете начать с поиска идентификатора (например, найти людей с именами Анна и Барбара), а затем начать перемещение по ребрам. Как видим, графовые базы предназначены для ситуаций, в которых большую часть времени вы перемещаетесь по связям.
Акцент на связях резко отличает графовые базы данных от агрегатноориентированных. Это отличие имеет несколько последствий; такие базы данных чаще работают на одном сервере, а не распределены по кластерам. Транзакции ACID должны охватывать несколько узлов и ребер, чтобы обеспечивать согласованность данных. Единственное, что связывает их с агрегатно-ориентированными базами данных, — отрицание реляционной модели и повышенное внимание специалистов, объясняемое интересом к технологии NoSQL.
