Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Hinweis
Dieses Feature ist zurzeit als öffentliche Preview verfügbar. Diese Vorschauversion wird ohne Vereinbarung zum Servicelevel bereitgestellt und ist nicht für Produktionsworkloads vorgesehen. Manche Features werden möglicherweise nicht unterstützt oder sind nur eingeschränkt verwendbar. Weitere Informationen finden Sie unter Supplementale Nutzungsbedingungen für Microsoft Azure Previews.
Dieser Artikel enthält Anleitungen zum Schreiben von GQL-Abfragen (Graph Query Language), die beim Arbeiten mit Fabric Graph vorhersehbar und effizient ausgeführt werden. Die Empfehlungen basieren auf dem aktuellen Plattformverhalten und dokumentierten Einschränkungen.
Für feste Grenzwerte für die Größe von Diagrammen, die Ergebnisgröße und das Abfragetimeout finden Sie unter "Aktuelle Einschränkungen".
Frühzeitiges Filtern innerhalb von Mustern
Platzieren Sie Filter in Diagrammmustern und nicht in späteren Anweisungen. Klauseln auf Musterebene WHERE reduzieren die Anzahl der Zwischenergebnisse vor Verknüpfungen und nachfolgenden Anweisungen, wodurch die Gesamtausführungskosten gesenkt werden.
Empfohlen: Filtern Sie während des Musterabgleichs.
-- Pattern-level WHERE reduces intermediate results
MATCH (p:Person WHERE p.birthday < 19940101)-[:workAt]->(c:Company WHERE c.id > 1000)
RETURN p.firstName, p.lastName, c.name
Vermeide: Die Filterung verspätet mit einem separaten FILTER-Befehl durchzuführen.
-- Statement-level filter runs after all pattern matches are produced
MATCH (p:Person)-[:workAt]->(c:Company)
FILTER p.birthday < 19940101 AND c.id > 1000
RETURN p.firstName, p.lastName, c.name
Beide Abfragen geben dieselben Ergebnisse zurück, aber mit der ersten Version kann das Abfragemodul Zeilen weiter oben im Auswertungsprozess löschen.
Tipp
Stellen Sie sich die Musterebene WHERE analog zu einer SQL-Bedingung JOIN ... ON vor. Es schränkt Übereinstimmungen zum Zeitpunkt der Bewertung ein, anstatt die vollständige Ergebnismenge nachträglich zu filtern.
Nur die benötigten Eigenschaften zurückgeben
Geben Sie nur die Knoten- und Edgeeigenschaften zurück, die für Ihr Szenario erforderlich sind. Vermeiden Sie die Rückgabe vollständiger Knoten oder die Verwendung RETURN * , wenn Sie nur eine Teilmenge von Eigenschaften benötigen.
In Graph werden die Eigenschaften von OneLake-Tabellen als Hintergrundknoten angezeigt. Das Auswählen unnötiger Eigenschaften erhöht die Datenlese-, Serialisierungskosten und Antwortgröße. Während der Diagrammmodellierung werden alle Spalten aus der Quelltabelle standardmäßig als Eigenschaften hinzugefügt, es sei denn, Sie entfernen sie.
Empfohlen: Schmale Projektion.
MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName, p.lastName, c.name
Vermeide: Zurückgabe von vollständigen Knoten.
MATCH (p:Person)-[:workAt]->(c:Company)
RETURN *
Hinweis
Entfernen Sie nicht verwendete Eigenschaften während der Diagrammmodellierung, indem Sie das Papierkorbsymbol neben jeder Eigenschaft auswählen. Weniger Eigenschaften pro Knoten reduzieren sowohl Speicher- als auch Abfragekosten.
Begrenzen der Ergebnismenge
Wenden Sie LIMIT oder andere Begrenzungsbedingungen beim Abfragen von Knoten oder Beziehungen an, die möglicherweise eine hohe Kardinalität aufweisen. Ungebundene Graphen-Matches können sehr große Ergebnismengen erzeugen, die die Grenzen der Plattform erreichen.
Empfohlen: Begrenzte Ergebnisse.
MATCH (p:Person)-[:knows]->(friend:Person)
RETURN p.firstName, friend.firstName
LIMIT 1000
Vermeide: Unbegrenzten Match mit hoher Kardinalität.
MATCH (p:Person)-[:knows]->(friend:Person)
RETURN p.firstName, friend.firstName
Von Bedeutung
Graph schneidet Antworten ab, die größer als 64 MB sind und die Aggregationsleistung instabil sein kann, wenn die Ergebnisse 128 MB überschreiten. Verwenden Sie FILTER, LIMIT und GROUP BY, um Ergebnisse innerhalb dieser Grenzen zu halten. Weitere Informationen finden Sie unter Aktuelle Einschränkungen.
Halten Sie Traversals flach und gezielt
Vermeiden Sie tief geschachtelte oder hochkomplexe Diagrammmuster. Bevorzugen Sie einfache, gezielte Durchgänge, die direkt eine bestimmte Frage beantworten. Jeder zusätzliche Hop in einem variablen Längenmuster kann die Anzahl der von der Engine ausgewerteten Pfade exponentiell erhöhen, insbesondere in dicht verbundenen Graphen.
Empfohlen: Enge Grenzen.
-- Use the narrowest hop range that answers your question
MATCH (p:Person)-[:knows]->{1,3}(friend:Person)
RETURN p.firstName, friend.firstName
LIMIT 1000
Vermeide: Maximale Tiefendurchquerung ohne klaren Bedarf.
-- Exploring the full 8-hop limit on a dense graph is expensive
MATCH (p:Person)-[:knows]->{1,8}(friend:Person)
RETURN *
Von Bedeutung
Graph unterstützt Muster mit variabler Länge von bis zu acht Sprüngen. Verwenden Sie in diesem Fall die strengsten Grenzen, die Ihr Szenario zulässt. Im Beispiel ist das {1,3} Muster deutlich günstiger als {1,8} im gleichen Diagramm.
Verwenden von TRAIL, um redundante Traversale zu verhindern
Verwenden Sie TRAIL den Pfadmodus, um zu verhindern, dass das Abfragemodul denselben Rand erneut angibt. In dichten Graphen können Zyklen eine exponentielle Pfadexplosion verursachen.
TRAIL stellt sicher, dass jede Kante höchstens einmal pro Pfad besucht wird, was sowohl die Korrektheit als auch die Leistung verbessert.
-- TRAIL prevents revisiting the same :knows edge
MATCH TRAIL (src:Person)-[:knows]->{1,4}(dst:Person)
WHERE src.firstName = 'Alice' AND dst.firstName = 'Bob'
RETURN count(*) AS numPaths
Ohne TRAIL kann dieselbe Abfrage auf einem zyklischen Graphen eine viel größere (und häufig redundante) Ergebnismenge erstellen.
Verwenden freigegebener Variablen für effiziente Verknüpfungen
Wenn eine Abfrage Daten aus mehreren Beziehungen erfordert, verwenden Sie eine freigegebene Variable, um Muster für dieselbe Entität zu verknüpfen. Ohne eine freigegebene Variable können Muster ein kartesisches Produkt erzeugen – jede Kombination von Übereinstimmungen aus beiden Mustern – was zu einem viel größeren Resultset führt.
Empfohlen: Die freigegebene Variable p verknüpft die Muster.
-- Single shared variable ensures an efficient join
MATCH (p:Person)-[:workAt]->(c:Company),
(p)-[:isLocatedIn]->(city:City)
RETURN p.firstName, c.name AS company, city.name AS city
LIMIT 1000
Vermeide: Unabhängige Muster ohne freigegebene Variable.
-- Without a shared variable, this produces a cartesian product
MATCH (p1:Person)-[:workAt]->(c:Company),
(p2:Person)-[:isLocatedIn]->(city:City)
RETURN p1.firstName, c.name, p2.firstName, city.name
Ein kartesisches Produkt paart jedes Ergebnis aus einem Muster mit jedem Ergebnis aus dem anderen. Wenn Person-workAt->Company 1.000 Zeilen und Person-isLocatedIn->City 500 Zeilen übereinstimmen, gibt die Abfrage 1.000 × 500 = 500.000 Zeilen zurück. Durch das Hinzufügen einer freigegebenen Variablen wird die Verknüpfung eingeschränkt, sodass nur übereinstimmende Paare zurückgegeben werden.
Schlüsseleinschränkungen auf Knoten definieren
Definieren Sie Knotenschlüsseleinschränkungen in Ihrem Diagrammtyp. Mit Schlüsselbeschränkungen kann das System Abfragen optimieren, die bestimmte Knoten anhand ihrer Schlüsseleigenschaften suchen, ähnlich wie bei Primärschlüsselindizes in relationalen Datenbanken.
Wenn dein Diagrammtyp beispielsweise id als Schlüssel für Person Knoten definiert:
CONSTRAINT person_pk
FOR (n:Person) REQUIRE n.id IS KEY
Anschließend können Abfragen, die auf id filtern, diesen Schlüssel für ein direktes Nachschlagen verwenden.
-- Fast: the engine can look up person 12345 directly using the key
MATCH (p:Person WHERE p.id = 12345)-[:workAt]->(c:Company)
RETURN p.firstName, c.name
Ohne den Filter für die Schlüsseleigenschaft muss das Modul jeden Person Knoten überprüfen:
-- Slower: scans all Person nodes before traversing
MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName, c.name
Tipp
Wenn Sie einen bestimmten Knoten benötigen, filtern Sie im Muster nach seiner Schlüsseleigenschaft MATCH , um die von Ihnen definierte Einschränkung zu nutzen.
Auswählen geeigneter Datentypen
Wählen Sie den spezifischsten Datentyp für jede Eigenschaft während der Diagrammmodellierung aus. Die Auswahl der richtigen Typen ist sowohl für die Speichereffizienz als auch für die Abfrageleistung wichtig. Beispielsweise sind numerische Vergleiche für INT Eigenschaften schneller als Zeichenfolgenvergleiche für gleichwertige STRING Werte.
Unterstützte Datentypen finden Sie unter "Aktuelle Einschränkungen" – Datentypen und unterstützte Eigenschaftstypen.
Kombinieren verwandter Traversale in einer einzelnen Abfrage
Rufen Sie nach Möglichkeit verwandte Entitäten in einem einzelnen Diagrammmuster ab, anstatt separate Abfragen auszugeben, die die gleichen Kanten unabhängig voneinander durchlaufen. Durch die Kombination von Traversierungen werden redundante Musterabgleiche vermieden und das N+1-Abfrageproblem verhindert, bei dem eine erste Abfrage eine separate Abfrage für jede Ergebniszeile auslöst.
Empfohlen: Einzelnes kombiniertes Muster.
MATCH (c:Customer)-[:purchased]->(o:Order)-[:contains]->(product:Product)
RETURN c.id, o.id, product.name
LIMIT 1000
Vermeide: Zwei separate Abfragen, die denselben Customer → Order Rand durchlaufen.
-- Query 1: fetch 100 orders
MATCH (c:Customer)-[:purchased]->(o:Order)
RETURN c.id, o.id
-- Query 2: run once per order to get products (N+1 problem)
MATCH (o:Order)-[:contains]->(product:Product)
RETURN o.id, product.name
Testen von Abfragen mit realistischen Datenvolumes
Abfragen, die für kleine Datasets gut funktionieren, werden möglicherweise nicht linear skaliert. Testen Sie Ihre Abfragen mit Datenvolumes, die Ihre erwartete Produktionsauslastung darstellen.
- Bevorzugen Sie konservative Abfrage-Shapes, die Filter und Grenzwerte enthalten.
- Vermeiden Sie explorative "alles zurückgeben" Abfragen gegen große Grafen.
- Überwachen Sie die Abfragedauer relativ zum Zeitlimit von 20 Minuten.