Modern Informatiounssystemer sinn zimlech komplex. Net zulescht vun allem ass hir Komplexitéit wéinst der Komplexitéit vun den Donnéeën déi an hinnen veraarbecht ginn. D'Komplexitéit vun den Daten läit dacks an der Villfalt vun Datenmodeller déi benotzt ginn. Also, zum Beispill, wann d'Donnéeën "grouss" ginn, ass ee vun de problematesch Charakteristiken net nëmme säi Volumen ("Volumen"), awer och hir Varietéit ("Varietéit").
Wann Dir nach kee Feeler am Begrënnung fannt, da liest weider.
Inhalt
Polyglot Persistenz
Dat hei uewen féiert zu der Tatsaach, datt heiansdo och am Kader vun engem System et néideg ass e puer verschidde DBMSs ze benotzen fir Daten ze späicheren a verschidde Probleemer vun der Veraarbechtung ze léisen, jidderee vun deenen hiren eegene Datemodell ënnerstëtzt. Mat der liichter Hand vum M. Fowler, eng Rei vu berühmte Bicher an ee vun Agile Manifest, gëtt dës Situatioun genannt Multi-Variant Stockage ("Polyglot Persistenz").
Fowler huet och dat folgend Beispill fir d'Organisatioun vun Datelagerung an enger vollstänneger an héijer Applikatioun am Beräich vum E-Commerce.
Dëst Beispill ass natierlech e bëssen iwwerdriwwen, awer e puer Iwwerleeungen zugonschte fir een oder aneren DBMS fir deen entspriechende Zweck ze fannen, zum Beispill, .
Et ass kloer, datt en Dénger an esou engem Zoo net einfach ass.
- D'Quantitéit vum Code, deen Datelagerung ausféiert, wiisst proportional zu der Unzuel vun den DBMSen déi benotzt ginn; d'Quantitéit u Code Synchroniséierungsdaten ass gutt wann net proportional zum Quadrat vun dëser Zuel.
- Als Multiple vun der Unzuel vun den DBMSen déi benotzt ginn, ginn d'Käschte fir d'Entreprisecharakteristiken (Skalierbarkeet, Feelertoleranz, héich Disponibilitéit) vun all de benotzten DBMSen erop.
- Et ass onméiglech fir d'Entreprise Charakteristiken vum Späichersubsystem als Ganzt ze garantéieren - besonnesch Transaktiounsfäegkeet.
Aus der Siicht vum Zoo-Direkter gesäit alles esou aus:
- Eng multiple Erhéijung vun de Käschte vun de Lizenzen an technescher Ënnerstëtzung vum DBMS Hiersteller.
- Iwwerbemannt a verstäerkte Frist.
- Direkt finanziell Verloschter oder Strofe wéinst Dateninkonsistenz.
Et gëtt eng bedeitend Erhéijung vun de Gesamtkäschte vum Besëtz (TCO) vum System. Gëtt et e Wee aus der Situatioun vu "Multiple Späicheroptiounen"?
Multi-Modell
De Begrëff "Multivariate Lagerung" koum am Joer 2011 a Gebrauch. D'Bewosstsinn iwwer d'Problemer vun der Approche an der Sich no enger Léisung huet e puer Joer gedauert, a bis 2015, duerch de Mond vun den Gartner Analysten, gouf d'Äntwert formuléiert:
- Vun ""
D'Zukunft vun DBMSen, hir Architekturen a Weeër fir se ze benotzen ass Multi-Modell.
- Vun ""
Leading operationell DBMSs bidden verschidde Modeller-relational an net-relational-als Deel vun enger eenzeger Plattform.
Et schéngt, datt dës Kéier Gartner Analysten mat hirer Prognose richteg waren. Wann Dir op d'Säit mat DBMS op DB-Engines, Dir kënnt dat gesinnоDéi meescht vu senge Leader positionéiere sech speziell als Multi-Modell DBMSs. Datselwecht kann op der Säit mat all private Bewäertung gesi ginn.
D'Tabell hei ënnen weist d'DBMS - d'Leader an jiddereng vun de private Bewäertungen, déi behaapten Multi-Modell ze sinn. Fir all DBMS gëtt den ursprénglechen ënnerstëtzte Modell (deen eemol deen eenzegen war) a mat deem d'Modeller déi aktuell ënnerstëtzt ginn uginn. Och opgezielt sinn DBMSen déi sech als "ursprénglech Multi-Modell" positionéieren an, laut den Creatoren, keen initialen ierfleche Modell hunn.
| DBMS | Éischte Modell | Zousätzlech Modeller |
|---|---|---|
| entscheet | Relational | Grafik, Dokument |
| MSSQL | Relational | Grafik, Dokument |
| PostgreSQL | Relational | Graf*, Dokument |
| MarkLogic | Dokumentarfilm | Grafik, relational |
| MongoDB | Dokumentarfilm | Schlësselwäert, Grafik * |
| DataStax | Breet-Kolonn | Dokumentarfilm, Grafik |
| Redis | Schlëssel-Wäert | Dokumentarfilm, Grafik* |
| ArangoDB | - | Grafik, Dokument |
| Orient DB | - | Grafik, Dokument, relational |
| Azure CosmosDB | - | Grafik, Dokument, relational |
Notizen op den Dësch
Asterisken an der Tabell markéieren Aussoen déi Reservatioun erfuerderen:
- De PostgreSQL DBMS ënnerstëtzt net de Grafikdatenmodell, awer dëst Produkt ënnerstëtzt et , wéi AgensGraph.
- Am Zesummenhang mat MongoDB ass et méi korrekt iwwer d'Präsenz vu Grafikoperateuren an der Ufrosprooch ze schwätzen (, ) wéi iwwer d'Ënnerstëtzung vum Grafikmodell, obwuel natierlech hir Aféierung e puer Optimisatiounen um kierperleche Späicherniveau erfuerdert a Richtung Ënnerstëtzung vum Grafikmodell.
- Am Zesummenhang mat Redis mengen mir d'Verlängerung .
Als nächst wäerte mir fir jiddereng vun de Klassen weisen wéi Ënnerstëtzung fir verschidde Modeller an der DBMS vun dëser Klass ëmgesat gëtt. Mir wäerten d'Relatiouns-, Dokument- a Grafikmodeller als déi wichtegst betruechten a benotze Beispiller vu spezifesche DBMSs fir ze weisen wéi déi "fehlend" ëmgesat ginn.
Multi-Modell DBMS baséiert op der relational Modell
Déi féierend DBMSs sinn am Moment relational; Dem Gartner seng Prognose kéint net als richteg ugesi ginn wann RDBMSs keng Bewegung a Richtung Multi-Modellering weisen. A si demonstréieren. Elo kann d'Iddi datt e Multi-Modell DBMS wéi e Schwäizer Messer ass, wat näischt gutt maache kann, direkt un de Larry Ellison geleet ginn.
Den Auteur huet awer léiwer d'Ëmsetzung vu Multi-Modelléierung am Microsoft SQL Server, op deem Beispill vun deem RDBMS Ënnerstëtzung fir Dokument- a Grafikmodeller beschriwwe gëtt.
Dokumentmodell am MS SQL Server
Et goufe schonn zwee exzellent Artikelen iwwer Habré iwwer wéi MS SQL Server Ënnerstëtzung fir den Dokumentmodell implementéiert; Ech wäert mech op eng kuerz Erzielung a Kommentar limitéieren:
De Wee fir den Dokumentmodell am MS SQL Server z'ënnerstëtzen ass zimmlech typesch fir relational DBMSs: JSON Dokumenter gi proposéiert an normalen Textfelder ze späicheren. Ënnerstëtzung fir den Dokumentmodell ass speziell Betreiber ze bidden fir dësen JSON ze analyséieren:
- fir scalar Attribut Wäerter ze extrahieren,
- Ënner-Dokumenter extrahéieren.
Dat zweet Argument vu béide Bedreiwer ass en Ausdrock an der JSONPath-ähnlecher Syntax.
Abstrakt kënne mir soen datt Dokumenter déi op dës Manéier gespäichert sinn net "éischt Klass Entitéiten" an enger relationaler DBMS, am Géigesaz zu Tuples. Speziell, am MS SQL Server ginn et momentan keng Indexen op de Felder vun JSON Dokumenter, wat et schwéier mécht Dëscher matzemaachen mat de Wäerter vun dëse Felder a souguer Dokumenter mat dëse Wäerter auswielen. Wéi och ëmmer, et ass méiglech eng berechent Kolonn fir sou e Feld an en Index drop ze kreéieren.
Zousätzlech bitt MS SQL Server d'Fäegkeet fir bequem e JSON Dokument aus dem Inhalt vun Dëscher mam Bedreiwer ze konstruéieren - eng Méiglechkeet, an engem gewësse Sënn, Géigendeel zu der viregter, konventionell Stockage. Et ass kloer datt egal wéi séier en RDBMS ass, dës Approche widdersprécht der Ideologie vun Dokument DBMSs, déi am Wesentlechen fäerdeg Äntwerten op populär Ufroen späicheren, a kënnen nëmme Probleemer vun der Liichtegkeet vun der Entwécklung léisen, awer net Geschwindegkeet.
Schlussendlech erlaabt MS SQL Server Iech de Géigendeel Problem vun der Dokumentkonstruktioun ze léisen: Dir kënnt JSON an Tabellen ofsetzen . Wann d'Dokument net ganz flaach ass, musst Dir benotzen CROSS APPLY.
Grafikmodell am MS SQL Server
Ënnerstëtzung fir de Grafik (LPG) Modell ass och voll am Microsoft SQL Server implementéiert : Et gëtt proposéiert speziell Dëscher ze benotzen fir Noden ze späicheren a Grafikkanten ze späicheren. Esou Dëscher gi mat Ausdréck erstallt CREATE TABLE AS NODE и CREATE TABLE AS EDGE respektéiert.
Dëscher vun der éischter Zort sinn ähnlech wéi normal Dëscher fir Rekorder ze späicheren, mam eenzegen externen Ënnerscheed ass datt den Dësch e Systemfeld enthält $node_id - Eenzegaarteg Identifizéierer vun engem Grafiknode an der Datebank.
Ähnlech hunn Dëscher vum zweeten Typ Systemfelder $from_id и $to_id, Entréen an esou Dëscher definéieren kloer d'Verbindungen tëscht Noden. Eng separat Tabell gëtt benotzt fir Bezéiunge vun all Typ ze späicheren.
Loosst eis dëst mat engem Beispill illustréieren. Loosst d'Grafikdaten e Layout hunn wéi deen an der Figur gewisen. Dann fir déi entspriechend Struktur an der Datebank ze kreéieren musst Dir déi folgend DDL Ufroen ausféieren:
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);D'Haaptspezifizitéit vun esou Dëscher ass datt an Ufroen géint si et méiglech ass Grafikmuster mat Cypher-ähnlechen Syntax ze benotzen (awer "*"etc. sinn nach net ënnerstëtzt). Baséierend op Leeschtungsmiessunge kann et och ugeholl ginn datt d'Art a Weis wéi d'Daten an dësen Dëscher gespäichert sinn anescht wéi d'Art a Weis wéi d'Daten a reguläre Dëscher gespäichert ginn an optimiséiert sinn fir esou Grafikufroen auszeféieren.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Ausserdeem ass et zimmlech schwéier dës Grafikmuster net ze benotzen wann Dir mat sou Dëscher schafft, well an normalen SQL Ufroen fir ähnlech Probleemer ze léisen, wäert et néideg sinn zousätzlech Efforten ze maachen fir System "Grafik" Node Identifizéierer ze kréien ($node_id, $from_id, $to_id; Aus deemselwechte Grond ginn Ufroe fir d'Insertéierung vun Daten hei net gewisen, well se onnéideg ëmständlech sinn).
Fir d'Beschreiwung vun den Implementatioune vun den Dokument- a Grafikmodeller am MS SQL Server ze resuméieren, géif ech feststellen datt esou Implementatioune vun engem Modell op engem aneren net erfollegräich schéngen, virun allem aus der Siicht vum Sproochdesign. Et ass néideg eng Sprooch mat enger anerer ze verlängeren, d'Sprooche sinn net komplett "ortogonal", d'Kompatibilitéitsregele kënne ganz bizar sinn.
Multi-Modell DBMS baséiert op dem Dokumentmodell
An dëser Sektioun wëll ech d'Ëmsetzung vu Multi-Modell an Dokument DBMSs illustréieren mat dem Beispill vun der net populärsten vun hinnen, MongoDB (wéi gesot, et huet nëmmen bedingte Grafikoperateuren $lookup и $graphLookup, schafft net op sharded Sammlungen), awer benotzt d'Beispill vun enger méi reife an "Entreprise" DBMS .
Also, loosst d'Sammlung eng Rei vun XML Dokumenter vun der folgender Zort enthalen (MarkLogic erlaabt Iech och JSON Dokumenter ze späicheren):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Relational Modell an MarkLogic
Eng relational Vue vun enger Sammlung vun Dokumenter kann erstallt ginn mat (Inhalt vun Elementer value am Beispill hei ënnen kann et en arbiträren XPath sinn):
<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>Dir kënnt déi erstallt Vue mat enger SQL Ufro adresséieren (zum Beispill iwwer ODBC):
SELECT name, surname FROM Person WHERE name="John"Leider ass d'relational Vue erstallt vun der Displayschabloun nëmme liesen. Wann Dir eng Demande dofir veraarbecht, probéiert MarkLogic ze benotzen . Virdrun, MarkLogic hat limitéiert relational Meenung, ganz a schrëftlech, awer elo gi se als ofgeschaaft ugesinn.
Grafikmodell an MarkLogic
Mat Ënnerstëtzung fir de Grafik (RDF) Modell ass alles ongeféier d'selwecht. Nach eng Kéier mat der Hëllef Dir kënnt eng RDF Representatioun vun enger Sammlung vun Dokumenter aus dem Beispill hei uewen 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>Dir kënnt déi resultéierend RDF Grafik mat enger SPARQL Ufro adresséieren:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Am Géigesaz zu der relationaler ënnerstëtzt MarkLogic de Grafikmodell op zwou aner Weeër:
- En DBMS kann eng vollwäerteg separat Späichere vun RDF Daten sinn (Drëppelen an et ginn genannt am Géigesaz zu deenen uewen beschriwwen ).
- RDF a speziell Serialiséierung kann einfach an XML oder JSON Dokumenter agebaut ginn (an Triplets ginn dann genannt ). Dëst ass wahrscheinlech eng Alternativ zu Mechanismen
idrefan anerer.
Eng gutt Iddi wéi d'Saache "wierklech" an MarkLogic funktionnéieren gëtt vun , an dësem Sënn ass et niddereg-Niveau, obwuel säin Zweck éischter de Géigendeel ass - ze probéieren aus dem benotzten Datemodell ze abstrakt, fir konsequent Aarbecht mat Daten a verschiddene Modeller, Transaktiounsfäegkeet, etc.
Multi-Modell DBMS "ouni Haaptmodell"
Et ginn och DBMSen um Maart déi sech als ursprénglech Multi-Modell positionéieren, ouni ierflechen Haaptmodell. Dozou gehéiert , (zënter 2018 gehéiert d'Entwécklungsfirma zu SAP) an (Service als Deel vun der Microsoft Azure Cloud Plattform).
Tatsächlech ginn et "Kär" Modeller an ArangoDB an OrientDB. A béide Fäll sinn dës hir eege Datemodeller, déi Generaliséierunge vum Dokument sinn. D'Generalisatiounen sinn haaptsächlech fir d'Fäegkeet ze erliichteren fir Ufroe vun enger Grafik a relationeller Natur auszeféieren.
Dës Modeller sinn déi eenzeg verfügbar fir an der spezifizéierter DBMS ze benotzen; hir eege Ufrosprooche si entwéckelt fir mat hinnen ze schaffen. Natierlech sinn esou Modeller an DBMSe villverspriechend, awer de Mangel u Kompatibilitéit mat Standardmodeller a Sproochen mécht et onméiglech dës DBMSen an legacy Systemer ze benotzen - fir d'DBMSs déi schonn do benotzt goufen ze ersetzen.
Et war schonn e wonnerschéinen Artikel iwwer ArangoDB an OrientDB op Habré: .
ArangoDB
ArangoDB behaapt Ënnerstëtzung fir e Grafikdatenmodell.
D'Node vun enger Grafik an ArangoDB sinn normal Dokumenter, an d'Kante sinn Dokumenter vun engem speziellen Typ, deen zesumme mat reguläre Systemfelder (_key, _id, _rev) Systemfelder _from и _to. Dokumenter an Dokument DBMSs ginn traditionell a Sammlungen kombinéiert. Sammlunge vun Dokumenter, déi Kanten representéieren, ginn Randkollektiounen an ArangoDB genannt. Iwwregens, Randkollektiounsdokumenter sinn och Dokumenter, sou datt Kanten an ArangoDB och als Node kënnen handelen.
Roude sinn
Loosst eis eng Sammlung hunn persons, deenen hir Dokumenter esou ausgesinn:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Loosst et och eng Sammlung ginn cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Dann d'Kollektioun likes kéint esou ausgesinn:
[
{
"_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
}
]Ufroen a Resultater
Eng Grafik-Stil Ufro an der AQL Sprooch, déi an ArangoDB benotzt gëtt, zréck a mënschlech liesbarer Form Informatioun iwwer wien wéi ee Café gär huet, gesäit esou aus:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }An engem relationelle Stil, wou mir Relatiounen "rechenen" anstatt se ze späicheren, kann dës Ufro esou nei geschriwwe ginn (iwwregens ouni d'Sammlung likes kéint ouni maachen):
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 }D'Resultat a béide Fäll wäert d'selwecht sinn:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Méi Ufroen a Resultater
Wann d'Resultatformat hei uewen méi typesch fir eng relational DBMS schéngt wéi fir en Dokument DBMS, kënnt Dir dës Ufro probéieren (oder Dir kënnt benotzen ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}D'Resultat wäert esou ausgesinn:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]Orient DB
D'Basis fir e Grafikmodell uewen op engem Dokumentmodell an OrientDB ëmzesetzen ass Dokument Felder, zousätzlech zu méi oder manner Standard scalar Wäerter, hunn och Wäerter vun Typen wéi LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. D'Wäerter vun dësen Aarte si Linken oder Sammlunge vu Linken op Dokumenter.
Den Dokumentidentifizéierer, deen vum System zougewisen ass, huet eng "kierperlech Bedeitung", wat d'Positioun vum Rekord an der Datebank ugeet, a gesäit esou aus: @rid : #3:16. Also sinn d'Wäerter vun de Referenzeigenschaften wierklech Hiweiser (wéi am Grafikmodell) anstatt Selektiounsbedéngungen (wéi am relationale Modell).
Wéi ArangoDB, Kanten an OrientDB ginn als separat Dokumenter duergestallt (och wann e Rand keng eegen Eegeschaften huet, kann et gemaach ginn , an et wäert net zu engem separaten Dokument entspriechen).
Roude sinn
An engem Format no bei OrientDB Datebank, d'Donnéeën aus dem fréiere Beispill fir ArangoDB géifen esou ausgesinn:
[
{
"@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"
}
]Wéi mir kënne gesinn, späicheren Wirbelen och Informatioun iwwer erakommen an erausgaang Kanten. Op D'Dokument API muss d'referentiell Integritéit selwer iwwerwaachen, an d'Graph API iwwerhëlt dës Aarbecht. Awer loosst eis kucken wéi den Zougang zu OrientDB an "rengen" Ufrosproochen ausgesäit, déi net a Programméierungssproochen integréiert sinn.
Ufroen a Resultater
Eng Ufro ähnlech am Zweck wéi d'Ufro aus dem Beispill fir ArangoDB an OrientDB gesäit esou aus:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameD'Resultat gëtt an der folgender Form kritt:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Wann d'Resultat Format nees ze "relational" schéngt, musst Dir d'Linn ewechhuelen mat :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]Dem OrientDB seng Ufrosprooch kann als SQL mat Gremlin-ähnlechen Inserts beschriwwe ginn. An der Versioun 2.2 ass eng Cypher-ähnlech Ufroform erschéngt, :
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_nameD'Resultatformat wäert d'selwecht sinn wéi an der viregter Ufro. Denkt un wat muss geläscht ginn fir et méi "relational" ze maachen, wéi an der alleréischter Ufro.
Azure CosmosDB
A mannerem Mooss, wat uewen iwwer ArangoDB an OrientDB gesot gouf, gëllt fir Azure CosmosDB. CosmosDB bitt déi folgend Datenzougang APIen: SQL, MongoDB, Gremlin a Cassandra.
SQL API a MongoDB API gi benotzt fir Zougang zu Daten am Dokumentmodell ze kréien. Gremlin API a Cassandra API - fir Zougang zu Daten a Grafik- a Kolonnformater, respektiv. Daten an all Modeller ginn am CosmosDB internt Modellformat gespäichert: ("Atom-Rekord-Sequenz"), déi och no beim Dokument een ass.
Awer den Datemodell, dee vum Benotzer gewielt gëtt an d'API, déi benotzt gëtt, sinn fixéiert zum Zäitpunkt vun der Schafung vun engem Kont am Service. Et ass net méiglech Zougang zu Daten, déi an engem Modell gelueden sinn am Format vun engem anere Modell, wéi illustréiert duerch sou eppes:
Also ass Multi-Modell an Azure CosmosDB haut nëmmen d'Fäegkeet fir verschidde Datenbanken ze benotzen déi verschidde Modeller vun engem Hiersteller ënnerstëtzen, wat net all d'Problemer vun der Multi-Variant Lagerung léist.
Multi-Modell DBMS baséiert op engem Grafikmodell?
Bemierkenswäert ass d'Tatsaach datt et nach keng Multi-Modell DBMSen um Maart sinn, déi op engem Grafikmodell baséieren (ausser Multi-Modell Ënnerstëtzung fir gläichzäiteg zwee Grafikmodeller: RDF a LPG; kuckt dëst an ). Déi gréisste Schwieregkeete ginn duerch d'Ëmsetzung vun engem Dokumentmodell uewen op engem Grafikmodell verursaacht, anstatt e relationalen.
D'Fro, wéi een e relational Modell uewen um Grafikmodell ëmzesetzen, gouf och während der Bildung vum leschte berücksichtegt. Wéi zum Beispill :
Et gëtt näischt inherent an der Grafik Approche déi verhënnert datt eng Schicht erstallt gëtt (zB duerch gëeegent Indexéierung) op enger Grafikdatenbank déi eng relational Vue erméiglecht mat (1) Erhuelung vun Tuples aus den üblechen Schlësselwäertpaaren an (2) Gruppéierung vun tuples no Relatioun Typ.
Wann Dir en Dokumentmodell uewen op engem Grafikmodell implementéiert, musst Dir zum Beispill déi folgend am Kapp behalen:
- Elementer vun engem JSON-Array ginn als bestallt ugesinn, awer déi, déi aus dem Wirt vun engem Rand vun der Grafik erauskommen, sinn net;
- Daten am Dokumentmodell sinn normalerweis denormaliséiert; Dir wëllt ëmmer nach net e puer Kopien vum selwechte embedded Dokument späicheren, an Ënnerdokumenter hunn normalerweis keng Identifizéierer;
- Op der anerer Säit ass d'Ideologie vun Dokument DBMSen datt Dokumenter fäerdeg "Aggregate" sinn déi net all Kéier nei gebaut musse ginn. Et ass erfuerderlech de Grafikmodell d'Fäegkeet ze ginn fir séier en Ënnergrafik ze kréien deen dem fäerdegen Dokument entsprécht.
E bësse Reklamm
Den Auteur vum Artikel ass mat der Entwécklung vum NitrosBase DBMS verbonnen, den internen Modell vun deem Grafik ass, an déi extern Modeller - relational an Dokument - sinn hir Representatioune. All Modeller sinn gläich: bal all Donnéeën ass verfügbar a jidderee vun hinnen mat enger Ufrosprooch déi natierlech ass. Ausserdeem, an all Vue, kënnen d'Donnéeën geännert ginn. Ännerungen wäerten am internen Modell reflektéiert ginn an deementspriechend an aner Meenungen.
Ech wäert hoffentlech beschreiwen wéi Modellmatching an NitrosBase an engem vun den folgenden Artikelen ausgesäit.
Konklusioun
Ech hoffen, datt d'allgemeng Kontur vun deem wat Multi-Modellering genannt gëtt, dem Lieser méi oder manner kloer ginn. Multi-Modell DBMSs si ganz anescht, an "Multi-Modell Support" kann anescht ausgesinn. Fir ze verstoen wat "Multi-Modell" an all spezifesche Fall genannt gëtt, ass et nëtzlech fir déi folgend Froen ze beäntweren:
- Schwätze mir iwwer d'Ënnerstëtzung vun traditionelle Modeller oder eng Zort "Hybrid" Modell?
- Sinn d'Modeller "gläich", oder ass ee vun hinnen de Sujet vun deenen aneren?
- Sinn d'Modeller "indiferent" zueneen? Kann Daten, déi an engem Modell geschriwwe sinn, an engem anere gelies ginn oder souguer iwwerschriwwe ginn?
Ech mengen datt d'Fro iwwer d'Relevanz vu Multi-Modell DBMS scho positiv beäntwert ka ginn, awer déi interessant Fro ass wéi eng Zorte vun hinnen an der nächster Zukunft méi gefrot ginn. Et schéngt, datt Multi-Modell DBMSs déi traditionell Modeller ënnerstëtzen, haaptsächlech relational, méi grouss Nofro sinn; D'Popularitéit vu Multi-Modell DBMSs, déi nei Modeller ubidden, déi d'Virdeeler vu verschiddenen traditionellen kombinéieren, ass eng Saach vun der méi wäiter Zukunft.
Nëmme registréiert Benotzer kënnen un der Ëmfro deelhuelen. , wann ech glift.
Benotzt Dir Multi-Modell DBMS?
-
Mir benotzen et net, mir späicheren alles an engem DBMS an an engem Modell
-
Mir benotzen Multi-Modell Fäegkeeten vun traditionelle DBMSs
-
Mir üben polyglot Persistenz
-
Mir benotzen nei Multi-Modell DBMS (Arango, Orient, CosmosDB)
19 Benotzer hunn gestëmmt. 4 Benotzer hu sech enthalen.
Source: will.com