A dica joinOrder SPARQL de consulta - Amazon Neptune

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.

joinOrderSPARQLsintaxe 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.

joinOrderSPARQLexemplo 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, inclusive Jane.

  • Uma única pessoa chamada Jane que curte (:likes) 10 pessoas, inclusive John.

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:

  1. Encontrar todas as pessoas chamadas John.

  2. Encontrar todas as pessoas conectadas a John por uma borda :likes.

  3. Filtrar esse conjunto por pessoas chamadas Jane.

  4. 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 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:

  1. Encontrar o nó de uma única pessoa com :name Jane.

  2. Encontrar o nó de uma única pessoa com :name John.

  3. Verificar se o primeiro nó está conectado ao segundo com uma borda :likes.

  4. 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.