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.
Graph-Datenbanken bieten eine leistungsstarke Möglichkeit zum Modellieren und Abfragen verbundener Daten. Im Gegensatz zu herkömmlichen relationalen Datenbanken, die Daten in Tabellen speichern, stellen Graphdatenbanken Informationen als Knoten (Entitäten) und Kanten (Beziehungen) dar, wodurch komplexere Verbindungen und Muster einfacher untersucht werden können. In diesem Artikel werden die Kernkonzepte von Graphdatenbanken, die Funktionsweise von Graphabfragen und wann die Verwendung einer Graphdatenbank für Ihre Arbeitslast in Betracht gezogen werden sollte, erläutert. Es vergleicht Fabric Graph auch mit eigenständigen Graph-Datenbankbereitstellungen.
Der am häufigsten verwendete Typ der Diagrammdatenbank implementiert das Modell für beschriftete Eigenschaftendiagramme (LPG): Entitäten (Knoten) und Beziehungen (Kanten) können Bezeichnungen und Eigenschaften (Schlüsselwertpaare) aufweisen. Dieses flexible Modell ermöglicht sowohl schema-optionale als auch schemagesteuerte Designs und ermöglicht ihnen das Ausdrücken umfangreicher Semantik. Da Verbindungen explizit als Kanten gespeichert werden, durchlaufen Abfragen Beziehungen, indem sie Kanten folgen, anstatt teure Verknüpfungen zur Abfragezeit zu berechnen.
Von Bedeutung
In diesem Artikel wird ausschließlich das Beispieldiagramm-Dataset für soziale Netzwerke verwendet.
Kernkonzepte von Graph-Datenbanken
- Knoten stellen Entitäten wie Personen, Produkte oder Orte dar. Knoten können Bezeichnungen und Eigenschaften aufweisen, die ihre Attribute beschreiben. Beispielsweise kann ein Person-Knoten Eigenschaften wie Vorname, Nachname und Alter aufweisen.
- Kanten stellen dar, wie die Entitäten verbunden sind, z. B. FRIENDS_WITH, GEKAUFT oder LOCATED_IN. Edges können auch Eigenschaften und Labels zum Codieren von Beziehungsmetadaten tragen.
- Eigenschaften fügen Details zu Knoten und Kanten an (z. B. den Namen einer Person oder das Datum einer Kante). Da Beziehungen explizit als Kanten gespeichert werden, navigieren Abfragen im Diagramm, indem Sie Verbindungen folgen, anstatt sie zur Abfragezeit zu berechnen.
Wie das Abfragen von Beziehungen funktioniert
Graph-Abfragen rufen verbundene Informationen ab, indem sie von einem Startknoten zu dessen Nachbarn durchlaufen, dann zu deren Nachbarn und so weiter. Der Aufwand, den ein Traversal ausführt, ist an die Anzahl der Kanten gebunden, die es berührt (die lokale Nachbarschaft), nicht die Gesamtgröße des Datensatzes. Dieses Merkmal stellt Fragen zu Pfaden, Verbindungen und Mustern – wie Freunde von Freunden, kürzesten Pfaden oder Multi-Hop-Abhängigkeiten – natürlich und effizient zum Ausdruck.
Graph-Datenbanken verwenden musterbasierte Abfragesprachen, z. B. die zunehmend eingeführte Graph Query Language (GQL), um diese Traversale präzise zu beschreiben. Die gleiche internationale Arbeitsgruppe, die SQL (ISO/IEC 39075) überwacht, standardisiert GQL, das die Graphabfrage mit etablierten Datenbankstandards abstimmt.
Beispiel (Musterabgleich mit GQL):
MATCH (p:Person {firstName: "Annemarie"})-[:knows]->(friend)-[:likes]->(c:Comment)
RETURN c
ORDER BY c.creationDate
LIMIT 100
Dieses Muster liest wie folgt: Beginnend am Knoten "Person" für Annemarie, folgen Sie den :knows Kanten zu jedem Freundknoten und dann den :likes Kanten zu verknüpften :Comment Knoten. Gibt die 100 neuesten Kommentare zurück, die nach dem Erstellungsdatum sortiert sind.
Modellierung und Schema
Graph-Datenmodelle sind Schema-optional: Sie können mit einem festen Schema arbeiten, wenn Sie eine starke Governance benötigen, oder das Modell weiterentwickeln, wenn neue Knotentypen, Beziehungen oder Eigenschaften auftauchen. Dieser Ansatz reduziert den Bedarf an Datenduplizierung und ermöglicht Teams die Vereinheitlichung von Daten aus mehreren Quellen, ohne dass eine hohe Neugestaltung im Voraus erforderlich ist.
Allgemeine Verwendungen für Graphdatenbanken
Graph-Datenbanken passen gut zu Bereichen, in denen Verbindungen den Wert bestimmen, z. B.:
- Soziale Netzwerke
- Wissensdiagramme
- Empfehlungssysteme
- Betrugs- und Risikonetzwerke
- Netzwerk- und IT-Topologie
- Abhängigkeitsanalyse der Lieferkette
In diesen Szenarien drehen sich die Fragen weniger um einzelne Datensätze und mehr darum, wie viele Entitäten miteinander in Beziehung stehen und über mehrere Verbindungen interagieren.
Wann sollten Sie eine Diagrammdatenbank in Betracht ziehen?
Wählen Sie eine Diagrammdatenbank aus, wenn:
- Ihre hauptfragen umfassen Pfade, Nachbarschaften und Muster in verbundenen Daten.
- Die Anzahl der Hops ist variabel oder im Voraus nicht bekannt.
- Sie müssen Beziehungen zwischen unterschiedlichen Datasets kombinieren und navigieren.
Wenn Sie diese Art von Fragen regelmäßig stellen, ist ein Diagrammmodell eine natürliche Passform.
Vergleich von Fabric Graph mit eigenständigen Diagrammdatenbanken
Die Darstellung Ihrer Daten als Diagramm und das Speichern in einer separaten, eigenständigen Graphdatenbank führt häufig zu ETL (Extrahieren, Transformieren, Laden) und Governance-Overhead. Im Gegensatz dazu arbeitet Graph direkt auf OneLake, wodurch die Notwendigkeit separater ETL-Pipelines und Datenduplizierung reduziert oder eliminiert wird. Berücksichtigen Sie diese Kompromisse:
- Datenverschiebung und Duplizierung: Eigenständige Diagrammdatenbanken erfordern in der Regel das Extrahieren, Transformieren und Laden von Daten in einen separaten Speicher, wodurch die Komplexität erhöht und zu duplizierten Datasets führen kann. Graph arbeitet auf OneLake, sodass Sie verbundene Daten modellieren und abfragen können, ohne sie zu verschieben.
- Betriebskosten: Eigenständige Diagrammstapel werden als separate Cluster oder Dienste ausgeführt und tragen häufig Leerlaufkosten. Graph-Workloads verbrauchen gepoolte Kapazitätseinheiten (CUs) mit automatischer Skalierung und zentralisierten Metriken, was die Vorgänge vereinfacht und Kosten senken kann.
- Skalierbarkeit: Einige eigenständige Graphdatenbanken hängen von skalierungs- oder herstellerspezifischem Clustering ab. Graph ist für groß angelegte Graphen konzipiert und verwendet Scale-Out-Sharding über mehrere Worker hinweg, um Big-Data-Workloads effizient zu verarbeiten.
- Tools und Fähigkeiten: Anbieterspezifische Diagrammsysteme können spezielle Sprachen und separate Analyseframeworks erfordern. Graph bietet einheitliche Modellierung, standardsbasierte Abfrage (GQL), integrierte Graph-Analysealgorithmen, BI- und KI-Integration sowie explorative Tools mit geringem/ohne Code. Diese Funktionen ermöglichen eine breitere Gruppe von Benutzern, mit verbundenen Daten zu arbeiten.
- Governance und Sicherheit: Separate Graph-Bereitstellungen benötigen unabhängige Governance- und Sicherheitskonfigurationen. Graph verwendet die OneLake-Governance, Abstammung und rollenbasierte Zugriffskontrolle von Arbeitsbereichen (RBAC), sodass Compliance, Überwachung und Berechtigungen im Einklang mit dem Rest Ihrer Fabric-Umgebung bleiben.