Question

我需要在一个非常大的存储库中修改三元组，所以为了避免内存问题，我想做一个基本的sparql更新，但是将它拆分成块。

DELETE { ?s predi:cate ?o }
INSERT { ?s predi:cate <http://whatever> }
WHERE { ?s predi:cate ?context} LIMIT 100

是我想要做的，但是我得到了限制的sparql语法错误，所以我假设不会工作。

子查询是唯一的方法吗？通过做类似的事情，我能够进一步发展：

DELETE { ?s predi:cate ?o }
INSERT { ?s predi:cate <http://whatever> }
WHERE { SELECT ?s ?o { ?s predi:cate ?o } LIMIT 100}

更新似乎在这种情况下有效，但奇怪的是，如果限制为100或100000，查询仍然需要相同的执行时间，因此它似乎不是很有效。想法？

编辑：这是完整的查询。

DELETE {
    GRAPH ?g {
        ?uri MY:URI ?context
    }
}

INSERT {
    GRAPH ?g {
        ?uri  MY:URI ?context2
    }
}

WHERE {
    GRAPH ?g {
        SELECT ?uri ?context ?context2 {
            ?uri MY:URI  ?context . 
            BIND(URI(REPLACE(STR(?context),"olddomain","newdomain") AS ?context2) } LIMIT 100
    }
}

到目前为止，它看起来像删除和插入每条记录，但它只能替换100.有没有办法重新排序，以便它只删除/插入已更改的内容？对不起，我对sparql有点新鲜

Answer 1

在重写的原始查询中，我们有：

WHERE {
    GRAPH ?g {
        SELECT ?uri ?context ?context2 {
            ?uri MY:URI  ?context . 
            BIND(URI(REPLACE(STR(?context),"olddomain","newdomain") AS ?context2)
        } LIMIT 100
    }
}

所以LIMIT在GRAPH？g内部，每个GRAPH限制为100？

点击

   WHERE
    { SELECT ?uri ?context ?context2 {
          GRAPH ?g {
            ?uri MY:URI  ?context . 
            BIND(URI(REPLACE(STR(?context),"olddomain","newdomain") AS ?context2)
          }
       } LIMIT 100
    }

如果这不是核心问题，请提供一个完整的，最小的工作示例。

Answer 2

您看到的行为可能会依赖于底层的SPARQL引擎。有限查询花费与无限查询相同的时间这一事实意味着瓶颈是查询的WHERE子句。根据您的SPARQL引擎的实现方式，添加LIMIT并不一定能更快地评估查询部分。

您可以通过仅使用更新的WHERE部分作为带有和不带LIMIT的查询来测试这一点，以查看执行时间是否大致相同。如果是这样的话，除了与供应商交谈之外，您可能无法提高性能。

对于与此相关的性能相关问题，了解您的软件和硬件环境的详细信息会有所帮助，否则您将只获得像我这样的一般推测性答案。

在sparql更新中使用LIMIT？

2 个答案: