Moderne Informationssysteme sind ziemlich komplex. Ihre Komplexität ist nicht zuletzt durch die Vielfalt der verarbeiteten Daten bedingt. Die Komplexität dieser Daten liegt häufig in der Vielzahl der verwendeten Datenmodelle. So wird zum Beispiel, wenn Daten „groß“ werden, nicht nur ihr Umfang („volume“) als herausfordernd angesehen, sondern auch ihre Vielfalt („variety“).

Wenn Sie bisher keinen Fehler in den Überlegungen finden, lesen Sie weiter.

Inhalt

Polyglot Persistence
Multimodalität
Multimodale DBMS auf Basis des relationalen Modells
     Dokumentenmodell in MS SQL Server
     Graphmodell in MS SQL Server
Multimodale DBMS auf Basis des Dokumentenmodells
     Relationales Modell in MarkLogic
     Graphmodell in MarkLogic
Multimodale DBMS „ohne Hauptmodell“
     ArangoDB
     OrientDB
     Azure CosmosDB
Multimodale DBMS auf Basis des Graphmodells?
Fazit
Umfrage

Polyglot Persistence

Das Obige führt dazu, dass in einem einzigen System manchmal mehrere verschiedene DBMS zur Speicherung von Daten und zur Lösung verschiedener Verarbeitungsaufgaben verwendet werden müssen, von denen jedes sein eigenes Datenmodell unterstützt. Auf Anregung von M. Fowler, Autor einer Reihe bekannter Bücher und eines der Mitautoren des Agile Manifesto erhielt diese Situation den Namen polyglot persistence. Fowler wird auch mit folgendem Beispiel für die Datenorganisation in einer voll funktionsfähigen und hochbelasteten Anwendung im Bereich E-Commerce zitiert.

Dieses Beispiel ist zwar etwas übertrieben, aber einige Überlegungen zur Wahl eines bestimmten DBMS für einen bestimmten Zweck finden sich, zum Beispiel,

Es ist klar, dass es nicht einfach ist, in einem solchen Zoo zu arbeiten. hier.

Das Volumen des Codes, der Daten speichert, wächst proportional zur Anzahl der verwendeten DBMS; das Volumen des Codes, der Daten synchronisiert, wächst im besten Fall nicht proportional zum Quadrat dieser Anzahl.

Die Kosten für die Gewährleistung von Enterprise-Eigenschaften (Skalierbarkeit, Fehlertoleranz, hohe Verfügbarkeit) steigen in gleichem Maße wie die Anzahl der verwendeten DBMS.
Es ist unmöglich, die Enterprise-Eigenschaften der Speichersubsysteme insgesamt zu gewährleisten – besonders die Transaktionsfähigkeit.
Aus der Sicht des Zoo-Leiters sieht das so aus:

Das Kostensteigerung bei Lizenzen und technischem Support vom DBMS-Anbieter.

Ein mehrfacher Anstieg der Lizenzkosten und des technischen Supports durch den DBMS-Hersteller.
Aufblähung des Staates und Verlängerung der Fristen.
Direkte finanzielle Verluste oder Strafen aufgrund von Inkonsistenzen bei den Daten.

Es gibt einen signifikanten Anstieg der Gesamtkosten für den Betrieb des Systems (TCO). Gibt es einen Ausweg aus der Situation des "multivariaten Speicherns"?

Multimodalität

Der Begriff "multivariates Speichern" wurde 2011 populär. Das Bewusstsein für die Probleme des Ansatzes und die Suche nach Lösungen dauerten mehrere Jahre, und bis 2015 wurde von den Analysten von Gartner die Antwort formuliert:

Aus "Market Guide for NoSQL DBMSs — 2015»:
Die Zukunft der DBMS, ihrer Architekturen und Verwendungsweisen — Multimodalität.
Aus "Magic Quadrant for ODBMS — 2016»:
Führende operationale DBMS werden mehrere Modelle anbieten — relationale und nicht-relationale — innerhalb einer einzigen Plattform.

