Indicateur de requête evaluationStrategy SPARQL

L'indicateur de requête evaluationStrategy indique au moteur de requête Amazon Neptune que le fragment de la requête annotée doit être évalué de bas en haut en tant qu'unité indépendante. Cela signifie qu'aucune des solutions des étapes d'évaluation précédentes n'est utilisée pour calculer le fragment de requête. Le fragment de requête est évalué en tant qu'unité autonome, et ses solutions produites sont jointes au reste de la requête une fois que celle-ci est calculée.

L'utilisation de l'indicateur de requête evaluationStrategy implique un plan de requête bloquant (non en pipeline), ce qui signifie que les solutions du fragment annoté avec l'indicateur de requête sont matérialisées et mises en tampon dans la mémoire principale. L'utilisation de l'indicateur de requête peut se traduire par une augmentation importante de la quantité de mémoire principale requise pour évaluer la requête, surtout si le fragment de requête annoté calcule un grand nombre de résultats.

Syntaxe des indicateurs evaluationStrategy SPARQL

L'indicateur de requête evaluationStrategy 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#>
hint:SubQuery hint:evaluationStrategy "BottomUp" .

Portées disponibles

• hint:SubQuery

Note

Cet indicateur de requête est pris en charge uniquement dans les sous-requêtes imbriquées.

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 evaluationStrategy SPARQL

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

Pour cet exemple, supposons que l'ensemble de données a les caractéristiques suivantes :

• Il contient de 1 000 arêtes étiquetées :connectedTo.

• Chaque nœud component est connecté en moyenne à 100 autres nœuds component.

• Le nombre typique de connexions cycliques à quatre tronçons entre les nœuds est de 100 environ.

Aucun indicateur de requête

La requête SPARQL suivante extrait tous les nœuds component qui sont connectés cycliquement les uns aux autres via quatre tronçons :

PREFIX : <https://example.com/>
PREFIX hint: <http://aws.amazon.com/neptune/vocab/v01/QueryHints#>
SELECT * {
  ?component1 :connectedTo ?component2 .
  ?component2 :connectedTo ?component3 .
  ?component3 :connectedTo ?component4 .
  ?component4 :connectedTo ?component1 .
}

L'approche du moteur de requête Neptune consiste à évaluer cette requête à l'aide des étapes suivantes :

• Extraire la totalité des 1 000 arêtes connectedTo dans le graphe.

• Multiplier par 100 (le nombre d'arêtes connectedTo sortantes de component2).

  Résultats intermédiaires : 100 000 nœuds.

• Multiplier par 100 (le nombre d'arêtes connectedTo sortantes de component3).

  Résultats intermédiaires : 10 000 000 nœuds.

• Analyser les 10 000 000 nœuds pour la fermeture du cycle.

Cela se traduit par un plan de requête de streaming ayan une quantité constante de mémoire principale.

Indicateur de requête et sous-requêtes

Il se peut que vous souhaitiez faire une compromis sur l'espace mémoire principale pour accélérer le calcul. En réécrivant la requête à l'aide d'un indicateur de requête evaluationStrategy, vous pouvez forcer le moteur à calculer une jointure entre deux sous-ensembles matérialisés plus petits.

PREFIX : <https://example.com/>
          PREFIX hint: <http://aws.amazon.com/neptune/vocab/v01/QueryHints#>
SELECT * {
  {
    SELECT * WHERE {
      hint:SubQuery hint:evaluationStrategy "BottomUp" .
      ?component1 :connectedTo ?component2 .
      ?component2 :connectedTo ?component3 .
    }
  }
  {
    SELECT * WHERE {
      hint:SubQuery hint:evaluationStrategy "BottomUp" .
      ?component3 :connectedTo ?component4 .
      ?component4 :connectedTo ?component1 .
    }
  }
}

Au lieu d'évaluer les modèles de triplet dans l'ordre tout en utilisant de manière itérative les résultats des modèles de triplet précédents comme entrée pour les modèles suivantes, avec l'indicateur evaluationStrategy, les deux sous-requêtes sont évaluées de manière indépendante. Les deux sous-requêtes produisent 100 000 nœuds pour les résultats intermédiaires, qui sont ensuite joints pour former la sortie finale.

En particulier, lorsque vous exécutez Neptune sur des types d'instances de plus grande taille, stocker temporairement ces deux sous-ensembles de 100 000 nœuds en mémoire principale augmente l'utilisation de la mémoire tout en accélérant l'évaluation de manière significative.