Neptun-Operatoren SPARQL explain

In den folgenden Abschnitten werden die Operatoren und Parameter für die SPARQL explain Funktion beschrieben, die derzeit in Amazon Neptune verfügbar ist.

Wichtig

Die SPARQL explain Funktion wird noch verfeinert. Die hier dokumentierten Operatoren und Parameter unterliegen möglicherweise Änderungen in zukünftigen Versionen.

Aggregation-Operator

Führt eine oder mehrere Aggregationen durch und implementiert dabei die Semantik von SPARQL Aggregationsoperatoren wie countmax,min,sum, usw.

Aggregation verfügt über optionale Gruppierung mithilfe von groupBy-Klauseln sowie über optionale having-Einschränkungen.

Argumente

• groupBy – (Optional) Stellt die groupBy-Klausel zur Angabe der Abfolge von Ausdrücken je nach Gruppierung der eingehenden Lösungen bereit.

• aggregates – (Erforderlich) Gibt eine geordnete Liste von Aggregationsausdrücke an.

• having— (Optional) Fügt Einschränkungen hinzu, um nach Gruppen zu filtern, wie in der having Klausel in der Abfrage impliziert. SPARQL

ConditionalRouting-Operator

Leitet eingehende Lösungen auf Grundlage einer bestimmten Bedingung weiter. Lösungen, die die Bedingung erfüllen, werden an die Operator-ID weitergeleitet, die von Out #1 verwiesen wurde. Dagegen werden Lösungen, die die Bedingung nicht erfüllen, an den Operator weitergeleitet, der von Out #2 verwiesen wird.

Argumente

• condition – (Erforderlich) Die Weiterleitungsbedingung.

Copy-Operator

Delegiert den Lösungs-Stream auf die vom angegebenen Modus bestimmte Weise.

Modi

• forward – Leitet die Lösungen an den Downstream-Operator weiter, wie von Out #1 identifiziert.

• duplicate – Dupliziert die Lösungen und leitet sie an beide Operatoren weiter, die von Out #1 und Out #2 identifiziert werden.

Copy hat keine Argumente.

DFENode-Operator

Dieser Operator ist eine Abstraktion des Plans, der von der DFE alternativen Abfrage-Engine ausgeführt wird. Der detaillierte DFE Plan ist in den Argumenten für diesen Operator beschrieben. Das Argument ist derzeit überladen, um die detaillierten Laufzeitstatistiken des DFE Plans zu enthalten. Es enthält die Zeit, die von für die verschiedenen Schritte der Abfrageausführung aufgewendet wurdeDFE.

Der logisch optimierte abstrakte Syntaxbaum (AST) für den DFE Abfrageplan wird mit Informationen zu den Operatortypen gedruckt, die bei der Planung berücksichtigt wurden, und zu den damit verbundenen Kosten für die Ausführung der Operatoren im besten und schlechtesten Fall. Der AST besteht derzeit aus den folgenden Knotentypen:

• DFEJoinGroupNode –  Stellt die Vereinigung eines oder mehrerer DFEPatternNodes dar.

• DFEPatternNode –  Kapselt ein zugrundeliegendes Muster mit den übereinstimmenden Tupeln, die aus der zugrunde liegenden Datenbank projiziert werden.

Der Unterabschnitt,Statistics & Operator histogram, enthält Einzelheiten zur Ausführungszeit des DataflowOp Plans und zur Aufschlüsselung der von den einzelnen Operatoren benötigten CPU Zeit. Darunter befindet sich eine Tabelle, die detaillierte Laufzeitstatistiken des von DFE ausgeführten Plans ausgibt.

Anmerkung

Da DFE es sich um eine experimentelle Funktion handelt, die im Labormodus veröffentlicht wurde, kann sich das genaue explain Ausgabeformat ändern.

Distinct-Operator

Berechnet die unterschiedliche Projektion bei einer Teilmenge der Variablen, sodass Duplikate vermieden werden. Dies hat zur Folge, dass die Anzahl eingehender Lösungen größer oder gleich der Anzahl der ausgehenden Lösungen ist.

Argumente

• vars – (Erforderlich) Die Variablen, auf die die Distinct-Projektion angewendet werden soll.

