Moderne informatiesystemen zijn behoorlijk complex. Niet in de laatste plaats is hun complexiteit te danken aan de complexiteit van de gegevens die erin worden verwerkt. De complexiteit van data ligt vaak in de verscheidenheid aan gebruikte datamodellen. Wanneer data bijvoorbeeld “groot” worden, is een van de problematische kenmerken niet alleen het volume (“volume”), maar ook de variëteit (“variëteit”).
Als je nog geen fout in de redenering ontdekt, lees dan verder.
Inhoud
Polyglot volharding
Het bovenstaande leidt ertoe dat het soms zelfs binnen het raamwerk van één systeem nodig is om verschillende DBMS'en te gebruiken om gegevens op te slaan en verschillende problemen bij de verwerking ervan op te lossen, die elk hun eigen datamodel ondersteunen. Met de lichte hand van M. Fowler, een aantal bekende boeken en één van Agile Manifesto, heet deze situatie opslag in meerdere varianten (“polyglotte volharding”).
Fowler heeft ook het volgende voorbeeld van het organiseren van gegevensopslag in een volledig functionele en zwaarbelaste applicatie op het gebied van e-commerce.
Dit voorbeeld is natuurlijk enigszins overdreven, maar er zijn bijvoorbeeld enkele overwegingen die pleiten voor het kiezen van een of ander DBMS voor het overeenkomstige doel: .
Het is duidelijk dat het niet eenvoudig is om bediende te zijn in zo'n dierentuin.
- De hoeveelheid code die gegevensopslag uitvoert, groeit evenredig met het aantal gebruikte DBMS's; de hoeveelheid codesynchronisatiegegevens is goed, zo niet evenredig met het kwadraat van dit getal.
- Als een veelvoud van het aantal gebruikte DBMS'en stijgen de kosten voor het bieden van ondernemingskenmerken (schaalbaarheid, fouttolerantie, hoge beschikbaarheid) van elk van de gebruikte DBMS'en.
- Het is onmogelijk om de bedrijfskenmerken van het opslagsubsysteem als geheel te garanderen, vooral de transactionaliteit.
Vanuit het standpunt van de dierentuindirecteur ziet alles er als volgt uit:
- Een meervoudige stijging van de kosten van licenties en technische ondersteuning van de DBMS-fabrikant.
- Overbezetting en langere deadlines.
- Directe financiële verliezen of boetes als gevolg van inconsistentie van gegevens.
Er is een aanzienlijke stijging van de totale eigendomskosten (TCO) van het systeem. Is er een uitweg uit de situatie van “meerdere opslagopties”?
Multi-model
De term ‘multivariate opslag’ werd in 2011 in gebruik genomen. Het bewustzijn van de problemen van de aanpak en het zoeken naar een oplossing duurde enkele jaren, en in 2015 werd door de mond van Gartner-analisten het antwoord geformuleerd:
- Van "'
De toekomst van DBMS'en, hun architecturen en manieren om ze te gebruiken is multi-model.
- Van "'
Toonaangevende operationele DBMS'en zullen meerdere modellen aanbieden – relationeel en niet-relationeel – als onderdeel van één enkel platform.
Het lijkt erop dat de analisten van Gartner deze keer gelijk hadden met hun voorspelling. Als u naar de pagina gaat met DBMS op DB-Engines, dat zie jeоDe meeste leiders positioneren zichzelf specifiek als DBMS'en met meerdere modellen. Hetzelfde is te zien op de pagina met elke privébeoordeling.
De onderstaande tabel toont de DBMS - de leiders in elk van de particuliere beoordelingen, die beweren multi-model te zijn. Voor elk DBMS wordt het oorspronkelijk ondersteunde model (dat ooit het enige was) en daarmee de momenteel ondersteunde modellen aangegeven. Ook worden DBMS'en vermeld die zichzelf positioneren als "oorspronkelijk multi-model" en volgens de makers geen initieel geërfd model hebben.
| DBMS | Initieel model | Extra modellen |
|---|---|---|
| Oracle | relationeel | Grafiek, document |
| MS SQL | relationeel | Grafiek, document |
| PostgreSQL | relationeel | Grafiek*, document |
| MarkLogic | Documentaire | Grafiek, relationeel |
| MongoDB | Documentaire | Sleutelwaarde, grafiek* |
| DataStax | Brede kolom | Documentaire, grafiek |
| Redis | Sleutel waarde | Documentaire, grafiek* |
| ArangoDB | - | Grafiek, document |
| OrientDB | - | Grafiek, document, relationeel |
| Azure CosmosDB | - | Grafiek, document, relationeel |
Tabelnotities
Sterretjes in de tabel markeren uitspraken waarvoor reserveringen vereist zijn:
- Het PostgreSQL DBMS ondersteunt het grafiekgegevensmodel niet, maar dit product ondersteunt dit wel , zoals AgensGraph.
- Met betrekking tot MongoDB is het juister om te praten over de aanwezigheid van grafiekoperatoren in de querytaal (, ) dan over de ondersteuning van het grafische model, hoewel de introductie ervan uiteraard enkele optimalisaties op het fysieke opslagniveau vereiste in de richting van de ondersteuning van het grafische model.
- Met betrekking tot Redis bedoelen we de extensie .
Vervolgens laten we voor elk van de klassen zien hoe ondersteuning voor verschillende modellen vanuit deze klasse in het DBMS is geïmplementeerd. We zullen de relationele, document- en grafiekmodellen als de belangrijkste beschouwen en voorbeelden van specifieke DBMS'en gebruiken om te laten zien hoe de "ontbrekende" worden geïmplementeerd.
Multi-model DBMS gebaseerd op het relationele model
De toonaangevende DBMS'en zijn momenteel relationeel; de voorspelling van Gartner kan niet als waar worden beschouwd als RDBMS'en geen beweging in de richting van multi-modellering laten zien. En ze demonstreren. Nu kan het idee dat een DBMS met meerdere modellen als een Zwitsers mes is, dat niets goeds kan, rechtstreeks aan Larry Ellison worden gericht.
De auteur geeft echter de voorkeur aan de implementatie van multi-modellering in Microsoft SQL Server, aan de hand van het voorbeeld waarvan RDBMS-ondersteuning voor document- en grafiekmodellen zal worden beschreven.
Documentmodel in MS SQL Server
Er zijn al twee uitstekende artikelen over Habré verschenen over hoe MS SQL Server ondersteuning voor het documentmodel implementeert; ik zal mij beperken tot een korte hervertelling en commentaar:
De manier om het documentmodel in MS SQL Server te ondersteunen is vrij typerend voor relationele DBMS's: er wordt voorgesteld om JSON-documenten op te slaan in gewone tekstvelden. Ondersteuning voor het documentmodel is het bieden van speciale operators om deze JSON te parseren:
- om scalaire attribuutwaarden te extraheren,
- om subdocumenten te extraheren.
Het tweede argument van beide operators is een expressie in JSONPath-achtige syntaxis.
Abstract gezien kunnen we zeggen dat documenten die op deze manier zijn opgeslagen geen ‘eersteklas entiteiten’ zijn in een relationeel DBMS, in tegenstelling tot tupels. Concreet zijn er in MS SQL Server momenteel geen indexen op de velden van JSON-documenten, wat het moeilijk maakt om tabellen samen te voegen met behulp van de waarden van deze velden en zelfs documenten te selecteren met behulp van deze waarden. Het is echter wel mogelijk om voor zo’n veld een berekende kolom te maken en er een index op te plaatsen.
Bovendien biedt MS SQL Server de mogelijkheid om met behulp van de operator gemakkelijk een JSON-document samen te stellen uit de inhoud van tabellen - een mogelijkheid, in zekere zin, tegengesteld aan de vorige, conventionele opslag. Het is duidelijk dat, hoe snel een RDBMS ook is, deze benadering in tegenspraak is met de ideologie van document-DBMS's, die in wezen kant-en-klare antwoorden op populaire vragen opslaan en alleen problemen van ontwikkelingsgemak kunnen oplossen, maar niet van snelheid.
Ten slotte kunt u met MS SQL Server het tegenovergestelde probleem van documentconstructie oplossen: u kunt JSON in tabellen opsplitsen met behulp van . Als het document niet helemaal vlak is, moet u dit gebruiken CROSS APPLY.
Grafiekmodel in MS SQL Server
Ondersteuning voor het grafiekmodel (LPG) is ook volledig geïmplementeerd in Microsoft SQL Server : Er wordt voorgesteld om speciale tabellen te gebruiken om knooppunten en grafiekranden op te slaan. Dergelijke tabellen worden gemaakt met behulp van expressies CREATE TABLE AS NODE и CREATE TABLE AS EDGE respectievelijk.
Tabellen van het eerste type zijn vergelijkbaar met gewone tabellen voor het opslaan van records, met als enige externe verschil dat de tabel een systeemveld bevat $node_id — unieke identificatiecode van een grafiekknooppunt in de database.
Op dezelfde manier hebben tabellen van het tweede type systeemvelden $from_id и $to_id, definiëren de vermeldingen in dergelijke tabellen duidelijk de verbindingen tussen knooppunten. Er wordt een aparte tabel gebruikt om relaties van elk type op te slaan.
Laten we dit illustreren met een voorbeeld. Laat de grafiekgegevens een lay-out hebben zoals weergegeven in de afbeelding. Om vervolgens de overeenkomstige structuur in de database te creëren, moet u de volgende DDL-query's uitvoeren:
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);De belangrijkste specificiteit van dergelijke tabellen is dat het bij zoekopdrachten ertegen mogelijk is om grafiekpatronen te gebruiken met een Cypher-achtige syntaxis (echter: “*"etc. worden nog niet ondersteund). Op basis van prestatiemetingen kan ook worden aangenomen dat de manier waarop gegevens in deze tabellen worden opgeslagen anders is dan de manier waarop gegevens in gewone tabellen worden opgeslagen en dat deze is geoptimaliseerd voor het uitvoeren van dergelijke grafiekquery's.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Bovendien is het vrij moeilijk om deze grafiekpatronen niet te gebruiken bij het werken met dergelijke tabellen, omdat het bij gewone SQL-query's om soortgelijke problemen op te lossen extra inspanningen zal moeten leveren om systeem-"grafiek"-knooppunt-ID's te verkrijgen ($node_id, $from_id, $to_id; Om dezelfde reden worden zoekopdrachten voor het invoegen van gegevens hier niet weergegeven, omdat deze onnodig omslachtig zijn).
Om de beschrijving van de implementaties van de document- en grafiekmodellen in MS SQL Server samen te vatten, zou ik willen opmerken dat dergelijke implementaties van het ene model bovenop het andere niet succesvol lijken, vooral vanuit het oogpunt van taalontwerp. Het is noodzakelijk om de ene taal met de andere uit te breiden, de talen zijn niet volledig “orthogonaal”, de compatibiliteitsregels kunnen behoorlijk bizar zijn.
DBMS met meerdere modellen gebaseerd op het documentmodel
In deze sectie wil ik de implementatie van multi-model in document-DBMS's illustreren met behulp van het voorbeeld van de niet meest populaire ervan, MongoDB (zoals gezegd, het heeft alleen voorwaardelijke grafiekoperatoren $lookup и $graphLookup, waarbij niet wordt gewerkt aan gesharde collecties), maar waarbij het voorbeeld wordt gebruikt van een meer volwassen en ‘ondernemings’ DBMS .
Laat de verzameling dus een set XML-documenten van het volgende type bevatten (met MarkLogic kunt u ook JSON-documenten opslaan):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Relationeel model in MarkLogic
Een relationele weergave van een verzameling documenten kan worden gemaakt met behulp van (inhoud van elementen value in het onderstaande voorbeeld kan er een willekeurige XPath zijn):
<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>U kunt de gemaakte weergave adresseren met een SQL-query (bijvoorbeeld via ODBC):
SELECT name, surname FROM Person WHERE name="John"Helaas is de relationele weergave die door de weergavesjabloon wordt gemaakt, alleen-lezen. Bij het verwerken van een verzoek hiervoor zal MarkLogic proberen gebruik te maken van . Voorheen had MarkLogic geheel beperkte relationele opvattingen en beschrijfbaar, maar nu worden ze als verouderd beschouwd.
Grafiekmodel in MarkLogic
Met ondersteuning voor het grafiekmodel (RDF) is alles ongeveer hetzelfde. Opnieuw met hulp u kunt een RDF-weergave van een verzameling documenten maken op basis van het bovenstaande voorbeeld:
<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>U kunt de resulterende RDF-grafiek adresseren met een SPARQL-query:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}In tegenstelling tot het relationele model ondersteunt MarkLogic het grafiekmodel op twee andere manieren:
- Een DBMS kan een volwaardige afzonderlijke opslag van RDF-gegevens zijn (tripletten daarin worden genoemd in tegenstelling tot de hierboven beschreven ).
- RDF in speciale serialisatie kan eenvoudig in XML- of JSON-documenten worden ingevoegd (en triplets worden dan aangeroepen ). Dit is waarschijnlijk een alternatief voor mechanismen
idrefetc.
Een goed beeld van hoe dingen “echt” werken in MarkLogic wordt gegeven door In die zin is het een laag niveau, hoewel het doel eerder het tegenovergestelde is: proberen te abstraheren van het gebruikte datamodel, consistent werken met data in verschillende modellen, transactionaliteit, enz. te garanderen.
Multi-model DBMS “zonder hoofdmodel”
Er zijn ook DBMS'en op de markt die zichzelf positioneren als aanvankelijk multi-model, zonder enig overgeërfd hoofdmodel. Deze omvatten , (sinds 2018 is het ontwikkelingsbedrijf eigendom van SAP) en (dienst als onderdeel van het Microsoft Azure cloudplatform).
In feite zijn er “kernmodellen” in ArangoDB en OrientDB. In beide gevallen zijn dit hun eigen datamodellen, die generalisaties zijn van het document. De generalisaties zijn voornamelijk bedoeld om de mogelijkheid te vergemakkelijken om zoekopdrachten van grafische en relationele aard uit te voeren.
Deze modellen zijn de enige die beschikbaar zijn voor gebruik in het opgegeven DBMS; hun eigen querytalen zijn ontworpen om ermee te werken. Natuurlijk zijn dergelijke modellen en DBMS’en veelbelovend, maar het gebrek aan compatibiliteit met standaardmodellen en talen maakt het onmogelijk om deze DBMS’en in oudere systemen te gebruiken – ter vervanging van de DBMS’en die daar al worden gebruikt.
Er stond al een prachtig artikel over ArangoDB en OrientDB op Habré: .
ArangoDB
ArangoDB claimt ondersteuning voor een grafiekgegevensmodel.
De knooppunten van een grafiek in ArangoDB zijn gewone documenten, en de randen zijn documenten van een speciaal type die, samen met reguliere systeemvelden, (_key, _id, _rev) systeemvelden _from и _to. Documenten in document-DBMS'en worden traditioneel gecombineerd tot verzamelingen. Verzamelingen van documenten die randen vertegenwoordigen, worden in ArangoDB randverzamelingen genoemd. Overigens zijn edge-verzamelingsdocumenten ook documenten, dus randen in ArangoDB kunnen ook als knooppunten fungeren.
Initiële gegevens
Laten we een verzameling hebben persons, waarvan de documenten er als volgt uitzien:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Laat er ook een collecte zijn cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Dan de collectie likes zou er zo uit kunnen zien:
[
{
"_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
}
]Vragen en resultaten
Een query in grafiekstijl in de AQL-taal die in ArangoDB wordt gebruikt en die in voor mensen leesbare vorm informatie retourneert over wie van welk café houdt, ziet er als volgt uit:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }In een relationele stijl, waarbij we relaties ‘berekenen’ in plaats van ze op te slaan, kan deze zoekopdracht op deze manier worden herschreven (trouwens, zonder de verzameling likes kan zonder):
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 }Het resultaat zal in beide gevallen hetzelfde zijn:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Meer vragen en resultaten
Als het bovenstaande resultaatformaat meer typerend lijkt voor een relationeel DBMS dan voor een document-DBMS, kunt u deze query proberen (of u kunt ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Het resultaat ziet er als volgt uit:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
De basis voor het implementeren van een grafiekmodel bovenop een documentmodel in OrientDB is documentvelden hebben, naast min of meer standaard scalaire waarden, ook waarden van typen zoals LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. De waarden van deze typen zijn links of verzamelingen links naar documenten.
De door het systeem toegewezen documentidentificatie heeft een ‘fysieke betekenis’, die de positie van het record in de database aangeeft, en ziet er ongeveer zo uit: @rid : #3:16. De waarden van referentie-eigenschappen zijn dus eigenlijk aanwijzingen (zoals in het grafiekmodel) in plaats van selectievoorwaarden (zoals in het relationele model).
Net als ArangoDB worden randen in OrientDB weergegeven als afzonderlijke documenten (hoewel als een rand geen eigen eigenschappen heeft, deze kan worden gemaakt , en het komt niet overeen met een afzonderlijk document).
Initiële gegevens
In een formaat dichtbij OrientDB-database, zouden de gegevens uit het vorige voorbeeld voor ArangoDB er ongeveer zo uitzien:
[
{
"@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"
}
]Zoals we kunnen zien, slaan hoekpunten ook informatie op over inkomende en uitgaande randen. Bij De Document API moet de referentiële integriteit zelf monitoren, en de Graph API neemt dit werk op zich. Maar laten we eens kijken hoe toegang tot OrientDB eruit ziet in ‘pure’ querytalen die niet in programmeertalen zijn geïntegreerd.
Vragen en resultaten
Een query die qua doel vergelijkbaar is met de query uit het voorbeeld voor ArangoDB in OrientDB ziet er als volgt uit:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameHet resultaat wordt verkregen in de volgende vorm:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Als het resultaatformaat opnieuw te “relationeel” lijkt, moet u de regel met verwijderen :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]De querytaal van OrientDB kan worden omschreven als SQL met Gremlin-achtige inserts. In versie 2.2 verscheen een Cypher-achtig aanvraagformulier, :
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_nameHet resultaatformaat zal hetzelfde zijn als in het vorige verzoek. Denk na over wat er moet worden verwijderd om het meer ‘relationeel’ te maken, zoals in de allereerste vraag.
Azure CosmosDB
In mindere mate is wat hierboven werd gezegd over ArangoDB en OrientDB van toepassing op Azure CosmosDB. CosmosDB biedt de volgende API's voor gegevenstoegang: SQL, MongoDB, Gremlin en Cassandra.
SQL API en MongoDB API worden gebruikt om toegang te krijgen tot gegevens in het documentmodel. Gremlin API en Cassandra API - voor toegang tot gegevens in respectievelijk grafiek- en kolomformaten. Gegevens in alle modellen worden opgeslagen in de interne modelindeling van CosmosDB: (“atom-record-sequence”), wat ook dicht bij het document ligt.
Maar het door de gebruiker gekozen datamodel en de gebruikte API staan vast op het moment dat een account in de dienst wordt aangemaakt. Het is niet mogelijk om toegang te krijgen tot gegevens die in het ene model zijn geladen in het formaat van een ander model, zoals geïllustreerd door zoiets als dit:
Multi-model in Azure CosmosDB is tegenwoordig dus alleen maar de mogelijkheid om meerdere databases te gebruiken die verschillende modellen van één fabrikant ondersteunen, wat niet alle problemen van opslag met meerdere varianten oplost.
Multi-model DBMS op basis van een grafisch model?
Opmerkelijk is het feit dat er nog geen multi-model DBMS’en op de markt zijn die gebaseerd zijn op een graafmodel (behalve multi-model ondersteuning voor gelijktijdig twee graafmodellen: RDF en LPG; zie dit in ). De grootste problemen worden veroorzaakt door de implementatie van een documentmodel bovenop een grafiekmodel, in plaats van een relationeel model.
De vraag hoe een relationeel model bovenop het grafiekmodel moest worden geïmplementeerd, werd zelfs tijdens de vorming van dit laatste in overweging genomen. Hoe Bijvoorbeeld, :
Er is niets inherent aan de grafiekbenadering dat het creëren van een laag (bijvoorbeeld door geschikte indexering) op een grafiekdatabase verhindert die een relationele weergave mogelijk maakt met (1) herstel van tupels uit de gebruikelijke sleutelwaardeparen en (2) groepering van tupels op relatietype.
Wanneer u een documentmodel bovenop een grafiekmodel implementeert, moet u bijvoorbeeld met het volgende rekening houden:
- Elementen van een JSON-array worden als geordend beschouwd, maar de elementen die uit het hoekpunt van een rand van de grafiek komen, zijn dat niet;
- Gegevens in het documentmodel zijn meestal gedenormaliseerd; u wilt nog steeds niet meerdere exemplaren van hetzelfde ingebedde document opslaan, en subdocumenten hebben meestal geen ID's;
- Aan de andere kant is de ideologie van document-DBMS'en dat documenten kant-en-klare 'aggregaten' zijn die niet elke keer opnieuw hoeven te worden gebouwd. Het is vereist om het grafiekmodel de mogelijkheid te bieden om snel een subgrafiek te verkrijgen die overeenkomt met het voltooide document.
wat reclame
De auteur van het artikel heeft betrekking op de ontwikkeling van het NitrosBase DBMS, waarvan het interne model een grafiek is, en de externe modellen - relationeel en document - de representaties ervan zijn. Alle modellen zijn gelijk: vrijwel alle gegevens zijn in elk van deze modellen beschikbaar met behulp van een querytaal die daarvoor natuurlijk is. Bovendien kunnen de gegevens in elke weergave worden gewijzigd. Veranderingen zullen worden weerspiegeld in het interne model en daarmee ook in andere opvattingen.
Ik zal hopelijk in een van de volgende artikelen beschrijven hoe modelmatching eruit ziet in NitrosBase.
Conclusie
Ik hoop dat de algemene contouren van wat multi-modellering wordt genoemd min of meer duidelijk zijn geworden voor de lezer. DBMS's met meerdere modellen zijn behoorlijk verschillend, en "ondersteuning voor meerdere modellen" kan er anders uitzien. Om te begrijpen wat in elk specifiek geval ‘multimodel’ wordt genoemd, is het nuttig om de volgende vragen te beantwoorden:
- Hebben we het over het ondersteunen van traditionele modellen of over een soort ‘hybride’ model?
- Zijn de modellen “gelijk”, of is één ervan het onderwerp van de andere?
- Staan de modellen “onverschillig” tegenover elkaar? Kunnen gegevens die in het ene model zijn geschreven, in een ander model worden gelezen of zelfs worden overschreven?
Ik denk dat de vraag over de relevantie van multi-model DBMS al positief kan worden beantwoord, maar de interessante vraag is welke typen daarvan in de nabije toekomst meer in trek zullen zijn. Het lijkt erop dat er meer vraag zal zijn naar DBMS'en met meerdere modellen die traditionele, voornamelijk relationele modellen ondersteunen; De populariteit van DBMS'en met meerdere modellen, die nieuwe modellen bieden die de voordelen van verschillende traditionele modellen combineren, is een kwestie van de verdere toekomst.
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. , Alsjeblieft.
Maakt u gebruik van DBMS met meerdere modellen?
-
Wij gebruiken het niet, we slaan alles op in één DBMS en in één model
-
We maken gebruik van de multi-modelmogelijkheden van traditionele DBMS'en
-
We beoefenen meertalige volharding
-
We gebruiken nieuwe multi-model DBMS (Arango, Orient, CosmosDB)
19 gebruikers hebben gestemd. 4 gebruikers onthielden zich van stemming.
Bron: www.habr.com