第一个问题:我想知道存储库是否会随着时间的推移而变得巨大并且我想对其运行查询,速度性能会受到影响吗?
是的。大小影响查询性能的程度取决于许多因素,最重要的是您使用的实际数据库实现,您如何配置该数据库,还取决于您的实际数据的形状(例如类型语句的数量,等),当然还有你所做的查询类型。Sesame 是一个 quadstore框架,它带有一些内置的数据库类型(内存中的和本机的),但当然存在许多与 Sesame 兼容的第三方 RDF 数据库,每个数据库都有自己的性能特征。
第二个问题(如果第一个问题的答案是肯定的):如果我对不同的三元组集使用命名图,并对它们运行查询,我会比在整个存储库上正常运行它们更快地检索结果吗?
同样,它取决于您使用的数据库及其配置,以及您使用的查询类型。
假设您正在使用 Sesame 本地存储,并且已启用至少一个索引,其中命名图(或在 Sesame 中称为“上下文”)是主键(例如cspo
)-此外,您还有通常的默认值指数(即spoc
和posc
)。在这种情况下,如果可以将命名图用作过滤器(即命名图本身预先选择总潜在结果的特定子集),则使用命名图可以在性能上产生显着差异:查询计划器可以使用cspo
索引快速放大整个存储库的一个小得多的子集。
但是请注意,在您的特定示例查询中,这并不重要:在您的示例中,您假设所有类型的资源都csm:someClass
恰好出现在一个特定的命名图中(如果不是这种情况,这两个查询当然不会返回相同的结果),因此实际上选择该命名图并不会进一步减少潜在的答案集(与仅选择类型的所有资源相比csm:someClass
)。
更详细地解释:查询引擎将为查询中的每个图形模式在索引中进行查找。第一个模式 ( ?a a csm:someClass
) 查找成本最低,因为它只有一个自由变量。引擎将posc
为此目的使用索引,因为它知道该索引的前两个键。查询的第二个模式将由第一个的结果启动(因此?a
将由第一个查找的结果实例化)。在带有命名图的查询中,引擎将选择cspo
索引,因为我们知道c
和s
。在没有命名图的查询中,它将选择spoc
索引,因为我们知道s
(但不知道c
)。然而,因为具有该特定值的所有值s
总是出现在同一个命名图中,所以两个查找实际上将覆盖几乎完全相同数量的值:所有可能的值组合o
和p
。spoc
索引当然也会超过,但它c
永远只有一个值,所以它是一个非常快速的查找。因此,两个索引都将在非常可比的时间内返回它们的结果,并且c
提前知道并不会提高性能(顺便说一句,我在这里有点过分简化了查询引擎的工作来说明这一点)。
命名图是用于数据组织目的的一个很好的工具,如果你有它们,在查询中使用它们是一个好主意,因为它可以帮助提高性能(并且肯定不会受到伤害)。但我不会纯粹出于查询性能的目的在命名图中组织我的数据。