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 joinOrder
SPARQL de consulta
Quando você envia uma SPARQL consulta, o mecanismo de consulta 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 complexos OPTIONAL ou MINUS blocosFILTERs, 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.
joinOrder
SPARQLsintaxe de dica
A dica de joinOrder
consulta é especificada como um padrão triplo incluído em uma SPARQL consulta.
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: <http://aws.amazon.com/neptune/vocab/v01/QueryHints#>
scope
hint:joinOrder "Ordered" .
Escopos disponíveis
hint:Query
hint:Group
Para obter mais informações sobre escopos de dica de consulta, consulte Escopo das dicas de SPARQL consulta em Neptune.
joinOrder
SPARQLexemplo de dica
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, inclusiveJane
.Uma única pessoa chamada
Jane
que curte (:likes
) 10 pessoas, inclusiveJohn
.
Nenhuma dica de consulta
A SPARQL consulta a seguir extrai todos os pares de pessoas nomeadas John
e Jane
que gostam uma da outra de um conjunto de dados de redes sociais:
PREFIX : <https://example.com/> 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:
Encontrar todas as pessoas chamadas
John
.Encontrar todas as pessoas conectadas a
John
por uma borda:likes
.Filtrar esse conjunto por pessoas chamadas
Jane
.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 dica de joinOrderconsulta para garantir que o Jane
nó e suas bordas de saída sejam processados primeiro, desativando toda a reordenação automática de junções da consulta:
PREFIX : <https://example.com/> PREFIX hint: <http://aws.amazon.com/neptune/vocab/v01/QueryHints#> 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 : <https://example.com/> PREFIX hint: <http://aws.amazon.com/neptune/vocab/v01/QueryHints#> 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:
Encontrar o nó de uma única pessoa com
:name
Jane
.Encontrar o nó de uma única pessoa com
:name
John
.Verificar se o primeiro nó está conectado ao segundo com uma borda
:likes
.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 * 100 (100.000) pares para bordas :likes
.