L'indice de requêtejoinOrder SPARQL - Amazon Neptune

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.

L'indice de requêtejoinOrder SPARQL

Lorsque vous soumettez une requête SPARQL, le moteur de requête Amazon Neptune examine la structure de la requête. 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, des FILTRES ou des blocs OPTIONNEL ou MINUS complexes, le moteur de requête Neptune les réorganise dans la mesure du possible, afin d'obtenir un ordre d'évaluation efficace.

Pour les requêtes plus complexes, l'ordre dans lequel Neptune choisit d'évaluer la requête n'est pas toujours optimal. Par exemple, Neptune peut omettre des caractéristiques spécifiques aux données d'instance (telles que l'atteinte de nœuds puissants dans le graphique) qui apparaissent lors de l'évaluation des requêtes.

Si vous connaissez les caractéristiques exactes des données et souhaitez dicter manuellement l'ordre d'exécution de la requête, utilisez l'indicateur dejoinOrder requête Neptune pour spécifier que la requête doit être évaluée dans l'ordre indiqué.

joinOrderSyntaxe d'indice SPARQL

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

Par souci de clarté, la syntaxe suivante utilise unhint préfixe défini et inclus dans la requête pour spécifier l'espace de noms Neptune query-hint :

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 indices de requête SPARQL dans Neptune.

joinOrderExemple d'indice 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 instructions dans un ordre différent de celui dans lequel elles ont été écrites. 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 pour s'assurer que leJane nœud et ses tronçons sortants sont traités en premier en désactivant toute 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.