Federation-Operator

Leitet eine angegebene Abfrage an einen angegebenen SPARQL Remote-Endpunkt weiter.

Argumente

• endpoint— (Erforderlich) Der Endpunkt URL in der SPARQL SERVICE Anweisung. Dies kann eine konstante Zeichenfolge sein, oder, wenn der Abfrageendpunkt basierend auf einer Variablen innerhalb derselben Abfrage bestimmt wird, kann es sich um den Variablennamen handeln.

• query – (Erforderlich) Die rekonstruierte Abfragezeichenfolge, die an den Remote-Endpunkt gesendet werden soll. Die Engine fügt dieser Abfrage Standardpräfixe hinzu, auch wenn der Client keine angibt.

• silent – (Erforderlich) Ein boolescher Wert, der angibt, ob das Schlüsselwort SILENT nach dem Schlüsselwort angezeigt wurde. SILENT weist die Engine an, bei einem Fehlschlag von SERVICE nicht die gesamte Abfrage fehlschlagen zu lassen.

Filter-Operator

Filtert die eingehenden Lösungen. Nur Lösungen, die die Filterbedingung erfüllen, werden an die Upstream-Operator weitergeleitet. Alle anderen werden gelöscht.

Argumente

• condition – (Erforderlich) Die Filterbedingung.

HashIndexBuild-Operator

Übernimmt eine Liste der Bindungen und spult sie in einem Hash-Index, dessen Name vom solutionSet-Argument definiert wird. In der Regel führen nachfolgende Operatoren Joins für diesen Lösungssatz aus und verweisen ihn mit diesem Namen.

Argumente

• solutionSet – (Erforderlich) Der Name des Hash-Index-Lösungssatzes.

• sourceType – (Required) Der Typ der Quelle, aus der die Bindungen für die Speicherung im Hash-Index abgerufen werden:

  • pipeline – Spult die eingehenden Lösungen aus dem Downstream-Operator in der Operator-Pipeline in den Hash-Index.

  • binding set – Spult den vom sourceBindingSet-Argument angegebenen festen Bindungssatz in den Hash-Index.

• sourceBindingSet – (Optional) Wenn das Argument sourceType den Wert binding set hat, gibt dieses Argument den statischen Bindungssatz an, der in den Hash-Index gespult werden soll.

HashIndexJoin-Operator

Verbindet die eingehenden Lösungen für den Lösungssatz des Hash-Index, der vom solutionSet-Argument identifiziert wird.

Argumente

• solutionSet – (Erfoderlich) Name des Lösungssatzes, mit dem der Join durchgeführt werden soll. Dies muss ein Hash-Index sein, der in einem vorherigen Schritt mithilfe des Operators HashIndexBuild konstruiert wurde.

• joinType – (Erforderlich) Der Typ des Join, der ausgeführt werden soll:

  • join – Ein normales Join, für das eine exakte Übereinstimmung aller geteilten Variablen erforderlich ist.

  • optional— Ein optional Join, der die SPARQL OPTIONAL Operatorsemantik verwendet.

  • minus— Eine minus Operation behält unter Verwendung der SPARQL MINUS Operatorsemantik eine Zuordnung bei, für die kein Join-Partner existiert.

  • existence check – Prüft, ob ein Join-Partner vorhanden ist, und bindet die Variable existenceCheckResultVaran das Ergebnis dieser Prüfung.

• constraints – (Optional) Zusätzliche Join-Einschränkungen, die während des Join in Betracht gezogen werden. Joins, die diese Einschränkungen nicht erfüllen, werden verworfen.

• existenceCheckResultVar – (Optional) Wird nur für Joins verwendet, in denen joinType gleich existence check ist (siehe zuvor das Argument joinType).

MergeJoin-Operator

Ein Zusammenführungs-Join über mehrere Lösungen, wie es vom solutionSets-Argument identifiziert wird.

Argumente

• solutionSets – (Erforderlich) Die Lösungssätze, für die ein Join ausgeführt werden soll.

NamedSubquery-Operator

