Dans lajoinOrderIndice de requête 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.

Dans lajoinOrderIndice de requête SPARQL

Lorsque vous soumettez une requête SPARQL, le moteur de requêtes Amazon Neptune étudie 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ê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 ignorer des caractéristiques spécifiques aux données d'instance (telles que le fait de toucher des nœuds d'alimentation 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 le NeptunejoinOrderindice de requête pour spécifier que la requête doit être évaluée dans l'ordre indiqué.

joinOrderSyntaxe d'une règle

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

Pour des raisons de clarté, la syntaxe suivante utilise unhintpré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 conseils 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êtes Neptune peut évaluer les instructions dans un ordre différent de celui dans lequel elles sont é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 utilisejoinOrderindice de requête pour vous assurer queJanele nœud et ses tronçons sortants sont d'abord traités 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.