GraphQL是否否定了对图形数据库的需求

Question

使用图形数据库的大多数原因似乎是关系数据库在进行图形查询时很慢.

但是,如果我将GraphQL与数据加载器一起使用,那么我的所有查询都会使用数据加载器进行展平和组合,因此您最终会进行更简单的SELECT * FROM X类型查询,而不是进行任何繁重的连接.我甚至可能使用No-SQL数据库,这种数据通常在这些平面查询中非常快.

如果是这种情况,当与GraphQL结合使用时,是否还有Graph数据库的用例？Neo4j似乎正在推广 GraphQL.我想了解其中的优势.

Answer 1

GraphQL根本不能否定对图形数据库的需求,连接非常强大,使得GraphQL更具性能和功能.

你提到过:

但是,如果我将GraphQL与数据加载器一起使用,那么我的所有查询都会使用数据加载器进行展平和组合,因此您最终会进行更简单的SELECT*FROM X类型查询,而不是进行任何繁重的连接.

这是一个奇怪的观点,因为如果你做了很多SELECT * FROM X并且数据是通过图形加载器连接的,那么你仍然在进行连接,你只是在数据库之外的软件中,在另一层,另一层上进行连接.手段.如果即使该软件层没有加入任何东西,那么通过对数据库执行许多查询以及附加层的开销而没有在数据库中进行连接而获得的收益.查看一系列单独"简单选择"的排序的性能概况.通过不进行这些连接,你可能已经失去了30年的计算机科学研究价值......而不是让RDMBS优化查询执行路径,它上面的软件层通过选择哪个选择以哪个顺序执行来强制特定路径, 什么时候.

按理说,如果你不必经历任何形式主义转换层(关系 - >图形),你将会处于更好的位置.因为形式主义翻译是一种成本,你必须每次付费,每次查询,没有例外.这有点类似于显而易见的观察结果,即XML数据库在执行XPath表达式方面比在顶部具有一些XPath抽象的关系数据库更好.计算机科学很简单; 用于该任务的专用数据结构通常优于适用于新任务的通用数据结构.

如果您想深入了解存储格式和查询处理方法的重要性,我建议Jim Webber关于本机图数据库动机的文章.

如果它不是本机图数据库怎么办？如果你有上RDBMS之上的抽象图形,然后使用GraphQL做对图表的查询是,那么你已经转向何处以及如何图遍历发生,但你仍然无法回避的事实得到了根本数据结构(表)没有针对此进行优化,并且您在翻译中会产生额外的开销.

因此,出于所有这些原因,本机图形数据库+ GraphQL将是性能最高的选项,因此我得出结论,GraphQL不会使图形数据库变得不必要,相反,它显示了它们发光的地方.

它们就像巧克力和花生酱.两者都很棒,但真的太棒了.:)

Answer 2

是的GraphQL允许您进行某种图形查询，您可以从一个实体开始，然后探索其邻域，依此类推。

但是，如果需要图形查询的性能，则需要具有本机图形数据库。

使用GraphQL，您可以为最终用户提供强大的功能。他可以进行深层的GraphQL查询。

如果您有SQL数据库，则有两种选择：

• 计算具有大量联接的大型SQL查询（确实是个坏主意）
• 进行大量的SQL查询以检索邻域的邻域，...

如果您有本机图形数据库，它将只是一个性能良好的查询！这是一个图遍历，并且为此创建了本机图数据库。

此外，如果使用GraphQL，则将数据模型视为图形。因此，将其存储为图形似乎很明显，并且可以减少麻烦:)

我建议您阅读这篇文章：本机图数据库的动机

图加载程序的答案

使用Graph loader，您将执行很多小的查询（这是我上面回答的第二个选择），但是请等一下，...有一个缓存记录。

图形加载器只做batch和cache。

比较：

• 您需要添加另一个库并实现逻辑（更多代码）
• 您需要管理缓存。关于此主题的文档很多。（更多的内存和复杂性）
• 由于SELECT *在装载机，你总是会得到更多的数据比需要的例子：我只想id和name用户的不是他的email，birthday...（少高性能）
• ...