Влияет ли на скорость получения результата запроса использование именованных графов?

Первый вопрос: я хотел бы знать, если репозиторий со временем станет огромным, и я хочу запускать запросы к нему, повлияет ли скорость на производительность?

да. Степень, в которой размер влияет на производительность запроса, зависит от ряда факторов, в первую очередь от фактической реализации базы данных, которую вы используете, от того, как вы настроили эту базу данных, а также от формы ваших фактических данных (например, количество операторов типов, д.), и, конечно же, типы запросов, которые вы делаете. Sesame – это платформа с четырьмя хранилищами, которая поставляется с несколькими встроенными типами баз данных (в памяти и нативными), но, конечно же, существует множество сторонних баз данных RDF, совместимых с Sesame, каждая из которых имеет свои характеристики производительности. .

Второй вопрос (если ответ на первый вопрос положительный): если я использую именованные графы для разных наборов троек и запускаю на них запросы, смогу ли я получить результат намного быстрее, чем если бы я обычно запускал их на всем репозитории?

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

Предположим, вы используете собственное хранилище Sesame и включили хотя бы один индекс, в котором именованный граф (или «контекст», как его называют в Sesame) является первичным ключом (например, cspo) — и, кроме того, у вас есть обычный индексы по умолчанию (т.е. spoc и posc). В этом сценарии использование именованных графов может иметь заметное значение в производительности, если вы можете использовать его в качестве фильтра (то есть сам именованный граф предварительно выбирает определенное подмножество общего потенциального результата): планировщик запросов может использовать cspo index для быстрого увеличения гораздо меньшего подмножества всего репозитория.

Однако обратите внимание, что в ваших конкретных примерах запросов это не будет иметь большого значения: в вашем примере вы предполагаете, что все ресурсы типа csm:someClass встречаются ровно в одном конкретном именованном графе (если бы это было не так, два запроса, конечно, не возвращает тот же результат), поэтому фактический выбор этого именованного графа не приводит к дальнейшему уменьшению потенциального набора ответов (по сравнению с простым выбором всех ресурсов типа csm:someClass).

Чтобы объяснить более подробно: механизм запросов будет выполнять поиск в индексах для каждого из шаблонов графика в вашем запросе. Первый шаблон (?a a csm:someClass) является самым дешевым для поиска, так как он имеет только одну свободную переменную. Движок будет использовать для этой цели индекс posc, так как он знает первые два ключа для этого индекса. Второй шаблон запроса будет основан на результате первого (поэтому ?a будет создан на основе результата первого поиска). В запросе с именованным графиком движок выберет индекс cspo, поскольку мы знаем и c, и s. В запросе без именованного графа будет выбран индекс spoc, так как мы знаем s (но не c). Однако, поскольку все значения с этим конкретным s всегда встречаются в графе с одним и тем же именем, оба поиска фактически будут охватывать почти одинаковое количество значений: все возможные комбинации значений o и p. Индекс spoc, конечно, также будет находиться в диапазоне от c, но для него всегда будет только одно единственное значение, так что это очень быстрый поиск. Таким образом, оба индекса вернут свои результаты за очень сравнимое время, и знание c заранее не дает прироста производительности (кроме того, я несколько упрощаю работу механизма запросов, чтобы проиллюстрировать это).

Именованные графы — отличный инструмент для целей организации данных, и если они у вас есть, их использование в запросах — хорошая идея, поскольку это может повысить производительность (и уж точно не повредит). Но я бы не стал организовывать свои данные в именованные графики исключительно для повышения производительности запросов.

Я думаю, это немного зависит от используемого вами тройного магазина. Я в основном использую именованные графики для фильтрации (я не знаю, имеете ли вы в виду то же самое, когда упомянули группировку). У нас огромные объемы данных и очень длинные запросы. Каждый набор данных хранится в отдельном именованном графе в одном репозитории. Тройки без именованного графа (в зависимости от логики обратной или прямой цепочки) обычно являются предполагаемыми тройками. Итак, для ускорения запроса можно отфильтровать часть троек на основе именованного графа:

select *
   where{ 
      graph ?g {
         ?s a ?o.
      }
      filter (?g=<specific_graph>)
      ... the rest of the massive query
   }

Я обнаружил, что этот подход ускоряет запрос (хотя, как я упоминал ранее, он зависит от тройного хранилища, поскольку я играл только с несколькими тройными хранилищами).

Другое преимущество именованного графа — когда вы хотите написать запрос для извлечения информации только из определенного источника. Иногда мы используем его для отслеживания происхождения данных. Если у вас есть API, расположенный поверх данных, вы можете легко фильтровать на основе графиков, что у вас есть полные права, некоторые права, ...

Что-то, что меня разочаровало, это то, что некоторые тройные хранилища не так чтят именованный граф. Например, если у вас есть тройка на диаграмме, и вы переписываете ту же самую тройку на другой диаграмме, контекст или диаграмма могут быть перезаписаны, что раздражает и делает фильтрацию на основе именованного графа неточной. Я действительно не играл с quad-store, но я надеюсь, что у них нет этой проблемы. Я ожидаю найти тройку в двух разных контекстах, а не только в последнем.