Amazon Neptune a ajouté une fonction SPARQL nommée “explain” (mi juin 2019) qui permet de comprendre l’approche d’exécution adoptée par le moteur Neptune. Dans la réalité, c’est un paramètre de plus (explain) à transmettre dans un appel HTTP dans une requête SPARQL.

La fonction “Explain” est la nouvelle fonctionnalité introduite dans AWS Neptune depuis le mois de Juin 2019

La fonction “EXPLAIN”

La fonction explain fournit des informations sur la structure logique des plans d’exécution de requête. Ces informations bien utilisées peuvent aider à optimiser une requête et ainsi gagner en temps d’exécution. Selon la documentation de Amazon [1], il existe deux modes pour l’usage de la fonction: le mode statique ou dynamique. – En mode statique, explain affiche uniquement la structure statique du plan de requête. – En mode dynamique, explain inclut également les aspects dynamiques du plan de requête. Ces aspects peuvent inclure le nombre de liaisons intermédiaires transitant via les opérateurs et le ratio de liaisons sortantes par rapport aux liaisons entrantes.

Pourquoi utiliser “EXPLAIN”?

Cette fonction permet principalement d’optimiser le moteur de Neptune afin de produire le résultat dans le meilleur temps possible. Cela implique l’ajout d’un espace de nom supplémentaire, de triplets permettant de considérer la portée ainsi que l’indicateur pris en charge et sa valeur. Il existe trois types de portée: – Au niveau requête, avec le mot-clé “hint:Query” – Au niveau groupe, avec le mot-clé “hint:Group” – Au niveau d’une sous-requête (ou requête imbriquée), avec le mot clé “hint:SubQuery“

Curl avec “Explain”

Considérons cette requête originale q12.rq. Afin de pouvoir passer le nom de fichier, il faut rajouter dans le fichier .rq ou .sparql le mot clé “query=…” en début de fichier (voir l’exemple ici ) $ curl http://{myendpoint}:8182/sparql \

-d “@q12.rq” \

-d “explain=dynamic” \

-H “Accept: text/html” A titre d’illustration, le résultat HTML pour “Explain” avec la requête q12 optimisée donne ce rendu HTML.

Applications avec les requêtes du bench OPOCE

Grâce à la précieuse aide de l’équipe de AWS Neptune (merci Justin T. et Ian R.), nous avons procédé à l’optimisation de 7 requêtes SPARQL de la catégorie 1 (dont 6 faisaient un time out de 60s lors du bench).  La liste se trouve dans notre repo Github.  Les résultats comparatifs du benchmark avec ces requêtes et les résultats sans optimisation se trouvent dans la figure ci-dessous:

Deux observations à la lecture de la figure ci-dessus:

Limitations actuelles

Pour le moment, ces optimisations concernent seulement les requêtes SELECT. De même, il n’est pas encore possible pour le moteur AWS Neptune de choisir de manière automatique quel serait la meilleure réécriture de la requête. Ainsi, pour le moment, l’utilisateur doit soi-même réécrire manuellement la requête. En attendant de voir une version “smart” de l’engin de Neptune, on peut déjà se réjouir de cette fonction qui permet de faire du “tuning” de requêtes SPARQL. Cependant, le risque du “tuning” est celui d’être dépendant du moteur, perdant ainsi en intéropérabilité de requêtes SPARQL d’un moteur sémantique à un autre. Ghislain A.

Références

[1] https://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/sparql-explain-using.html

[2] https://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/sparql-query-hints.html

[3] https://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/sparql-explain-operators.html