Один разработчик взвешивает плюсы и минусы графовых баз данных и делится своими соображениями о том, что лучше всего подходит для различных сценариев использования.
Я огромный фанат графовых баз данных. Все думают, что существует только два типа баз данных: noSQL и SQL. Тем не менее, графовые базы данных — это будущее и лучший выбор!
Почему?
Графовые базы данных хранят указатели на связи напрямую. SQL-базам данных требуется обход другой таблицы с помощью операции соединения (join) или индекса.
Это ОГРОМНО! Графовой базе данных не нужно обходить таблицу соединений, чтобы что-то найти, она просто идет напрямую к месту, где расположено одно или несколько соединений.
А как же обычные сканирования? Теоретически, SQL-базы данных должны быть быстрее при базовых сканированиях таблиц с индексацией, сортировкой или агрегацией. Тем не менее, современные и новые (графовые) базы данных учли прошлые потребности СУБД. И они, пожалуй, могут сканировать с такой же скоростью при равных переменных; но скорость любой базы данных зависит от инфраструктуры, настроек базы данных и масштаба.
Компромисс графовых баз данных. SQL — зрелая технология. Это единственный достоверный компромисс.
Кратко (TL;DR)
Мы рассматриваем классические графовые базы данных, новые графовые базы данных и графовые базы данных на базе SQL, а также рассказываем, для чего они подходят лучше всего. Наиболее примечательны Progress MarkLogic и SurrealDB.
Умершие графовые базы данных — покойтесь с миром 🪦
Прежде чем перейти к современным вариантам, давайте взглянем на некоторые недавно закрытые базы данных.
Gel
Прошедшая ребрендинг из EdgeDB, Gel представляла собой мастер-класс по созданию облачной базы данных. Она предлагала встроенную аутентификацию, простое создание схем, похожее на Prisma, а также мощный и лаконичный язык запросов. Кроме того, она была построена на базе Python поверх Postgres. Это значит, что мы знали о ее стабильности.
Конечно, поскольку на самом деле это Postgres, это НЕ настоящая графовая база данных, которая «под капотом» хранит указатели вместо таблиц. Это означает, что обходы графа никогда не будут нативной скорости, как у настоящей графовой базы данных.
Что случилось? Поскольку команда Gel состояла в основном из разработчиков на Python, вся команда присоединилась к Vercel для работы над Python в облаке.
Статус: Открытый исходный код
FaunaDB
Я по собственному признанию мало что знаю о FaunaDB, но помню, когда она появилась. Это была noSQL база данных, которая умела выполнять соединения подобно графовой базе данных. Тем не менее, способ их выполнения был невероятно неинтуитивным. Вам практически приходилось вручную создавать индексы, что было непросто, и вы не могли просто легко делать к ним запросы, как к Firebase, которая, пожалуй, была ее первым конкурентом. Тем не менее, я считаю, что в последних версиях делать запросы стало проще.
Изначально она была только облачной, что означало привязку к поставщику и невозможность развернуть ее самостоятельно. Это была одна из многих проблем. Позже мы узнали, что она написана на Scala.
Что случилось? Простой ответ — у нее закончились деньги. Я лично считаю, что она не набрала достаточно пользователей из-за высокого порога входа, но это всего лишь догадка.
Статус: Открытый исходный код
Dgraph
Для меня это больная тема. Я написал десятки статей о Dgraph, создал несколько инструментов на JavaScript и в какой-то момент даже внес вклад в основной код. Была небольшая группа людей, которые были преданными фанатами, но так и не получили желаемого. Мы были очень активны в сообществе, даже несмотря на три смены владельца. Я думаю, что никто, включая основателя, не понимал того невероятного продукта и потенциала, который был у этой базы данных.
Dgraph представляла собой облачную базу данных, которая позволяла создавать схему для генерации конечной точки GraphQL для вашей базы данных без написания кода!
Что случилось? У них закончились деньги. У них были миллионы венчурных долларов, и они их все растратили. Другая большая проблема заключалась в том, что Dgraph не понимала, чем она является. Я твердо уверен, что если бы у них тогда было больше денег, они смогли бы создать нечто невероятное, и время исправило бы многие проблемы.
Изначально Dgraph была написана на языке под названием DQL. Он был настолько похож на GraphQL, что команда решила переписать запросы и создание схем на GraphQL. Facebook и GitHub сделали GraphQL популярным в то время, так что это был частый запрос. Однако вместо нативной реализации команда решила компилировать GraphQL в DQL, что еще больше всё запутало. Я подозреваю, что они не знали, что спецификация GraphQL в ее изначальном виде не может обслуживать каждый базовый сценарий использования и имеет серьезные концептуальные пробелы.
Эти два языка разделили пользователей пополам. С одной стороны, были государственные платные пользователи, использующие ее как графовую базу данных без компонента GraphQL, а с другой — веб-разработчики, использующие компонент GraphQL для создания приложений. И то, и другое было сырым и не имело всех необходимых функций. Компонент GraphQL имел некоторые крупные неразрешенные проблемы безопасности, в то время как DQL не могла выполнять некоторые из базовых функций обхода, которые умела neo4j. Ей требовалось больше алгоритмов.
Ее покупали три или четыре раза, в какой-то момент существовало по меньшей мере два активных форка, о которых мне известно, и я полагаю, что некоторые некоммерческие организации или государственные контракты используют ее по сей день. Она по-прежнему поддерживается, но я не видел никаких новых функций в разработке, кроме обслуживания.
Статус: Открытый исходный код
Графовые базы данных в памяти (In-Memory) 💾
Хотя они не предназначены для стандартного использования в качестве баз данных, графовые базы данных в оперативной памяти заслуживают упоминания.
MemGraph
Если вы заплатите высокую цену, вы получите RBAC, аутентификацию и аудит в MemGraph. Бесплатная версия Community не поддерживает эти функции. Как и любая база данных в памяти, она будет работать чрезвычайно быстро, но стоить будет колоссально дорого. Это отлично подходит для кэширования данных, когда вам нужен доступ к сложным графовым запросам. Запросы выполняются на Cypher, впервые представленном .
FalkorDB
Ранее известная как RedisGraph, FalkorDB чуть было не попала в раздел RIP. Тем не менее, FalkorDB очень активна и в настоящее время размещается в облаке. В ней есть базовый контроль доступа, и она также использует Cypher, но MemGraph настроена немного тоньше. FalkorDB не сильно отстает и по-прежнему совместима с экосистемой Redis.
Ненативные графовые базы данных 🛢️
Люди любят строить решения поверх SQL. Мы уже упомянули Gel, которая теперь закрыта. Также стоит упомянуть Good Cloud Spanner Graph, построенную на таблицах Spanner в SQL, другую SQL-графовую базу данных Oracle Graph Database, созданную на базе Oracle. Если вы хотите развернуть собственный графовый слой поверх SQL, вы также можете присмотреться к Puppy Graph.
Apache AGE
Хотя облачной версии Apache AGE, которую я смог бы найти, не существует, это популярное расширение для Postgres, написанное на C, которое позволяет выполнять запросы Cypher в вашей базе данных Postgres. Опять же, оно не меняет сам движок запросов для волшебного хранения указателей, но действительно расширяет возможности работы с запросами.
PostgreSQL 19
Недавно выпущенный релиз Version 19 of PostgreSQL позволяет создавать графовые колонки и выполнять запросы к графам с помощью системы запросов cypher-like. Если вы собираетесь оставаться на Postgres, это ваш лучший выбор.
JanusGraph
JanusGraph сможет бешено масштабироваться и технически быстрее любой графовой базы данных, построенной поверх SQL, но при этом она не является нативной графовой базой данных. Она построена на базе Key Value Database. Однако это может не иметь значения при работе с миллиардами узлов.
Классические графовые базы данных 🕒
Здесь представлены тяжеловесы рынка.
Progress MarkLogic
Выпущенная в 2003 году, Progress MarkLogic является одной из старейших и лучших графовых баз данных, особенно когда ваши источники разнородны. Эта корпоративная многомодельная база данных поддерживает документы, поиск и RDF-триплеты. Вы используете SPARQL для запросов и создания ориентированных на документы разрешений для обеспечения детальной безопасности. Она создана для семантического веба, а не для графов свойств.
И, конечно же, теперь она принадлежит материнской компании Telerik и Kendo UI — Progress Software:
GraphDB
Выпущенная годом позже в 2004 году (изначально OWLIM) и прошедшая ребрендинг в 2008-м, GraphDB лучше всего подходит для семантического рассуждения в базе данных хранилища RDF-триплетов. Она хороша для баз знаний с интеграцией связанных данных.
AllegroGraph
Очень похожая на GraphDB и выпущенная в 2004 году, база данных AllegroGraph представляет собой еще одну базу данных графов знаний RDF. Возможно, она лучше справляется с графовой аналитикой, чем GraphDB, но у нее нет версии с открытым исходнымходом.
Stardog
В 2010 году появилась еще одна RDF-база данных, за исключением того, что она специализируется на маппинге виртуальных графов для запросов к внешним источникам данных в реальном времени. Если вам нужна динамическая RDF-база данных, Stardog — ваш выбор.
OrientDB
Запущенная в 2010 году, OrientDB известна как первая многомодельная NoSQL база данных; MarkLogic получила многомодельные функции позже. Эта база данных может масштабироваться горизонтально, но больше известна благодаря своей NoSQL составляющей.
Neo4j
Определенно самая популярная графовая база данных, появившаяся в 2007 году. — это прародитель графовых баз данных, известный созданием языка запросов Cypher и тем, что является классическим стандартом для графов свойств.
Ее можно развернуть где угодно, хотя для детального управления доступом на основе ролей (RBAC) вам придется заплатить за корпоративную версию. Она, пожалуй, самая зрелая, но не самая быстрая.
Cosmos DB
Cosmos DB — это графовая база данных от Microsoft, выпущенная в 2017 году, которая удерживает вас в экосистеме Azure. Она также в основном представляет собой NoSQL-базу данных с графовой структурой. Поддерживает как Cypher, так и Gremlin.
Amazon Neptune
Amazon Neptune — это графовая база данных от Amazon, выпущенная в 2018 году, которая привязывает вас к Amazon. Опять же, убедитесь, что вы хотите остаться на их инфраструктуре. Она отлично подходит для скорости и графов свойств. Поддерживает как Cypher, так и Gremlin.
ArangoDB
Известная как одна из первых настоящих многомодельных баз данных 2012 года, с помощью ArangoDB вы можете хранить графы, документы или таблицы. Она использует пользовательский язык запросов AQL для получения данных.
NebulaGraph ⚠️
NebulaGraph создана для масштабирования в качестве отличного облачного сервиса графов, появившегося в 2019 году. Тем не менее, я НИКОГДА не рекомендовал бы ее использовать, так как любая база данных родом из Китая несет огромный риск безопасности для ваших данных.
TigerGraph
TigerGraph впечатляет. Выпущенная в 2017 году, это нативная графовая база данных, которая умеет масштабироваться, имеет RBAC, открытый исходный код и создана для аналитики. Тем не менее, у нее высокий порог вхождения, и она не так дружелюбна к веб-разработчикам, как Neo4j.
Новые графовые базы данных
SurrealDB
Я большой поклонник . У нее есть потенциал стать всем, чем должна быть база данных. В нее встроенны аутентификация, RBAC, функции, создание алгоритмов, полнотекстовый поиск, схемы и многое другое. Она очень новая, поэтому мне любопытно посмотреть, куда она развиваться. В настоящее время я являюсь Ambassador для этой базы данных. Я не знаю, можно ли найти все эти функции в любой другой базе данных из списка.
Helix-DB
Helix-DB не отличается изобилием функций, но стоит отдать должное тому, что она делает хорошо. Созданная для масштабирования графов знаний, векторов, темпоральных данных, полнотекстового поиска и многого другого, я нашел ее порог вхождения чрезвычайно простым. Я определенно рекомендую ее.
TypeDB
TypeDB лучше всего подходит для описания объектов. Вы храните элементы как объекты в виде сущности, атрибута или отношения. Это очень уникальная база данных, которая позволяет хранить данные как типы, наследовать элементы и выполнять запросы подобно графу.
Aerospike Graph
Масштабируемая высокопроизводительная графовая база данных. Готовая для разработчиков с минимальной совокупной стоимостью владения. Вычислительный модуль служб Aerospike Graph представляет собой распределенную реализацию с горизонтальным масштабированием фреймворца с открытым исходным кодом Apache Tinkerpop.
Победители
Как и во всем, здесь все зависит от обстоятельств. Вот где я бы назвал победителей:
Лучшая RDF и многомодельная база данных
Лучшие функции и потенциал на будущее
Лучшая чистая графовая база данных для аналитики
Лучшая база данных в памяти (In-Memory)
Лучшая для пользователей SQL
Лучший порог вхождения
Лучшая для Microsoft Azure
- Cosmos DB
Лучшая для Amazon Web Services
Лучшая для Google Cloud
Графовые базы данных — это будущее; жаль только, что они не вытеснили реляционные базы данных полностью. Я устал от соединений (joins), когда мы можем хранить связи напрямую в виде указателей.
Если вы хотите начать работу с отличной графовой базой данных для вашего веб-приложения, обратите внимание на .
Однако, когда вы будете готовы к корпоративной базе данных для запросов к многомодельной сложности, — это то, что нужно!
