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

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

1 голос
/ 04 октября 2019

Я проверяю запрос 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 секунд? Я что-то упустил?

1 Ответ

1 голос
/ 11 октября 2019

В соответствии со спецификацией 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'
}

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

...