As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Full-text-search execução de consultas no Amazon Neptune
<a name="full-text-search-query-execution"></a>

Em uma consulta que inclui full-text-search, o Neptune tenta colocar full-text-search as chamadas primeiro, antes de outras partes da consulta. Isso reduz o número de chamadas OpenSearch e, na maioria dos casos, melhora significativamente o desempenho. No entanto, isso não é de forma alguma uma hard-and-fast regra. Há situações, por exemplo, em que `PatternNode` ou `UnionNode` pode preceder uma chamada de pesquisa em texto completo.

Por exemplo, pense na seguinte consulta do Gremlin para um banco de dados que contenha cem mil instâncias de `Person`:

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

Se essa consulta fosse executada na ordem em que as etapas aparecem, 100.000 soluções entrariam OpenSearch, causando centenas de OpenSearch chamadas. Na verdade, Netuno OpenSearch chama primeiro e depois une os resultados aos resultados de Netuno. Na maioria dos casos, isso é muito mais rápido do que executar a consulta na ordem original.

É possível impedir essa reordenação da execução de etapas de consulta usando a [dica de consulta 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~');
```

Neste segundo caso, a etapa `.hasLabel` é executada primeiro e, logo depois, a etapa `.has('name', 'Neptune#fts marcello~')`.

Para outro exemplo, considere uma consulta SPARQL em relação ao mesmo tipo de dados:

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

Aqui, novamente, o Neptune executa a parte `SERVICE` da consulta primeiro e depois une os resultados aos dados `Person`. É possível suprimir esse comportamento usando a [dica de consulta 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 .
  }
}
```

Novamente, na segunda consulta, as partes são executadas na ordem em que são exibidas na consulta.

**nota**  
 Consultar um alias do OpenSearch em um índice, em vez de consultar diretamente um índice do openSearch, pode produzir resultados incorretos. Consulte o índice do OpenSearch diretamente, não o alias.