Exécution d'une requête de recherche en texte intégral dans Amazon Neptune

Dans une requête qui inclut une recherche en texte intégral, Neptune essaie de mettre les appels de cette recherche en premier, avant les autres parties de la requête. Cette approche réduit le nombre d'appels vers OpenSearch et, dans la plupart des cas, améliore considérablement les performances. Cependant, il ne s'agit en aucun cas d'une règle absolue. 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 seraient acheminés vers OpenSearch, provoquant des centaines d'appels OpenSearch. En fait, Neptune appelle d'abord OpenSearch, puis joint les résultats à ceux 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.