Löst eine Bewertung der Unterabfrage aus, die vom subQuery-Argument identifiziert wird, und spult das Ergebnis in den vom solutionSet-Argument angegebenen Lösungssatz. Die eingehenden Lösungen für den Operator werden an die Unterabfrage und dann an den nächsten Operator weitergeleitet.

Argumente

• subQuery – (Erforderlich) Der Name der Unterabfrage, die ausgewertet werden soll. Die Unterabfrage wird in der Ausgabe explizit gerendert.

• solutionSet – (Erforderlich) Der Name des Lösungssatzes, in dem das Ergebnis der Unterabfrage gespeichert werden soll.

PipelineJoin-Operator

Erhält die Ausgabe des vorherigen Operators als Eingabe und verbindet sie mit dem Tupel-Muster, das vom pattern-Argument definiert wird.

Argumente

• pattern— (Erforderlich) Das Muster, das die Form eines Tupels und optional eines Graphen annimmt subject-predicate-object, das der Verknüpfung zugrunde liegt. Wenn distinct für das Muster angegeben wird, extrahiert der Join nur unterschiedliche Lösungen aus den Projektionsvariablen, die vom projectionVars-Argument angegeben werden, anstatt alle passenden Lösungen zu extrahieren.

• inlineFilters – (Optional) Eine Reihe von Filtern, die auf die Variablen im Muster angewendet werden sollen. Das Muster wird in Verbindung mit diesen Filtern ausgewertet.

• joinType – (Erforderlich) Der Typ des Join, der ausgeführt werden soll:

  • join – Ein normales Join, für das eine exakte Übereinstimmung aller geteilten Variablen erforderlich ist.

  • optional— Ein optional Join, der die Operatorsemantik verwendet. SPARQL OPTIONAL

  • minus— Eine minus Operation behält unter Verwendung der SPARQL MINUS Operatorsemantik eine Zuordnung bei, für die kein Join-Partner existiert.

  • existence check – Prüft, ob ein Join-Partner vorhanden ist, und bindet die Variable existenceCheckResultVaran das Ergebnis dieser Prüfung.

• constraints – (Optional) Zusätzliche Join-Einschränkungen, die während des Join in Betracht gezogen werden. Joins, die diese Einschränkungen nicht erfüllen, werden verworfen.

• projectionVars – (Optional) Die Projektionsvariablen. Werden in Verbindung mit distinct := true verwendet, um das Extrahieren unterschiedlicher Projektionen aus einem bestimmten Variablensatz zu erzwingen.

• cutoffLimit – (Optional) Ein Abschnittslimit für die Anzahl der extrahierten Join-Partner. Obwohl standardmäßig kein Limit vorliegt, können Sie diesen Wert bei Ausführen von Joins auf 1 festlegen, um FILTER (NOT) EXISTS-Klauseln zu implementieren, sofern es ausreicht zu beweisen oder zu wiederlegen, dass ein Join-Partner vorhanden ist.

PipelineCountJoin-Operator

Eine Variante von PipelineJoin. Anstatt einen Join durchzuführen, werden einfach die übereinstimmenden Join-Partner gezählt und die Anzahl wird an die Variable gebunden, die vom countVar-Argument angegeben wird.

Argumente

• countVar – (Erforderlich) Die Variable, über die das Ergebnis der Zählung, d. h. die Anzahl der Join-Partner, gebunden werden soll.

• pattern— (Erforderlich) Das Muster, das die Form eines Tupels und optional eines Graphen annimmt subject-predicate-object, das der Verknüpfung zugrunde liegt. Wenn distinct für das Muster angegeben wird, extrahiert der Join nur unterschiedliche Lösungen aus den Projektionsvariablen, die vom projectionVars-Argument angegeben werden, anstatt alle passenden Lösungen zu extrahieren.

• inlineFilters – (Optional) Eine Reihe von Filtern, die auf die Variablen im Muster angewendet werden sollen. Das Muster wird in Verbindung mit diesen Filtern ausgewertet.

