Question

我使用Sesame服务器来存储三元组。

第一个问题

我想知道存储库是否会随着时间的推移而变大，我想对它运行查询，会不会影响性能？

第二个问题（如果第一个问题的答案是肯定的）

如果我对不同的三元组使用命名图，并对它们运行查询，我是否会比通常在整个存储库中运行它们更快地检索结果？

我想问的是 -
这个慢了吗？

PREFIX csm: <http://exmple.org/some_ontology.owl#>

SELECT ?b ?c
WHERE {
    ?a a csm:SomeClass.
    ?a ?b ?c.
}

比这个：

PREFIX csm: <http://exmple.org/some_ontology.owl#>

SELECT ?b ?c
WHERE {
    GRAPH <http://example.org/some_graph> {
      ?a a csm:SomeClass.
      ?a ?b ?c.
    }
}

当存储的数据集非常庞大时？

Answer 1

我认为这取决于你正在使用的triplestore。我主要使用命名图是用于过滤（当你提到分组时我不知道你的意思是否相同）。我们有大量的数据和非常长的查询。每个数据集都存储在同一存储库中的单独命名图中。没有命名图形的三元组（取决于后向链接或前向链接推理器）通常是推断的三元组。因此，为了加快查询速度，您可以根据命名图过滤一些三元组：

select *
   where{ 
      graph ?g {
         ?s a ?o.
      }
      filter (?g=<specific_graph>)
      ... the rest of the massive query
   }

我发现这种方法可以加快查询速度（尽管正如我之前提到的那样，它依赖于三重存储，因为我只玩了很多三重存储）。

拥有命名图的另一个好处是，当您要编写查询以仅从特定源中提取信息时。有时我们会用它来跟踪数据的来源。如果您有一个位于数据顶部的API，您可以根据您拥有完整权利，某些权利的图表轻松过滤......

我发现令人沮丧的是，有些三重商店并没有像那样尊重命名图。例如，如果图表中有三元组，并且您在另一个图形中重写相同的三元组，则上下文或图形可能会被覆盖，这令人沮丧，并使基于命名图形的过滤不准确。我还没有真正玩四元店，但我希望他们没有这个问题。我希望在两种不同的环境中找到三联，而不是只有最新的一种。

Answer 2

第一个问题：我想知道存储库是否会随着时间的推移而变得越来越大并且我想对它运行查询，会加速性能的影响吗？

是。大小影响查询性能的程度取决于许多因素，最重要的是您使用的实际数据库实现，您如何配置该数据库，还取决于您的实际数据的形状（例如，类型的数量 - 语句等），当然还有你所做的查询类型。 Sesame是一个四元组框架，它带有一些内置数据库类型（内存和本机），但当然存在许多第三方兼容Sesame的RDF数据库，每个数据库都有自己的性能特征。

第二个问题（如果第一个问题的答案是肯定的）：如果我对不同的三元组使用命名图，并对它们运行查询，我是否会比通常在运行它们时更快地检索结果整个存储库？

同样，它取决于您使用的数据库及其配置，以及您使用的查询类型。

假设您正在使用Sesame本机存储，并且至少启用了一个索引，其中命名图（或者＆＃34; context＆＃34;在Sesame中调用）是主键（例如cspo） - 此外，您还有通常的默认索引（即spoc和posc）。在这种情况下，如果您可以将命名图用作过滤器（即，命名图本身预先选择总潜在结果的特定子集），则使用命名图可以在性能上产生显着差异：查询规划器可以使用{ {1}}索引可以快速放大整个存储库的一个小得多的子集。

但请注意，在您的特定示例查询中，它并不重要：在您的示例中，您假设所有类型cspo的资源都出现在一个特定的命名图中（如果不是如果两个查询当然不会返回相同的结果），那么实际选择该命名图不会进一步减少潜在的答案集（与仅选择csm:someClass类型的所有资源相比）。

要更详细地解释：查询引擎将在查询中为每个图形模式执行查找。第一个模式（csm:someClass）是最便宜的查找，因为它只有一个自由变量。引擎将使用?a a csm:someClass索引来实现此目的，因为它知道此索引的前两个键。查询的第二种模式将由第一种模式的结果引发（因此posc将由第一次查找的结果实例化）。在查询 with 命名图中，引擎将选择?a索引，因为我们知道cspo和c。在查询不带命名图的情况下，它会选择s索引，因为我们知道spoc（但不是s）。但是，因为具有该特定c的所有值始终出现在同一个命名图中，所以两个查找实际上将在几乎完全相同的值数范围内进行：{的所有可能值组合{1}}和s。 o索引当然也会超过p，但它只会有一个值，所以它是一个非常快速的查找。因此，两个索引都会在非常可比的时间内返回结果，并且提前知道spoc并不会提升性能（另外，我在某种程度上过于简化了查询引擎的工作，以说明这一点）。

命名图是一个很好的数据组织工具，如果你有它们，在你的查询中使用它们是一个好主意，因为它可以帮助提高性能（并且肯定不会受到伤害）。但是出于查询性能的考虑，我不会在命名图纯粹中组织我的数据。

检索查询结果的速度是否受使用命名图影响？

2 个答案: