SPARQL 在内存中查询 GRAPH 联合？答案

【问题标题】：SPARQL query GRAPH unions in-memory?SPARQL 在内存中查询 GRAPH 联合？
【发布时间】：2020-04-15 10:54:52
【问题描述】：

我在阅读book 时遇到了这一行：

"SPARQL FROM 子句提供了另一种定义自定义联合图的方法。FROM 子句用于标识查询的默认图。最典型的用途是标识单个 RDF 图。但是，如果多个 FROM在查询中指定子句，然后这些图的内容被合并（通常在内存中）以提供联合图，它将形成查询的默认图。因此，SPARQL 的这一特性可以提供另一个组装数据集的有用的图形无关视图的方法。”

这里说“这些图被合并（通常在内存中）以提供联合图”。

我是 Apache Jena 的新手，所以这让我想到这么大的 GRAPH 联合会发生在内存中吗？

所以我使用 TDB 来存储我的图并使用 SPARQL 查询它们，我想查询“在多个 FROM 子句中给出的 2 个特定图的 GRAPH 联合”或“所有命名图的 GRAPH 联合”：

这些 UNION 会在我使用 ARQ 查询 TDB 的 Java 代码中发生在内存中吗？

这不会导致 OutOfMemory 错误很多次，因为 Graphs 可能很多吗？

这似乎是菜鸟问题，请原谅我在耶拿的初学者经验。

【问题讨论】：

我不能专门为 Apache Jena 说话，但一般来说这不是真的。我没有立即意识到任何计算内存中多个 FROM 子句的联合的 SPARQL 引擎或数据库系统（当然，除非您计算实际的内存数据库）。可能有一些我不知道的情况，但这绝对不是“典型”情况。
它不在 Apache Jena 的内存中。对图联合的每次访问都看起来像是一个图（没有重复）。在最坏的情况下，这可能会占用一些内存 - 但它只与访问的三元组成正比，而不是整个图。

标签： sparql rdf jena triplestore named-graphs

【解决方案1】：

我当然只能在这里猜测作者的意图，但他们可能只是说可以通过从每个命名图检索数据然后作为查询的一部分来处理多个 FROM 子句处理产生这些作为查询结果的联合合并。请注意，这并不意味着整个命名图都保存在内存中，只是当查询执行并迭代单个结果（在内存中）时，它将来自两个源的结果组合成一个“联合”结果。

无论如何：任何严肃的 SPARQL 数据库（包括 Jena）都不太可能通过首先将整个数据集加载到内存来处理具有多个 FROM 子句的查询。

【讨论】：

再次引用它"图被合并（通常在内存中）以提供一个联合图，它将形成查询的默认图。"我>。因此联合图形成了默认的图 for 查询。所以阅读这种观点作者并不是指个别查询结果。但是，通常将命名图带入内存是没有意义的。
如果图表是从远程 URL 读取的，那么图表很可能在内存中 - 没有本地存储数据库。当有来自本地数据库的图并集时，确实不需要物化合并图。所有事情确实访问看起来像 - 这是抑制重复。
@AndyS：您是说对于本地存储，图表不会在内存中，而对于远程存储，它们将在内存中？对于example，如果我连接到 Fuseki 服务器并使用 ARQ 执行查询，这将在 Fuseki 服务器上运行，而我的应用程序几乎没有内存消耗？
是的。 TDB 查询引擎将对访问执行联合，而不是对图本身。
@AndyS：抱歉没听懂。访问时执行？合并将在 Fuseki 服务器上发生？