Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Full-text-search esecuzione di query in Amazon Neptune
<a name="full-text-search-query-execution"></a>

In una query che include full-text-search, Neptune cerca di inserire full-text-search le chiamate prima delle altre parti della query. Ciò riduce il numero di chiamate OpenSearch e nella maggior parte dei casi migliora significativamente le prestazioni. Tuttavia, questa non è affatto una hard-and-fast regola. Esistono situazioni, ad esempio, in cui `PatternNode` o `UnionNode` può precedere una chiamata di ricerca full-text.

Si consideri la seguente query Gremlin su un database contenente 100.000 istanze di `Person`:

```
g.withSideEffect('Neptune#fts.endpoint', 'your-es-endpoint-URL')
 .hasLabel('Person')
 .has('name', 'Neptune#fts marcello~');
```

Se questa query venisse eseguita nell'ordine in cui compaiono i passaggi, arriverebbero 100.000 soluzioni OpenSearch, che genererebbero centinaia di OpenSearch chiamate. In effetti, Neptune OpenSearch chiama prima e poi unisce i risultati con i risultati di Neptune. Nella maggior parte dei casi, questo è molto più veloce rispetto all'esecuzione della query nell'ordine originale.

È possibile impedire questo riordinamento dell'esecuzione del passaggio di query utilizzando l'[hint di query noReordering](gremlin-query-hints-noReordering.md):

```
g.withSideEffect('Neptune#fts.endpoint', 'your-es-endpoint-URL')
 .withSideEffect('Neptune#noReordering', true)
 .hasLabel('Person')
 .has('name', 'Neptune#fts marcello~');
```

In questo secondo caso, il passaggio `.hasLabel` viene eseguito per primo e il passaggio `.has('name', 'Neptune#fts marcello~')` per secondo.

Per un altro esempio, si consideri una query SPARQL sullo stesso tipo di dati:

```
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 .
  }
}
```

Anche in questo caso, Neptune esegue prima la parte `SERVICE` della query, poi unisce i risultati con i dati relativi a `Person`. È possibile eliminare questo comportamento usando l'[hint di query joinOrder](sparql-query-hints-joinOrder.md):

```
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 .
  }
}
```

Ancora una volta, nella seconda query le parti vengono eseguite nell'ordine in cui appaiono nella query.

**Nota**  
 Interrogare un alias opensearch su un indice, invece di interrogare direttamente un indice opensearch, può produrre risultati errati. È necessario interrogare direttamente l'indice di opensearch e non l'alias.