• joinType – (Erforderlich) Der Typ des Join, der ausgeführt werden soll:

  • join – Ein normales Join, für das eine exakte Übereinstimmung aller geteilten Variablen erforderlich ist.

  • optional— Ein optional Join, der die Operatorsemantik verwendet. SPARQL OPTIONAL

  • minus— Eine minus Operation behält unter Verwendung der SPARQL MINUS Operatorsemantik eine Zuordnung bei, für die kein Join-Partner existiert.

  • existence check – Prüft, ob ein Join-Partner vorhanden ist, und bindet die Variable existenceCheckResultVaran das Ergebnis dieser Prüfung.

• constraints – (Optional) Zusätzliche Join-Einschränkungen, die während des Join in Betracht gezogen werden. Joins, die diese Einschränkungen nicht erfüllen, werden verworfen.

• projectionVars – (Optional) Die Projektionsvariablen. Werden in Verbindung mit distinct := true verwendet, um das Extrahieren unterschiedlicher Projektionen aus einem bestimmten Variablensatz zu erzwingen.

• cutoffLimit – (Optional) Ein Abschnittslimit für die Anzahl der extrahierten Join-Partner. Obwohl standardmäßig kein Limit vorliegt, können Sie diesen Wert bei Ausführen von Joins auf 1 festlegen, um FILTER (NOT) EXISTS-Klauseln zu implementieren, sofern es ausreicht zu beweisen oder zu wiederlegen, dass ein Join-Partner vorhanden ist.

PipelinedHashIndexJoin-Operator

Dies ist ein all-in-one Build-Hash-Index und ein Join-Operator. Er nimmt eine Liste von Bindungen, spult sie in einen Hash-Index und verknüpft dann die eingehenden Lösungen anhand des Hash-Indexes.

Argumente

• sourceType  –   (Required) Der Typ der Quelle, aus der die Bindungen für die Speicherung im Hash-Index abgerufen werden:

  • pipeline  –   Lässt PipelinedHashIndexJoin die eingehenden Lösungen aus dem Downstream-Operator in der Operator-Pipeline in den Hash-Index spulen.

  • binding set  –   Lässt PipelinedHashIndexJoin den vom sourceBindingSet-Argument angegebenen festen Bindungssatz in den Hash-Index spulen.

• sourceSubQuery   –   (Optional) Wenn das Argument sourceType den Wert pipeline hat, gibt dieses Argument die Unterabfrage an, die ausgewertet und in den Hash-Index gespoolt wird.

• sourceBindingSet   –   (Optional) Wenn das Argument sourceType den Wert binding set hat, gibt dieses Argument den statischen Bindungssatz an, der in den Hash-Index gespult werden soll.

• joinType  –   (Erforfderlich) Der Typ des Join, der ausgeführt werden soll:

  • join – Ein normales Join, für das eine exakte Übereinstimmung aller geteilten Variablen erforderlich ist.

  • optional— Ein optional Join, der die SPARQL OPTIONAL Operatorsemantik verwendet.

  • minus— Eine minus Operation behält unter Verwendung der SPARQL MINUS Operatorsemantik eine Zuordnung bei, für die kein Join-Partner existiert.

  • existence check – Prüft, ob ein Join-Partner vorhanden ist, und bindet die Variable existenceCheckResultVaran das Ergebnis dieser Prüfung.

• existenceCheckResultVar— (Optional) Wird nur für Verknüpfungen verwendet, bei denen joinType gleich ist existence check (siehe das joinType Argument oben).

Projection-Operator

Projiziert über eine Teilmenge der Variablen. Die Anzahl der eingehenden Lösungen entspricht der Anzahl der ausgehenden Lösungen, aber die Form der Lösung ist je nach Moduseinstellung unterschiedlich.

Modi

• retain – In Lösungen werden nur die Variablen beibehalten, die vom Argument vars angegeben werden.

• drop – Alle Variablen, die vom Argument vars angegeben werden, werden entfernt.

Argumente

• vars – (Erforderlich) Die Variablen, die je nach Moduseinstellung beibehalten oder entfernt werden sollen.

PropertyPath-Operator

Aktiviert rekursive Eigenschaftspfade wie + oder *. Neptune implementiert einen Festkomma-Iterationsansatz, der auf einer durch das Argument iterationTemplate angegebenen Vorlage basiert. Bekannte Variablen der linken oder rechten Seite werden in der Vorlage solange für jede Iteration mit festem Punkt gebunden, bis keine neuen Lösungen gefunden werden können.

