SPARQL:OFFSET 没有 ORDER BY 来获取查询的所有结果?
SPARQL : OFFSET whithout ORDER BY to get all results of a query?
我有一个很大的 TDB 数据集(参见 post ),我需要提取数据以制作 "subgraph" 并将其导入 fuseki。
我发现如果这些结果太多(大约 12M 三元组),OFFSET
可能是获取查询所有结果的解决方案。
这是我的问题:
1) 我读到 W3C 的建议 OFFSET
应该与 ORDER BY
一起使用:
Using LIMIT and OFFSET (...) will not be useful unless the order is
made predictable by using ORDER BY.
(比照https://www.w3.org/TR/rdf-sparql-query/#modOffset)
-- 不幸的是,ORDER BY
在我的数据集上似乎很长。我发现了一些没有 ORDER BY 的 OFFSET 示例(这里有一个:Getting list of persons using SPARQL dbpedia),所以我尝试单独使用 OFFSET
,它似乎有效。
-- 我需要确保如果我重复相同的查询,我将获得所有结果。因此,我尝试了一个样本,并检查了结果是否给出了不同的值和预期的数字,一切似乎都很好。
所以我假设只有在 2 个查询之间修改数据集时才需要 ORDER BY ("predictable order")?
2)性能是否取决于比率limit/offset?
-- 我试过LIMIT = 100, 1000, 5000, 10000,偏移量一样,速度好像差不多。
-- 还尝试比较不同的 OFFSET 值,似乎大偏移量的执行时间更长(但也许这只是 TDB 的问题:cf : https://www.mail-archive.com/users@jena.apache.org/msg13806.html)
~~~~~~ 更多信息 ~~~~~~
-- 我使用带有 tdbquery
的脚本和此命令:
./tdbquery --loc=$DATASET --time --results=ttl "$PREFIXES construct { ?exp dcterms:title ?titre } where { ?manif dcterms:title ?titre ; rdarelationships:expressionManifested ?exp } limit $LIMIT offset $OFFSET"
-- 数据集:~168M 三元组和~12M 三元组 dcterms:title 。
~~~~~~~~~~~~~~~~~~~~~~
提前致谢
谢谢 AKSW 和 Andy,您的评论帮助我了解了 Sparql。
所以我尝试用SELECT REDUCED
,但是很长,不用OFFSET
进程也停不下来。此外,我需要转换结果以生成新图(并且我想对作者等进行其他转换)。
我阅读了一些关于流、模型和序列化的页面,发现我可以在同一查询中通过多次更新直接转换数据。这是一个可能的解决方案:首先复制 TDB 文件,然后在 while 循环中使用此查询:
DELETE {
?manif dcterms:title ?titre ;
rdarelationships:expressionManifested ?exp
}
INSERT {
graph <http://titres_1> {
?manif rdarelationships:expressionManifested ?exp .
?exp dcterms:titre ?titre
}
}
WHERE {
select * where
{
?manif dcterms:title ?titre ;
rdarelationships:expressionManifested ?exp
}
LIMIT 100000
}
这个解决方案有几个优点:
- 很简单,没有java代码(我不知道Jena 类和Java,现在没时间学习)也没有文件处理。
- 我可以在需要时停止进程。
- 每次都删除结果可以确保检索到所有匹配的三元组
- 每次删除后,默认图都会变小,因此查询应该会越来越高效
也许可以做一些更有效的事情:任何想法都将不胜感激。
----- 编辑 ----------
我已经开始转换数据,使用 bash 脚本重复查询,并 s-get ... | split
将三元组导出到 .nt 文件中。每次导出后,"temp" 图形都会用 s-update 清除。
一切似乎都还好,但是
- 比我想象的要花费 更多的时间(50 x 限制 = 10 000 的查询大约需要 1 小时)。
- 我的 TDB 文件现在 比我想象的要大得多。就好像被删除的三元组并没有真正被删除(它们是否存储在某些 "backup" 图中?或者可能只修改了索引?)。转换前:默认图中有 168 300 000 个三元组,TDB 文件有 20,6 Go。现在:默认图表中有 155 100 000 个,文件有 55 个...
因此,2个问题:
- a) 这是 "normal" 行为吗?我可以减小文件的大小(不仅是存储问题,我认为下一个查询应该更快)?
- b) 您是否知道另一种方法,使用命令行实用程序,这可能会更快?
提前致谢
最后编辑
文件大小和性能似乎取决于可以在 tdb.cfg
文件中设置的参数:参见 http://jena.apache.org/documentation/tdb/store-parameters.html。
我的数据集文件夹中没有任何 .cfg 文件。我做的第一个测试是添加一个并将 tdb.file_mode
更改为 'direct' :文件的大小似乎没有像以前那样增长。但是,它会消耗更多 RAM 并且查询速度会降低(即使我增加了 java -Xms 和 -Xmx)。我认为文件大小和查询性能之间存在 'tradeoff'。如果我有时间,我会订阅 jena-users 邮件列表,询问什么是最好的 'tuning'。
结论:测试查询很有趣,但是我的数据集太大了;我将使用带有命名图形的原始 xml 文件制作另一个(但使用 tdbloader2 不允许这样做)或几个较小的数据集。
我有一个很大的 TDB 数据集(参见 post OFFSET
可能是获取查询所有结果的解决方案。
这是我的问题:
1) 我读到 W3C 的建议 OFFSET
应该与 ORDER BY
一起使用:
Using LIMIT and OFFSET (...) will not be useful unless the order is made predictable by using ORDER BY.
(比照https://www.w3.org/TR/rdf-sparql-query/#modOffset)
-- 不幸的是,ORDER BY
在我的数据集上似乎很长。我发现了一些没有 ORDER BY 的 OFFSET 示例(这里有一个:Getting list of persons using SPARQL dbpedia),所以我尝试单独使用 OFFSET
,它似乎有效。
-- 我需要确保如果我重复相同的查询,我将获得所有结果。因此,我尝试了一个样本,并检查了结果是否给出了不同的值和预期的数字,一切似乎都很好。 所以我假设只有在 2 个查询之间修改数据集时才需要 ORDER BY ("predictable order")?
2)性能是否取决于比率limit/offset?
-- 我试过LIMIT = 100, 1000, 5000, 10000,偏移量一样,速度好像差不多。
-- 还尝试比较不同的 OFFSET 值,似乎大偏移量的执行时间更长(但也许这只是 TDB 的问题:cf : https://www.mail-archive.com/users@jena.apache.org/msg13806.html)
~~~~~~ 更多信息 ~~~~~~
-- 我使用带有 tdbquery
的脚本和此命令:
./tdbquery --loc=$DATASET --time --results=ttl "$PREFIXES construct { ?exp dcterms:title ?titre } where { ?manif dcterms:title ?titre ; rdarelationships:expressionManifested ?exp } limit $LIMIT offset $OFFSET"
-- 数据集:~168M 三元组和~12M 三元组 dcterms:title 。
~~~~~~~~~~~~~~~~~~~~~~
提前致谢
谢谢 AKSW 和 Andy,您的评论帮助我了解了 Sparql。
所以我尝试用SELECT REDUCED
,但是很长,不用OFFSET
进程也停不下来。此外,我需要转换结果以生成新图(并且我想对作者等进行其他转换)。
我阅读了一些关于流、模型和序列化的页面,发现我可以在同一查询中通过多次更新直接转换数据。这是一个可能的解决方案:首先复制 TDB 文件,然后在 while 循环中使用此查询:
DELETE {
?manif dcterms:title ?titre ;
rdarelationships:expressionManifested ?exp
}
INSERT {
graph <http://titres_1> {
?manif rdarelationships:expressionManifested ?exp .
?exp dcterms:titre ?titre
}
}
WHERE {
select * where
{
?manif dcterms:title ?titre ;
rdarelationships:expressionManifested ?exp
}
LIMIT 100000
}
这个解决方案有几个优点:
- 很简单,没有java代码(我不知道Jena 类和Java,现在没时间学习)也没有文件处理。
- 我可以在需要时停止进程。
- 每次都删除结果可以确保检索到所有匹配的三元组
- 每次删除后,默认图都会变小,因此查询应该会越来越高效
也许可以做一些更有效的事情:任何想法都将不胜感激。
----- 编辑 ----------
我已经开始转换数据,使用 bash 脚本重复查询,并 s-get ... | split
将三元组导出到 .nt 文件中。每次导出后,"temp" 图形都会用 s-update 清除。
一切似乎都还好,但是
- 比我想象的要花费 更多的时间(50 x 限制 = 10 000 的查询大约需要 1 小时)。
- 我的 TDB 文件现在 比我想象的要大得多。就好像被删除的三元组并没有真正被删除(它们是否存储在某些 "backup" 图中?或者可能只修改了索引?)。转换前:默认图中有 168 300 000 个三元组,TDB 文件有 20,6 Go。现在:默认图表中有 155 100 000 个,文件有 55 个...
因此,2个问题:
- a) 这是 "normal" 行为吗?我可以减小文件的大小(不仅是存储问题,我认为下一个查询应该更快)?
- b) 您是否知道另一种方法,使用命令行实用程序,这可能会更快?
提前致谢
最后编辑
文件大小和性能似乎取决于可以在 tdb.cfg
文件中设置的参数:参见 http://jena.apache.org/documentation/tdb/store-parameters.html。
我的数据集文件夹中没有任何 .cfg 文件。我做的第一个测试是添加一个并将 tdb.file_mode
更改为 'direct' :文件的大小似乎没有像以前那样增长。但是,它会消耗更多 RAM 并且查询速度会降低(即使我增加了 java -Xms 和 -Xmx)。我认为文件大小和查询性能之间存在 'tradeoff'。如果我有时间,我会订阅 jena-users 邮件列表,询问什么是最好的 'tuning'。
结论:测试查询很有趣,但是我的数据集太大了;我将使用带有命名图形的原始 xml 文件制作另一个(但使用 tdbloader2 不允许这样做)或几个较小的数据集。