Remplacer Jena Fuseki par Oxigraph

Bonjour à toutes et tous,

Jena nous a démontré plusieurs fois ses faiblesses en termes de performance lors de la résolution de requêtes sparql sur des volumes de données important. Chez Data Players, au delà de 5000 sujets nous n’utilisons plus SPARQL mais les container LDP pour profiter du cache redis. Les filtrages sont alors faits sur le navigateur.

Oxigraph est une alternative à Jena, a été créé par Thomas Tanon (également contributeur wikidata) et @niko.plp a déjà échangé avec lui et j’ai compris que le projet semble relativement stable et exploitable.
Il reste plusieurs question en suspend pour moi :

  • Est-ce qu’il est possible de rajouter un plugin d’ACL comme nous l’avons fait pour Jena?
  • Combien de jour serait nécessaire pour faire ce plugin et qui en serait capable ?
  • Est-ce que toute les requêtes SPARQL sont supportés y compris en écriture ?
  • Quel est le gain de performance attendu.?

Je souhaite donc organiser une réunion avec Thomas Tanon, @guillaume.rouyer, @niko.plp , @srosset et toutes celles et ceux qui le souhaite pour

  • interconnaissance
  • proposer une meilleure synergie entre AV et oxigraph (proposer d’être membre?)
  • aborder les questions ci-dessus

DP est en train de répondre à un appel à Projet qui explicite l’usage du Bus Sémantique et de Semapps dans lequel il y aura au moins 10000 sujets (sans compter historique et moderation) et il est envisageable de financer des améliorations de semapps dans le budget. D’autres améliorations sont probables dans ce projet (gestion des droits par groupes, historisation, modération…) et il y aura des arbitrage à faire en fonction des coûts.

@guillaume.rouyer ou @niko.plp pouvez vous me mettre en relation avec Thomas Tanon si vous avez son mail svp?

2 « J'aime »

Je suis sûr que @nicolas.chauvat pourrait également être intéressé par une rencontre avec Thomas ! Et oui ca pourrait être un beau projet !

Je ne le connais pas, il faut miser sur @niko.plp :slight_smile: Tu nous mets en lien Niko ?

Je regardai la roadmap d’Oxigraph encore hier et j’ai noté qu’il n’y a rien autour de la notion d’extensions ou de plugins. C’est ce que m’avait dit Niko aussi.

Peut-être avec du financement ça peut être possible, mais ça peut prendre du temps…

On pourrait commencer par l’utiliser pour des projets qui n’ont pas besoin d’ACL, ça permettrait de tester la stabilité et les performances (il est indiqué dans la roadmap que les optimisations des requêtes SPARQL n’a pas encore été faite)

Salut a tous,

Quelques elements de reponse :

  • il n’y a pas d’interface dans oxigraph pour des plugins. pas d’ACL non plus. donc il faudra faire un fork.
  • en effet oxigraph n’est pas encore optimisé. je n’ai pas d’info sur ses benchmarks pour le moment.
  • pourquoi avoir besoin de contacter Thomas ? si vous voulez faire un fork (Rust), en effet, vous pouvez le contacter pour lui en parler. Mais oxigraph est un projet qu’il maintient dans le cadre de son job a plein temps, et sa roadmap est donc tres lié a l éntreprise pour laquelle il travaille.
  • oxigraph est compatible a 100% avec le SPARQL protocol 1.1 donc il y a toutes les fonctionnalités, y compris l’ecriture.
  • je reste dubitatif sur les problemes de performances que Simon evoque. Sont-ils liés a l’utilisation des ACLs dans Jena/semapps ? ou bien on parle d’un probleme de performance general de Jena ?
    Jena est capable de gerer bien plus de triples que 10k. Je serais plutot d’avis que vos requetes SPARQL sont mal ecrites… il faut bien prendre en compte en les ecrivant, comment les indexes marchent dans Jena. on a deja eu des episodes de ce genre, où les perfs etaient desastreuses, mais c’etait lié a des requetes qui scannaient tous les triples du datastore (plusieurs fois) avant de pouvoir retrourner des resultats, et donc c’etait normal que les perfs soient degradées. Apres correction des requetes, vous aviez obtenu de meilleurs resultats.
  • il est certain que les ACLs tels qu’elles sont implementés dans semapps pour le moment, degradent les perfs. et le cache redis est bien efficace pour ameliorer les perfs dans ce cas.
  • enfin, je ne suis pas dispo pour un travail en rust sur oxigraph qui consisterait a y implementer des ACLs de type WAC/webACL, car je suis a fond sur nextgraph, qui par ailleurs, devrait pouvoir etre connecté a semapps, ce qui sera peut etre fait a l’avenir, en collaboration avec Seb et son projet ActivityPods.
  • Nexgraph est basé sur un modele de permissions differents, qui est en gros des « capabilities » (des clés secretes qui donnent acces a des resources. si on possede la clé, on doit l énvoyer dans la requete sparql, et le serveur donnera acces a cette resource).
  • nextgraph resout aussi le probleme de la federation/mirroir des donnees de maniere elegante grace au CRDTs.
  • je reste a la disposition de semapps dans l eventualité d’une migration du backend sparql de jena vers nextgraph.
