Freigeben über


Was ist eine Diagrammdatenbank?

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.

Eine Diagrammdatenbank ist ein Datenbanktyp, der Informationen als Knoten (Entitäten) und Kanten (Beziehungen) anstelle von Tabellen und Zeilen darstellt. Diese Struktur macht es einfach, komplexe Verbindungen und Muster in Ihren Daten zu untersuchen.

Der am häufigsten verwendete Typ der Diagrammdatenbank implementiert das Modell für beschriftete Eigenschaftendiagramme (LPG): Entitäten (Knoten) und Beziehungen (Kanten) können Beschriftungen und Eigenschaften (Schlüsselwertpaare) aufweisen. Dieses flexible Modell ermöglicht sowohl schema-optionalen als auch schemagesteuerten Designs und erlaubt es Ihnen, komplexe Beziehungen auszudrücken. Da Verbindungen explizit als Kanten gespeichert werden, durchlaufen Abfragen Beziehungen, indem sie Kanten folgen, anstatt teure Verknüpfungen zur Abfragezeit zu berechnen.

Hinweis

Beispiele in diesem Artikel verwenden das Beispieldiagramm-Dataset für soziale Netzwerke.

Kernkonzepte von Graph-Datenbanken

Eine Diagrammdatenbank organisiert Daten in drei grundlegende Bausteine:

  • Knoten stellen Entitäten wie Personen, Produkte oder Orte dar. Knoten können Bezeichnungen und Eigenschaften aufweisen, die ihre Attribute beschreiben. Ein Knoten kann Person z. B. Eigenschaften wie firstName, lastName, und age haben.
  • Edges stellen dar, wie die Entitäten verbunden sind, z. B. FRIENDS_WITH, PURCHASED oder LOCATED_IN. Edges können auch Eigenschaften und Labels besitzen, um Beziehungsmetadaten zu erfassen.
  • Eigenschaften fügen Details zu Knoten und Kanten an (z. B. den Namen einer Person oder das Datum einer Kante).

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. Die Kosten eines Traversals hängen von der Anzahl der Kanten ab, die es berührt (die lokale Nachbarschaft), nicht von der 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. 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.

Graph-Datenmodell und Schemaflexibilität

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. Weitere Informationen zum datenmodell, das in Graph in Microsoft Fabric verwendet wird, finden Sie unter "Beschriftete Eigenschaftendiagramme".

Allgemeine Verwendungen für Graphdatenbanken

Graph-Datenbanken passen gut zu Bereichen, in denen Verbindungen den Wert bestimmen, z. B.:

  • Soziale Netzwerke – Modellbeziehungen zwischen Menschen und ihren Interaktionen
  • Wissensdiagramme – Verbinden von Konzepten, Entitäten und Fakten für semantische Suche und Begründung
  • Empfehlungssysteme – Durchlaufen von Benutzerelementinteraktionen, um personalisierte Vorschläge anzuzeigen
  • Betrugs- und Risikonetzwerke – Erkennen verdächtiger Muster für Konten, Transaktionen und Geräte
  • Netzwerk- und IT-Topologie – Zuordnen von Abhängigkeiten zwischen Servern, Diensten und Infrastrukturkomponenten
  • Analyse der Abhängigkeiten in der Lieferkette – Ursprung von Komponenten nachverfolgen und Beziehungen zwischen den Lieferanten analysieren

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?

Eine Graphdatenbank ist optimal geeignet, wenn Beziehungen die Kernfragen bestimmen, die Sie beantworten müssen. 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 Graph in Microsoft Fabric mit eigenständigen Graphdatenbanken

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 in Microsoft Fabric 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. Bei der Verwendung von Graph verbrauchen Workloads kapazitätsgebündelte Einheiten (CUs) mit automatischen Skalierungsfunktionen und zentralisierten Metriken, die die Abläufe vereinfachen und Kosten senken können.
  • 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.