Es scheint, dass die Analysten von Gartner diesmal mit ihrer Prognose recht hatten. Wenn man die Seite mit dem Hauptranking der DBMS auf DB-Engines aufruft, kann man sehen, dass dieomeisten ihrer Führer sich tatsächlich als multimodale DBMS positionieren. Das gleiche lässt sich auch auf der Seite mit einem beliebigen Teilranking beobachten.

In der folgenden Tabelle sind die DBMS aufgeführt, die in jedem der Teilrankings führend sind und ihre Multimodalität beanspruchen. Für jedes DBMS sind das ursprünglich unterstützte Modell (welches einmal das einzige war) sowie die Modelle, die jetzt unterstützt werden, angegeben. Außerdem werden DBMS aufgeführt, die sich als "von Anfang an multimodal" positionieren und nach Angaben der Hersteller kein ursprüngliches ererbtes Modell haben.

Datenbankmanagementsystem	Ursprüngliches Modell	Zusätzliche Modelle
Oracle	Relational	Graph, Dokument
MS SQL	Relational	Graph, Dokument
PostgreSQL	Relational	Graph*, Dokument
MarkLogic	Dokument	Graph, relational
MongoDB	Dokument	Key-Value, Graph*
DataStax	Wide-Column	Dokument, Graph
Redis	Key-Value	Dokument, Graph*
ArangoDB	—	Graph, Dokument
OrientDB	—	Graph, Dokument, relational
Azure CosmosDB	—	Graph, Dokument, relational

Anmerkungen zur Tabelle

Mit Sternchen in der Tabelle gekennzeichnete Aussagen erfordern Vorbehalte:

DBMS PostgreSQL unterstützt kein Graphdatenmodell, jedoch wird es von einem Produkt unterstützt, das auf dessen Basis, wie zum Beispiel AgensGraph.
Hinsichtlich MongoDB ist es richtiger, eher von der Verfügbarkeit grafischer Operatoren in der Abfragesprache zu sprechen ($lookup, $graphLookup), als von der Unterstützung eines Graphmodells, obwohl deren Einführung natürlich einige Optimierungen auf der Ebene der physischen Speicherung in Richtung Unterstützung des Graphmodells erforderte.
Im Falle von Redis bezieht sich dies auf eine Erweiterung RedisGraph.

Für jede der Klassen werden wir zeigen, wie die Unterstützung mehrerer Modelle in den DBMS dieser Klasse implementiert wird. Die wichtigsten Modelle sind das relationale, dokumentenorientierte und grafenbasierte Modell. Anhand konkreter DBMS-Beispiele werden wir erläutern, wie die 'fehlenden' Modelle umgesetzt werden.

Multimodale DBMS auf Basis des relationalen Modells

Die führenden DBMS sind derzeit relationale Systeme. Die Prognose von Gartner würde sich nicht bewahrheiten, wenn RDBMS nicht in Richtung Multimodalität tendieren würden. Und genau das tun sie. Die Überlegungen, dass multimodale DBMS wie ein Schweizer Taschenmesser sind, mit dem man nichts richtig machen kann, können direkt an Larry Ellison gerichtet werden.

Der Autor bevorzugt jedoch die Umsetzung der Multimodalität in Microsoft SQL Server, an dessen Beispiel die Unterstützung der dokumentenorientierten und grafischen Modelle beschrieben werden soll.

Dokumentenmodell in MS SQL Server

Über die Implementierung der Unterstützung des dokumentenorientierten Modells in MS SQL Server gab es bereits zwei ausgezeichnete Artikel auf Habré. Ich werde mich auf eine kurze Zusammenfassung und Anmerkung beschränken:

Die Art und Weise, wie das dokumentenorientierte Modell in MS SQL Server unterstützt wird, ist für relationale DBMS typisch: JSON-Dokumente sollen in normalen Textfeldern gespeichert werden. Die Unterstützung des dokumentenorientierten Modells besteht darin, spezielle Operatoren zur Analyse dieses JSON bereitzustellen:

JSON_VALUE um skalare Werte von Attributen zu extrahieren,
JSON_QUERY um Unterdokumente zu extrahieren.

Das zweite Argument beider Operatoren ist ein Ausdruck im JSONPath-ähnlichen Syntax.

