Медленный запрос SparQL при объединении двух наборов URI

Я проверяю запрос SparQL, который работает слишком медленно в моей системе. Очень упрощенно, запрос выглядит так:

# The whole query takes ~20 seconds
SELECT ?baseUri_s1 {

    # This takes ~1 second and returns 3000 results
    { SELECT ?baseUri_s1 {
      # Here goes some more complex business logic
      ?baseUri_s1 myOntology:hasProperty1 'myProperty1'
    } }

    # This takes ~0.1 seconds and returns 1 result
    { SELECT ?baseUri_s2 {
      # Here goes some more complex business logic
      ?baseUri_s2 myOntology:hasProperty2 'myProperty2'
    } }

    FILTER (?baseUri_s1 = ?baseUri_s2)
}

Итак, если два внутренних выбора занимают менее 1 секунды каждый... Возможно ли, что объединение списка из 3000 URI и другого списка одного URI занимает более 18 секунд? Я что-то упускаю?


graphdb sparql
person elvaras    schedule 04.10.2019    source источник
comment
почему вы используете 2 подзапроса вместо того, чтобы использовать одну и ту же переменную для обоих тройных шаблонов? SELECT ?s { ?s1 myOntology:hasProperty1 'myProperty1' . ?s1 myOntology:hasProperty2 'myProperty2' } - но да, если оба подзапроса сложные, это может занять некоторое время. Вопрос в том, сколько времени уже занимает каждый подзапрос. Действительно, мы не знаем ни ваших данных, ни сложных запросов, ни сервера, на котором вы используете тройной магазин.   -  person UninformedUser    schedule 04.10.2019
comment
Два подзапроса занимают менее секунды каждый, и, таким образом, все это вернется примерно через 1,5 секунды, если удалить строку FILTER. Подзапросы возвращают 3000 и 1 результат, поэтому с этого момента речь идет в основном о соединении обоих списков URI... и только эта последняя часть занимает 15 секунд.   -  person elvaras    schedule 04.10.2019
comment
Не могли бы вы привести пример на FactForge?   -  person Stanislav Kralin    schedule 04.10.2019
comment
что произойдет, если вы просто вернете одно и то же имя переменной в каждом подзапросе, т.е. не используете фильтр?   -  person UninformedUser    schedule 04.10.2019
comment
То же самое происходит, это все еще занимает 18-20 секунд   -  person elvaras    schedule 07.10.2019

Ответы (1)


arrow_upward
1
arrow_downward

Согласно спецификации SPARQL, каждый подвыбор будет выполняться независимо. Если первый подзапрос вернет 1 000 результатов, а второй — 300, декартово произведение двух наборов данных будет равно 300 000. Сравнение 300'00, вероятно, будет намного медленнее.

Почему вы просто не выполняете запрос как:

# The whole query takes ~20 seconds
SELECT ?baseUri_s1 {

    # Here goes some more complex business logic query 1
    ?baseUri_s myOntology:hasProperty1 'myProperty1'

    # Here goes some more complex business logic query 2
    ?baseUri_s myOntology:hasProperty2 'myProperty2'
}

Тогда вы устраните неприятный декартовский продукт между подзапросами без общих переменных, и оптимизатор запросов может ускорить некоторые из сложных оптимизаций бизнес-логики.

person vassil_momtchev    schedule 11.10.2019