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.
Wenn Neptune Abfrageoptimierungen durchführt, erschweren bidirektionale Edges die Erstellung optimaler Abfragepläne. Bei suboptimalen Plänen muss die Engine unnötige Arbeit verrichten, was zu einer schlechteren Leistung führt.
Verwenden Sie daher nach Möglichkeit direktionale anstelle von bidirektionalen Edges. Verwenden Sie beispielsweise:
MATCH p=(:airport {code: 'ANC'})-[:route]->(d) RETURN p)
anstelle von:
MATCH p=(:airport {code: 'ANC'})-[:route]-(d) RETURN p)
Die meisten Datenmodelle müssen Edges nicht wirklich in beide Richtungen durchqueren, so dass Abfragen durch die Umstellung auf die Verwendung direktionaler Edges zu erheblichen Leistungsverbesserungen führen können.
Wenn Ihr Datenmodell das Durchqueren bidirektionaler Edges erfordert, machen Sie den ersten Knoten (linke Seite) im MATCH-Muster zum Knoten mit der restriktivsten Filterung.
Nehmen wir das Beispiel „Finde alle routes zum und vom ANC-Flughafen“. Schreiben Sie diese Abfrage wie folgt so, dass sie am ANC-Flughafen beginnt:
MATCH p=(src:airport {code: 'ANC'})-[:route]-(d) RETURN p
Die Engine kann den geringsten Arbeitsaufwand zur Erfüllung der Abfrage wählen, da der Knoten mit den meisten Einschränkungen als erster Knoten (linke Seite) im Muster platziert wird. Die Engine kann dann die Abfrage optimieren.
Das ist weitaus besser, als den ANC-Flughafen am Ende des Musters wie folgt zu filtern:
MATCH p=(d)-[:route]-(src:airport {code: 'ANC'}) RETURN p
Wenn der Knoten mit den meisten Einschränkungen nicht an erster Stelle im Muster steht, muss die Engine zusätzliche Arbeit leisten, da sie die Abfrage nicht optimieren kann und zusätzliche Suchvorgänge durchführen muss, um zu den Ergebnissen zu gelangen.
