2

我正在使用芝麻服务器来存储三元组。

第一个问题

我想知道存储库是否会随着时间的推移而增长巨大并且我想对其运行查询,速度性能会受到影响吗?

第二个问题(如果第一个问题的答案是肯定的)

如果我为不同的三元组使用命名图,并在它们上运行查询,我会比在整个存储库上正常运行它们更快地检索结果吗?

我想问的是——<br>这慢吗:

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.
    }
}

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

4

2 回答 2

1

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

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

我发现这种方法加快了查询速度(尽管正如我之前提到的,它依赖于三重存储,因为我只使用了一些三重存储)。

拥有命名图的另一个优点是当您想要编写查询以仅从特定来源提取信息时。有时我们使用它来跟踪数据的来源。如果您有一个位于数据之上的 API,您可以轻松地根据您拥有全部权限、某些权限、...

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

于 2015-11-03T21:26:32.307 回答
1

第一个问题:我想知道存储库是否会随着时间的推移而变得巨大并且我想对其运行查询,速度性能会受到影响吗?

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

第二个问题(如果第一个问题的答案是肯定的):如果我对不同的三元组集使用命名图,并对它们运行查询,我会比在整个存储库上正常运行它们更快地检索结果吗?

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

假设您正在使用 Sesame 本地存储,并且已启用至少一个索引,其中命名图(或在 Sesame 中称为“上下文”)是主键(例如cspo)-此外,您还有通常的默认值指数(即spocposc)。在这种情况下,如果可以将命名图用作过滤器(即命名图本身预先选择总潜在结果的特定子集),则使用命名图可以在性能上产生显着差异:查询计划器可以使用cspo索引快速放大整个存储库的一个小得多的子集。

但是请注意,在您的特定示例查询中,这并不重要:在您的示例中,您假设所有类型的资源都csm:someClass恰好出现在一个特定的命名图中(如果不是这种情况,这两个查询当然不会返回相同的结果),因此实际上选择该命名图并不会进一步减少潜在的答案集(与仅选择类型的所有资源相比csm:someClass)。

更详细地解释:查询引擎将为查询中的每个图形模式在索引中进行查找。第一个模式 ( ?a a csm:someClass) 查找成本最低,因为它只有一个自由变量。引擎将posc为此目的使用索引,因为它知道该索引的前两个键。查询的第二个模式将由第一个的结果启动(因此?a将由第一个查找的结果实例化)。在带有命名图的查询中,引擎将选择cspo索引,因为我们知道cs。在没有命名图的查询中,它将选择spoc索引,因为我们知道s(但不知道c)。然而,因为具有该特定值的所有值s总是出现在同一个命名图中,所以两个查找实际上将覆盖几乎完全相同数量的值:所有可能的值组合opspoc索引当然也会超过,但它c永远只有一个值,所以它是一个非常快速的查找。因此,两个索引都将在非常可比的时间内返回它们的结果,并且c提前知道并不会提高性能(顺便说一句,我在这里有点过分简化了查询引擎的工作来说明这一点)。

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

于 2015-11-08T01:44:31.023 回答