Abstrakt gesagt kann man sagen, dass Dokumente, die auf diese Weise gespeichert werden, in einem relationalen DBMS keine 'Entities erster Klasse' sind, im Gegensatz zu Tupeln. Konkret fehlen in MS SQL Server momentan Indizes für die Felder von JSON-Dokumenten, was die Operationen von Tabellenverknüpfungen anhand der Werte dieser Felder und selbst die Abfrage von Dokumenten anhand dieser Werte erschwert. Es ist jedoch möglich, für ein solches Feld eine berechnete Spalte und einen Index darauf zu erstellen.

Zusätzlich bietet MS SQL Server die Möglichkeit, JSON-Dokumente bequem aus den Inhalten von Tabellen mit dem Operator zu konstruieren FOR JSON PATH — die Möglichkeit, in gewissem Sinne das Gegenteil der vorherigen, üblichen Speicherung. Es ist klar, dass, egal wie schnell ein DBMS ist, ein solcher Ansatz der Ideologie dokumentorientierter DBMS widerspricht, die im Grunde fertige Antworten auf populäre Anfragen speichert, und er kann nur Entwicklungshöflichkeiten lösen, nicht jedoch die Geschwindigkeit.

Schließlich ermöglicht MS SQL Server die Lösung der umgekehrten Aufgabe der Dokumentenkonstruktion: Man kann JSON mithilfe von OPENJSONin Tabellen aufteilen. Wenn das Dokument nicht ganz flach ist, muss man CROSS APPLY.

Graphmodell in MS SQL Server

verwenden. Die Unterstützung des graphenorientierten (LPG) Modells ist in Microsoft SQL Server ebenfalls durchaus vorhersehbar: Es wird vorgeschlagen, spezielle Tabellen für die Speicherung von Knoten und für die Speicherung der Kanten des Graphen zu verwenden. Solche Tabellen werden mit Hilfe von Ausdrücken erstellt, CREATE TABLE AS NODE und CREATE TABLE AS EDGE entsprechend.

Tabellen der ersten Art ähneln den gewöhnlichen Tabellen zur Speicherung von Datensätzen mit dem einzigen äußeren Unterschied, dass in der Tabelle ein Systemfeld enthalten ist, $node_id — ein innerhalb der Datenbank eindeutiger Identifikator des Graphenknotens.

Analog dazu enthalten Tabellen der zweiten Art Systemfelder, $from_id und $to_id, wobei die Einträge in solchen Tabellen verständlicherweise die Beziehungen zwischen den Knoten definieren. Für die Speicherung von Beziehungen jeder Art wird eine separate Tabelle verwendet.

Illustrieren wir das Gesagte anhand eines Beispiels. Angenommen, die graphischen Daten haben ein Schema wie in der Abbildung gezeigt. Um die entsprechende Struktur in der Datenbank zu schaffen, müssen die folgenden DDL-Abfragen ausgeführt werden:

CREATE TABLE Person (
  ID INTEGER NOT NULL,
  name VARCHAR(100)
) AS NODE;

CREATE TABLE Cafe (
  ID INTEGER NOT NULL, 
  name VARCHAR(100), 
) AS NODE;

CREATE TABLE likes (
  rating INTEGER
) AS EDGE;

CREATE TABLE friendOf
  AS EDGE;

ALTER TABLE likes
  ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe);

Die Hauptspezifik dieser Tabellen besteht darin, dass in Anfragen an sie graphenbasierte Muster mit Cypher-ähnlicher Syntax verwendet werden können (übrigens werden "*" und ähnliche derzeit noch nicht unterstützt). Auf Basis der Leistungskennzahlen lässt sich auch annehmen, dass die Art der Datenspeicherung in diesen Tabellen sich von dem Mechanismus der Datenspeicherung in herkömmlichen Tabellen unterscheidet und für die Ausführung solcher graphenbasierten Anfragen optimiert ist.

SELECT Cafe.name
  FROM Person, likes, Cafe
  WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
  AND Person.name = 'John';

