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. # Der SPARQL-Abfragehinweis `joinOrder` Wenn Sie eine SPARQL-Abfrage senden, untersucht die Abfrage-Engine von Amazon Neptune die Struktur der Abfrage. Sie ordnet Teile der Abfrage neu an und versucht, den für die Auswertung erforderlichen Aufwand und die Reaktionszeit der Abfrage zu reduzieren. Beispielsweise wird eine Folge verbundener Triple-Muster in der Regel nicht in der angegebenen Reihenfolge ausgewertet. Sie wird mittels Heuristik und Statistik neu angeordnet, beispielweise der Selektivität der einzelnen Muster und der Art ihrer Verbindung mittels gemeinsamer Variablen. Wenn Ihre Abfrage außerdem komplexere Muster wie Unterabfragen oder komplexe OPTIONAL- oder MINUS-Blöcke enthält FILTERs, ordnet die Neptune-Abfrage-Engine diese nach Möglichkeit neu an, um eine effiziente Bewertungsreihenfolge zu erreichen. Für komplexere Abfragen ist die Reihenfolge, in der Neptune die Abfrage bewertet, möglicherweise nicht immer optimal. Beispielsweise übersieht Neptune möglicherweise spezifische Instance-Dateneigenschaften (z. B. Power-Knoten im Diagramm), die während der Auswertung der Abfrage auftauchen. Wenn Sie die genauen Merkmale der Daten kennen und die Reihenfolge der Abfrageausführung manuell festlegen möchten, können Sie den Neptune-Abfragehinweis `joinOrder` verwenden, um anzugeben, dass die Abfrage in der angegebenen Reihenfolge ausgewertet werden soll. ## SPARQL-Hinweissyntax `joinOrder` Der Abfragehinweis `joinOrder` ist als Triple-Muster angegeben, das in einer SPARQL-Abfrage enthalten ist. Die folgende Syntax verwendet das Präfix `hint`, das in der Abfrage definiert und eingefügt ist, zur Angabe des Neptune-Abfragehinweis-Namespace: ``` PREFIX hint: scope hint:joinOrder "Ordered" . ``` **Verfügbare Bereiche** + `hint:Query` + `hint:Group` Weitere Informationen zu Bereichen von Abfragehinweisen finden Sie unter [Bereich der SPARQL-Abfragehinweise in Neptune](sparql-query-hints.md#sparql-query-hints-scope). ## Beispiel für einen SPARQL-Hinweis `joinOrder` Dieser Abschnitt zeigt eine mit und ohne den Abfragehinweis `joinOrder` geschriebene Abfrage und die entsprechenden Optimierungen. In diesem Beispiel wird davon ausgegangen, dass der Datensatz die folgenden Elemente enthält: + Eine einzelne Person mit dem Namen `John`, die 1.000 Personen mit `:likes` markiert hat, darunter `Jane`. + Eine einzelne Person mit dem Namen `Jane`, die 10 Personen mit `:likes` markiert hat, darunter `John`. **Kein Abfragehinweis** Die folgende SPARQL-Abfrage extrahiert alle Paare von Personen mit dem Namen `John` und `Jane` aus einem Satz von Daten aus sozialen Netzwerken, die sich gegenseitig mit „Like“ (Gefällt) markiert haben. ``` PREFIX : SELECT ?john ?jane { ?person1 :name "Jane" . ?person1 :likes ?person2 . ?person2 :name "John" . ?person2 :likes ?person1 . } ``` Die Abfrage-Engine von Neptune wertet die Anweisungen möglicherweise in einer anderen Reihenfolge als geschrieben aus. Sie könnte sie beispielsweise in der folgenden Reihenfolge auswerten: 1. Suche nach allen Personen mit dem Namen `John`. 1. Suche nach allen mit `John` über das Edge `:likes` verbundenen Personen. 1. Filtern dieses Satzes nach Personen mit dem Namen `Jane`. 1. Filtern dieses Satzes nach mit `John` über das Edge `:likes` verbundenen Personen. Entsprechend dem Datensatz ergibt die Auswertung in der Reihenfolge 1.000 Entitäten, die im zweiten Schritt extrahiert werden. Der dritte Schritt engt dies auf den einzelnen Knoten `Jane` ein. Im letzten Schritt wird ermittelt, dass `Jane` den Knoten `John` auch mit `:likes` markiert hat. **Abfragehinweis** Es wäre günstiger, mit dem Knoten `Jane` zu beginnen, da dieser nur 10 ausgehende `:likes` Edges besitzt. Dies reduziert den Aufwand während der Auswertung der Abfrage, da das Extrahieren der 1.000 Entitäten im zweiten Schritt vermieden wird. Das folgende Beispiel verwendet den Abfragehinweis **joinOrder**, um sicherzustellen, dass der Knoten `Jane` und dessen ausgehenden Kanten zuerst verarbeitet werden, indem die automatische Neuanordnung der Verbindung für die Abfrage deaktiviert ist: ``` PREFIX : PREFIX hint: SELECT ?john ?jane { hint:Query hint:joinOrder "Ordered" . ?person1 :name "Jane" . ?person1 :likes ?person2 . ?person2 :name "John" . ?person2 :likes ?person1 . } ``` Ein reales Szenario wäre etwa eine Social-Network-Anwendung, bei der Personen im Netzwerk als Influencer mit zahlreichen Verbindungen oder als normale Nutzer mit wenigen Verbindungen klassifiziert würden. In einem solchen Szenario könnten Sie dafür sorgen, dass in einem Beispiel wie dem obigen der normale Benutzer (`Jane`) vor dem Influencer (`John`) verarbeitet würde. **Abfragehinweis und Neuanordnung** Sie können mit diesem Beispiel einen Schritt weiter gehen. Wenn Sie wissen, dass das `:name`-Attribut für einen Knoten eindeutig ist, könnten Sie die Abfrage durch Neuanordnung und Verwendung des Abfragehinweises `joinOrder` beschleunigen Dieser Schritt stellt sicher, dass die eindeutigen Knoten zuerst extrahiert werden. ``` PREFIX : PREFIX hint: SELECT ?john ?jane { hint:Query hint:joinOrder "Ordered" . ?person1 :name "Jane" . ?person2 :name "John" . ?person1 :likes ?person2 . ?person2 :likes ?person1 . } ``` In diesem Fall können Sie die Abfrage auf die folgenden einzelnen Aktionen in jedem Schritt reduzieren: 1. Suchen des Einzelpersonknotens mit `:name` `Jane`. 1. Suchen des Einzelpersonknotens mit `:name` `John`. 1. Prüfen, ob der erste Knoten über eine `:likes`-Edge mit dem zweiten verbunden ist. 1. Prüfen, ob der zweite Knoten über eine `:likes`-Edge mit dem ersten verbunden ist. **Wichtig** Wenn Sie die falsche Reihenfolge wählen, kann der Abfragehinweis `joinOrder` zu erheblichen Leistungseinbußen führen. Das vorangehende Beispiel wäre beispielsweise ineffizient, wenn die `:name`-Attribute nicht eindeutig wären. Hätten alle 100-Knoten den Namen `Jane` und alle 1.000-Knoten den Namen `John`, würde die Abfrage 1.000 \$1 100 (100.000) Paare für `:likes`-Edges prüfen.