GraphQL совсем не отменяет необходимость в базах данных графов, соединение очень мощное и делает GraphQL более производительным и мощным.
Вы упомянули:
Однако, если я использую GraphQL с загрузчиком данных, все мои запросы сглаживаются и объединяются с использованием загрузчика данных, так что в итоге вы выполняете более простые запросы типа SELECT * FROM X вместо каких-либо тяжелых объединений.
Это любопытный момент, потому что, если вы делаете много SELECT * FROM X и данные связаны с загрузчиком графиков, вы все еще выполняете объединения, вы просто делаете их в программном обеспечении вне базы данных, на другом уровне, с помощью других средств. Если даже этот программный уровень ничего не объединяет, то, что вы получаете, не делая объединения в базе данных, вы теряете, выполняя много запросов к базе данных, плюс накладные расходы дополнительного уровня. Посмотрите на профиль производительности последовательности этих отдельных "легко выбирает". Не выполняя эти объединения, вы, возможно, потеряли 30-летнюю ценность компьютерных исследований ... вместо того, чтобы позволить RDMBS оптимизировать путь выполнения запроса, программный уровень над ним форсирует конкретный путь, выбирая, какие из них выбираются для выполнения в каком порядке. , в это время.
Само собой разумеется, что если вам не нужно проходить какой-либо слой преобразования формализма (реляционный -> граф), вы окажетесь в лучшем положении. Поскольку этот перевод формализма - это цена, которую вы должны платить каждый раз, каждый запрос, без исключений. Это в некотором роде эквивалентно очевидному наблюдению, что базы данных XML будут лучше выполнять выражения XPath, чем реляционные базы данных, которые имеют некоторую абстракцию XPath сверху. Информатика этого проста; специализированные структуры данных для задачи обычно превосходят общие структуры данных, адаптированные к новой задаче.
Я рекомендую статью Джима Уэббера о мотивах для собственной базы данных графов , если вы хотите глубже понять, почему формат хранения и подход к обработке запросов имеют значение.
Что если это не нативная графовая база данных? Если у вас есть абстракция графа поверх СУБД, а затем вы используете GraphQL для выполнения графовых запросов к , что , то вы сместились, где и как происходит обход графа, но вы все равно не можете получить вокруг того факта, что базовая структура данных (таблицы) не оптимизирована для этого, и вы переносите дополнительные затраты на перевод.
Так что по всем этим причинам нативная графовая база данных + GraphQL будет наиболее производительным вариантом, и в результате я пришел бы к выводу, что GraphQL не делает ненужными графические базы данных, напротив, он показывает, где они светятся.
Они как шоколад и арахисовое масло. Оба великолепны, но действительно фантастичны вместе. :)