Zudem ist es ziemlich schwierig, bei der Arbeit mit solchen Tabellen auf diese Graphmuster zu verzichten, da in normalen SQL-Abfragen für die Lösung ähnlicher Aufgaben zusätzliche Anstrengungen unternommen werden müssen, um die systeminternen "Graph"-Identifikatoren der Knoten zu erhalten ($node_id, $from_id, $to_id; aus diesem Grund sind die Datenbankanfragen zum Einfügen hier nicht aufgeführt, da sie als übermäßig komplex gelten).

Zusammenfassend möchte ich bei der Beschreibung der Implementierungen des dokumenten- und graphbasierten Modells in MS SQL Server erwähnen, dass solche Implementierungen eines Modells über einem anderen aus sprachgestalterischer Sicht zunächst unvorteilhaft erscheinen. Es ist erforderlich, eine Sprache mit einer anderen zu erweitern, die Sprachen sind nicht ganz "orthogonal", und die Kompatibilitätsregeln können recht merkwürdig sein.

Multimodale DBMS auf Basis des Dokumentenmodells

In diesem Abschnitt möchte ich die Umsetzung der Multimodalität in dokumentenbasierten DBMS am Beispiel einer der weniger populären Systeme, MongoDB, illustrieren (wie bereits erwähnt, hat es nur bedingt graphbasierte Operatoren, $lookup und $graphLookup, die nicht auf sharded Sammlungen funktionieren), sondern anhand eines reiferen und "unternehmensgerechten" DBMS. MarkLogic.

So sei gesagt, dass die Sammlung eine Menge XML-Dokumente des folgenden Typs enthält (MarkLogic unterstützt auch die Speicherung von JSON-Dokumenten):

John
  Smith

Relationales Modell in MarkLogic

Ein relationales Modell für die Sammlung von Dokumenten kann mit Hilfe eines Mapping-Templates erzeugt werden (der Inhalt der Elemente value im folgenden Beispiel kann beliebiger XPath sein):

/Person
  
    
      Person
      
        
          SSN
          @SSN
          string
        
        
          name
          name
        
        
          surname
          surname

Auf die erstellte Ansicht kann eine SQL-Anfrage gerichtet werden (zum Beispiel über ODBC):

SELECT name, surname FROM Person WHERE name="John"

Leider ist die durch das Mapping-Template erstellte relationale Ansicht nur schreibgeschützt verfügbar. Bei der Bearbeitung einer Anfrage an sie wird MarkLogic versuchen, die Dokumentenindizeszu verwenden. Zuvor gab es in MarkLogic auch eingeschränkte relationale Ansichten, die vollständig auf Indizes basierten und schreibbar waren, aber heutzutage gelten sie als veraltet.

Graphmodell in MarkLogic

Mit der Unterstützung des graphbasierten (RDF) Modells sieht es ähnlich aus. Wiederum kann man mit Hilfe von Mapping-Templates eine RDF-Darstellung der im obigen Beispiel verwendeten Dokumentensammlung erstellen:

/Person
    
      
        PREFIX
        "http://example.org/example#"
      
    
  
    
      sem:iri( $PREFIX || @SSN )
      sem:iri( $PREFIX || surname )
      
    
    
      sem:iri( $PREFIX || @SSN )
      sem:iri( $PREFIX || name )

An das erhaltene RDF-Diagramm kann eine SPARQL-Abfrage gerichtet werden:

PREFIX : 
SELECT ?name ?surname {
  :631803299804 :name ?name ; :surname ?surname .
}

Im Gegensatz zum relationalen Modell wird das graphbasierte Modell von MarkLogic auf zwei weitere Arten unterstützt:

Das DBMS kann ein vollständiges, separates Repository für RDF-Daten sein (die Tripel werden dann als managed bezeichnet, im Gegensatz zu den oben beschriebenen extracted.).
RDF kann in einer speziellen Serialisierung einfach in XML- oder JSON-Dokumente eingefügt werden (und die Tripel werden dann als unmanaged). Wahrscheinlich ist dies eine Art Alternative zu den Mechanismen idref. u. a.

