Мне просто любопытно знать, если в контексте, где транзакции не нужны, ни квадроциклы, но много запросов sparql к модели, будет ли триплетируемый превзойти ТриплсТоремЕму (с учетом того, что их оборачивает)

Так что вместо

 ModelFactory.createDefaultModel()
 

как насчет того, чтобы объявить дефолт

 DatasetFactory.createTxnMem().getDefaultModel
 

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

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

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

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

ПРАВКА1

Причина, по которой я указываю внутри транзакции, заключается в том, что я следую 2 документам.

Явадок из

 public static DatasetGraph createTxnMem() { return new DatasetGraphInMemory(); }
 

в datasetgraph Factory говорится

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

Однако, учитывая, что DatasetGraphInMemory не задокументирована в официальном документе, кроме java, самым близким, что я смог найти, был учебник по TDB. Там написано:

TDB поддерживает общий API Jena для транзакций с наборами данных RDF (представлен в Jena 2.7.0, ARQ 2.9.0).

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

Поэтому я решил, что это может сработать для DatasetGraphInMemory, поскольку у них в основном один и тот же предок. База данных TDB специализируется на постоянстве.

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

Следовательно, нужно ли мне управлять транзакцией вручную, и стоит ли это того, если я хочу только скорости, действительно ли я выиграю ?

Это будет зависеть от использования.

TIM (TIM = «Транзакции в памяти» = DatasetGraphInMemory) использует постоянные структуры данных (в смысле функционального программирования «постоянные»). Реализация обеспечивается коллекциями Dexx.

Он генерирует больше краткосрочных объектов, поэтому имеет эффект GC.

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