Magasins triples vs bases de données relationnelles
Je me demandais quels sont les avantages d'utiliser Triple Stores sur une base de données relationnelle?
Le point de vue du CTO d'une entreprise qui utilise largement RDF Triplestores commercialement:
Flexibilité du schéma - il est possible de faire l'équivalent d'un changement de schéma dans un magasin RDF en direct, et sans aucun temps d'arrêt, ni refonte - ce n'est pas un déjeuner gratuit, vous devez faire attention au fonctionnement de votre logiciel, mais c'est une chose assez facile à faire.
Plus moderne - RDF les magasins sont généralement interrogés via HTTP, il est très facile de les intégrer dans les architectures de service sans solutions de pontage hacky ou pénalités de performances. De plus, ils gèrent mieux le contenu internationalisé que les bases de données SQL classiques - par exemple vous pouvez avoir plusieurs valeurs dans différentes langues.
Standardisation - le niveau de standardisation des implémentations utilisant RDF et SPARQL est beaucoup plus élevé que SQL. Il est possible d'échanger un triplestore pour un autre, bien que vous deviez faire attention à ne pas sortir des normes. Il est facile de déplacer des données entre les magasins, car ils parlent tous la même langue.
Expressivité - il est beaucoup plus facile de modéliser des données complexes dans RDF que dans SQL, et le langage de requête permet de faire plus facilement des choses comme LEFT JOINs (appelées OPTIONAL dans SPARQL). À l'inverse cependant, si vos données sont très tabulaires, SQL est beaucoup plus facile.
Provenance - SPARQL vous permet de suivre la provenance de chaque élément d'information et vous pouvez stocker des métadonnées à ce sujet, vous permettant de faire facilement des requêtes sophistiquées, en prenant uniquement en compte les données de certaines sources, ou avec un certain niveau de confiance, à partir d'une certaine plage de dates etc.
Il y a cependant des inconvénients. Les bases de données SQL sont généralement beaucoup plus matures et ont plus de fonctionnalités que les bases de données RDF classiques. Des choses comme les transactions sont souvent beaucoup plus grossières, voire inexistantes. De plus, les informations de coût par unité stockées dans le SQL de RDF v sont sensiblement plus élevées. Il est difficile de généraliser, mais cela peut être important si vous avez beaucoup de données - bien qu'au moins dans notre cas, il s'agit d'un avantage financier global étant donné la flexibilité et le pouvoir.
Les deux commentateurs ont raison, d'autant plus que Web sémantique n'est pas une base de données, c'est un peu plus général que cela.
Mais je suppose que vous pourriez parler de triple magasin, plutôt que du Web sémantique en général, car la triple base de données relationnelle est une comparaison un peu plus significative. Je préface le reste de ma réponse en notant que je ne suis pas un expert des systèmes de bases de données relationnelles, mais j'ai un peu de connaissances sur les magasins triples.
Les magasins triples (ou quadruples) sont essentiellement des bases de données pour les données sur le Web sémantique, en particulier RDF. C'est là que s'arrête la similitude entre les triplets de magasins et les bases de données relationnelles. Les deux stockent les données, les deux ont des langages de requête, les deux peuvent être utilisés pour créer des applications par-dessus; donc je suppose que si vous plissez les yeux, ils sont assez similaires. Mais le type de données que chacun stocke est assez différent, de sorte que les deux technologies optimisent pour différents cas d'utilisation et structures de données, donc elles ne sont pas vraiment interchangeables.
Beaucoup de gens ont travaillé pour superposer une vue triple du monde au-dessus d'une base de données relationnelle, et cela peut fonctionner, et sera également plus lent qu'un système dédié au stockage et à la récupération de triplets. Une partie des problèmes est que SPARQL, le langage de requête standard utilisé par les magasins triples, peut nécessiter beaucoup d'auto-jointures, ce pour quoi les bases de données relationnelles ne sont pas optimisées. Si vous regardez des benchmarks, tels que SP2B , vous pouvez voir qu'Oracle, qui superpose juste le support SPARQL sur son système relationnel, s'exécute au milieu ou à l'arrière du pack par rapport aux systèmes qui plus supporte nativement RDF.
Bien sûr, les systèmes RDF seraient probablement écrasés par Oracle s'ils effectuaient des requêtes SQL sur des données relationnelles. Mais c'est en quelque sorte le point, vous choisissez l'outil qui convient bien à l'application que vous souhaitez construire.
Donc, si vous songez à créer une application Web sémantique, ou tout simplement à essayer de vous familiariser avec le domaine, je vous recommanderais de choisir un magasin triple dédié.
Je ne m'attarderai pas sur le raisonnement et sur la façon dont cela joue dans la réponse aux requêtes dans les magasins triples, car c'est encore une autre discussion, mais c'est une autre distinction importante entre les systèmes relationnels et les magasins triples qui font le raisonnement.
Certains triplestores (Virtuoso, Jena SDB) sont basés sur des bases de données relationnelles et fournissent simplement une interface RDF/SPARQL. Donc, pour reformuler légèrement la question, les triplestores sont construits à partir de zéro comme un triplestore plus performant. que ceux qui ne le sont pas - @ steve-harris connaît certainement la réponse à cela;) mais je parie que oui.
Deuxièmement, quelles sont les fonctionnalités des triplestores que le SGBDR n'a pas. La réponse simple est la prise en charge de SPARQL, RDF, OWL etc. (c'est-à-dire la pile de la technologie du Web sémantique) et pour en faire un combat équitable, il est préférable de définir la valeur de SPARQL sur la base de SPARQL 1.1 (il a considérablement plus de fonctionnalités que 1.0) . Cela prend en charge la fédération (si cool), les expressions de chemin de propriété et les régimes d'implication ainsi qu'un ensemble standard de protocoles de mise à jour, de protocoles de gestion des graphes (que SPARQL 1.0 n'avait pas et manquait cruellement). @ Steve-harris souligne également que les transactions ne font pas partie de la norme (bidon de vers) bien que de nombreux fournisseurs fournissent des mécanismes non standardisés pour les transactions (Virtuoso prend en charge la mise en commun et la gestion des connexions compatibles JDBC et Hibernate ainsi que toutes les fonctionnalités transactionnelles d'Hibernate)
Le gros inconvénient dans mon esprit est que peu de triplestores supportent tous SPARQL 1.1 (car il n'est toujours pas recommandé) et c'est là que résident les vrais avantages.
Cela dit, je suis et j'ai toujours été un partisan de la substitution du SGBDR avec les triplestores et les plates-formes que je fournis fonctionnent entièrement à partir de triplestores (Volkswagen dans mon dernier rôle en était un exemple), ce qui déprécie le besoin de RDBMS. Un avantage supplémentaire est que l'objet vers RDF est plus flexible et offre plus d'options et de flexibilité que l'ORM traditionnel (également connu sous le nom de mise d'une cheville carrée dans un trou rond).
Vous pouvez également utiliser une base de données mais utiliser RDF comme format d'échange de données qui est très flexible.