Moderne inligtingstelsels is redelik kompleks. Die kompleksiteit daarvan is nie die minste nie te danke aan die kompleksiteit van die data wat daarin verwerk word. Die kompleksiteit van data lê dikwels in die verskeidenheid datamodelle wat gebruik word. So, byvoorbeeld, wanneer data "groot" word, is een van die problematiese kenmerke nie net die volume ("volume") nie, maar ook die verskeidenheid ("verskeidenheid").
As jy nog nie 'n fout in die redenasie vind nie, lees dan verder.
inhoud
Poliglot volharding
Bogenoemde lei tot die feit dat dit soms selfs binne die raamwerk van een stelsel nodig is om verskeie verskillende DBBS'e te gebruik om data te stoor en verskeie probleme met die verwerking daarvan op te los, wat elkeen sy eie datamodel ondersteun. Met die ligte hand van M. Fowler, 'n aantal bekende boeke en een van Agile Manifes, word hierdie situasie genoem multi-variant berging ("poliglot volharding").
Fowler het ook die volgende voorbeeld van die organisering van databerging in 'n volledige en hoë-lading toepassing op die gebied van e-handel.
Hierdie voorbeeld is natuurlik ietwat oordrewe, maar 'n paar oorwegings ten gunste van die keuse van een of ander DBBS vir die ooreenstemmende doel kan gevind word, bv. .
Dit is duidelik dat dit nie maklik is om 'n bediende in so 'n dieretuin te wees nie.
- Die hoeveelheid kode wat databerging uitvoer, groei in verhouding tot die aantal DBBS'e wat gebruik word; die hoeveelheid kode-sinchroniserende data is goed indien nie eweredig aan die kwadraat van hierdie getal nie.
- As 'n veelvoud van die aantal DBBS'e wat gebruik word, verhoog die koste van die verskaffing van ondernemingskenmerke (skaalbaarheid, fouttoleransie, hoë beskikbaarheid) van elk van die DBBS'e wat gebruik word.
- Dit is onmoontlik om die ondernemingseienskappe van die bergingsubstelsel as geheel te verseker - veral transaksionaliteit.
Uit die oogpunt van die dieretuindirekteur lyk alles so:
- 'n Veelvuldige toename in die koste van lisensies en tegniese ondersteuning van die DBMS-vervaardiger.
- Oorbemaning en verhoogde spertye.
- Direkte finansiële verliese of boetes as gevolg van data-inkonsekwentheid.
Daar is 'n aansienlike toename in die stelsel se totale koste van eienaarskap (TCO). Is daar enige uitweg uit die situasie van "veelvuldige bergingsopsies"?
Multi-model
Die term "multivariaatberging" het in 2011 in gebruik gekom. Bewustheid van die probleme van die benadering en die soeke na 'n oplossing het etlike jare geneem, en teen 2015, deur die mond van Gartner-ontleders, is die antwoord geformuleer:
- Van "'
Die toekoms van DBBS'e, hul argitekture en maniere om dit te gebruik is multi-model.
- Van "'
Toonaangewende operasionele DBBS'e sal verskeie modelle bied—relasioneel en nie-relasioneel—as deel van 'n enkele platform.
Dit blyk dat Gartner-ontleders hierdie keer reg was met hul voorspelling. As jy na die bladsy gaan met DBMS op DB-Engines, jy kan dit sienоDie meeste van sy leiers posisioneer hulself spesifiek as multi-model DBBS'e. Dieselfde kan gesien word op die bladsy met enige private gradering.
Die tabel hieronder toon die DBBS - die leiers in elk van die private graderings, wat daarop aanspraak maak dat dit multi-model is. Vir elke DBBS word die oorspronklike ondersteunde model (wat eens die enigste was) en daarmee saam die modelle wat tans ondersteun word aangedui. Ook gelys is DBBS'e wat hulself as "oorspronklik multi-model" posisioneer en, volgens die skeppers, geen aanvanklike geërfde model het nie.
| DBMS | Aanvanklike model | Bykomende modelle |
|---|---|---|
| Oracle | relasionele | Grafiek, dokument |
| MS SQL | relasionele | Grafiek, dokument |
| PostgreSQL | relasionele | Grafiek*, dokument |
| MarkLogic | Dokumentêr | Grafiek, relasioneel |
| MongoDB | Dokumentêr | Sleutelwaarde, grafiek* |
| DataStax | Wye-kolom | Dokumentêr, grafiek |
| Redis | Sleutel-waarde | Dokumentêr, grafiek* |
| ArangoDB | - | Grafiek, dokument |
| OrientDB | - | Grafiek, dokument, relasioneel |
| Azure CosmosDB | - | Grafiek, dokument, relasioneel |
Notas op die tafel
Sterretjies in die tabel merk stellings wat besprekings vereis:
- Die PostgreSQL DBMS ondersteun nie die grafiekdatamodel nie, maar hierdie produk ondersteun dit wel , soos AgensGraph.
- Met betrekking tot MongoDB is dit meer korrek om te praat oor die teenwoordigheid van grafiekoperateurs in die navraagtaal (, ) as om die grafiekmodel te ondersteun, hoewel die bekendstelling daarvan natuurlik 'n paar optimaliserings op die fisiese bergingsvlak vereis het in die rigting om die grafiekmodel te ondersteun.
- Met betrekking tot Redis, bedoel ons die uitbreiding .
Vervolgens sal ons vir elk van die klasse wys hoe ondersteuning vir verskeie modelle in die DBBS vanuit hierdie klas geïmplementeer word. Ons sal die relasionele, dokument- en grafiekmodelle as die belangrikste beskou en voorbeelde van spesifieke DBBS'e gebruik om te wys hoe die "vermiste" geïmplementeer word.
Multi-model DBBS gebaseer op die relasionele model
Die voorste DBBS'e is tans relasioneel; Gartner se voorspelling kon nie as waar beskou word as RDBBS'e nie beweging in die rigting van multi-modellering toon nie. En hulle demonstreer. Nou kan die idee dat 'n multi-model DBMS soos 'n Switserse mes is, wat niks goed kan doen nie, direk aan Larry Ellison gerig word.
Die skrywer verkies egter die implementering van multi-modellering in Microsoft SQL Server, op die voorbeeld waarvan RDBMS-ondersteuning vir dokument- en grafiekmodelle beskryf sal word.
Dokumentmodel in MS SQL Server
Daar was reeds twee uitstekende artikels oor Habré oor hoe MS SQL Server ondersteuning vir die dokumentmodel implementeer; Ek sal myself beperk tot 'n kort oorvertelling en kommentaar:
Die manier om die dokumentmodel in MS SQL Server te ondersteun, is nogal tipies vir relasionele DBBS'e: JSON-dokumente word voorgestel om in gewone teksvelde gestoor te word. Ondersteuning vir die dokumentmodel is om spesiale operateurs te voorsien om hierdie JSON te ontleed:
- om skalêre kenmerkwaardes te onttrek,
- sub-dokumente te onttrek.
Die tweede argument van beide operateurs is 'n uitdrukking in JSONPath-agtige sintaksis.
Abstrak kan ons sê dat dokumente wat op hierdie manier gestoor word nie "eersteklas entiteite" in 'n relasionele DBBS is nie, anders as tuples. Spesifiek, in MS SQL Server is daar tans geen indekse op die velde van JSON-dokumente nie, wat dit moeilik maak om tabelle aan te sluit deur die waardes van hierdie velde te gebruik en selfs dokumente te kies wat hierdie waardes gebruik. Dit is egter moontlik om 'n berekende kolom vir so 'n veld en 'n indeks daarop te skep.
Boonop bied MS SQL Server die vermoë om 'n JSON-dokument gerieflik te bou uit die inhoud van tabelle met behulp van die operateur - 'n moontlikheid, in 'n sekere sin, teenoor die vorige een, konvensionele berging. Dit is duidelik dat dit nie saak maak hoe vinnig 'n RDBBS is nie, hierdie benadering weerspreek die ideologie van dokument DBBS'e, wat in wese klaargemaakte antwoorde op gewilde navrae stoor, en slegs probleme van gemak van ontwikkeling kan oplos, maar nie spoed nie.
Ten slotte laat MS SQL Server jou toe om die teenoorgestelde probleem van dokumentkonstruksie op te los: jy kan JSON in tabelle ontbind met . As die dokument nie heeltemal plat is nie, sal jy dit moet gebruik CROSS APPLY.
Grafiekmodel in MS SQL Server
Ondersteuning vir die grafiek (LPG) model is ook ten volle geïmplementeer in Microsoft SQL Server : Daar word voorgestel om spesiale tabelle te gebruik om nodusse te stoor en om grafiekrande te stoor. Sulke tabelle word geskep deur uitdrukkings te gebruik CREATE TABLE AS NODE и CREATE TABLE AS EDGE onderskeidelik.
Tabelle van die eerste tipe is soortgelyk aan gewone tabelle vir die stoor van rekords, met die enigste eksterne verskil dat die tabel 'n stelselveld bevat $node_id - unieke identifiseerder van 'n grafieknodus binne die databasis.
Net so het tabelle van die tweede tipe stelselvelde $from_id и $to_id, inskrywings in sulke tabelle definieer duidelik die verbindings tussen nodusse. 'n Aparte tabel word gebruik om verhoudings van elke tipe te stoor.
Kom ons illustreer dit met 'n voorbeeld. Laat die grafiekdata 'n uitleg hê soos die een wat in die figuur getoon word. Om dan die ooreenstemmende struktuur in die databasis te skep, moet jy die volgende DDL-navrae uitvoer:
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 belangrikste spesifisiteit van sulke tabelle is dat dit in navrae daarteen moontlik is om grafiekpatrone met Cypher-agtige sintaksis te gebruik (maar "*"ensovoorts word nog nie ondersteun nie). Gebaseer op prestasiemetings, kan daar ook aanvaar word dat die manier waarop data in hierdie tabelle gestoor word, verskil van die manier waarop data in gewone tabelle gestoor word en geoptimaliseer is vir die uitvoering van sulke grafieknavrae.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Boonop is dit nogal moeilik om nie hierdie grafiekpatrone te gebruik wanneer u met sulke tabelle werk nie, aangesien dit in gewone SQL-navrae om soortgelyke probleme op te los nodig sal wees om bykomende pogings aan te wend om stelsel-“grafiek”-nodusidentifiseerders ($node_id, $from_id, $to_id; Om dieselfde rede word navrae vir die invoeging van data nie hier gewys nie, aangesien dit onnodig omslagtig is).
Om die beskrywing van die implementerings van die dokument- en grafiekmodelle in MS SQL Server op te som, wil ek daarop let dat sulke implementerings van een model bo-op 'n ander nie suksesvol lyk nie, hoofsaaklik vanuit die oogpunt van taalontwerp. Dit is nodig om een taal met 'n ander uit te brei, die tale is nie heeltemal "ortogonaal nie", die versoenbaarheidsreëls kan nogal bisar wees.
Multi-model DBBS gebaseer op die dokument model
In hierdie afdeling wil ek graag die implementering van multi-model in dokument DBBS'e illustreer deur die voorbeeld van die nie gewildste van hulle, MongoDB (soos gesê, dit het slegs voorwaardelike grafiekoperateurs) $lookup и $graphLookup, werk nie aan verskeurde versamelings nie), maar gebruik die voorbeeld van 'n meer volwasse en "onderneming" DBBS .
Laat die versameling dus 'n stel XML-dokumente van die volgende tipe bevat (MarkLogic laat jou ook toe om JSON-dokumente te stoor):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Relasionele model in MarkLogic
'n Relasionele aansig van 'n versameling dokumente kan geskep word deur gebruik te maak van (inhoud van elemente value in die voorbeeld hieronder kan daar 'n arbitrêre XPath wees):
<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 kan die geskepte aansig aanspreek met 'n SQL-navraag (byvoorbeeld via ODBC):
SELECT name, surname FROM Person WHERE name="John"Ongelukkig is die relasionele aansig wat deur die vertoonsjabloon geskep is, leesalleen. Wanneer 'n versoek daarvoor verwerk word, sal MarkLogic probeer gebruik . Voorheen het MarkLogic heeltemal beperkte relasionele sienings gehad en skryfbaar, maar nou word hulle as afgekeur beskou.
Grafiekmodel in MarkLogic
Met ondersteuning vir die grafiek (RDF) model, is alles omtrent dieselfde. Weereens met die hulp jy kan 'n RDF-voorstelling van 'n versameling dokumente uit die voorbeeld hierbo skep:
<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 kan die resulterende RDF-grafiek aanspreek met 'n SPARQL-navraag:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Anders as die relasionele een, ondersteun MarkLogic die grafiekmodel op twee ander maniere:
- 'n DBBS kan 'n volwaardige afsonderlike berging van RDF-data wees (drieling daarin sal genoem word in teenstelling met dié hierbo beskryf ).
- RDF in spesiale serialisering kan eenvoudig in XML- of JSON-dokumente ingevoeg word (en drieling sal dan genoem word ). Dit is waarskynlik 'n alternatief vir meganismes
idrefens.
'n Goeie idee van hoe dinge "regtig" werk in MarkLogic word gegee deur , in hierdie sin is dit lae-vlak, alhoewel die doel daarvan eerder die teenoorgestelde is - om te probeer abstraheer van die datamodel wat gebruik word, om konsekwente werk met data in verskillende modelle, transaksionaliteit, ens.
Multi-model DBBS "sonder 'n hoofmodel"
Daar is ook DBBS'e op die mark wat hulself as aanvanklik multi-model posisioneer, sonder enige oorgeërfde hoofmodel. Dit sluit in , (sedert 2018 behoort die ontwikkelingsmaatskappy aan SAP) en (diens as deel van die Microsoft Azure-wolkplatform).
Trouens, daar is "kern" modelle in ArangoDB en OrientDB. In beide gevalle is dit hul eie datamodelle, wat veralgemenings van die dokument een is. Die veralgemenings is hoofsaaklik om die vermoë te fasiliteer om navrae van 'n grafiek en relasionele aard uit te voer.
Hierdie modelle is die enigste wat beskikbaar is vir gebruik in die gespesifiseerde DBBS; hul eie navraagtale is ontwerp om daarmee te werk. Natuurlik is sulke modelle en DBBS'e belowend, maar die gebrek aan versoenbaarheid met standaardmodelle en tale maak dit onmoontlik om hierdie DBBS'e in verouderde stelsels te gebruik - om die DBBS'e wat reeds daar gebruik word, te vervang.
Daar was reeds 'n wonderlike artikel oor ArangoDB en OrientDB op Habré: .
ArangoDB
ArangoDB eis ondersteuning vir 'n grafiekdatamodel.
Die nodes van 'n grafiek in ArangoDB is gewone dokumente, en die rande is dokumente van 'n spesiale tipe wat saam met gereelde stelselvelde (_key, _id, _rev) stelsel velde _from и _to. Dokumente in dokument-DBBS'e word tradisioneel in versamelings gekombineer. Versamelings van dokumente wat rande verteenwoordig, word randversamelings in ArangoDB genoem. Terloops, randversamelingsdokumente is ook dokumente, so rande in ArangoDB kan ook as nodusse optree.
Aanvanklike gegewens
Laat ons 'n versameling hê persons, wie se dokumente so lyk:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Laat daar ook 'n kollekte wees cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Dan die versameling likes kan so lyk:
[
{
"_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
}
]Navrae en resultate
'n Grafiekstyl-navraag in die AQL-taal wat in ArangoDB gebruik word, wat in mens-leesbare vorm inligting gee oor wie van watter kafee hou, lyk soos volg:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }In 'n relasionele styl, waar ons verhoudings "reken" eerder as om dit te stoor, kan hierdie navraag so herskryf word (terloops, sonder die versameling likes kan sonder):
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 }Die resultaat in beide gevalle sal dieselfde wees:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Meer navrae en resultate
As die resultaatformaat hierbo meer tipies is vir 'n relasionele DBBS as vir 'n dokument DBBS, kan jy hierdie navraag probeer (of jy kan gebruik ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Die resultaat sal so lyk:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
Die basis vir die implementering van 'n grafiekmodel bo-op 'n dokumentmodel in OrientDB is dokumentvelde, benewens min of meer standaard skalaarwaardes, het ook waardes van tipes soos LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Die waardes van hierdie tipe is skakels of versamelings van skakels na dokumente.
Die dokument-identifiseerder wat deur die stelsel toegeken word, het 'n "fisiese betekenis", wat die posisie van die rekord in die databasis aandui, en lyk iets soos volg: @rid : #3:16. Dus, die waardes van verwysingseienskappe is regtig wysers (soos in die grafiekmodel) eerder as seleksietoestande (soos in die relasionele model).
Soos ArangoDB, word rande in OrientDB as aparte dokumente voorgestel (alhoewel as 'n rand nie sy eie eienskappe het nie, kan dit gemaak word , en dit sal nie ooreenstem met 'n aparte dokument nie).
Aanvanklike gegewens
In 'n formaat naby aan OrientDB databasis, sal die data van die vorige voorbeeld vir ArangoDB iets soos volg lyk:
[
{
"@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"
}
]Soos ons kan sien, stoor hoekpunte ook inligting oor inkomende en uitgaande rande. By Die Document API moet self verwysingsintegriteit monitor, en die Graph API neem hierdie werk aan. Maar kom ons kyk hoe toegang tot OrientDB lyk in "suiwer" navraagtale wat nie in programmeertale geïntegreer is nie.
Navrae en resultate
'n Navraag soortgelyk in doel as die navraag uit die voorbeeld vir ArangoDB in OrientDB lyk soos volg:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameDie resultaat sal in die volgende vorm verkry word:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]As die resultaatformaat weer te "relasioneel" lyk, moet jy die lyn met verwyder :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]OrientDB se navraagtaal kan beskryf word as SQL met Gremlin-agtige insetsels. In weergawe 2.2 het 'n Cypher-agtige versoekvorm verskyn, :
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_nameDie resultaatformaat sal dieselfde wees as in die vorige versoek. Dink aan wat verwyder moet word om dit meer "relasioneel" te maak, soos in die heel eerste navraag.
Azure CosmosDB
In 'n mindere mate is wat hierbo gesê is oor ArangoDB en OrientDB van toepassing op Azure CosmosDB. CosmosDB bied die volgende datatoegang-API's: SQL, MongoDB, Gremlin en Cassandra.
SQL API en MongoDB API word gebruik om toegang tot data in die dokumentmodel te verkry. Gremlin API en Cassandra API - vir toegang tot data in onderskeidelik grafiek- en kolomformate. Data in alle modelle word gestoor in die CosmosDB interne model formaat: ("atoom-rekord-volgorde"), wat ook naby die dokument een is.
Maar die datamodel wat deur die gebruiker gekies is en die API wat gebruik word, is vasgestel ten tyde van die skep van 'n rekening in die diens. Dit is nie moontlik om toegang te verkry tot data wat in een model gelaai is in 'n ander model se formaat nie, soos geïllustreer deur iets soos hierdie:
Dus, multi-model in Azure CosmosDB vandag is slegs die vermoë om verskeie databasisse te gebruik wat verskillende modelle van een vervaardiger ondersteun, wat nie al die probleme van multi-variant berging oplos nie.
Multi-model DBBS gebaseer op 'n grafiek model?
Opmerklik is die feit dat daar nog geen multi-model DBBS'e op die mark is wat op 'n grafiekmodel gebaseer is nie (behalwe vir multi-model ondersteuning vir gelyktydig twee grafiekmodelle: RDF en LPG; sien dit in ). Die grootste probleme word veroorsaak deur die implementering van 'n dokumentmodel bo-op 'n grafiekmodel, eerder as 'n relasionele een.
Die vraag hoe om 'n relasionele model bo-op die grafiekmodel te implementeer, is selfs tydens die vorming van laasgenoemde oorweeg. Hoe byvoorbeeld :
Daar is niks inherent aan die grafiekbenadering wat die skep van 'n laag (bv. deur geskikte indeksering) op 'n grafiekdatabasis verhoed wat 'n relasionele aansig moontlik maak met (1) herwinning van tupels uit die gewone sleutelwaardepare en (2) groepering van tupels volgens tipe verhouding.
Wanneer u 'n dokumentmodel bo-op 'n grafiekmodel implementeer, moet u byvoorbeeld die volgende in gedagte hou:
- Elemente van 'n JSON-skikking word as geordende beskou, maar dié wat uit die hoekpunt van 'n rand van die grafiek kom, is nie;
- Data in die dokumentmodel is gewoonlik gedenormaliseer; jy wil steeds nie verskeie kopieë van dieselfde ingebedde dokument stoor nie, en subdokumente het gewoonlik nie identifiseerders nie;
- Aan die ander kant is die ideologie van dokument-DBBS'e dat dokumente klaargemaakte "aggregate" is wat nie elke keer nuut gebou hoef te word nie. Dit word vereis om die grafiekmodel te voorsien van die vermoë om vinnig 'n subgrafiek te verkry wat ooreenstem met die voltooide dokument.
Bietjie advertensie
Die skrywer van die artikel hou verband met die ontwikkeling van die NitrosBase DBBS, waarvan die interne model grafiek is, en die eksterne modelle - relasioneel en dokument - is die voorstellings daarvan. Alle modelle is gelyk: byna enige data is beskikbaar in enige van hulle deur gebruik te maak van 'n navraagtaal wat natuurlik daarvoor is. Boonop kan die data in enige aansig verander word. Veranderinge sal weerspieël word in die interne model en, dienooreenkomstig, in ander sienings.
Ek sal hopelik in een van die volgende artikels beskryf hoe modelpassing in NitrosBase lyk.
Gevolgtrekking
Ek hoop dat die algemene buitelyne van wat genoem word multi-modellering vir die leser min of meer duidelik geword het. Multi-model DBBS'e verskil redelik, en "multi-model ondersteuning" kan anders lyk. Om te verstaan wat in elke spesifieke geval "multi-model" genoem word, is dit nuttig om die volgende vrae te beantwoord:
- Praat ons van die ondersteuning van tradisionele modelle of 'n soort "baster" model?
- Is die modelle “gelyk”, of is een van hulle die onderwerp van die ander?
- Is die modelle “onverskillig” teenoor mekaar? Kan data wat in een model geskryf is in 'n ander gelees word of selfs oorskryf word?
Ek dink dat die vraag oor die relevansie van multi-model DBBS reeds positief beantwoord kan word, maar die interessante vraag is watter tipes daarvan in die nabye toekoms meer in aanvraag sal wees. Dit blyk dat multi-model DBBS'e wat tradisionele modelle ondersteun, hoofsaaklik relasioneel, in groter aanvraag sal wees; Die gewildheid van multi-model DBBS'e, wat nuwe modelle bied wat die voordele van verskeie tradisionele kombineer, is 'n kwessie van die meer verre toekoms.
Slegs geregistreerde gebruikers kan aan die opname deelneem. , asseblief.
Gebruik jy multi-model DBMS?
-
Ons gebruik dit nie, ons stoor alles in een DBBS en in een model
-
Ons gebruik multi-model vermoëns van tradisionele DBBSs
-
Ons oefen poliglot volharding
-
Ons gebruik nuwe multi-model DBMS (Arango, Orient, CosmosDB)
19 gebruikers het gestem. 4 gebruikers het buite stemming gebly.
Bron: will.com