1 « J'aime »

salut @niko.plp ,

  • Les requetes utilisées sont celles qui ont déjà été optimisée depuis le dataprovider semapps du front. Nous (Data Players) gere dejà des projets qui s’approchent des 10K sujet. 10K sujets aboutira à 100K triplet ou plus et si on ajoute l’historisation on arrive à 1000K triplets ou plus.
  • Le cache redis resoud une grande partie des problème pour Get Ressource ou Container mais lorsqu’on fait une recherche (sur un ou plusieurs) predicat, le cache redis ne peut pas être utilisé pour la requette sparql. à 10K Sujet on passe donc en fitrage sur navigateur et pas en sparql.
  • les ressources dont l’acces est gérées par « capabilities » dont tu parles , sont des sujets ou des triplet?

Salut Simon,

Oui j’ai vu apres que tu parlais de 100K resources et donc de beaucoup plus de triples. 1 million de triples ca ne me parait pas infaisable pour Jena non plus. La question est surtout de savoir si vous avez les ACL activées sur votre dataset dans lequel vous faites des filtrages. Car en effet, si les ACLs sont activées, ca va reduire les perfs significativement. C’est dommage de passer en filtrage coté client pour une raison de perf sur le serveur.

Il faudrait analyser si vous avez vraiment besoin des ACLs ou pas, et si vous pourriez peut etre faire une copy (mirroir) des données avec ACL, dans un dataset sans ACL (les rendre publiques) afin que les recherches et filtrages soient plus efficaces. Je ne connais pas vos cas d’usage. Des fois on a besoin des ACLs pour verifier qui peut modifier les donnees ou pas (donc les ACLs sont importantes pour l’ecriture) mais apres en lecture on n’en a plus besoin (car les données sont publiques de toute facon) et dans ce cas, faire un mirroir des données dans un dataset sans ACLs peut resoudre vos problemes de perfs. Vous feriez donc les requetes sparql de filtrage sur le dataset mirroir qui n ;a pas d’ACL, ca aurait de meilleurs perfs.

Enfin, la granularité de permission de NextGraph est au niveau de la resource (sujet), comme dans semapps.

Et puis ca serait interessant de faire un test de perf avec oxugraph. en importnat vos donnees dans une instance oxigraph, puis en faisant tourner vos requetes de filtrage pour voir les perfs.

2 « J'aime »

merci pour ta réponse @niko.plp
Dans les cas d’usages en quesition, nous pourions peut être passer par un dataset mirroir sans ACL mais ce ne sera pas toujours le cas. on essaiera sur un prochain projet.
Je pense effectivement qu’il faut qu’on experimente oxigraph avant de rentrer en contact avec avec Thomas Tanon.