Jena ARQ/TDB Оптимизация запросов

Question

У меня довольно маленький график, содержащий примерно 500 тыс. Троек. Я также сгенерировал файл stats.opt и запустил свой код на довольно быстром компьютере (четырехъядерный процессор, 16-Гбайт оперативная память, дисковод ssd). Но для запроса, который я создаю с помощью интерфейса OP, требуется вечно перебрать набор результатов. Результирующий набор содержит около 15000 строк, а итерация занимает 4 секунды, что недопустимо для конечных пользователей. Выполнение запроса занимает всего 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 )
  }    

(Есть ли лучший способ запросить эти узлы:? 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(); ...

Answer 1

На ARQ Query Engine

Прежде всего, вы, похоже, неправильно понимаете, как работает ARQ engine:

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, поэтому я не могу сказать, так ли это на самом деле.

Нижняя линия

Как правило, в вашем вопросе недостаточно информации для диагностики, если в вашей настройке действительно есть проблема или ваш запрос просто дорогой. Было бы полезно сообщить об этом в качестве минимального контрольного примера (минимальный полный код плюс примеры данных) в список [e-mail] для дальнейшего анализа.

В качестве общего комментария к вашему запросу, множество фильтров диапазона являются дорогостоящими для выполнения, что, вероятно, где большую часть времени идет.