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á.
# A dica de consulta `joinOrder` SPARQL
Quando você envia uma consulta do SPARQL, o mecanismo de consulta do Amazon Neptune investiga a estrutura da consulta. Ele reordena partes da consulta e tenta minimizar a quantidade de trabalho necessária para a avaliação e o tempo de resposta da consulta.
Por exemplo, uma sequência de padrões triplos conectados normalmente não é avaliada na ordem indicada. Ela é reordenada usando heurística e estatísticas, como a seletividade dos padrões individuais e como eles estão conectados por meio de variáveis compartilhadas. Além disso, se sua consulta contiver padrões mais complexos, como subconsultas ou blocos OPTIONAL ou MINUS complexos FILTERs, o mecanismo de consulta Neptune os reordenará sempre que possível, visando uma ordem de avaliação eficiente.
Para consultas mais complexas, a ordem que o Neptune escolhe para avaliar a consulta pode não ser sempre a ideal. Por exemplo, o Neptune pode perder características específicas de dados da instância (como atingir nós avançados no grafo) que surgem durante a avaliação da consulta.
Se você sabe exatamente as características dos dados e deseja ditar manualmente a ordem de execução da consulta, use a dica de consulta `joinOrder` do Neptune para especificar que a consulta deve ser avaliada na ordem indicada.
## Sintaxe de dica `joinOrder` SPARQL
A dica de consulta `joinOrder` é especificada como um padrão triplo incluído em uma consulta SPARQL.
Para fins de clareza, a seguinte sintaxe usa um prefixo `hint` definido e incluído na consulta para especificar o namespace de dica de consulta do Neptune:
```
PREFIX hint:
scope hint:joinOrder "Ordered" .
```
**Escopos disponíveis**
+ `hint:Query`
+ `hint:Group`
Para obter mais informações sobre escopos de dica de consulta, consulte [Escopo de dicas de consulta do SPARQL no Neptune](sparql-query-hints.md#sparql-query-hints-scope).
## Exemplo de dica `joinOrder` SPARQL
Esta seção mostra uma consulta gravada com e sem a dica de consulta `joinOrder` e otimizações relacionadas.
Para este exemplo, suponha que o conjunto de dados contenha o seguinte:
+ Uma única pessoa chamada `John` que curte (`:likes`) 1.000 pessoas, inclusive `Jane`.
+ Uma única pessoa chamada `Jane` que curte (`:likes`) 10 pessoas, inclusive `John`.
**Nenhuma dica de consulta**
A seguinte consulta SPARQL extrai todos os pares de pessoas chamados `John` e `Jane` que curtem um ao outro de um conjunto de dados de redes sociais:
```
PREFIX :
SELECT ?john ?jane {
?person1 :name "Jane" .
?person1 :likes ?person2 .
?person2 :name "John" .
?person2 :likes ?person1 .
}
```
O mecanismo de consulta do Neptune pode avaliar as declarações em uma ordem diferente da escrita. Por exemplo, ele pode escolher avaliar na seguinte ordem:
1. Encontrar todas as pessoas chamadas `John`.
1. Encontrar todas as pessoas conectadas a `John` por uma borda `:likes`.
1. Filtrar esse conjunto por pessoas chamadas `Jane`.
1. Filtrar esse conjunto por aqueles indivíduos conectados a `John` por uma borda `:likes`.
De acordo com o conjunto de dados, avaliar nesta ordem resulta em 1.000 entidades sendo extraídas na segunda etapa. A terceira etapa restringe isso ao único nó, `Jane`. A etapa final determina que `Jane` também curte (`:likes`) o nó `John`.
**Dica de consulta**
Seria favorável começar com o nó `Jane` porque ela tem apenas 10 bordas `:likes` de saída. Isso reduz a quantidade de trabalho durante a avaliação da consulta, evitando a extração de 1.000 entidades durante a segunda etapa.
O exemplo a seguir usa a consulta **joinOrder** para garantir que o nó `Jane` e suas bordas de saída sejam processados primeiro ao desabilitar toda a reordenação automática de junção da consulta:
```
PREFIX :
PREFIX hint:
SELECT ?john ?jane {
hint:Query hint:joinOrder "Ordered" .
?person1 :name "Jane" .
?person1 :likes ?person2 .
?person2 :name "John" .
?person2 :likes ?person1 .
}
```
Um cenário do mundo real aplicável pode ser um aplicativo de rede social no qual as pessoas na rede são classificadas tanto como influenciadoras com muitas conexões ou como usuários normais com poucas conexões. Em um cenário como esse, você pode garantir que o usuário normal (`Jane`) seja processado antes do influenciador (`John`) em uma consulta como o exemplo anterior.
**Dica de consulta e reordenação**
Você pode levar este exemplo uma etapa adiante. Se você sabe que o atributo `:name` é exclusivo para um único nó, pode acelerar a consulta ao reorganizar e usar a dica de consulta `joinOrder`. Essa etapa garante que os nós exclusivos sejam extraídos primeiro.
```
PREFIX :
PREFIX hint:
SELECT ?john ?jane {
hint:Query hint:joinOrder "Ordered" .
?person1 :name "Jane" .
?person2 :name "John" .
?person1 :likes ?person2 .
?person2 :likes ?person1 .
}
```
Nesse caso, você pode reduzir a consulta às seguintes ações individuais em cada etapa:
1. Encontrar o nó de uma única pessoa com `:name` `Jane`.
1. Encontrar o nó de uma única pessoa com `:name` `John`.
1. Verificar se o primeiro nó está conectado ao segundo com uma borda `:likes`.
1. Verificar se o segundo nó está conectado ao primeiro com uma borda `:likes`.
**Importante**
Se você escolher a ordem errada, a dica de consulta `joinOrder` poderá resultar em quedas de desempenho significativas. Por exemplo, o exemplo anterior seria ineficaz se os atributos `:name` não fossem exclusivos. Se todos os 100 nós fossem nomeados `Jane` e todos os 1.000 nós fossem nomeados `John`, a consulta terminaria verificando 1.000 \$1 100 (100.000) pares para bordas `:likes`.