2011-01-21 4 views
0

Я пытаюсь создать базу данных из тройки RDF dbpedia. У меня есть таблица Categories, которая содержит все категории в Википедии. Чтобы сохранить категоризации, я создал таблицу с полями child и parent, оба внешних ключа - Categories. Чтобы загрузить категории из NTriples IAM, используя следующий SQL-запросВикипедия График базы данных Вставка

INSERT INTO CatToCat (`child`, `parent`) 
values((SELECT id FROM Categories WHERE BINARY identifier='Bar'), 
     (SELECT id FROM Categories WHERE BINARY identifier='Bar')); 

Но вставку очень медленно .. вставка 2.5 миллиона отношений займет очень много времени .. есть лучший способ для оптимизации запроса, схем ??

+0

Ваш вопрос для меня не имеет смысла. Вы говорите, что используете SQL для запроса NTriples, который не имеет большого смысла. Я предполагаю, что у вас уже есть данные, импортированные в базу данных SQL. Почему отчасти возникает вопрос? Вероятно, вам будет намного лучше помещать таблицу в RDF/Triple Store и использовать рассуждения, чтобы вывести отношения. – RobV

+0

Я пытаюсь загрузить данные из NTriples в базу данных SQL. Мое приложение не требует всех данных RDF, например, предикатов. Я мог бы просто извлечь это прямо из википедии, но я думал, что быстрее будет загружаться с dbpedia nt dumps. Мне просто нужна иерархия категорий. Я думал, что triplestore может быть излишним, поскольку мне не нужно использовать SPARQL и тому подобное. – z33m

+0

Какие индексы вы создали в таблице CatToCat? –

ответ

1

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

2

вы можете попробовать Graph Database как Neo4j с RDF слоями на вершине, есть, например, реализация Tinkerpop ПАРУС см https://github.com/tinkerpop/blueprints/wiki/Sail-Implementation

Это должно работать немного лучше, чем РСУБД, по крайней мере, для Neo4j.

/питер

1
  1. Рассмотрим загрузку SELECT id, indentifier from Categories в хэш-таблицу (или) синтаксического дерева на стороне клиента, а также с помощью, чтобы заполнить CatToCat. В базе данных размер википедии, я ожидаю увидеть огромную разницу в производительности между постоянными хэш-поисками и trie lookups (которые являются постоянными по отношению к количеству разных элементов данных) и log n B-Tree lookups. (Разумеется, вам нужно иметь доступную память.)

  2. Рассмотрите возможность использования одного PreparedStatement с привязкой параметров, чтобы MySQL не нуждался в повторном анализе и повторной оптимизации запроса для каждой вставки.

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

Смежные вопросы