Modernaj informsistemoj estas sufiĉe kompleksaj. Ne malplej, ilia komplekseco ŝuldiĝas al la komplekseco de la datumoj prilaboritaj en ili. La komplekseco de datumoj ofte kuŝas en la vario de datummodeloj uzataj. Do, ekzemple, kiam datumoj fariĝas "grandaj", unu el la problemaj trajtoj estas ne nur ĝia volumeno ("volumo"), sed ankaŭ ĝia vario ("vario").
Se vi ankoraŭ ne trovas difekton en la rezonado, tiam legu plu.
Enhavo
Poliglota persisto
Ĉi-supra kondukas al la fakto, ke foje eĉ en la kadro de unu sistemo necesas uzi plurajn malsamajn DBMS-ojn por stoki datumojn kaj solvi diversajn problemojn pri prilaborado de ili, ĉiu el kiuj subtenas sian propran datummodelon. Kun la malpeza mano de S-ro Fowler, kelkaj famaj libroj kaj unu el Agile Manifesto, ĉi tiu situacio nomiĝas plurvaria stokado ("poliglota persisto").
Fowler ankaŭ havas la sekvan ekzemplon de organizado de datumstokado en plenefika kaj alt-ŝarĝa aplikaĵo en la kampo de elektronika komerco.
Ĉi tiu ekzemplo, kompreneble, estas iom troigita, sed kelkaj konsideroj favore al elekto de unu aŭ alia DBMS por la responda celo troveblas, ekzemple, .
Estas klare, ke esti servisto en tia zoo ne estas facila.
- La kvanto de kodo kiu elfaras datumstokadon kreskas proporcie al la nombro da DBMSoj uzataj; la kvanto de kodo sinkroniganta datumoj estas bona se ne proporcia al la kvadrato de ĉi tiu nombro.
- Kiel oblo de la nombro da DBMSoj uzitaj, la kostoj de disponigado de entreprenaj karakterizaĵoj (skaleblo, faŭltoleremo, alta havebleco) de ĉiu el la DBMSoj uzitaj pliiĝas.
- Estas neeble certigi la entreprenajn trajtojn de la stokada subsistemo kiel tuto - precipe transakcia.
El la vidpunkto de la zoodirektoro, ĉio aspektas jene:
- Multobla pliiĝo en la kosto de licencoj kaj teknika subteno de la fabrikanto de DBMS.
- Tropersonado kaj pliigitaj templimoj.
- Rektaj financaj perdoj aŭ punoj pro datuma nekongrueco.
Estas signifa pliiĝo en la totalkosto de proprieto (TCO) de la sistemo. Ĉu ekzistas ia maniero eliri la situacion de "multoblaj stokaj opcioj"?
Multi-modelo
La esprimo "plurvaria stokado" ekuziĝis en 2011. Konscio pri la problemoj de la aliro kaj la serĉo de solvo daŭris plurajn jarojn, kaj antaŭ 2015, per la buŝoj de Gartner-analizistoj, la respondo estis formulita:
- De "»:
La estonteco de DBMSoj, iliaj arkitekturoj kaj manieroj uzi ilin estas multmodela.
- De "»:
Gvidantaj funkciaj DBMS-oj ofertos plurajn modelojn - rilatajn kaj ne-rilatajn - kiel parto de ununura platformo.
Ŝajnas, ke ĉi-foje analizistoj de Gartner pravis kun sia prognozo. Se vi iras al la paĝo kun DBMS sur DB-Engines, vi povas vidi tionоLa plej multaj el ĝiaj gvidantoj poziciigas sin specife kiel multi-modelaj DBMSoj. La sama povas esti vidita sur la paĝo kun ajna privata takso.
La suba tabelo montras la DBMS - la gvidantojn en ĉiu el la privataj taksoj, kiuj asertas esti multmodelaj. Por ĉiu DBMS, la originala subtenata modelo (kiu iam estis la nura) kaj kune kun ĝi la modeloj nuntempe subtenataj estas indikitaj. Ankaŭ listigitaj estas DBMS, kiuj poziciigas sin kiel "originale multmodelaj" kaj, laŭ la kreintoj, ne havas ajnan komencan hereditan modelon.
| DBMS | Komenca modelo | Pliaj modeloj |
|---|---|---|
| plejsanktejo | rilataj | Graph, dokumento |
| MSSQL | rilataj | Graph, dokumento |
| PostgreSQL | rilataj | Graph*, dokumento |
| MarkLogic | Dokumentario | Graph, rilata |
| MongoDB | Dokumentario | Ŝlosilvaloro, grafikaĵo* |
| DataStax | Larĝ-kolumno | Dokumentario, grafikaĵo |
| Redis | Ŝlosilvaloro | Dokumentario, grafikaĵo* |
| ArangoDB | - | Graph, dokumento |
| OrientDB | - | Grafiko, dokumento, rilata |
| Azure CosmosDB | - | Grafiko, dokumento, rilata |
Notoj sur la tablo
Asteriskoj en la tabelo markas deklarojn kiuj postulas rezervojn:
- La PostgreSQL DBMS ne subtenas la grafikan datummodelon, sed ĉi tiu produkto subtenas ĝin , kiel ekzemple AgensGraph.
- Rilate al MongoDB, estas pli ĝuste paroli pri la ĉeesto de grafikaj operatoroj en la demanda lingvo (, ) ol pri subtenado de la grafeomodelo, kvankam, kompreneble, ilia enkonduko postulis kelkajn optimumigojn ĉe la fizika stokado-nivelo en la direkto de apogado de la grafeomodelo.
- Rilate al Redis, ni celas la etendon .
Poste, por ĉiu el la klasoj, ni montros kiel subteno por pluraj modeloj estas efektivigita en la DBMS de ĉi tiu klaso. Ni konsideros la rilatajn, dokumentojn kaj grafikajn modelojn kiel la plej gravajn kaj uzos ekzemplojn de specifaj DBMS-oj por montri kiel la "mankantaj" estas efektivigitaj.
Multi-modela DBMS bazita sur la interrilata modelo
La gvidaj DBMSoj nuntempe estas interrilataj; la prognozo de Gartner ne povus esti konsiderita vera se RDBMSoj ne montris movadon en la direkto de multi-modeligado. Kaj ili pruvas. Nun la ideo, ke multmodela DBMS estas kiel svisa tranĉilo, kiu ne povas fari ion bone, povas esti direktita rekte al Larry Ellison.
La aŭtoro tamen preferas la efektivigon de plurmodelado en Microsoft SQL Server, sur kies ekzemplo estos priskribita subteno de RDBMS por dokumento kaj grafikaj modeloj.
Dokumentmodelo en MS SQL Server
Jam estis du bonegaj artikoloj pri Habré pri kiel MS SQL Server efektivigas subtenon por la dokumentmodelo; mi limigos min al mallonga rerakonto kaj komento:
La maniero subteni la dokumentmodelon en MS SQL Server estas sufiĉe tipa por interrilataj DBMSoj: JSON-dokumentoj estas proponitaj esti stokitaj en ordinaraj tekstkampoj. Subteno por la dokumentmodelo estas provizi specialajn funkciigistojn por analizi ĉi tiun JSON:
- por ĉerpi skalarajn atributajn valorojn,
- por ĉerpi subdokumentojn.
La dua argumento de ambaŭ funkciigistoj estas esprimo en JSONPath-simila sintakso.
Abstrakte, ni povas diri, ke dokumentoj konservitaj tiamaniere ne estas "unuaklasaj entoj" en interrilata DBMS, male al opoj. Specife, en MS SQL Server nuntempe ne ekzistas indeksoj sur la kampoj de JSON-dokumentoj, kio malfaciligas kunigi tabelojn uzante la valorojn de ĉi tiuj kampoj kaj eĉ elekti dokumentojn per ĉi tiuj valoroj. Tamen, eblas krei kalkulitan kolumnon por tia kampo kaj indekson sur ĝi.
Aldone, MS SQL Server disponigas la kapablon oportune konstrui JSON-dokumenton el la enhavo de tabeloj uzante la funkciigiston - ebleco, en certa senco, kontraŭa al la antaŭa, konvencia stokado. Estas klare, ke kiom ajn rapida estas RDBMS, ĉi tiu aliro kontraŭdiras la ideologion de dokumentoj DBMS, kiuj esence stokas pretajn respondojn al popularaj demandoj, kaj povas nur solvi problemojn de facileco de disvolviĝo, sed ne rapideco.
Fine, MS SQL Server permesas vin solvi la kontraŭan problemon de dokumenta konstruado: vi povas malkomponi JSON en tabelojn uzante . Se la dokumento ne estas tute plata, vi devos uzi CROSS APPLY.
Grafika modelo en MS SQL Server
Subteno por la grafeo (LPG) modelo ankaŭ estas plene efektivigita en Microsoft SQL Server : Oni proponas uzi specialajn tabelojn por stoki nodojn kaj por stoki grafeajn randojn. Tiaj tabeloj estas kreitaj per esprimoj CREATE TABLE AS NODE и CREATE TABLE AS EDGE laŭe.
Tabeloj de la unua tipo estas similaj al ordinaraj tabeloj por stoki rekordojn, kun la nura ekstera diferenco estas ke la tabelo enhavas sistemkampon. $node_id — unika identigilo de grafeodo ene de la datumbazo.
Simile, tabeloj de la dua tipo havas sistemajn kampojn $from_id и $to_id, enskriboj en tiaj tabeloj klare difinas la ligojn inter nodoj. Aparta tablo estas uzata por konservi rilatojn de ĉiu tipo.
Ni ilustru ĉi tion per ekzemplo. Lasu la grafikajn datumojn havi aranĝon kiel tiu montrita en la figuro. Tiam por krei la respondan strukturon en la datumbazo, vi devas ruli la sekvajn DDL-demandojn:
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);La ĉefa specifeco de tiaj tabeloj estas, ke en demandoj kontraŭ ili eblas uzi grafikajn ŝablonojn kun Cypher-simila sintakso (tamen, "*"ktp. estas ankoraŭ ne subtenataj). Surbaze de spektaklomezuradoj, oni povas ankaŭ supozi ke la maniero kiel datumoj estas stokitaj en ĉi tiuj tabeloj estas diferenca de la maniero kiel datumoj estas stokitaj en regulaj tabeloj kaj estas optimumigita por efektivigi tiajn grafikdemandojn.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Krome, estas sufiĉe malfacile ne uzi ĉi tiujn grafeajn ŝablonojn kiam oni laboras kun tiaj tabeloj, ĉar en ordinaraj SQL-demandoj por solvi similajn problemojn, estos necese fari pliajn klopodojn por akiri sistemajn "grafikajn" nodidentigilojn ($node_id, $from_id, $to_id; Pro la sama kialo, demandoj por enmeti datumojn ne estas montritaj ĉi tie ĉar ili estas nenecese ĝenaj).
Por resumi la priskribon de la efektivigoj de la dokumento- kaj grafikaj modeloj en MS SQL Server, mi rimarkus, ke tiaj efektivigoj de unu modelo super alia ne ŝajnas sukcesaj, ĉefe el la vidpunkto de lingvodezajno. Necesas etendi unu lingvon kun alia, la lingvoj ne estas tute "ortaj", la reguloj de kongruo povas esti sufiĉe bizaraj.
Plurmodela DBMS bazita sur la dokumentmodelo
En ĉi tiu sekcio, mi ŝatus ilustri la efektivigon de multmodelo en dokumentoj DBMS uzante la ekzemplon de la ne plej populara el ili, MongoDB (kiel estis dirite, ĝi nur havas kondiĉajn grafikajn operatorojn. $lookup и $graphLookup, ne laborante pri fragmentaj kolektoj), sed uzante la ekzemplon de pli matura kaj "entreprena" DBMS .
Do, lasu la kolekton enhavi aron da XML-dokumentoj de la sekva tipo (MarkLogic ankaŭ permesas vin stoki JSON-dokumentojn):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Rilata modelo en MarkLogic
Rilata vido de kolekto de dokumentoj povas esti kreita uzante (enhavo de elementoj value en la malsupra ekzemplo povas ekzisti arbitra XPath):
<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>Vi povas trakti la kreitan vidon per SQL-demando (ekzemple per ODBC):
SELECT name, surname FROM Person WHERE name="John"Bedaŭrinde, la interrilata vido kreita de la montra ŝablono estas nurlegebla. Kiam vi prilaboras peton por ĝi, MarkLogic provos uzi . Antaŭe, MarkLogic havis limigitajn interrilatajn vidojn, tute kaj skribeblaj, sed nun ili estas konsiderataj malrekomenditaj.
Grafikmodelo en MarkLogic
Kun subteno por la grafeo (RDF) modelo, ĉio estas proksimume la sama. Denove kun la helpo vi povas krei RDF-reprezenton de kolekto de dokumentoj el la supra ekzemplo:
<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>Vi povas trakti la rezultan RDF-grafikon per SPARQL-demando:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Male al la interrilata, MarkLogic apogas la grafeomodelon laŭ du aliaj manieroj:
- DBMS povas esti plenrajta aparta stokado de RDF-datumoj (tripletoj en ĝi estos nomitaj kontraste al tiuj supre priskribitaj ).
- RDF en speciala seriigo povas simple esti enigita en XML aŭ JSON dokumentojn (kaj triopoj tiam estos nomitaj ). Ĉi tio verŝajne estas alternativo al mekanismoj
idrefkaj aliaj.
Bona ideo pri kiel aferoj "vere" funkcias en MarkLogic estas donita de , en ĉi tiu senco, ĝi estas malaltnivela, kvankam ĝia celo estas prefere la malo - provi abstrakti de la datummodelo uzata, certigi konsekvencan laboron kun datumoj en malsamaj modeloj, transakco ktp.
Plurmodela DBMS "sen ĉefa modelo"
Ekzistas ankaŭ DBMSoj sur la merkato, kiuj poziciigas sin kiel komence multmodelaj, sen iu ajn heredita ĉefa modelo. Ĉi tiuj inkluzivas , (ekde 2018 la evoluentrepreno apartenas al SAP) kaj (servo kiel parto de la nuba platformo Microsoft Azure).
Fakte, ekzistas "kernaj" modeloj en ArangoDB kaj OrientDB. En ambaŭ kazoj, ĉi tiuj estas siaj propraj datummodeloj, kiuj estas ĝeneraligoj de la dokumento. La ĝeneraligoj estas ĉefe faciligi la kapablon fari demandojn de grafeo kaj interrilata naturo.
Ĉi tiuj modeloj estas la nuraj disponeblaj por uzo en la specifita DBMS; iliaj propraj demandlingvoj estas dezajnitaj por labori kun ili. Kompreneble, tiaj modeloj kaj DBMS-oj estas promesplenaj, sed la manko de kongruo kun normaj modeloj kaj lingvoj malebligas uzi ĉi tiujn DBMS-ojn en heredaj sistemoj - por anstataŭigi la DBMS-ojn jam uzatajn tie.
Jam estis mirinda artikolo pri ArangoDB kaj OrientDB pri Habré: .
ArangoDB
ArangoDB postulas subtenon por grafika datummodelo.
La nodoj de grafeo en ArangoDB estas ordinaraj dokumentoj, kaj la randoj estas dokumentoj de speciala tipo, kiuj, kune kun regulaj sistemaj kampoj, havas (_key, _id, _rev) sistemaj kampoj _from и _to. Dokumentoj en dokumentoj DBMSoj estas tradicie kombinitaj en kolektojn. Kolektoj de dokumentoj reprezentantaj randoj estas nomitaj randkolektoj en ArangoDB. Cetere, randkolektaj dokumentoj ankaŭ estas dokumentoj, do randoj en ArangoDB ankaŭ povas funkcii kiel nodoj.
Fontaj datumoj
Ni havu kolekton persons, kies dokumentoj aspektas jene:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Estu ankaŭ kolekto cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Poste la kolekto likes povus aspekti tiel:
[
{
"_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
}
]Demandoj kaj rezultoj
Grafik-stila demando en la AQL-lingvo uzata en ArangoDB, resendante en homlegebla formo informojn pri kiu ŝatas kiun kafejon, aspektas jene:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }En rilata stilo, kie ni "komputas" rilatojn prefere ol stokas ilin, ĉi tiu demando povas esti reverkita tiel (cetere, sen la kolekto likes povus malhavi):
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 }La rezulto en ambaŭ kazoj estos la sama:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Pli da demandoj kaj rezultoj
Se la rezultformato supre ŝajnas esti pli tipa por interrilata DBMS ol por dokumento DBMS, vi povas provi ĉi tiun demandon (aŭ vi povas uzi ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}La rezulto aspektos jene:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
La bazo por efektivigi grafikan modelon aldone al dokumentmodelo en OrientDB estas dokumentkampoj, krom pli-malpli normaj skalaj valoroj, ankaŭ havas valorojn de tipoj kiel ekzemple LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. La valoroj de ĉi tiuj tipoj estas ligiloj aŭ kolektoj de ligiloj al dokumentoj.
La dokumentidentigilo asignita de la sistemo havas "fizikan signifon", indikante la pozicion de la rekordo en la datumbazo, kaj aspektas kiel ĉi tio: @rid : #3:16. Tiel, la valoroj de referencaj propraĵoj estas vere montriloj (kiel en la grafika modelo) prefere ol elektokondiĉoj (kiel en la interrilata modelo).
Kiel ArangoDB, randoj en OrientDB estas reprezentitaj kiel apartaj dokumentoj (kvankam se rando ne havas siajn proprajn trajtojn, ĝi povas esti farita , kaj ĝi ne respondas al aparta dokumento).
Fontaj datumoj
En formato proksima al OrientDB-datumbazo, la datumoj de la antaŭa ekzemplo por ArangoDB aspektus kiel ĉi tio:
[
{
"@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"
}
]Kiel ni povas vidi, verticoj ankaŭ stokas informojn pri enirantaj kaj elirantaj randoj. Ĉe La Dokumenta API devas mem kontroli referencan integrecon, kaj la Graph-API prenas ĉi tiun laboron. Sed ni vidu kiel aspektas aliro al OrientDB en "puraj" konsultlingvoj, kiuj ne estas integritaj al programlingvoj.
Demandoj kaj rezultoj
Demando simila en celo al la demando de la ekzemplo por ArangoDB en OrientDB aspektas jene:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameLa rezulto estos akirita en la sekva formo:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Se la rezultformato denove ŝajnas tro "rilata", vi devas forigi la linion kun :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]La demandlingvo de OrientDB povas esti priskribita kiel SQL kun Gremlin-similaj enigaĵoj. En versio 2.2 aperis ĉifr-simila petoformularo, :
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_nameLa rezultoformato estos la sama kiel en la antaŭa peto. Pensu pri tio, kio devas esti forigita por fari ĝin pli "rilata", kiel en la unua demando.
Azure CosmosDB
En pli malgranda mezuro, kio estis dirita supre pri ArangoDB kaj OrientDB validas por Azure CosmosDB. CosmosDB provizas la jenajn datumajn alirajn APIojn: SQL, MongoDB, Gremlin kaj Cassandra.
SQL API kaj MongoDB API estas uzataj por aliri datumojn en la dokumentmodelo. Gremlin API kaj Cassandra API - por alirado de datumoj en grafeo kaj kolumnoformatoj, respektive. Datenoj en ĉiuj modeloj estas konservitaj en la interna modelformato de CosmosDB: ("atomo-rekordo-sekvenco"), kiu ankaŭ estas proksima al la dokumento.
Sed la datuma modelo elektita de la uzanto kaj la API uzata estas fiksitaj en la momento de kreado de konto en la servo. Ne eblas aliri datumojn ŝarĝitajn en unu modelo en la formato de alia modelo, kiel ilustrite per io kiel ĉi tio:
Tiel, plurmodelo en Azure CosmosDB hodiaŭ estas nur la kapablo uzi plurajn datumbazojn subtenantajn malsamajn modelojn de unu fabrikanto, kio ne solvas ĉiujn problemojn de plurvaria stokado.
Plurmodela DBMS bazita sur grafika modelo?
Rimarkinda estas la fakto, ke ekzistas neniuj plurmodelaj DBMS-oj sur la merkato tamen kiuj estas bazitaj sur grafika modelo (krom plurmodela subteno por samtempe du grafeaj modeloj: RDF kaj LPG; vidu ĉi tion en ). La plej grandaj malfacilaĵoj estas kaŭzitaj de efektivigo de dokumentmodelo aldone al grafika modelo, prefere ol interrilata.
La demando pri kiel efektivigi interrilatan modelon super la grafika modelo estis pripensita eĉ dum la formado de ĉi-lasta. Kiel ekzemple :
Estas nenio eneca en la grafika aliro, kiu malhelpas krei tavolon (ekz., per taŭga indeksado) sur grafea datumbazo, kiu ebligas interrilatan vidon kun (1) reakiro de opoj de la kutimaj ŝlosilaj valorparoj kaj (2) grupigo de opoj laŭ rilata tipo.
Kiam vi efektivigas dokumentmodelon super grafika modelo, vi devas memori, ekzemple, la jenon:
- Elementoj de JSON-tabelo estas konsiderataj ordigitaj, sed tiuj elirantaj el la vertico de rando de la grafeo ne estas;
- Datumoj en la dokumentmodelo estas kutime malnormaligitaj; vi ankoraŭ ne volas konservi plurajn kopiojn de la sama enigita dokumento, kaj subdokumentoj kutime ne havas identigilojn;
- Aliflanke, la ideologio de dokumentoj DBMS estas ke dokumentoj estas pretaj "agregaĵoj" kiuj ne bezonas esti konstruitaj denove ĉiufoje. Estas postulate provizi la grafikan modelon per la kapablo rapide akiri subgrafeon respondan al la finita dokumento.
Iom da reklamado
La verkinto de la artikolo rilatas al la evoluo de la NitrosBase DBMS, kies interna modelo estas grafeo, kaj la eksteraj modeloj - interrilataj kaj dokumento - estas ĝiaj reprezentoj. Ĉiuj modeloj estas egalaj: preskaŭ ĉiuj datumoj haveblas en iu ajn el ili uzante konsultlingvon kiu estas natura al ĝi. Krome, en ajna vido, la datumoj povas esti ŝanĝitaj. Ŝanĝoj speguliĝos en la interna modelo kaj, sekve, en aliaj vidpunktoj.
Mi espereble priskribos kiel aspektas modelo-kongruo en NitrosBase en unu el la sekvaj artikoloj.
konkludo
Mi esperas, ke la ĝeneralaj konturoj de tio, kion oni nomas plurmodelado, fariĝis pli-malpli klaraj por la leganto. Plurmodelaj DBMS-oj estas sufiĉe malsamaj, kaj "multi-modela subteno" povas aspekti malsama. Por kompreni, kion oni nomas "multmodelo" en ĉiu specifa kazo, estas utile respondi la jenajn demandojn:
- Ĉu ni parolas pri subteno de tradiciaj modeloj aŭ ian "hibridan" modelon?
- Ĉu la modeloj estas "egalaj", aŭ ĉu unu el ili estas la temo de la aliaj?
- Ĉu la modeloj estas "indiferentaj" unu al la alia? Ĉu datumoj skribitaj en unu modelo povas legi en alia aŭ eĉ anstataŭi?
Mi pensas, ke la demando pri la graveco de plurmodelaj DBMS jam povas esti pozitive respondita, sed la interesa demando estas, kiuj specoj de ili estos pli postulataj en proksima estonteco. Ŝajnas, ke multmodelaj DBMS kiuj subtenas tradiciajn modelojn, ĉefe interrilatajn, estos pli postulataj; La populareco de multmodelaj DBMSoj, proponantaj novajn modelojn, kiuj kombinas la avantaĝojn de diversaj tradiciaj, estas afero de la pli malproksima estonteco.
Nur registritaj uzantoj povas partopreni la enketon. , bonvolu.
Ĉu vi uzas multmodelan DBMS?
Ni ne uzas ĝin, ni stokas ĉion en unu DBMS kaj en unu modelo
Ni uzas multmodelaj kapabloj de tradiciaj DBMSoj
Ni praktikas poliglotan persiston
Ni uzas novan plurmodelan DBMS (Arango, Orient, CosmosDB)
Voĉdonis 19 uzantoj. 4 uzantoj sindetenis.
fonto: www.habr.com