Ein gutes Verständnis dafür, wie "es tatsächlich" in MarkLogic funktioniert, vermittelt Optic API, in diesem Sinne ist es niedrigschwellig, obwohl sein Zweck eher gegenteilig ist – zu versuchen, sich von dem verwendeten Datenmodell zu abstrahieren, einen konsistenten Umgang mit Daten in verschiedenen Modellen zu gewährleisten, Transaktionsfähigkeit usw.

Multimodale DBMS „ohne Hauptmodell“

Auf dem Markt gibt es auch DBMS, die sich ursprünglich als multimodale Systeme positionieren, ohne dass ein vererbtes Hauptmodell vorhanden ist. Dazu gehören ArangoDB, OrientDB (seit 2018 gehört das Entwicklerunternehmen zu SAP) und CosmosDB (ein Service innerhalb der Cloud-Plattform Microsoft Azure).

Tatsächlich gibt es "grundlegende" Modelle in ArangoDB und OrientDB. In beiden Fällen handelt es sich um eigene Datenmodelle, die eine Verallgemeinerung des Dokumentenmodells darstellen. Die Verallgemeinerungen bestehen hauptsächlich darin, die Möglichkeit zu erleichtern, Anfragen graphischer und relationaler Art zu stellen.

Diese Modelle sind in den angegebenen DBMS die einzig verfügbaren zur Nutzung, und sie verwenden eigene Abfragesprachen. Zweifellos sind solche Modelle und DBMS zukunftsträchtig, jedoch macht das Fehlen der Kompatibilität mit Standardmodellen und -sprachen die Nutzung dieser DBMS in ererbten Systemen unmöglich — eine Ersetzung der dort bereits genutzten DBMS wäre daher nicht möglich.

Über ArangoDB und OrientDB gab es bereits einen großartigen Artikel auf Habré: JOIN in NoSQL-Datenbanken.

ArangoDB

ArangoDB gibt Unterstützung für das grafische Datenmodell an.

Die Knoten im Graph von ArangoDB sind gewöhnliche Dokumente, während die Kanten spezielle Dokumente sind, die neben den normalen Systemfeldern (_key, _id, _rev) systemische Felder _from und _to. Dokumente in dokumentenbasierten DBMS sind traditionell in Sammlungen gruppiert. Die Sammlungen von Dokumenten, die Kanten darstellen, werden in ArangoDB als Kanten-Sammlungen bezeichnet. Übrigens sind die Dokumente der Kanten-Sammlungen ebenfalls Dokumente, sodass Kanten in ArangoDB auch als Knoten fungieren können.

Stammdaten

Angenommen, wir haben eine Sammlung persons, deren Dokumente folgendermaßen aussehen:

[
  {
    "_id"  : "people\/alice" ,
    "_key" : "alice" ,
    "name" : "Alice"
  },
  {
    "_id"  : "people\/bob" ,
    "_key" : "bob" ,
    "name" : "Bob"  
  }
]

Angenommen, es gibt auch eine Sammlung cafes:

[
  {
    "_id" : "cafes\/jd" ,
    "_key" : "jd" ,
    "name" : "John Donne"  
  },
  {
    "_id" : "cafes\/jj" ,
    "_key" : "jj" ,
    "name" : "Jean-Jacques"
  }
]

Dann könnte die Sammlung likes folgendermaßen aussehen:

[
  {
    "_id" : "likes\/1" ,
    "_key" : "1" ,
    "_from" : "persons\/alice" ,
    "_to" : "cafes\/jd",
    "since" : 2010 
  },
  {
    "_id" : "likes\/2" ,
    "_key" : "2" ,
    "_from" : "persons\/alice" ,
    "_to" : "cafes\/jj",
    "since" : 2011 
  } ,
  {
    "_id" : "likes\/3" ,
    "_key" : "3" ,
    "_from" : "persons\/bob" ,
    "_to" : "cafes\/jd",
    "since" : 2012 
  }
]

Abfragen und Ergebnisse

Eine Abfrage im grafischen Stil in der in ArangoDB verwendeten Sprache AQL, die in menschenlesbarer Form Informationen darüber zurückgibt, wem welches Café gefällt, sieht so aus:

