1

我有一个相当小的图表,其中包含大约 500k 三元组。我还生成了 stats.opt 文件并在相当快的计算机(四核、16gb 内存、ssd 驱动器)上运行我的代码。但是对于我在 OP 接口的帮助下构建的查询,它需要永远遍历结果集。结果集大约有15000行,迭代需要4s,这对于最终用户来说是无法接受的。执行查询只需要 90 毫秒(我猜真正的工作是由游标迭代完成的?)。为什么这么慢,我该怎么做才能加快结果集迭代?

这是查询:

SELECT  ?apartment ?price ?hasBalcony ?lat ?long ?label ?hasImage ?park ?supermarket ?rooms ?area ?street
WHERE
  { ?apartment dssd:hasBalcony ?hasBalcony .
    ?apartment wgs84:lat ?lat .
    ?apartment wgs84:long ?long .
    ?apartment rdfs:label ?label .
    ?apartment dssd:hasImage ?hasImage .
    ?apartment dssd:hasNearby ?hasNearbyPark .
    ?hasNearbyPark dssd:hasNearbyPark ?park .
    ?apartment dssd:hasNearby ?hasNearbySupermarket .
    ?hasNearbySupermarket dssd:hasNearbySupermarket ?supermarket .
    ?apartment dssd:price ?price .
    ?apartment dssd:rooms ?rooms .
    ?apartment dssd:area ?area .
    ?apartment vcard:hasAddress ?address .
    ?address vcard:streetAddress ?street
    FILTER ( ?hasBalcony = true )
    FILTER ( ?price <= 1000.0e0 )
    FILTER ( ?price >= 650.0e0 )
    FILTER ( ?rooms <= 4.0e0 )
    FILTER ( ?rooms >= 3.0e0 )
    FILTER ( ?area <= 100.0e0 )
    FILTER ( ?area >= 60.0e0 )
  }    

(有没有更好的方法来查询这些 bnode:?hasNearbyPark,?hasNearbySupermarket)

以及执行查询的代码:

dataset.begin(ReadWrite.READ);
Model model = dataset.getNamedModel("http://example.com");
QueryExecution queryExecution = QueryExecutionFactory.create(buildQuery(), model);
ResultSet resultSet = queryExecution.execSelect();
while ( resultSet.hasNext() ) {
    QuerySolution solution = resultSet.next(); ...
4

1 回答 1

3

在 ARQ 查询引擎上

首先,您似乎误解了 ARQ 引擎的工作原理:

ResultSet resultSet = queryExecution.execSelect();

以上所做的只是为引擎如何评估查询准备一个查询计划,它实际上并没有评估查询,因此它几乎是即时的。

hasNext()在您开始致电和之前,不会发生回答您问题的实际工作next()

while ( resultSet.hasNext() ) {
   QuerySolution solution = resultSet.next(); ...

因此,您引用的时间不正确,查询需要 4 秒来评估,因为这是迭代所有结果所需的时间。

关于你的实际问题

您还没有展示您的buildQuery()方法的作用,但您说您正在以Op编程方式将查询构建为结构而不是字符串?如果是这种情况,那么查询引擎可能实际上并没有应用优化,尽管我不认为这将是问题。您可以尝试op = Algebra.optimize(op);在返回构建之前添加一个,Op但我不知道这会产生很大的不同。

看起来优化器应该在给定原始查询的情况下做得很好(并不是说您的查询除了连接重新排序之外还有很多优化空间)但是如果您以编程方式构建它,那么您可能正在构建一个不寻常的代数,优化器正在努力解决.

同样,我不确定您stats.opt的文件是否会受到尊重,因为您查询的是特定模型而不是 TDB 数据集,因此查询引擎可能是通用目的,而不是 TDB 引擎。我不是 TDB 方面的专家,所以我不知道是否是这种情况。

底线

通常,您的问题中没有足够的信息来诊断您的设置中是否存在实际问题,或者您的查询是否非常昂贵。将此作为最小测试用例(最小完整代码加上示例数据)报告给 user@jena.apache.org 列表以进行进一步分析将很有用。

作为对您的查询的一般评论,许多范围过滤器的执行成本很高,这可能是大部分时间都在使用的地方。

于 2013-08-29T19:31:20.043 回答