Вставка базы данных Wikipedia Graph

0

Я пытаюсь создать базу данных из dbpedia RDF троек. У меня есть таблица 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.5Million отношений займет очень много времени.. есть ли лучший способ оптимизировать запрос, схему

  • 0
    Ваш вопрос на самом деле не имеет смысла для меня. Вы говорите, что используете SQL для запроса NTriples, что не имеет особого смысла. Я предполагаю, что у вас уже есть данные, импортированные в базу данных SQL. Что частично вызывает вопрос, почему? Возможно, вам было бы гораздо лучше поместить стол в RDF / Triple Store и использовать рассуждения для вывода отношений.
  • 0
    Я пытаюсь загрузить данные из NTriples в базу данных SQL. Моему приложению не требуются все данные RDF, например, предикаты. Я мог бы просто извлечь это непосредственно из Википедии, но я думал, что будет быстрее загружать из дампов dbpedia nt. Мне просто нужна иерархия категорий. Я думал, что триплет может быть излишним, так как мне не нужно использовать SPARQL и тому подобное.
Показать ещё 3 комментария
Теги:
wikipedia
rdf

3 ответа

1
Лучший ответ

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

Поделиться
2

вы можете попробовать базу данных графиков, такую ​​как Neo4j, с верхними слоями RDF, например, реализация Tinkerpop SAIL, см. https://github.com/tinkerpop/blueprints/wiki/Sail-Implementation

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

/питер

Поделиться
1

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

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

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

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню