Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Neptune SPARQL-Operatoren für `explain` Die folgenden Abschnitte beschreiben die Operatoren und Parameter für das SPARQL-Feature `explain`, die zurzeit in Amazon Neptune verfügbar sind. **Wichtig** Das SPARQL–Feature `explain` wird zurzeit weiter optimiert. Die hier dokumentierten Operatoren und Parameter unterliegen möglicherweise Änderungen in zukünftigen Versionen. **Topics** + [`Aggregation`-Operator](#sparql-explain-operator-aggregation) + [`ConditionalRouting`-Operator](#sparql-explain-operator-conditional-routing) + [`Copy`-Operator](#sparql-explain-operator-copy) + [`DFENode`-Operator](#sparql-explain-operator-dfenode) + [`Distinct`-Operator](#sparql-explain-operator-distinct) + [`Federation`-Operator](#sparql-explain-operator-federation) + [`Filter`-Operator](#sparql-explain-operator-filter) + [`HashIndexBuild`-Operator](#sparql-explain-operator-hash-index-build) + [`HashIndexJoin`-Operator](#sparql-explain-operator-hash-index-join) + [`MergeJoin`-Operator](#sparql-explain-operator-merge-join) + [`NamedSubquery`-Operator](#sparql-explain-operator-named-subquery) + [`PipelineJoin`-Operator](#sparql-explain-operator-pipeline-join) + [`PipelineCountJoin`-Operator](#sparql-explain-operator-pipeline-count-join) + [`PipelinedHashIndexJoin`-Operator](#sparql-explain-operator-pipeline-hash-index-join) + [`Projection`-Operator](#sparql-explain-operator-projection) + [`PropertyPath`-Operator](#sparql-explain-operator-property-path) + [`TermResolution`-Operator](#sparql-explain-operator-term-resolution) + [`Slice`-Operator](#sparql-explain-operator-slice) + [`SolutionInjection`-Operator](#sparql-explain-operator-solution-injection) + [`Sort`-Operator](#sparql-explain-operator-sort) + [`VariableAlignment`-Operator](#sparql-explain-operator-variable-alignment) ## `Aggregation`-Operator Führt eine oder mehrere Aggregationen durch, mit denen die Semantik der SPARQL-Aggregationsoperatoren wie `count`, `max`, `min`, `sum` und so weiter implementiert wird. `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 Filtern für Gruppen Einschränkungen hinzu wie durch die `having`-Klausel in der SPARQL-Abfrage angegeben. ## `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 alternativen DFE-Abfrage-Engine ausgeführt wird. Der detaillierte DFE-Plan wird in den Argumenten für diesen Operator beschrieben. Das Argument ist zurzeit überladen, indem es die detaillierten Laufzeitstatistiken des DFE-Plans enthält. Es enthält die Zeit, die DFE für die einzelnen Schritte der Abfrageausführung benötigt hat. 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 Kosten für die Ausführung der Operatoren im besten und schlechtesten Fall. Der AST besteht zurzeit 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 Details zur Ausführungszeit des `DataflowOp`-Plans und zur Aufschlüsselung der von den einzelnen Operatoren genutzten CPU-Zeit. Unterhalb befindet sich eine Tabelle, in der detaillierte Laufzeitstatistiken des von der DFE ausgeführten Plans ausgegeben werden. **Anmerkung** Da es sich bei der DFE-Unterstützung für SPARQL um eine experimentelle Funktion handelt, kann sich das genaue Format der Ausgabe ändern. `explain` ## `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 Übergibt eine angegebene Abfrage an einen angegebenen Remote-SPARQL-Endpunkt **Argumente** + `endpoint` – (*Erforderlich*) Die Endpunkt-URL in der SPARQL-Anweisung `SERVICE`. 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, für das die SPARQL-`OPTIONAL`-Operatorsemantik verwendet wird. + `minus` – Eine `minus`-Operation behält eine Zuordnung, für die kein Join-Partner vorhanden ist, mithilfe der SPARQL-`MINUS`-Operatorsemantik bei. + `existence check` – Prüft, ob ein Join-Partner vorhanden ist, und bindet die Variable `existenceCheckResultVar`an 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 Graph-Tupels 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, für das die SPARQL-`OPTIONAL`-Operatorsemantik verwendet wird. + `minus` – Eine `minus`-Operation behält eine Zuordnung, für die kein Join-Partner vorhanden ist, mithilfe der SPARQL-`MINUS`-Operatorsemantik bei. + `existence check` – Prüft, ob ein Join-Partner vorhanden ist, und bindet die Variable `existenceCheckResultVar`an 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 hat 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, für das die SPARQL-`OPTIONAL`-Operatorsemantik verwendet wird. + `minus` – Eine `minus`-Operation behält eine Zuordnung, für die kein Join-Partner vorhanden ist, mithilfe der SPARQL-`MINUS`-Operatorsemantik bei. + `existence check` – Prüft, ob ein Join-Partner vorhanden ist, und bindet die Variable `existenceCheckResultVar`an 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, für das die SPARQL-`OPTIONAL`-Operatorsemantik verwendet wird. + `minus` – Eine `minus`-Operation behält eine Zuordnung, für die kein Join-Partner vorhanden ist, mithilfe der SPARQL-`MINUS`-Operatorsemantik bei. + `existence check` – Prüft, ob ein Join-Partner vorhanden ist, und bindet die Variable `existenceCheckResultVar`an das Ergebnis dieser Prüfung. + `existenceCheckResultVar` – (*Optional*) Wird nur für Joins verwendet, in denen `joinType` gleich `existence check` ist (siehe zuvor das Argument joinType). ## `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 ein Slice mithilfe der Semantik der `LIMIT`- und `OFFSET`-Klauseln von SPARQL über den eingehenden Lösungs-Stream. **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.