Может ли GraphDB загрузить 10 миллионов операторов с OWL-рассуждениями?

Я изо всех сил пытаюсь загрузить большинство файлов OWL Drug Ontology и большую часть файлов ChEBI OWL в бесплатный репозиторий GraphDB v8.3 с рассуждением Optimized OWL Horst.

Это возможно? Должен ли я сделать что-то кроме "быть терпеливым"?

Подробности:

Я использую автономный загрузчик loadrdf для заполнения экземпляра AWS r4.16xlarge 488,0 ГБ и 64 виртуальными ЦП.

В выходные я поиграл с разными размерами буферного пула и обнаружил, что большинство этих файлов по отдельности загружаются быстрее всего с буферным пулом 2000 или 20 000 операторов вместо предложенных 200 000. Я также добавил -Xmx470g к сценарию loadrdf. Большинство файлов OWL будут загружаться по отдельности менее чем за один час.

Около 10 часов вечера по восточному времени прошлой ночью я начал загружать все файлы, перечисленные ниже, одновременно. Сейчас 11 часов спустя, и еще есть миллионы заявлений. Скорость загрузки составляет около 70 в секунду. Похоже, что используется только 30% моей оперативной памяти, но загрузка процессора постоянно составляет около 60.

  • Существуют ли сайты, которые документируют других людей, делающих что-то такого масштаба?
  • я должен использовать другую конфигурацию рассуждений? Я выбрал эту конфигурацию, так как это была самая быстро загружаемая конфигурация OWL, основанная на моих экспериментах на выходных. Я думаю, что мне нужно будет искать отношения, которые выходят за рамки rdfs:subClassOf.

Файлы, которые я пытаюсь загрузить:

+-------------+------------+---------------------+
|    bytes    | statements |        file         |
+-------------+------------+---------------------+
| 471,265,716 | 4,268,532  | chebi.owl           |
| 61,529      | 451        | chebi-disjoints.owl |
| 82,449      | 1,076      | chebi-proteins.owl  |
| 10,237,338  | 135,369    | dron-chebi.owl      |
| 2,374       | 16         | dron-full.owl       |
| 170,896     | 2,257      | dron-hand.owl       |
| 140,434,070 | 1,986,609  | dron-ingredient.owl |
| 2,391       | 16         | dron-lite.owl       |
| 234,853,064 | 2,495,144  | dron-ndc.owl        |
| 4,970       | 28         | dron-pro.owl        |
| 37,198,480  | 301,031    | dron-rxnorm.owl     |
| 137,507     | 1,228      | dron-upper.owl      |
+-------------+------------+---------------------+

2 ответа

Решение

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

http://graphdb.ontotext.com/documentation/free/loading-data-using-preload.html

Просто набрав правильное предложение @Konstantin Petrov с более аккуратным форматированием. Все эти запросы должны выполняться в интересующем хранилище... в какой-то момент, работая над этим, я ввел себя в заблуждение, полагая, что мне следует подключиться к SYSTEM репо при выполнении этих запросов.

Все эти запросы также требуют следующего определения префикса

prefix sys: <http://www.ontotext.com/owlim/system#>

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

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

SELECT ?state ?ruleset { ?state sys:listRulesets ?ruleset }

Добавить предопределенный набор правил

INSERT DATA { _:b sys:addRuleset "rdfsplus-optimized" }

Сделать новый набор правил по умолчанию

INSERT DATA { _:b sys:defaultRuleset "rdfsplus-optimized" }

Повторный вывод... может занять много времени!

INSERT DATA { [] <http://www.ontotext.com/owlim/system#reinfer> [] }

Другие вопросы по тегам