SPARQLconseils de requête - Amazon Neptune
Portée des indicateurs de requête

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.

SPARQLconseils de requête

Vous pouvez utiliser des indices de requête pour définir des stratégies d'optimisation et d'évaluation pour une SPARQL requête spécifique dans Amazon Neptune.

Les indications de requête sont exprimées à l'aide de modèles triples supplémentaires intégrés à la SPARQL requête avec les parties suivantes :

scope hint value

  • portée : détermine la partie de la requête à laquelle l'indicateur de requête s'applique, comme un certain groupe dans la requête ou la requête complète.

  • hint : identifie le type d'indicateur à appliquer.

  • value : détermine le comportement de l'aspect du système pris en compte.

Les indicateurs et portées de requête sont exposés sous la forme de termes prédéfinis dans l'espace de noms Amazon Neptune http://aws.amazon.com/neptune/vocab/v01/QueryHints#. Les exemples de cette section décrivent l'espace de noms sous la forme d'un préfixe hint qui est défini et inclus dans la requête :

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

Par exemple, le code suivant montre comment inclure un indicateur joinOrder dans une requête SELECT :

PREFIX hint: <http://aws.amazon.com/neptune/vocab/v01/QueryHints#>
SELECT ... {
 hint:Query hint:joinOrder "Ordered" .
 ...
}

La requête précédente demande au moteur Neptune d'évaluer les jointures dans la requête dans l'ordre donné et de désactiver toute réorganisation automatique.

Tenez compte des éléments suivants lorsque vous utilisez des indicateurs de requête :

  • Vous pouvez combiner différents indicateurs de requête dans une seule requête. Par exemple, vous pouvez utiliser l'indicateur de requête bottomUp afin d'annoter une sous-requête pour une évaluation ascendante et un indicateur de requête joinOrder pour corriger l'ordre des jointures à l'intérieur de la sous-requête.

  • Vous pouvez utiliser le même indicateur de requête plusieurs fois, dans différentes portées qui ne se chevauchent pas.

  • Les indicateurs de requête sont des suggestions. Même si le moteur de requête vise généralement à prendre en compte des indicateurs de requête donnés, il peut également les ignorer.

  • Les indicateurs de requête préservent la sémantique. L'ajout d'un indice de requête ne modifie pas le résultat de la requête (sauf en ce qui concerne l'ordre des résultats potentiel lorsqu'aucune garantie de commande n'est donnée, c'est-à-dire lorsque l'ordre des résultats n'est pas explicitement appliqué à l'aide ORDER de BY).

Les sections suivantes fournissent plus d'informations sur les indicateurs de requête disponibles et leur utilisation dans Neptune.

Rubriques

Portée des indices de SPARQL requête dans Neptune

Le tableau suivant présente les étendues disponibles, les conseils associés et les descriptions des conseils de SPARQL requête dans Amazon Neptune. Le préfixe hint de ces entrées représente l'espace de noms Neptune des indicateurs :

PREFIX hint: <http://aws.amazon.com/neptune/vocab/v01/QueryHints#>
Portée Indicateurs pris en charge Description
hint:Query

joinOrder

 L'indicateur de requête s'applique à toute la requête.
hint:Query

queryTimeout

 La valeur de délai d’attente s'applique à l'ensemble de la requête.
hint:Query

rangeSafe

 La promotion de type est désactivée pour l'ensemble de la requête.
hint:Query

queryId

 La valeur d'ID de requête s'applique à l'ensemble de la requête.
hint:Query

utiliser DFE

 L'utilisation du DFE est activée (ou désactivée) pour l'ensemble de la requête.
hint:Group

joinOrder

 L'indicateur de requête s'applique aux éléments de niveau supérieur du groupe spécifié, mais pas aux éléments imbriqués (comme les sous-requêtes) ou aux éléments parents.
hint:SubQuery

evaluationStrategy

 L'indice est spécifié et appliqué à une SELECT sous-requête imbriquée. La sous-requête est évaluée de façon indépendante, sans tenir compte des solutions calculées avant la sous-requête.