我使用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.
}
}
当存储的数据集非常巨大时？
我认为这在一定程度上取决于您正在使用的三元组存储。我主要使用命名图进行过滤（我不知道你提到分组时的意思是否相同）。我们有大量的数据和很长的查询。每个数据集都存储在同一存储库中的一个单独的命名图中。没有命名图的三元组（取决于反向链接或正向链接推理器）通常是推断的三元组。因此，为了加快查询速度，您可以根据命名图过滤一些三元组：
select *
where{
graph ?g {
?s a ?o.
}
filter (?g=<specific_graph>)
... the rest of the massive query
}
我发现这种方法加快了查询速度（尽管正如我之前提到的，它是依赖于三元组存储的，因为我只玩过一些三元组存储）。
具有命名图的另一个优点是，当您希望编写查询以仅从特定源中提取信息时。有时我们会用它来追踪数据的来源。如果你有一个API放在数据之上，你可以很容易地根据你拥有完全权限，一些权限。。。
我发现令人沮丧的是，有些三元组存储并没有那么尊重命名图。例如，如果你在一个图中有一个三元组，而你在另一个图上重写了相同的三元组，那么上下文或图可能会被覆盖，这会令人沮丧，并使基于命名图的过滤不准确。我还没有真正玩过四元商店，但我希望他们没有这个问题。我希望能在两种不同的背景下找到三元组，而不仅仅是最新的一个。
第一个问题：我想知道，如果存储库随着时间的推移变得巨大，并且我想在上面运行查询，速度性能会受到影响吗？
是的。大小对查询性能的影响程度取决于许多因素，最重要的是您使用的实际数据库实现、如何配置该数据库，但也取决于实际数据的形状（例如类型语句的数量等），当然还有您执行的查询类型。Sesame是一个四存储框架，它带有一些内置的数据库类型（内存和本机），但当然存在许多与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并不能提高性能（顺便说一句，为了说明这一点，我在这里过于简化了查询引擎的工作方式）。
命名图是用于数据组织目的的一个很好的工具，如果您有它们，那么在查询中使用它们是一个好主意，因为它可以帮助提高性能（当然不会有任何影响）。但我不会纯粹出于查询性能的目的，将数据组织在命名图中。