FOR p IN persons
  FOR c IN OUTBOUND p likes
  RETURN { person : p.name , likes : c.name }

Im relationalen Stil, wenn wir eher die Beziehungen „berechnen“, anstatt sie zu speichern, könnte diese Abfrage so umgeschrieben werden (übrigens könnte auf die Sammlung likes verzichtet werden):

FOR p IN persons
  FOR l IN likes
  FILTER p._key == l._from
    FOR c IN cafes
    FILTER l._to == c._key
    RETURN { person : p.name , likes : c.name }

Das Ergebnis wird in beiden Fällen dasselbe sein:

[
  { "person" : "Alice" , likes : "Jean-Jacques" } ,
  { "person" : "Alice" , likes : "John Donne" } ,
  { "person" : "Bob" , likes : "John Donne" }
]

Weitere Abfragen und Ergebnisse

Wenn es so aussieht, als wäre das oben dargestellte Ergebnisformat mehr für relationale Datenbanken typisch als für dokumentenbasierte, könnte man diese Abfrage versuchen (oder COLLECT):

FÜR p IN personen
  RÜCKGABE {
    person : p.name,
    likes : (
      FÜR c IN OUTBOUND p likes
      RÜCKGABE c.name
    )
}

Das Ergebnis hat folgendes Format:

[
  { "person" : "Alice" , likes : ["Jean-Jacques" , "John Donne"]  } ,
  { "person" : "Bob" , likes : ["John Donne"] }
]

OrientDB

Die Implementierung des grafischen Modells über dem dokumentenbasierten in OrientDB basiert auf die Möglichkeit Dokumentenfeldern, die neben mehr oder weniger standardmäßigen skalaren Werten auch Werte der Typen wie LINK, LINKLIST, LINKSET, LINKMAP und LINKBAG. Die Werte dieser Typen sind Links oder Sammlungen von Links zu systematischen Identifikatoren Dokumenten.

Die vom System zugewiesene Dokumentenidentifikationsnummer hat eine „physische Bedeutung“, die die Position des Eintrags in der Datenbank angibt, und sieht ungefähr so aus: @rid : #3:16. Damit sind die Werte der Verweisattribute tatsächlich eher Zeiger (wie im grafischen Modell) und nicht Auswahlkriterien (wie in der relationalen Datenbank).

Wie auch in ArangoDB werden die Kanten in OrientDB als separate Dokumente dargestellt (obwohl, wenn eine Kante keine eigenen Attribute hat, sie auch leichtgewichtig sein, und es wird kein separates Dokument dafür geben).

Stammdaten

In einem Format, das dem Datenbank-Dump-Format von OrientDB ähnelt, würden die Daten aus dem vorherigen Beispiel für ArangoDB etwa so aussehen:

