Moderne Informationssysteme sind recht komplex. Ihre Komplexität ist nicht zuletzt auf die Komplexität der darin verarbeiteten Daten zurückzuführen. Die Komplexität von Daten liegt häufig in der Vielfalt der verwendeten Datenmodelle. Wenn Daten beispielsweise „groß“ werden, ist eine der problematischen Eigenschaften nicht nur ihr Umfang („Volume“), sondern auch ihre Vielfalt („Variety“).
Wenn Sie noch keinen Fehler in der Begründung finden, dann lesen Sie weiter.
Inhalt
Polyglotte Persistenz
Das oben Gesagte führt dazu, dass es manchmal sogar im Rahmen eines Systems notwendig ist, mehrere verschiedene DBMS zum Speichern von Daten und zum Lösen verschiedener Probleme bei deren Verarbeitung zu verwenden, von denen jedes sein eigenes Datenmodell unterstützt. Mit der leichten Hand von M. Fowler, eine Reihe berühmter Bücher und eines davon Agiles Manifest nennt man diese Situation Variantenreiche Lagerung („polyglotte Persistenz“).
Fowler hat auch das folgende Beispiel für die Organisation der Datenspeicherung in einer voll ausgestatteten und hochlastigen Anwendung im Bereich E-Commerce.
Dieses Beispiel ist natürlich etwas übertrieben, aber es gibt einige Überlegungen, die für die Wahl des einen oder anderen DBMS für den entsprechenden Zweck sprechen, zum Beispiel: .
Es ist klar, dass es nicht einfach ist, in einem solchen Zoo als Diener zu arbeiten.
- Die Menge an Code, der die Datenspeicherung durchführt, wächst proportional zur Anzahl der verwendeten DBMS. Die Menge der Code-Synchronisierungsdaten ist gut, wenn sie nicht proportional zum Quadrat dieser Zahl ist.
- Mit einem Vielfachen der Anzahl der verwendeten DBMS steigen die Kosten für die Bereitstellung von Unternehmensmerkmalen (Skalierbarkeit, Fehlertoleranz, hohe Verfügbarkeit) jedes der verwendeten DBMS.
- Es ist unmöglich, die Unternehmenseigenschaften des Speichersubsystems als Ganzes – insbesondere die Transaktionalität – sicherzustellen.
Aus Sicht des Zoodirektors sieht alles so aus:
- Eine mehrfache Erhöhung der Kosten für Lizenzen und technischen Support durch den DBMS-Hersteller.
- Überbesetzung und längere Fristen.
- Direkte finanzielle Verluste oder Strafen aufgrund von Dateninkonsistenzen.
Die Gesamtbetriebskosten (TCO) des Systems steigen erheblich. Gibt es einen Ausweg aus der Situation der „mehreren Speichermöglichkeiten“?
Multi-Modell
Der Begriff „multivariate Speicherung“ wurde 2011 eingeführt. Das Bewusstsein für die Probleme des Ansatzes und die Suche nach einer Lösung dauerten mehrere Jahre, und bis 2015 wurde durch den Mund von Gartner-Analysten die Antwort formuliert:
- Von "»:
Die Zukunft von DBMS, ihren Architekturen und Verwendungsmöglichkeiten ist multimodellorientiert.
- Von "»:
Führende operative DBMS bieten mehrere Modelle – relationale und nicht relationale – als Teil einer einzigen Plattform.
Es scheint, dass die Analysten von Gartner diesmal mit ihrer Prognose Recht hatten. Wenn Sie auf die Seite mit gehen DBMS auf DB-Engines, das sieht manоDie meisten ihrer Marktführer positionieren sich ausdrücklich als Multimodell-DBMS. Das Gleiche ist auf der Seite bei jeder privaten Bewertung zu sehen.
Die folgende Tabelle zeigt die DBMS – die Spitzenreiter in jedem der privaten Ratings, die behaupten, mehrere Modelle zu haben. Für jedes DBMS wird das ursprünglich unterstützte Modell (das früher das einzige war) und zusammen mit diesem die aktuell unterstützten Modelle angezeigt. Ebenfalls aufgeführt sind DBMS, die sich als „ursprünglich Multimodell“ positionieren und nach Angaben der Ersteller über kein anfängliches geerbtes Modell verfügen.
| DBMS | Erstes Modell | Weitere Modelle |
|---|---|---|
| Oracle | relational | Diagramm, Dokument |
| MS SQL | relational | Diagramm, Dokument |
| PostgreSQL | relational | Diagramm*, Dokument |
| MarkLogic | Dokumentarfilm | Diagramm, relational |
| MongoDB | Dokumentarfilm | Schlüsselwert, Diagramm* |
| DataStax | Breitspaltig | Dokumentarfilm, Grafik |
| Redis | Schlüsselwert | Dokumentarfilm, Grafik* |
| ArangoDB | - | Diagramm, Dokument |
| Orientierungsdatenbank | - | Diagramm, Dokument, relational |
| Azure CosmosDB | - | Diagramm, Dokument, relational |
Anmerkungen zur Tabelle
Sternchen in der Tabelle kennzeichnen Anweisungen, die Reservierungen erfordern:
- Das PostgreSQL-DBMS unterstützt das Diagrammdatenmodell nicht, dieses Produkt unterstützt es jedoch , wie zum Beispiel AgensGraph.
- In Bezug auf MongoDB ist es richtiger, über das Vorhandensein von Graphoperatoren in der Abfragesprache zu sprechen (, ) als um die Unterstützung des Graphenmodells, obwohl ihre Einführung natürlich einige Optimierungen auf der physischen Speicherebene in Richtung der Unterstützung des Graphenmodells erforderte.
- In Bezug auf Redis meinen wir die Erweiterung .
Als nächstes zeigen wir für jede der Klassen, wie die Unterstützung mehrerer Modelle im DBMS dieser Klasse implementiert wird. Wir werden die relationalen, Dokument- und Diagrammmodelle als die wichtigsten betrachten und anhand von Beispielen spezifischer DBMS zeigen, wie die „fehlenden“ implementiert werden.
Multimodell-DBMS basierend auf dem relationalen Modell
Die führenden DBMS sind derzeit relational; Gartners Prognose könnte nicht als wahr angesehen werden, wenn RDBMS keine Bewegung in Richtung Multimodellierung zeigen würden. Und sie demonstrieren. Nun kann die Idee, dass ein Multimodell-DBMS wie ein Schweizer Messer ist, das nichts Gutes kann, direkt auf Larry Ellison zurückgeführt werden.
Der Autor bevorzugt jedoch die Implementierung der Multimodellierung in Microsoft SQL Server, an dessen Beispiel die RDBMS-Unterstützung für Dokument- und Diagrammmodelle beschrieben wird.
Dokumentmodell in MS SQL Server
Auf Habré gab es bereits zwei hervorragende Artikel darüber, wie MS SQL Server die Unterstützung für das Dokumentmodell implementiert; ich beschränke mich auf eine kurze Nacherzählung und einen Kommentar:
Die Art und Weise, das Dokumentmodell in MS SQL Server zu unterstützen, ist recht typisch für relationale DBMS: Es wird vorgeschlagen, JSON-Dokumente in gewöhnlichen Textfeldern zu speichern. Die Unterstützung des Dokumentmodells besteht darin, spezielle Operatoren zum Parsen dieses JSON bereitzustellen:
- um skalare Attributwerte zu extrahieren,
- Unterdokumente extrahieren.
Das zweite Argument beider Operatoren ist ein Ausdruck in JSONPath-ähnlicher Syntax.
Abstrakt können wir sagen, dass auf diese Weise gespeicherte Dokumente im Gegensatz zu Tupeln keine „erstklassigen Entitäten“ in einem relationalen DBMS sind. Insbesondere gibt es in MS SQL Server derzeit keine Indizes für die Felder von JSON-Dokumenten, was es schwierig macht, Tabellen mit den Werten dieser Felder zu verknüpfen und sogar Dokumente mit diesen Werten auszuwählen. Es ist jedoch möglich, für ein solches Feld eine berechnete Spalte und einen Index dafür zu erstellen.
Darüber hinaus bietet MS SQL Server die Möglichkeit, mithilfe des Operators bequem ein JSON-Dokument aus den Inhalten von Tabellen zu erstellen - eine Möglichkeit, in gewissem Sinne im Gegensatz zur vorherigen, konventionellen Speicherung. Es ist klar, dass dieser Ansatz, egal wie schnell ein RDBMS ist, der Ideologie von Dokument-DBMS widerspricht, die im Wesentlichen vorgefertigte Antworten auf häufig gestellte Fragen speichern und nur Probleme der einfachen Entwicklung, nicht aber der Geschwindigkeit lösen können.
Schließlich können Sie mit MS SQL Server das umgekehrte Problem der Dokumentkonstruktion lösen: Sie können JSON mit in Tabellen zerlegen . Wenn das Dokument nicht ganz flach ist, müssen Sie es verwenden CROSS APPLY.
Diagrammmodell in MS SQL Server
Die Unterstützung für das Graph-Modell (LPG) ist auch in Microsoft SQL Server vollständig implementiert : Es wird vorgeschlagen, spezielle Tabellen zum Speichern von Knoten und Diagrammkanten zu verwenden. Solche Tabellen werden mithilfe von Ausdrücken erstellt CREATE TABLE AS NODE и CREATE TABLE AS EDGE jeweils.
Tabellen des ersten Typs ähneln gewöhnlichen Tabellen zum Speichern von Datensätzen, mit dem einzigen äußerlichen Unterschied, dass die Tabelle ein Systemfeld enthält $node_id – eindeutige Kennung eines Diagrammknotens innerhalb der Datenbank.
Ebenso verfügen Tabellen des zweiten Typs über Systemfelder $from_id и $to_id, Einträge in solchen Tabellen definieren klar die Verbindungen zwischen Knoten. Zum Speichern der Beziehungen jedes Typs wird eine separate Tabelle verwendet.
Lassen Sie uns dies anhand eines Beispiels veranschaulichen. Lassen Sie die Diagrammdaten ein Layout wie das in der Abbildung gezeigte haben. Um dann die entsprechende Struktur in der Datenbank zu erstellen, müssen Sie die folgenden DDL-Abfragen ausführen:
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 Hauptspezifität solcher Tabellen besteht darin, dass es bei Abfragen gegen sie möglich ist, Diagrammmuster mit Cypher-ähnlicher Syntax zu verwenden (allerdings „*"usw. werden noch nicht unterstützt). Basierend auf Leistungsmessungen kann außerdem davon ausgegangen werden, dass die Art und Weise, wie Daten in diesen Tabellen gespeichert werden, sich von der Art und Weise, wie Daten in regulären Tabellen gespeichert werden, unterscheidet und für die Ausführung solcher Diagrammabfragen optimiert ist.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Darüber hinaus ist es ziemlich schwierig, diese Diagrammmuster bei der Arbeit mit solchen Tabellen nicht zu verwenden, da bei gewöhnlichen SQL-Abfragen zur Lösung ähnlicher Probleme zusätzliche Anstrengungen unternommen werden müssen, um System-„Diagramm“-Knotenkennungen zu erhalten ($node_id, $from_id, $to_id; Aus dem gleichen Grund werden Abfragen zum Einfügen von Daten hier nicht dargestellt, da sie unnötig umständlich sind.
Um die Beschreibung der Implementierungen der Dokument- und Diagrammmodelle in MS SQL Server zusammenzufassen, möchte ich anmerken, dass solche Implementierungen eines Modells über einem anderen nicht erfolgreich zu sein scheinen, vor allem aus der Sicht des Sprachdesigns. Es ist notwendig, eine Sprache mit einer anderen zu erweitern, die Sprachen sind nicht vollständig „orthogonal“, die Kompatibilitätsregeln können ziemlich skurril sein.
Multimodell-DBMS basierend auf dem Dokumentmodell
In diesem Abschnitt möchte ich die Implementierung von Multimodellen in Dokument-DBMS am Beispiel des nicht populärsten davon, MongoDB, veranschaulichen (wie gesagt, es verfügt nur über bedingte Graphoperatoren). $lookup и $graphLookup, arbeitet nicht an Sharded-Sammlungen), sondern am Beispiel eines ausgereifteren und „Enterprise“-DBMS .
Lassen Sie die Sammlung also einen Satz XML-Dokumente des folgenden Typs enthalten (MarkLogic ermöglicht Ihnen auch das Speichern von JSON-Dokumenten):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Relationales Modell in MarkLogic
Eine relationale Ansicht einer Sammlung von Dokumenten kann mit erstellt werden (Inhalte von Elementen value im Beispiel unten kann es einen beliebigen XPath geben):
<template >
<context>/Person</context>
<rows>
<row>
<view-name>Person</view-name>
<columns>
<column>
<name>SSN</name>
<value>@SSN</value>
<type>string</type>
</column>
<column>
<name>name</name>
<value>name</value>
</column>
<column>
<name>surname</name>
<value>surname</value>
</column>
</columns>
</row>
<rows>
</template>Sie können die erstellte Ansicht mit einer SQL-Abfrage ansprechen (z. B. über ODBC):
SELECT name, surname FROM Person WHERE name="John"Leider ist die von der Anzeigevorlage erstellte relationale Ansicht schreibgeschützt. Bei der Bearbeitung einer Anfrage wird MarkLogic versuchen, diese zu verwenden . Zuvor verfügte MarkLogic über völlig eingeschränkte relationale Ansichten und beschreibbar, aber jetzt gelten sie als veraltet.
Diagrammmodell in MarkLogic
Mit der Unterstützung des Graphenmodells (RDF) ist alles ungefähr gleich. Wieder mit der Hilfe Sie können aus dem obigen Beispiel eine RDF-Darstellung einer Sammlung von Dokumenten erstellen:
<template >
<context>/Person</context>
<vars>
<var>
<name>PREFIX</name>
<val>"http://example.org/example#"</val>
</var>
</vars>
<triples>
<triple>
<subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
<predicate><value>sem:iri( $PREFIX || surname )</value></predicate>
<object><value>xs:string( surname )</value></object>
</triple>
<triple>
<subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
<predicate><value>sem:iri( $PREFIX || name )</value></predicate>
<object><value>xs:string( name )</value></object>
</triple>
</triples>
</template>Sie können das resultierende RDF-Diagramm mit einer SPARQL-Abfrage ansprechen:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Im Gegensatz zum relationalen Modell unterstützt MarkLogic das Diagrammmodell auf zwei weitere Arten:
- Ein DBMS kann ein vollwertiger separater Speicher für RDF-Daten sein (Dreiergruppen werden darin genannt). im Gegensatz zu den oben beschriebenen ).
- RDF in spezieller Serialisierung kann einfach in XML- oder JSON-Dokumente eingefügt werden (und dann werden Tripletts aufgerufen). ). Dies ist wahrscheinlich eine Alternative zu Mechanismen
idrefusw.
Eine gute Vorstellung davon, wie die Dinge in MarkLogic „wirklich“ funktionieren, finden Sie hier In diesem Sinne ist es auf niedriger Ebene, obwohl sein Zweck eher das Gegenteil ist – zu versuchen, vom verwendeten Datenmodell zu abstrahieren, um eine konsistente Arbeit mit Daten in verschiedenen Modellen, Transaktionalität usw. sicherzustellen.
Multimodell-DBMS „ohne Hauptmodell“
Es gibt auch DBMS auf dem Markt, die sich zunächst als Multimodell positionieren, also ohne geerbtes Hauptmodell. Diese beinhalten , (seit 2018 gehört die Entwicklungsgesellschaft zu SAP) und (Dienst als Teil der Microsoft Azure Cloud-Plattform).
Tatsächlich gibt es „Kern“-Modelle in ArangoDB und OrientDB. In beiden Fällen handelt es sich um eigene Datenmodelle, die Verallgemeinerungen des Dokumentmodells darstellen. Die Verallgemeinerungen dienen hauptsächlich dazu, die Fähigkeit zu erleichtern, Abfragen grafischer und relationaler Natur durchzuführen.
Diese Modelle sind die einzigen, die im angegebenen DBMS verwendet werden können; ihre eigenen Abfragesprachen sind für die Zusammenarbeit mit ihnen konzipiert. Natürlich sind solche Modelle und DBMS vielversprechend, aber die mangelnde Kompatibilität mit Standardmodellen und -sprachen macht es unmöglich, diese DBMS in Legacy-Systemen zu verwenden – um die dort bereits verwendeten DBMS zu ersetzen.
Es gab bereits einen wunderbaren Artikel über ArangoDB und OrientDB auf Habré: .
ArangoDB
ArangoDB beansprucht Unterstützung für ein Diagrammdatenmodell.
Die Knoten eines Diagramms in ArangoDB sind gewöhnliche Dokumente und die Kanten sind Dokumente eines speziellen Typs, die zusammen mit regulären Systemfeldern (_key, _id, _rev) Systemfelder _from и _to. Dokumente in Dokument-DBMS werden traditionell in Sammlungen zusammengefasst. Sammlungen von Dokumenten, die Kanten darstellen, werden in ArangoDB als Kantensammlungen bezeichnet. Edge-Collection-Dokumente sind übrigens auch Dokumente, sodass Kanten in ArangoDB auch als Knoten fungieren können.
Ausgangsdaten
Lasst uns eine Sammlung machen persons, dessen Dokumente so aussehen:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Lass es auch eine Sammlung geben cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Dann die Sammlung likes könnte so 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 Diagrammstil in der in ArangoDB verwendeten AQL-Sprache, die in für Menschen lesbarer Form Informationen darüber zurückgibt, wer welches Café mag, sieht folgendermaßen aus:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }In einem relationalen Stil, bei dem wir Beziehungen „berechnen“, anstatt sie zu speichern, kann diese Abfrage folgendermaßen umgeschrieben werden (übrigens ohne die Sammlung). likes könnte darauf verzichten):
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 das gleiche sein:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Weitere Abfragen und Ergebnisse
Wenn das obige Ergebnisformat für ein relationales DBMS typischer zu sein scheint als für ein Dokument-DBMS, können Sie diese Abfrage ausprobieren (oder verwenden). ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Das Ergebnis wird so aussehen:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]Orientierungsdatenbank
Die Grundlage für die Implementierung eines Diagrammmodells auf einem Dokumentmodell in OrientDB ist Dokumentfelder enthalten neben mehr oder weniger standardmäßigen Skalarwerten auch Werte von Typen wie LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Die Werte dieser Typen sind Links oder Sammlungen von Links zu Dokumenten.
Die vom System zugewiesene Dokumentkennung hat eine „physische Bedeutung“, die die Position des Datensatzes in der Datenbank angibt, und sieht etwa so aus: @rid : #3:16. Somit sind die Werte von Referenzeigenschaften eigentlich Zeiger (wie im Diagrammmodell) und keine Auswahlbedingungen (wie im relationalen Modell).
Wie in ArangoDB werden Kanten in OrientDB als separate Dokumente dargestellt (obwohl eine Kante erstellt werden kann, wenn sie keine eigenen Eigenschaften hat). , und es wird keinem separaten Dokument entsprechen).
Ausgangsdaten
In einem Format in der Nähe von OrientDB-Datenbank würden die Daten aus dem vorherigen Beispiel für ArangoDB etwa so aussehen:
[
{
"@type": "document",
"@rid": "#11:0",
"@class": "Person",
"name": "Алиса",
"out_likes": [
"#30:1",
"#30:2"
],
"@fieldTypes": "out_likes=LINKBAG"
},
{
"@type": "document",
"@rid": "#12:0",
"@class": "Person",
"name": "Боб",
"out_likes": [
"#30:3"
],
"@fieldTypes": "out_likes=LINKBAG"
},
{
"@type": "document",
"@rid": "#21:0",
"@class": "Cafe",
"name": "Жан-Жак",
"in_likes": [
"#30:2",
"#30:3"
],
"@fieldTypes": "in_likes=LINKBAG"
},
{
"@type": "document",
"@rid": "#22:0",
"@class": "Cafe",
"name": "Джон Донн",
"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 können, speichern Scheitelpunkte auch Informationen über ein- und ausgehende Kanten. Bei Die Document API muss die referenzielle Integrität selbst überwachen und die Graph API übernimmt diese Arbeit. Aber schauen wir mal, wie der Zugriff auf OrientDB in „reinen“ Abfragesprachen aussieht, die nicht in Programmiersprachen integriert sind.
Abfragen und Ergebnisse
Eine Abfrage mit ähnlichem Zweck wie die Abfrage aus dem Beispiel für ArangoDB in OrientDB sieht folgendermaßen aus:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameDas Ergebnis erhält man in folgender Form:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Wenn das Ergebnisformat erneut zu „relational“ erscheint, müssen Sie die Zeile mit entfernen :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]Die Abfragesprache von OrientDB kann als SQL mit Gremlin-ähnlichen Einfügungen beschrieben werden. In Version 2.2 erschien ein Cypher-ähnliches Anfrageformular, :
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_nameDas Ergebnisformat ist dasselbe wie in der vorherigen Anfrage. Überlegen Sie, was entfernt werden muss, um es „relationaler“ zu machen, wie in der allerersten Abfrage.
Azure CosmosDB
In geringerem Maße gilt das, was oben über ArangoDB und OrientDB gesagt wurde, auch für Azure CosmosDB. CosmosDB bietet die folgenden Datenzugriffs-APIs: SQL, MongoDB, Gremlin und Cassandra.
Für den Zugriff auf Daten im Dokumentmodell werden die SQL-API und die MongoDB-API verwendet. Gremlin-API und Cassandra-API – für den Zugriff auf Daten im Diagramm- bzw. Spaltenformat. Daten in allen Modellen werden im internen Modellformat von CosmosDB gespeichert: („Atom-Record-Sequence“), die ebenfalls der Dokument-Sequenz nahe kommt.
Das vom Benutzer gewählte Datenmodell und die verwendete API werden jedoch zum Zeitpunkt der Erstellung eines Kontos im Dienst festgelegt. Es ist nicht möglich, auf Daten zuzugreifen, die in einem Modell im Format eines anderen Modells geladen wurden, wie etwa Folgendes zeigt:
Daher bedeutet Multimodell in Azure CosmosDB heute nur die Möglichkeit, mehrere Datenbanken zu verwenden, die unterschiedliche Modelle eines Herstellers unterstützen, was nicht alle Probleme der multivarianten Speicherung löst.
Multimodell-DBMS basierend auf einem Diagrammmodell?
Bemerkenswert ist die Tatsache, dass es noch keine Multimodell-DBMS auf dem Markt gibt, die auf einem Graphenmodell basieren (mit Ausnahme der Multimodell-Unterstützung für gleichzeitig zwei Graphenmodelle: RDF und LPG; siehe dies in ). Die größten Schwierigkeiten entstehen durch die Implementierung eines Dokumentmodells auf einem Diagrammmodell und nicht auf einem relationalen Modell.
Die Frage, wie ein relationales Modell auf dem Graphenmodell implementiert werden kann, wurde bereits bei der Bildung des Graphenmodells berücksichtigt. Wie Beispielsweise :
Dem Graph-Ansatz ist nichts inhärent, was die Erstellung einer Ebene (z. B. durch geeignete Indizierung) auf einer Graph-Datenbank verhindert, die eine relationale Ansicht mit (1) Wiederherstellung von Tupeln aus den üblichen Schlüssel-Wert-Paaren und (2) Gruppierung von Tupeln ermöglicht Tupel nach Beziehungstyp.
Wenn Sie ein Dokumentmodell auf einem Diagrammmodell implementieren, müssen Sie beispielsweise Folgendes beachten:
- Elemente eines JSON-Arrays gelten als geordnet, diejenigen, die vom Scheitelpunkt einer Kante des Diagramms ausgehen, jedoch nicht.
- Daten im Dokumentmodell sind normalerweise denormalisiert; Sie möchten trotzdem nicht mehrere Kopien desselben eingebetteten Dokuments speichern und Unterdokumente haben normalerweise keine Kennungen;
- Andererseits besteht die Ideologie von Dokumenten-DBMS darin, dass Dokumente vorgefertigte „Aggregate“ sind, die nicht jedes Mal neu erstellt werden müssen. Es ist erforderlich, dem Diagrammmodell die Möglichkeit zu geben, schnell einen Untergraphen zu erhalten, der dem fertigen Dokument entspricht.
Ein bisschen Werbung
Der Autor des Artikels bezieht sich auf die Entwicklung des NitrosBase-DBMS, dessen internes Modell ein Diagramm ist und dessen externe Modelle – relational und dokumentarisch – seine Darstellungen sind. Alle Modelle sind gleich: Fast alle Daten sind in jedem von ihnen verfügbar und verwenden eine für sie natürliche Abfragesprache. Darüber hinaus können die Daten in jeder Ansicht geändert werden. Änderungen werden im internen Modell und entsprechend in anderen Ansichten widergespiegelt.
Wie Model Matching in NitrosBase aussieht, werde ich hoffentlich in einem der folgenden Artikel beschreiben.
Abschluss
Ich hoffe, dass dem Leser die allgemeinen Umrisse dessen, was man Multimodellierung nennt, mehr oder weniger klar geworden sind. Multi-Modell-DBMS sind ganz anders und die „Multi-Modell-Unterstützung“ kann anders aussehen. Um zu verstehen, was im Einzelfall als „Multimodell“ bezeichnet wird, ist es sinnvoll, die folgenden Fragen zu beantworten:
- Sprechen wir über die Unterstützung traditioneller Modelle oder einer Art „hybridem“ Modell?
- Sind die Modelle „gleich“ oder ist eines von ihnen Gegenstand der anderen?
- Sind die Modelle einander „gleichgültig“? Können in einem Modell geschriebene Daten in einem anderen gelesen oder sogar überschrieben werden?
Ich denke, dass die Frage nach der Relevanz von Multimodell-DBMS bereits jetzt positiv beantwortet werden kann, aber die interessante Frage ist, welche Arten davon in naher Zukunft stärker nachgefragt werden. Es scheint, dass die Nachfrage nach Multimodell-DBMS, die traditionelle, vor allem relationale Modelle unterstützen, größer sein wird. Die Beliebtheit von Multimodell-DBMS, die neue Modelle anbieten, die die Vorteile verschiedener traditioneller Modelle kombinieren, ist eine Frage der ferneren Zukunft.
An der Umfrage können nur registrierte Benutzer teilnehmen. bitte.
Verwenden Sie ein DBMS mit mehreren Modellen?
-
Wir verwenden es nicht, wir speichern alles in einem DBMS und in einem Modell
-
Wir nutzen die Multimodellfähigkeiten traditioneller DBMS
-
Wir üben polyglotte Beharrlichkeit
-
Wir verwenden ein neues Multimodell-DBMS (Arango, Orient, CosmosDB).
19 Benutzer haben abgestimmt. 4 Benutzer enthielten sich der Stimme.
Source: habr.com