Indicateur de requête joinOrder SPARQL

Lorsque vous soumettez une requête SPARQL, le moteur de requête Amazon Neptune étudie sa structure. Il réorganise les parties de la requête et tente de réduire au maximum la quantité de travail nécessaire pour l'évaluation et le temps de réponse de la requête.

Par exemple, une séquence de modèles de triplet connectés n'est généralement pas évaluée dans l'ordre donné. Elle est réorganisée à l'aide d'heuristique et de statistiques telles que la sélectivité des différents modèles et la façon dont ils sont connectés via des variables partagées. En outre, si votre requête contient des modèles plus complexes comme des sous-requêtes, des filtres FILTER, ou encore des blocs OPTIONAL ou MINUS complexes, le moteur de requête Neptune les réorganise dans la mesure du possible avec pour but un ordre d'évaluation efficace.

Pour les requêtes plus complexes, l'ordre dans lequel Neptune choisit d'évaluer la requête peut ne pas toujours être optimal. Par exemple, Neptune peut manquer des caractéristiques spécifiques aux données d'instance (par exemple, l'exécution de nœuds Power dans le graphe) qui émergent au cours de l'évaluation de la requête.

Si vous connaissez les caractéristiques exactes des données et que vous souhaitez imposer manuellement l'ordre de l'exécution de la requête, utilisez l'indicateur de requête Neptune joinOrder pour demander que la requête soit évaluée dans l'ordre donné.

Syntaxe des indicateurs joinOrder SPARQL

L'indicateur de requête joinOrder est spécifié en tant que modèle de triplet inclus dans une requête SPARQL.

Pour plus de clarté, la syntaxe suivante utilise un préfixe hint défini et inclus dans la requête pour spécifier l’espace de noms d'indicateur de requête Neptune :

PREFIX hint: <http://aws.amazon.com/neptune/vocab/v01/QueryHints#>
scope hint:joinOrder "Ordered" .

Portées disponibles

• hint:Query

• hint:Group

Pour plus d'informations sur les portées d'indicateur de requête, consultez Portée des indicateurs de requêtes SPARQL dans Neptune.

Exemple d'indicateur joinOrder SPARQL

Cette section montre une requête écrite avec et sans l'indicateur de requête joinOrder, ainsi que les optimisations associées.

Pour cet exemple, supposons que l'ensemble de données contient les éléments suivants :

• Une personne unique nommée John qui :likes 1 000 personnes, y compris Jane.

• Une personne unique nommée Jane qui :likes 10 personnes, y compris John.

Aucun indicateur de requête

La requête SPARQL suivante extrait toutes les paires de personnes nommées John et Jane qui sont amies à partir d'un ensemble de données de réseau social :

PREFIX : <https://example.com/>
SELECT ?john ?jane {
  ?person1 :name "Jane" .
  ?person1 :likes ?person2 .
  ?person2 :name "John" .
  ?person2 :likes ?person1 .
}

Le moteur de requête Neptune peut évaluer les déclarations dans un ordre différent de celui qui est écrit. Par exemple, il peut choisir d'évaluer dans l'ordre suivant :

1. Trouver toutes les personnes nommées John.

2. Trouver toutes les personnes connectées à John par une arête :likes.

3. Filtrer cet ensemble par les personnes nommées Jane.

4. Filtrer cet ensemble par les personnes connectées à John par une arête :likes.

Selon l'ensemble de données, l'évaluation dans cette commande se traduit par 1 000 entités extraites lors de la deuxième étape. La troisième étape affine l'extraction à un nœud unique, Jane. L'étape finale détermine ensuite que Jane :likes également le nœud John.

Indicateur de requête

Il serait préférable de démarrer avec le nœud Jane, car Jane n'a que 10 arêtes :likes sortantes. Cela réduit la quantité de travail pendant l'évaluation de la requête en évitant l'extraction des 1 000 entités au cours de la deuxième étape.

L'exemple suivant utilise l'indicateur de requête joinOrder afin de s'assurer que le nœud Jane et ses arêtes sortantes sont traités en premier en désactivant toute la réorganisation automatique des jointures pour la requête :

PREFIX : <https://example.com/>
PREFIX hint: <http://aws.amazon.com/neptune/vocab/v01/QueryHints#>
SELECT ?john ?jane {
  hint:Query hint:joinOrder "Ordered" .
  ?person1 :name "Jane" .
  ?person1 :likes ?person2 .
  ?person2 :name "John" .
  ?person2 :likes ?person1 .
}

Un scénario réel applicable peut être une application de réseau social où les utilisateurs du réseau sont classés soit comme des influenceurs avec de nombreuses connexions, soit comme des utilisateurs normaux avec peu de connexions. Dans un tel scénario, vous pouvez vous assurer que l'utilisateur normal (Jane) est traité avant l'influenceur (John) dans une requête similaire à l'exemple précédent.

Indicateur de requête et réorganisation

Vous pouvez encore améliorer cet exemple. Si vous savez que l'attribut :name est unique à un seul nœud, vous pouvez accélérer la requête en réorganisant et en utilisant l'indicateur de requête joinOrder. Cette étape permet de s'assurer que les nœuds uniques sont extraits en premier.

PREFIX : <https://example.com/>
PREFIX hint: <http://aws.amazon.com/neptune/vocab/v01/QueryHints#>
SELECT ?john ?jane {
  hint:Query hint:joinOrder "Ordered" .
  ?person1 :name "Jane" .
  ?person2 :name "John" .
  ?person1 :likes ?person2 .
  ?person2 :likes ?person1 .
}

Dans ce cas, vous pouvez réduire la requête suivante aux actions uniques suivantes dans chaque étape :

1. Rechercher le seul nœud de personne avec l'attribut :name Jane.

2. Rechercher le seul nœud de personne avec l'attribut :name John.

3. Vérifier que le premier nœud est connecté au deuxième nœud avec une arête :likes.

4. Vérifier que le deuxième nœud est connecté au premier nœud avec une arête :likes.

Important

Si vous ne choisissez pas l'ordre approprié, l'indicateur de requête joinOrder peut entraîner des baisses significatives de performance. Par exemple, l'exemple précédent serait inefficace si les attributs :name n'étaient pas uniques. Si les 100 nœuds étaient nommés Jane et si tous les 1 000 nœuds étaient nommés John, la requête auraient à vérifier 1 000 * 100 (100 000) paires pour les arêtes :likes.