SPARQL запрашивает объединения GRAPH в памяти?

Я читал книгу, где наткнулся на эту строку:

"Предложение SPARQL FROM обеспечивает еще один способ определения настраиваемых графов объединения. Предложение FROM используется для определения графа по умолчанию для запроса. Чаще всего используется для определения одного графа RDF. Однако, если указано несколько предложений FROM, в запросе содержимое этих графов объединяется (обычно в памяти) для получения графа объединения, который формирует граф по умолчанию для запроса. Таким образом, эта функция SPARQL может предоставить другой способ сборки полезное независимое от графика представление набора данных."

Здесь говорится, что «эти графы объединяются (обычно в памяти) для создания графа объединения».

Я новичок в Apache Jena, так что это заставило меня задуматься, происходят ли такие большие объединения GRAPH в памяти?

Поэтому я использую TDB для хранения своих графиков, и я запрашиваю их с помощью SPARQL, и я хочу запросить «объединение GRAPH двух конкретных графов, заданных в нескольких предложениях FROM» или «объединение GRAPH всех именованных графов»:

Будут ли эти операции UNION выполняться в памяти из моего кода Java, где я использую ARQ для запроса TDB??

Не вызовет ли это много раз ошибку OutOfMemory, поскольку графиков может быть много?

Это может показаться новичком, извините за мой опыт новичка в Йене.


sparql rdf jena triplestore named-graphs
person Siddharth Trikha    schedule 15.04.2020    source источник
comment
Я не могу говорить конкретно об Apache Jena, но в целом это неправда. Я не знаю ни одного механизма SPARQL или системы баз данных, которые вычисляют объединение нескольких предложений FROM в памяти (если, конечно, вы не считаете фактическую базу данных в памяти). Могут быть некоторые случаи этого, о которых я не знаю, но это совершенно определенно не типичный случай.   -  person Jeen Broekstra    schedule 15.04.2020
comment
Это не в памяти в Apache Jena. Каждый доступ к объединению графов выглядит так, как будто это один граф (без дубликатов). В худшем случае это может занять некоторое количество памяти, но оно пропорционально только количеству троек, а не всему графу.   -  person AndyS    schedule 16.04.2020

Ответы (1)


arrow_upward
1
arrow_downward

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

В любом случае: маловероятно, что какая-либо серьезная база данных SPARQL (включая Jena) будет обрабатывать запросы с несколькими предложениями FROM, загружая сначала весь набор данных в память.

person Jeen Broekstra    schedule 15.04.2020
comment
Процитируем еще раз: графики объединяются (обычно в памяти), чтобы получить граф объединения, который формирует граф по умолчанию для запроса.. Таким образом, объединенный граф формирует граф по умолчанию для запроса. Таким образом, читая этот вид, автор не имеет в виду отдельные результаты запроса. Однако, как правило, заносить в память названный граф не имеет смысла. - person Siddharth Trikha; 15.04.2020
comment
Если графики считываются с удаленных URL-адресов, то график, скорее всего, будет находиться в памяти — локальной базы данных для хранения нет. Когда есть объединение графов из локальной базы данных, действительно нет необходимости материализовать объединенный граф. Все, что имеет значение, это то, как выглядит доступ, то есть подавление дубликатов. - person AndyS; 16.04.2020
comment
@AndyS: Вы говорите, что для локального хранилища графики не будут в памяти, а для удаленного хранилища они будут в памяти ?? Для example Если я подключаюсь к серверу Fuseki и использую ARQ для выполнения моего запроса, это, конечно же, будет работать на сервере Fuseki с минимальным потреблением памяти в моем приложении? - person Siddharth Trikha; 16.04.2020
comment
да. Механизм запросов TDB будет выполнять объединение при доступе, а не по самим графам. - person AndyS; 16.04.2020
comment
@AndyS: Извини, не понял. Выполнять при доступе? Объединение произойдет на сервере Fuseki? - person Siddharth Trikha; 16.04.2020
comment
Предположим, есть два графа, каждый из которых имеет тройку :s :p :o. При доступе к объединению двух графов должно выглядеть так, как будто существует одна тройка, потому что граф RDF представляет собой набор троек. Это можно сделать путем предварительного вычисления объединения или путем фильтрации троек, когда приложение/SPARQL считывает график. Во всяком случае так, чтобы сохранялась иллюзия набора троек. Фильтрация при чтении должна обрабатывать только фактически прочитанные триплеты. - person AndyS; 16.04.2020
comment
Давайте продолжим это обсуждение в чате. - person Siddharth Trikha; 16.04.2020