Como o mecanismo de SPARQL consulta funciona no Neptune - 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á.

Como o mecanismo de SPARQL consulta funciona no Neptune

Para usar as informações que o SPARQL explain recurso fornece, você precisa entender alguns detalhes sobre como o mecanismo de consulta do Amazon SPARQL Neptune funciona.

O mecanismo traduz cada SPARQL consulta em um pipeline de operadores. A partir do primeiro operador, soluções intermediárias conhecidas como listas de associações fluem por meio desse pipeline de operadores. Você pode considerar uma lista de associações como uma tabela na qual os cabeçalhos da tabela são um subconjunto das variáveis usadas na consulta. Cada linha da tabela representa um resultado, até o ponto de avaliação.

Vamos supor que dois prefixos de namespace foram definidos para nossos dados:

@prefix ex: <http://example.com> . @prefix foaf: <http://xmlns.com/foaf/0.1/> .

Veja a seguir um exemplo de uma lista de associações simples nesse contexto:

?person | ?firstName ------------------------------------------------------ ex:JaneDoe | "Jane" ex:JohnDoe | "John" ex:RichardRoe | "Richard"

Para cada uma das três pessoas, a lista vincula a variável ?person a um identificador da pessoa, e a variável ?firstName ao nome da pessoa.

Em geral, as variáveis poderão permanecer desvinculadas, se, por exemplo, houver uma seleção OPTIONAL de uma variável em uma consulta para a qual nenhum valor está presente nos dados.

O operador PipelineJoin é um exemplo de mecanismo de consulta do Neptune presente na saída de explain. Ele utiliza um conjunto de associações de entrada do operador anterior e junta isso a um padrão triplo, digamos (?person, foaf:lastName, ?lastName). Esta operação usa as associações da variável ?person em seu fluxo de entrada, substitui-as no padrão triplo e procura triplos no banco de dados.

Quando executado no contexto de associações de entrada da tabela anterior, o PipelineJoin deve avaliar três pesquisas, ou seja, o seguinte:

(ex:JaneDoe, foaf:lastName, ?lastName) (ex:JohnDoe, foaf:lastName, ?lastName) (ex:RichardRoe, foaf:lastName, ?lastName)

Essa abordagem é chamada de avaliação as-bound. As soluções desse processo de avaliação são juntadas de volta com as soluções de entrada, preenchendo o ?lastName detectado nas soluções de entrada. Supondo-se que você encontre um sobrenome para todas as três pessoas, o operador deve produzir uma lista de associações de saída que será semelhante à seguinte:

?person | ?firstName | ?lastName --------------------------------------- ex:JaneDoe | "Jane" | "Doe" ex:JohnDoe | "John" | "Doe" ex:RichardRoe | "Richard" | "Roe"

Essa lista de associações de saída serve, então, como entrada para o próximo operador no pipeline. No final, a saída do último operador no pipeline define o resultado da consulta.

Com frequência, os pipelines de operadores são lineares, no sentido de que cada operador emite soluções para um único operador conectado. No entanto, em alguns casos, eles podem ter estruturas mais complexas. Por exemplo, um UNION operador em uma SPARQL consulta é mapeado para uma Copy operação. Essa operação duplica as associações e encaminha as cópias para dois subplanos, uma para o lado esquerdo e a outra para o lado direito da UNION.

Para obter mais informações sobre operadores, consulte Operadores de Netuno SPARQL explain.