[
     {
      "@type": "document",
      "@rid": "#11:0",
      "@class": "Person",
      "name": "Alice",
      "out_likes": [
        "#30:1",
        "#30:2"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#12:0",
      "@class": "Person",
      "name": "Bob",
      "out_likes": [
        "#30:3"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#21:0",
      "@class": "Cafe",
      "name": "Jean-Jacques",
      "in_likes": [
        "#30:2",
        "#30:3"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#22:0",
      "@class": "Cafe",
      "name": "John Donne",
      "in_likes": [
        "#30:1"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#30:1",
      "@class": "likes",
      "in": "#22:0",
      "out": "#11:0",
      "since": 1262286000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:2",
      "@class": "likes",
      "in": "#21:0",
      "out": "#11:0",
      "since": 1293822000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:3",
      "@class": "likes",
      "in": "#21:0",
      "out": "#12:0",
      "since": 1325354400000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    }
  ]

Wie wir sehen, speichern die Knoten auch Informationen über eingehende und ausgehende Kanten. Bei die Verwendung Bei der Dokumenten-API für die Konsistenz von Verknüpfungen muss man selbst darauf achten, während die Graph-API diese Aufgabe übernimmt. Lassen Sie uns jedoch ansehen, wie der Zugriff auf OrientDB in "reinen", nicht in Programmiersprachen integrierten Abfragesprachen aussieht.

Abfragen und Ergebnisse

Eine Anfrage, die dem Zweck der Anfrage im Beispiel für ArangoDB entspricht, sieht in OrientDB so aus:

SELECT name AS person_name, OUT('likes').name AS cafe_name
   FROM Person
   UNWIND cafe_name

Das Ergebnis wird wie folgt aussehen:

[
  { "person_name": "Alice", "cafe_name": "John Donne" },
  { "person_name": "Alice", "cafe_name": "Jean-Jacques" },
  { "person_name": "Bob",  "cafe_name": "Jean-Jacques" }
]

Wenn das Format des Ergebnisses wieder zu "relational" erscheint, sollte die Zeile mit UNWIND():

[
  { "person_name": "Alice", "cafe_name": [ "John Donne", "Jean-Jacques" ] },
  { "person_name": "Bob",  "cafe_name": [ "Jean-Jacques" ] }
]

Die Abfragesprache von OrientDB kann als SQL mit Gremlin-ähnlichen Einfügungen charakterisiert werden. In der Version 2.2 wurde eine Cypher-ähnliche Abfrageform eingeführt, MATCH :

MATCH {CLASS: Person, AS: person}-likes->{CLASS: Cafe, AS: cafe}
RETURN person.name AS person_name, LIST(cafe.name) AS cafe_name
GROUP BY person_name

Das Format des Ergebnisses wird das gleiche sein wie in der vorherigen Anfrage. Überlegen Sie, was entfernt werden muss, um es relationaler zu gestalten, wie in der allerersten Anfrage.

Azure CosmosDB

Weniger stark trifft das oben Gesagte zu ArangoDB und OrientDB auf Azure CosmosDB zu. CosmosDB bietet folgende APIs für den Datenzugriff: SQL, MongoDB, Gremlin und Cassandra.

Die SQL-API und die MongoDB-API werden für den Zugang zu Daten im Dokumentenmodell verwendet. Die Gremlin-API und die Cassandra-API sind entsprechend für den Zugang zu Daten im Graph- und Spaltenformat vorgesehen. Die Daten in allen Modellen werden im Format des internen Modells von CosmosDB gespeichert: ARS („atom-record-sequence“), das ebenfalls dem Dokumentenmodell nahe ist.

Doch die vom Benutzer gewählte Datenmodell und die verwendete API werden zum Zeitpunkt der Erstellung des Kontos im Dienst festgelegt. Es ist unmöglich, auf Daten, die in einem Modell hochgeladen wurden, im Format eines anderen Modells zuzugreifen, was etwa durch das folgende Bild veranschaulicht werden könnte:

Somit stellt die Multimodalität in Azure CosmosDB derzeit nur die Möglichkeit dar, mehrere Datenbanken zu nutzen, die verschiedene Modelle von einem Anbieter unterstützen, was nicht alle Herausforderungen der variantenreichen Speicherung löst.

Multimodale DBMS auf Basis des Graphmodells?

Es ist bemerkenswert, dass es auf dem Markt derzeit keine multimodalen DBMS gibt, die auf dem Graphmodell basieren (es sei denn, man zählt die gleichzeitige Unterstützung zweier Graphmodelle: RDF und LPG zur Multimodalität; siehe dazu vorherige Veröffentlichung). Die größte Herausforderung besteht darin, ein Dokumentenmodell auf einer Graphdatenbank umzusetzen und nicht auf einem relationalen.

Die Frage, wie ein relatives Modell auf einer Graphdatenbank umgesetzt werden kann, wurde bereits zu Zeiten diskutiert, als das relationale Modell entstand. Wie allerdings sieht man oft Situationen, in denen ein bereitgestelltes Framework im Code der Website verwendet wird, dessen Nutzung Einschränkungen für die weitere Nutzung mit sich bringt. Und während dies in einer 'normalen Umgebung' leicht zu bewältigen ist, kann ein solches Verhalten in Kubernetes problematisch werden, insbesondere wenn man damit zum ersten Mal konfrontiert wird. Obwohl ein kreativer Geist in der Lage ist, infrastrukturelle Lösungen anzubieten, die auf den ersten Blick offensichtlich und sogar gut erscheinen… ist es wichtig zu bedenken, dass die meisten Situationen architektonisch angegangen werden können und sollten., zum Beispiel, David McGovern:

Es gibt nichts, was dem graphbasierten Ansatz inhärent ist und die Erstellung einer Schicht (z. B. durch geeignete Indizierung) auf einer Graphdatenbank verhindert, die eine relationale Sicht ermöglicht mit (1) der Wiederherstellung von Tupeln aus den üblichen Schlüssel-Wert-Paaren und (2) der Gruppierung von Tupeln nach Beziehungstyp.

Bei der Umsetzung eines Dokumentenmodells auf einer Graphdatenbank muss man unter anderem Folgendes berücksichtigen:

JSON-Arrays sind geordnet, die von einer Kante des Graphen ausgehen – nicht;
Daten im Dokumentenmodell sind normalerweise denormalisiert, es ist nicht wünschenswert, mehrere Kopien desselben verschachtelten Dokuments zu speichern, und Unterdokumente haben normalerweise keine Identifikatoren;
Andererseits ist das Ideologie von dokumentenorientierten DBMS, dass Dokumente vollständige „Aggregate“ sind, die nicht jedes Mal neu aufgebaut werden müssen. Es muss sichergestellt werden, dass in der Graphdatenbank die Möglichkeit besteht, schnell einen Teilgraphen entsprechend einem fertigen Dokument abzurufen.

Ein wenig Werbung

Der Autor des Artikels ist an der Entwicklung der Datenbank NitrosBase beteiligt, deren internes Modell graphbasiert ist, während die externen Modelle relational und dokumentenorientiert dargestellt werden. Alle Modelle sind gleichberechtigt: praktisch alle Daten sind in jedem von ihnen mit der für sie typischen Abfragesprache zugänglich. Darüber hinaus können die Daten in jeder Darstellung geändert werden. Die Änderungen spiegeln sich im internen Modell wider und somit in anderen Darstellungen.

Wie die Modelle in NitrosBase übereinstimmen — ich hoffe, dass ich dies in einem der nächsten Artikel beschreiben kann.

Fazit

Ich hoffe, dass die allgemeinen Umrisse dessen, was als Multimodalität bezeichnet wird, dem Leser mehr oder weniger klar geworden sind. Als multimodal werden ganz unterschiedliche DBMS bezeichnet, und „Unterstützung mehrerer Modelle“ kann unterschiedlich aussehen. Um zu verstehen, was in jedem konkreten Fall als „Multimodalität“ bezeichnet wird, ist es nützlich, die folgenden Fragen zu beantworten:

Geht es um die Unterstützung traditioneller Modelle oder um eine bestimmte „hybride“ Modell?
Sind die Modelle „gleichberechtigt“ oder ist eines von ihnen untergeordneten für andere?
Sind Modelle einander gegenüber gleichgültig? Können Daten, die in einem Modell gespeichert sind, in einem anderen gelesen oder sogar überschrieben werden?

Ich denke, die Frage nach der Relevanz multimodaler DBMS kann bereits positiv beantwortet werden, aber interessant ist die Frage, welche spezifischen Arten in naher Zukunft gefragter sein werden. Es scheint, dass multimodale DBMS, die traditionelle Modelle unterstützen, insbesondere relationale, stärker nachgefragt werden; die Popularität multimodaler DBMS, die neue Modelle anbieten, die die Vorzüge verschiedener traditioneller Kombinationen vereinen, ist jedoch eher eine Angelegenheit der ferneren Zukunft.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte einloggen.

Verwenden Sie multimodale DBMS?

Wir verwenden keine, alle Daten werden in einem DBMS und einem Modell gespeichert.
Wir nutzen die multimodalen Möglichkeiten traditioneller DBMS.
Wir praktizieren polyglotte Persistenz.
Wir verwenden neue multimodale DBMS (Arango, Orient, CosmosDB).

19 Benutzer haben abgestimmt. 4 Benutzer haben sich enthalten.

Quelle: habr.com