SPARQL-запрос - почему выборка отдельных предикатов такая медленная?

Question

Когда я изучал некоторые запросы SPARQL, я заметил, что выборка отдельных предикатов чрезвычайно медленная, но при получении объектов или объектов таких проблем не возникает.

Я проверил его с использованием связанных с ним данных и выполнил следующие запросы в конечной точке связанных с ними данных (команда SERVICE в данном случае не использовалась по понятным причинам), на площадке SPARQL и на сервере Apache Jena Fuseki. Поведение было таким же. Может ли кто-нибудь помочь мне понять причину этого?

#selecting distinct subjects. Executes fast
SELECT * WHERE {
 SERVICE <http://linkedgeodata.org/sparql> {
 select distinct ?s
    where{
    ?s ?p ?o .        
    } limit 100
 }  
}

#selecting distinct predicates. VERY SLOW
SELECT * WHERE {
 SERVICE <http://linkedgeodata.org/sparql> {
 select distinct ?p
    where{
    ?s ?p ?o .        
    } limit 100
 }  
}

Answer 1

Ответил в комментариях @AKSW; перефразируя немного здесь -

Обычно схема набора данных содержит намного меньше троек, чем содержит данные экземпляра; то есть есть некоторые свойства и классы, но гораздо больше троек, которые используют каждый из этих классов и свойств.

Ваш запрос должен перебирать тройки в наборе данных до тех пор, пока не будет найдено достаточно предикатов (т.е. до LIMIT достигнуто). Это может даже привести к сканированию всего набора данных, если существует меньше предикатов, чем ваш LIMIT (здесь меньше 100).

LinkedGeoData имеет довольно небольшое количество свойств (~1805; см. Текст запроса и живой результат [занимает около 3 минут]) и довольно большое количество троек (~1 384 887 592; см. Текст запроса и живой результат [занимает около 1 минуты]), Таким образом, ваш второй запрос будет намного медленнее.

Индекс предиката, безусловно, ускорит этот запрос; он просто не является индексом по умолчанию в базах данных Virtuoso, потому что он не принесет большой пользы в большинстве распространенных сценариев (что не является этим запросом). Мы обсуждаем нашу схему индексации "3+2" по умолчанию и как добавить некоторые дополнительные, иногда полезные индексы, в документации.