Dans un précédent billet, Iamhondjack notait avec justesse en commentaire qu'il ne fallait pas dissocier SPARQL et SQL de manière aussi stricte que je pouvais le faire. Il appuie son propos sur l'expérience de D2R server qui permet d'interroger une base de données relationnelles en SPARQL grâce à un mapping entre la modélisation de la base de données relationnelles et le modèle de graphe. Dans la foulée, Christian pose la question essentielle à savoir la performance et le temps de réponse.

Il semble que la question du stockage des triples RDF soit dans l'air du temps ce qui est logique, eu égard, à l'intérêt grandissant du Web of data. Ainsi, même si Tim Berners-Lee donnait déjà des premiers éléments de réponse dès 1998 dans un document intitulé Relational Databases and the Semantic Web (in Design Issues), un workshop organisé par le W3C et intitulé « RDF Access to Relational Databases » a permis de faire récemment le point sur la question. Une des conclusions de ce workshop est la nécessité de mettre au point une procédure normalisée de benchmark pour les triple store RDF sur le modèle de TPC pour les bases de données relationnelles.

Force est de constater que nous disposons que peu de recul aujourd'hui sur la question, quelques ressources traînent à droite à gauche sur le sujet :

• sur le ESW wiki du W3C, on trouve une liste de triple store indiquant le nombre de triples pouvant être stocké et une liste d'articles présentant des rapports sur l'extensibilité des triple store ;
• Un thésard propose les résultats d'un benchmark des moteurs SPARQL qu'il a effectué dans le cadre de sa thèse.
• Dans un article très complet, l'équipe du CSAIL du MIT, à l'origine de C-store, propose une comparaison entre le stockage de RDF dans une base de données relationnelles et la solution choisie pour C-Store.
• Mise à jour 26/11/2007 : Benchmarck pour AllegroGraph
• Mise à jour 2/12/2007 (cf. les commentaires) : the Lehigh University Benchmark (LUBM), le benchmark pour AllegroGraph cité précédemment suit cette procédure, je vous conseille aussi la lecture de ce document qui analyse des résultats du LUBM d'Oracle, AllegroGraph, DAML DB, OpenLink Virtuoso et BigOWLIM (Via More News).

Or, il s'agit d'une question cruciale dans la perspective de l'industrialisation du modèle RDF et de la dissémination des technologies Web sémantique. Même si certaines personnes dont je fais partie pensent que le modèle relationnel atteint aujourd'hui ses limites, le modèle de graphe à la base de RDF ne pourra s'imposer que dans la mesure où il aura été prouvé que les outils permettant de l'exploiter présentent des performances supérieures. La mise au point d'un benchmark représente donc une étape essentielle.

Les benchmark devront rapidement dégager les avantages et inconvénients de chacun des trois modèles de stockage qui se dégage actuellement :

• Le mapping à la volée d'une modélisation d'une base de données relationnelles et du modèle de graphe. Ce modèle est celui des outils D2R server ou SquirellRDF, par exemple.
• Le stockage dans une base de données relationnelles dont la modélisation permet le stockage direct sous forme de triples, par exemple : 3store, RAP ou ARC reposant sur MySQL, Virtuoso, Sesame ou Semantic Web/RDF Library for C#/.NET
• Les entrepôts qui stockent de façon native les triples RDF, par exemple : AllegroGraph, BigOWLIM qui peut être une des solutions de stockage et d'inférence pour Sesame, Oracle 11g, Mulgara. Les deux derniers n'offrent pour l'instant qu'un support limité de SPARQL.

Il semble d'ors et déjà acquis que le premier modèle ne sera pertinent que dans la phase de transition, que nous vivons aujourd'hui. En effet, il ne répond que partiellement aux besoins des utilisateurs comme l'explique cet article des développeurs de D2R server, qui sont les mêmes que Dbpedia pour lequel ils ont utilisé Virtuoso.