2011-01-21 2 views
0

J'essaye de créer une base de données à partir des triplets de dbpedia RDF. J'ai une table Categories qui contient toutes les catégories dans wikipedia. Pour stocker les catégorisations, j'ai créé une table avec les champs child et parent, les deux clés étrangères du tableau Categories. Pour charger les catégories de NTriples Iam à l'aide de la requête SQL suivanteInsertion de la base de données de graphe Wikipedia

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

Mais l'insertion est très lent .. insertion 2,5millions relations prendrait très longtemps .. est-il une meilleure façon d'optimiser la requête, schéma ??

+0

Votre question n'a pas vraiment de sens pour moi. Vous dites que vous utilisez SQL pour interroger NTriples, ce qui n'a pas beaucoup de sens. Je suppose que vous avez déjà importé les données dans une base de données SQL. Ce qui en partie demande la question pourquoi? Vous feriez probablement mieux de mettre la table dans un RDF/Triple Store et d'utiliser un raisonnement pour déduire les relations. – RobV

+0

J'essaie de charger des données de NTriples dans la base de données SQL. Mon application ne nécessite pas toutes les données RDF, les prédicats par exemple. Je pourrais juste l'extraire directement de wikipedia mais je pensais que ce serait plus rapide à charger à partir des dumps de dbpedia nt. J'ai juste besoin de la hiérarchie des catégories. Je pensais qu'un triplestore pourrait être une surcharge car je n'ai pas besoin d'utiliser SPARQL et autres. – z33m

+0

Quel type d'index avez-vous créé dans la table CatToCat? –

Répondre

1

J'ai résolu le problème. Était quelques problèmes d'indexation. Identifiant créé dans les catégories uniques et binaires. Je suppose que cela a accéléré les deux sélections.

1
  1. Considérons le chargement SELECT id, indentifier from Categories dans une table de hachage (ou trie) du côté du client, et en utilisant le remplir CatToCat. Sur une base de données de la taille de wikipedia, je m'attendrais à voir une énorme différence de performance entre les recherches de hachage à temps constant et les recherches trie (qui sont constantes par rapport au nombre d'éléments de données différents) et log n. Envisagez d'utiliser un seul PreparedStatement, avec une liaison de paramètre pour que MySQL n'ait pas à ré-analyser et ré-optimiser la requête pour chaque insertion.

Vous devrez les évaluer pour déterminer leur degré d'amélioration.

Questions connexes