Argumente

• iterationTemplate – (Erforderlich) Der Name der Vorlage für die Unterabfrage, die für die Implementierung der Iteration mit festem Punkt verwendet wird.

• leftTerm – (Erforderlich) Der Begriff (Variable oder Konstante) auf der linken Seite des Eigenschaftspfads.

• rightTerm – (Erforderlich) Der Begriff (Variable oder Konstante) auf der rechten Seite des Eigenschaftspfads.

• lowerBound – (Erforderlich) Die untere Grenze für die Iteration mit festem Punkt (entweder 0 für *-Abfragen oder 1 für +-Abfragen).

TermResolution-Operator

Übersetzt interne Zeichenfolgekennungswerte zurück in ihre entsprechenden externen Zeichenfolgen oder übersetzt externe Zeichenfolgen in internen Kennungswerte. Dies ist vom Modus abhängig.

Modi

• value2id— Ordnet Begriffe wie Literale URIs den entsprechenden internen ID-Werten zu (Kodierung zu internen Werten).

• id2value— Ordnet interne ID-Werte den entsprechenden Begriffen wie Literalen und URIs (Dekodierung interner Werte) zu.

Argumente

• vars— (Erforderlich) Gibt die Variablen an, deren Zeichenketten oder interne Zeichenketten zugeordnet werden IDs sollen.

Slice-Operator

Implementiert einen Slice über dem eingehenden Lösungsstream und verwendet dabei die Semantik SPARQL von 'LIMITund OFFSET Klauseln.

Argumente

• limit – (Optional) Eine Einschränkung für die Lösungen, die weitergeleitet werden sollen.

• offset – (Optional) Der Versatz, mit dem Lösungen für die Weiterleitung ausgewertet werden.

SolutionInjection-Operator

Empfängt keine Eingabe. Bringt statische Lösungen in den Abfrageplan ein und nimmt sie in das solutions-Argument auf.

Anfragepläne beginnen immer mit dieser statischen Injektion. Wenn einzubringende statische Lösungen aus der Abfrage abgeleitet werden können, indem verschiedene Quellen statischer Bindungen (z. B. aus VALUES- oder BIND-Klauseln) abgeleitet werden können, bringt der SolutionInjection-Operator diese abgeleiteten statischen Lösungen ein. Im einfachsten Fall spiegelt dies Bindungen wider, die von einer äußeren VALUES-Klausel angedeutet werden.

Wenn keine statischen Lösungen aus der Abfrage abgeleitet werden können, bringt SolutionInjection die leere so genannte universelle Lösung ein, die erweitert und im Abfragebewertungsprozess multipliziert wird.

Argumente

• solutions – (Erforderlich) Die vom Operator eingefügte Lösungsabfolge.

Sort-Operator

Sortiert den Lösungssatz mithilfe bestimmter Sortierbedingungen.

Argumente

• sortOrder – (Erforderlich) Eine geordnete Liste von Variablen mit jeweils einer ASC-ID (aufsteigenden) oder einer DESC-ID (absteigend), die zum Sortieren des Lösungssatzes verwendet wird.

VariableAlignment-Operator

Prüft Lösungen einzeln und führt bei jeder davon eine Ausrichtung über zwei Variablen durch: ein angegebenes sourceVar-Element und ein angegebenes targetVar-Element.

Wenn sourceVar und targetVar in einer Lösung denselben Wert haben, gilt die Variablen als ausgerichtet und die Lösung wird weitergeleitet. Dabei wird das redundante sourceVar-Element heraus projiziert.

Wenn die Variablen an unterschiedliche Werte gebunden werden, wird die Lösung vollständig herausgefiltert.

Argumente

• sourceVar – (Erforderlich) Die Quellvariable, die mit der Zielvariablen verglichen werden soll. Wenn die Ausrichtung in einer Lösung erfolgreich ist, die beiden Variablen also den gleichen Wert haben, wird die Quellvariable heraus projiziert.

• targetVar – (Erforderlich) Die Zielvariable, mit der die Quellvariable verglichen werden soll. Wird auch beibehalten, wenn die Ausrichtung erfolgreich ist.