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 une requête incluant full-text-search, Neptune essaie de placer les full-text-search appels en premier, avant les autres parties de la requête. Cela permet de réduire le nombre d'appels OpenSearch et, dans la plupart des cas, d'améliorer considérablement les performances. Cependant, il ne s'agit en aucun cas d'une hard-and-fast règle. Dans certaines situations, par exemple, un élément PatternNode
ou UnionNode
peut précéder un appel de recherche en texte intégral.
Prenons la requête Gremlin suivante vers une base de données contenant 100 000 instances de Person
:
g.withSideEffect('Neptune#fts.endpoint', '
your-es-endpoint-URL
') .hasLabel('Person') .has('name', 'Neptune#fts marcello~');
Si cette requête était exécutée dans l'ordre dans lequel les étapes apparaissent, 100 000 solutions arriveraient OpenSearch, provoquant des centaines d' OpenSearch appels. En fait, Neptune appelle d' OpenSearch abord, puis joint les résultats aux résultats de Neptune. Dans la plupart des cas, cela est beaucoup plus rapide que l'exécution de la requête dans l'ordre d'origine.
Vous pouvez empêcher cette réorganisation de l'exécution de l'étape de requête à l'aide de l'indicateur de requête noReordering :
g.withSideEffect('Neptune#fts.endpoint', '
your-es-endpoint-URL
') .withSideEffect('Neptune#noReordering', true) .hasLabel('Person') .has('name', 'Neptune#fts marcello~');
Dans ce second cas, l'étape .hasLabel
est exécutée en premier et l'étape .has('name', 'Neptune#fts marcello~')
en deuxième.
Pour un autre exemple, prenez une requête SPARQL par rapport au même type de données :
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX neptune-fts: <http://aws.amazon.com/neptune/vocab/v01/services/fts#> SELECT ?person WHERE { ?person rdf:type foaf:Person . SERVICE neptune-fts:search { neptune-fts:config neptune-fts:endpoint '
http://your-es-endpoint.com
' . neptune-fts:config neptune-fts:field foaf:name . neptune-fts:config neptune-fts:query 'mike' . neptune-fts:config neptune-fts:return ?person . } }
Ici encore, Neptune exécute d'abord la partie SERVICE
de la requête, puis joint les résultats aux données Person
. Vous pouvez supprimer ce comportement en utilisant l'indicateur de requête joinOrder :
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX neptune-fts: <http://aws.amazon.com/neptune/vocab/v01/services/fts#> PREFIX hint: <http://aws.amazon.com/neptune/vocab/v01/QueryHints#> SELECT ?person WHERE { hint:Query hint:joinOrder "Ordered" . ?person rdf:type foaf:Person . SERVICE neptune-fts:search { neptune-fts:config neptune-fts:endpoint '
http://your-es-endpoint.com
' . neptune-fts:config neptune-fts:field foaf:name . neptune-fts:config neptune-fts:query 'mike' . neptune-fts:config neptune-fts:return ?person . } }
De nouveau, dans la deuxième requête, les parties sont exécutées dans l'ordre où elles apparaissent dans la requête.