Question

背景：14M三倍，Blazegraph工作台。我目前正在尝试设计组合SELECT和ASK的查询。更准确地说，我想在我的图表中选择假设为真的结果。

对于我的例子，想象我有很多书有一位作者和一位编辑。我想从作者中选择他的书通过随机路径长度属性链接到client#1的书。

就我而言，使用我的数据，需要花费大量时间直接实现查询：

SELECT ?id_book
WHERE {?id_book prefix:hasAuthor :author#1.
        ?id_book prefix:linkedToEditor*/prefix:hasClient :client#1}
ORDER by ?id_book

为了减少演算时间（x 1：1000），我正在使用脚本连续实现这些查询。该脚本选择作者为作者n°1：

的书籍

SELECT ?id_book
WHERE {?id_book prefix:hasAuthor :author#1}
ORDER by ?id_book

我要求每个结果为1到n（id_book#1，id_book#2，...，id_book#n）如果它与客户端n°1相关联：

ASK {id_book#i prefix:linkedToEditor*/prefix:hasClient :client#1}

对于相同结果，后跟ASK查询的SELECT查询比第一个SELECT查询要快得多。我不想探索?id_book prefix:linkedToEditor*/prefix:hasClient :client#1的所有可能性;我只想在链接存在的地方保存结果。我尝试使用FILTER EXISTS或两个SELECT查询，但查询时间同样很长：

SELECT ?id_book
WHERE {?id_book prefix:hasAuthor :author#1.}
FILTER EXIST {?id_book prefix:linkedToEditor*/prefix:hasClient :client#1}
ORDER by ?id_book

或

SELECT ?id_book
WHERE {?id_book prefix:linkedToEditor*/prefix:hasClient :client#1.
    {SELECT ?id_book
        WHERE {?id_book prefix:hasAuthor :author#1.}
    }
}

如何将查询优化为一个查询？

Answer 1

有点令人惊讶的是，您的查询时间存在这样的差异; SPARQL引擎应该能够优化查询以首先执行简单部分，然后再执行更复杂的查询属性路径。排序也可能会导致一些时间的增加，如果你只对布尔结果感兴趣，那么它真的不重要。

无论如何，由于嵌套查询首先在最里面执行，你可以先强制执行，然后执行此操作，然后执行此操作。通过嵌套这样的查询：

select ?id_book {
  #-- first, get the books by author one
  { select ?id_book { ?id_book prefix:hasAuthor :author#1 } }

  #-- then, then check that the book is related to client one
  ?id_book prefix:linkedToEditor*/prefix:hasClient :client#1
}
order by ?id_book

在同一查询

1 个答案: