yang db
1.0.0
https://www.yangdb.org/
Wiki
Versionsinformationen
Versionshinweise
Lior Perry
Römische Margolis
Moti Cohen
Elad Wies
Shimon Benoshti
Ein Beitrag, der unsere neue Open-Source-Initiative zum Aufbau einer skalierbaren verteilten Graph-Datenbank über Opensearch vorstellt https://www.linkedin.com/pulse/making-db-lior-perry/
Eine weitere Verwendung von Opensearch als Graph-DB https://medium.com/@imriqwe/elasticsearch-as-a-graph-database-bc0eee7f7622
Die Welt der Graphdatenbanken hat in den letzten Jahren einen enormen Einfluss gehabt, insbesondere in Bezug auf soziale Netzwerke und deren Auswirkungen auf unsere alltäglichen Aktivitäten.
Das einst mächtige (und einsame) RDBMS muss nun Platz machen für einen aufstrebenden und immer wichtigeren Partner im Rechenzentrum: die Graphdatenbank.
Twitter nutzt es, Facebook nutzt es, sogar Online-Dating-Seiten nutzen es; Sie verwenden Beziehungsdiagramme. Schließlich ist Soziales sozial und letztendlich dreht sich alles um Beziehungen.
Es gibt zwei Hauptelemente, die die Graphtechnologie unterscheiden: Speicherung und Verarbeitung.
Unter Diagrammspeicherung versteht man im Allgemeinen die Struktur der Datenbank, die Diagrammdaten enthält.
Eine solche Diagrammspeicherung ist in vielerlei Hinsicht für Diagramme optimiert und stellt sicher, dass Daten effizient gespeichert werden und Knoten und Beziehungen in der tatsächlichen physischen Schicht nahe beieinander bleiben.
Diagrammspeicher wird als nicht nativ klassifiziert, wenn der Speicher aus einer externen Quelle stammt, z. B. einer relationalen, spaltenbasierten oder einer anderen Art von Datenbank (in den meisten Fällen ist ein NoSQL-Speicher vorzuziehen).
Nicht-native Diagrammdatenbanken bestehen in der Regel aus vorhandenen relationalen, Dokument- und Schlüsselwertspeichern, die an die Abfrageszenarien des Diagrammdatenmodells angepasst sind.
Die Diagrammverarbeitung umfasst den Zugriff auf das Diagramm, das Durchlaufen der Eckpunkte und Kanten und das Sammeln der Ergebnisse.
Bei einer Durchquerung fragen Sie ein Diagramm ab, navigieren von Startknoten zu verwandten Knoten und folgen dabei Beziehungen gemäß bestimmten Regeln.
Antworten auf Fragen finden wie „Welche Musik mögen meine Freunde, die ich noch nicht besitze?“
Eines der beliebtesten Modelle zur Darstellung eines Diagramms ist das Eigenschaftsmodell.
Dieses Modell enthält verbundene Entitäten (die Knoten), die eine beliebige Anzahl von Attributen (Schlüssel-Wert-Paare) enthalten können.
Knoten haben eine eindeutige ID und eine Liste von Attributen, die ihre Funktionen und Inhalte darstellen.
Knoten können mit Beschriftungen gekennzeichnet werden, die ihre unterschiedlichen Rollen in Ihrer Domäne darstellen. Zusätzlich zu Beziehungseigenschaften können Beschriftungen auch Metadaten über Diagrammelemente bereitstellen.
Knoten werden häufig zur Darstellung von Entitäten verwendet, je nach Domäne können jedoch auch Beziehungen zu diesem Zweck verwendet werden.
Die Beziehung wird durch den Quell- und Zielknoten dargestellt, die sie verbinden, und im Falle mehrerer Verbindungen zwischen denselben Eckpunkten – zusätzliche Bezeichnung der Eigenschaft zur Unterscheidung (Art der Beziehung).
Beziehungen organisieren Knoten in beliebige Strukturen, sodass ein Diagramm einer Liste, einem Baum, einer Karte oder einer zusammengesetzten Entität ähneln kann – wobei jedes dieser Elemente zu noch komplexeren Strukturen kombiniert werden kann.
Ähnlich wie Fremdschlüssel zwischen Tabellen im relationalen DB-Modell beschreibt die Beziehung im Diagrammmodell die Beziehungen zwischen den Scheitelpunkten.
Ein wesentlicher Unterschied in diesem Modell (im Vergleich zum strengen relationalen Schema) besteht darin, dass diese schemalose Struktur das Hinzufügen/Entfernen von Beziehungen zwischen Scheitelpunkten ohne Einschränkungen ermöglicht.
Ein weiteres Diagrammmodell ist das Resource Description Framework (RDF)-Modell.
Unser Anwendungsfall liegt im Bereich der sozialen Netzwerke. Ein sehr großes soziales Diagramm, das regelmäßig aktualisiert werden muss und für beide verfügbar sein muss:
einfache (meist textuelle) Suche
graphbasierte Abfragen.
Alle Lese- und Schreibvorgänge erfolgen gleichzeitig mit angemessener Reaktionszeit und ständig wachsendem Durchsatz.
Die erste Anforderung wurde mit Opensearch erfüllt – einer bekannten und etablierten NoSql-Dokumentsuch- und Speichermaschine, die sehr große Datenmengen verarbeiten kann.
Für die zweite Anforderung haben wir beschlossen, dass unsere beste Lösung darin besteht, Opensearch als nicht-native Graph-DB-Speicherschicht zu verwenden .
Wie bereits erwähnt, kann eine Graph-DB-Speicherschicht mithilfe eines nicht-nativen Speichers wie NoSql-Speicher implementiert werden.
In einer zukünftigen Diskussion werde ich näher darauf eingehen, warum die beliebteste Community-Alternative für Graph-DB – Neo4J – nicht unseren Anforderungen entsprechen konnte.
Das erste Problem, mit dem wir uns befassen müssen, besteht darin, das Datenmodell zu entwerfen, das den Graphen als eine Reihe von Eckpunkten und Kanten darstellt.
Mit Opensearch können wir seine leistungsstarken Suchfunktionen nutzen, um Knoten- und Beziehungsdokumente entsprechend den Abfragefiltern effizient abzurufen.
In Opensearch kann jeder Index als Tabelle für ein bestimmtes Schema beschrieben werden. Der Index selbst ist in gemeinsame Partitionen unterteilt, die Skalierung und Redundanz (mit Replikaten) im gesamten Cluster ermöglichen.
Ein Dokument wird mithilfe der folgenden Formel an einen bestimmten Shard in einem Index weitergeleitet:
shard_num = hash(_routing) % num_primary_shards
Jeder Index verfügt über ein Schema (in Opensearch Typ genannt), das die Struktur des Dokuments definiert (in Opensearch Mapping genannt). Jeder Index kann nur einen einzigen Zuordnungstyp enthalten (seit Opensearch 6).
Der Vertices-Index enthält die Vertices-Dokumente mit den Eigenschaften, der Edges-Index enthält die Edges-Dokumente mit ihren Eigenschaften.
Die Art und Weise, wie wir beschreiben, wie der Graph durchlaufen wird (Datenquelle)
Es gibt nur wenige graphorientierte Abfragesprachen:
Cypher ist eine Abfragesprache für die Neo4j-Graphdatenbank (siehe openCypher-Initiative)
Gremlin ist eine Graph-Traversal-Sprache der Apache Software Foundation für OLTP- und OLAP-Graphsysteme.
SPARQL ist eine Abfragesprache für RDF-Diagramme.
Einige der Sprachen sind eher musterbasiert und deklarativ, andere eher imperativ – sie alle beschreiben die logische Art und Weise der Datendurchquerung.
Betrachten wir Cypher – eine deklarative, von SQL inspirierte Sprache zur visuellen Beschreibung von Mustern in Diagrammen mithilfe einer ASCII-Art-Syntax.
Damit können wir angeben, was wir aus unseren Diagrammdaten auswählen, einfügen, aktualisieren oder löschen möchten, ohne dass wir genau beschreiben müssen, wie das geht.
Sobald eine logische Abfrage vorliegt, müssen wir sie in die physische Ebene des Datenspeichers übersetzen, nämlich Opensearch.
Opensearch verfügt über eine Abfrage-DSL, die sich auf Suche und Aggregationen konzentriert – nicht auf Traversierung. Wir benötigen eine zusätzliche Übersetzungsphase, die die schematische Struktur des Diagramms (und die zugrunde liegenden Indizes) berücksichtigt.
Die Übersetzung von logischen in physische Abfragen ist ein Prozess, der nur wenige Schritte umfasst:
Validieren der Abfrage anhand des Schemas
Übersetzen der Beschriftungen in echte Schema-Entitäten (Indizes)
Erstellen der physischen Opensearch-Abfrage
Dies ist in der Praxis der Prozess bei einer High-Level-Überprüfung – es gibt mehrere Phasen, die die logische Abfrage optimieren; In einigen Fällen ist es möglich, mehrere physische Pläne (Ausführungspläne) zu erstellen und sie nach einer Effizienz-(Kosten-)Strategie zu ordnen, wie z. B. der Anzahl der zum Abrufen erforderlichen Elemente ...
Wir begannen mit der Erörterung des Zwecks der Diagramm-Datenbank in heutigen Geschäftsanwendungsfällen und überprüften verschiedene Modelle zur Darstellung eines Diagramms. Verständnis der grundlegenden logischen Bausteine, aus denen eine potenzielle Graph-Datenbank bestehen sollte, und Diskussion eines vorhandenen NoSql-Kandidaten zur Erfüllung der Speicherschichtanforderungen.
Nachdem wir Opensearch als Speicherschicht ausgewählt hatten, haben wir das LDBC Social Network Benchmark-Grafikmodell übernommen und es vereinfacht, um es für diesen speziellen Speicher zu optimieren. Wir haben das tatsächliche Speicherschema mit den redundanten Eigenschaften besprochen und die Verschlüsselungssprache überprüft, um den Speicher in einer SQL-ähnlichen Diagrammmustersprache abzufragen.
Wir haben weiterhin die tatsächliche Umwandlung der Verschlüsselungsabfrage in eine physische Ausführungsabfrage beobachtet, die von Opensearch ausgeführt wird.
Im letzten Abschnitt haben wir eine einfache Diagrammabfrage durchgeführt und uns die Details der Ausführungsstrategien und des Bulking-Mechanismus genauer angesehen.
Installationsanleitung:
Tutorial zur Schemaerstellung:
Tutorial zum Laden von Daten:
Tutorial zum Abfragen des Diagramms:
Tutorial zur Projektionsmaterialisierung und -zählung:
