

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Indicateur de requête `joinOrder` SPARQL
<a name="sparql-query-hints-joinOrder"></a>

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. De plus, si votre requête contient des modèles plus complexes tels que des sous-requêtes ou des blocs OPTIONNEL ou MINUS complexes FILTERs, le moteur de requêtes Neptune les réorganise dans la mesure du possible, dans le but d'obtenir 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
<a name="sparql-query-hints-joinOrder-syntax"></a>

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](sparql-query-hints.md#sparql-query-hints-scope).

## Exemple d'indicateur `joinOrder` SPARQL
<a name="sparql-query-hints-joinOrder-example"></a>

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`.

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

1. Filtrer cet ensemble par les personnes nommées `Jane`.

1. 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`.

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

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

1. 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 \$1 100 (100 000) paires pour les arêtes `:likes`.