Kaasaegsed infosüsteemid on üsna keerulised. Eelkõige on nende keerukus tingitud neis töödeldavate andmete keerukusest. Andmete keerukus seisneb sageli kasutatavate andmemudelite mitmekesisuses. Näiteks kui andmed muutuvad suureks, ei ole üheks probleemseks tunnuseks mitte ainult nende maht (“maht”), vaid ka mitmekesisus (“sorts”).
Kui te ei leia veel põhjenduses viga, siis lugege edasi.
Sisu
Polygloti püsivus
Eeltoodu toob kaasa asjaolu, et mõnikord on isegi ühe süsteemi raames vaja andmete salvestamiseks ja nende töötlemise erinevate probleemide lahendamiseks kasutada mitut erinevat DBMS-i, millest igaüks toetab oma andmemudelit. M. Fowleri kerge käega hulk kuulsaid raamatuid ja üks Agile Manifest, seda olukorda nimetatakse mitme variandiga salvestusruum ("polügloti püsivus").
Fowleril on ka järgmine näide andmesalvestuse korraldamisest e-kaubanduse valdkonna täisfunktsionaalses ja suure koormusega rakenduses.
See näide on muidugi mõnevõrra liialdatud, kuid mõningaid kaalutlusi ühe või teise DBMS-i vastavaks otstarbeks valimise kasuks võib leida näiteks .
Selge see, et sellises loomaaias sulaseks olemine pole lihtne.
- Andmete salvestamist teostava koodi hulk kasvab võrdeliselt kasutatavate DBMS-ide arvuga; koodide sünkroonimisandmete hulk on hea, kui mitte võrdeline selle arvu ruuduga.
- Kasutatavate DBMS-ide arvu kordsena suurenevad iga kasutatava DBMS-i ettevõtte omaduste (mastaapsus, tõrketaluvus, kõrge kättesaadavus) pakkumise kulud.
- Salvestusalamsüsteemi kui terviku ettevõtte omadusi – eriti tehingulisust – on võimatu tagada.
Loomaaia direktori seisukohalt näeb kõik välja selline:
- DBMS-i tootja litsentside ja tehnilise toe kulude mitmekordne tõus.
- Töötajate ülejääk ja pikendatud tähtajad.
- Otsesed rahalised kahjud või trahvid andmete ebaühtluse tõttu.
Süsteemi omamise kogukulu (TCO) on märgatavalt kasvanud. Kas "mitme salvestusvõimaluse" olukorrast on väljapääs?
Multimudel
Mõiste "mitme muutujaga salvestusruum" võeti kasutusele 2011. aastal. Lähenemisprobleemide teadvustamine ja lahenduse otsimine võttis aega mitu aastat ning 2015. aastaks Gartneri analüütikute suu läbi formuleeriti vastus:
- Alates ""
DBMS-ide tulevik, nende arhitektuur ja kasutusviisid on mitme mudeliga.
- Alates ""
Juhtivad operatiivsed DBMS-id pakuvad ühe platvormi osana mitut mudelit – relatsioonilisi ja mitterelatsioonilisi.
Tundub, et seekord läks Gartneri analüütikutel oma prognoosiga õigus. Kui lähete lehele koos DBMS-i DB-mootorites näete sedaоEnamik selle juhte positsioneerib end konkreetselt mitme mudeliga DBMS-ina. Sama on lehel näha mis tahes privaatse hinnanguga.
Allolev tabel näitab DBMS-i – kõigi privaatsete reitingute liidrid, mis väidavad end olevat mitme mudeliga. Iga DBMS-i jaoks on näidatud algne toetatud mudel (mis oli kunagi ainus) ja koos sellega praegu toetatud mudelid. Loetletud on ka DBMS-id, mis positsioneerivad end "algselt mitme mudelina" ja millel pole loojate sõnul ühtegi esialgset päritud mudelit.
| DBMS | Esialgne mudel | Lisamudelid |
|---|---|---|
| Oraakel | suhteline | Graafik, dokument |
| MS SQL | suhteline | Graafik, dokument |
| PostgreSQL | suhteline | Graafik*, dokument |
| MarkLogic | Dokumentaalfilm | Graafik, relatsioon |
| MongoDB | Dokumentaalfilm | Võtmeväärtus, graafik* |
| DataStax | Lai veerg | Dokumentaalfilm, graafik |
| Redis | Võtmeväärtus | Dokumentaalfilm, graafik* |
| ArangoDB | - | Graafik, dokument |
| OrientDB | - | Graafik, dokument, relatsioon |
| Azure CosmosDB | - | Graafik, dokument, relatsioon |
Märkmed lauale
Tärnid tabelis tähistavad reserveerimist nõudvaid avaldusi:
- PostgreSQL DBMS ei toeta graafiku andmemudelit, kuid see toode toetab seda , näiteks AgensGraph.
- Seoses MongoDB-ga on õigem rääkida graafioperaatorite olemasolust päringukeeles (, ) kui graafikumudeli toetamise kohta, kuigi loomulikult nõudis nende kasutuselevõtt mõningaid optimeerimisi füüsilise salvestusruumi tasemel graafikumudeli toetamise suunas.
- Redisega seoses peame silmas laiendust .
Järgmisena näitame iga klassi puhul, kuidas selle klassi DBMS-is rakendatakse mitme mudeli tugi. Peame kõige olulisemateks relatsiooni-, dokumendi- ja graafikumudelid ning kasutame konkreetsete DBMS-ide näiteid, et näidata, kuidas "puuduvaid" rakendatakse.
Relatsioonimudelil põhinev mitme mudeliga DBMS
Juhtivad DBMS-id on praegu relatsioonilised; Gartneri prognoosi ei saaks tõeseks pidada, kui RDBMS-id ei näita liikumist mitme modelleerimise suunas. Ja nad demonstreerivad. Nüüd saab mõtte, et mitme mudeliga DBMS on nagu Šveitsi nuga, mis ei oska midagi hästi teha, suunata otse Larry Ellisonile.
Autor eelistab aga multimodelleerimise rakendamist Microsoft SQL Serveris, mille näitel kirjeldatakse RDBMS-i tuge dokumendi- ja graafikumudelitele.
Dokumendimudel MS SQL Serveris
Habré kohta on juba ilmunud kaks suurepärast artiklit selle kohta, kuidas MS SQL Server rakendab dokumendimudeli tuge; piirdun lühikese ümberjutustuse ja kommentaariga:
Dokumendimudeli toetamise viis MS SQL Serveris on relatsiooniliste DBMS-ide jaoks üsna tüüpiline: JSON-dokumente soovitatakse salvestada tavalistele tekstiväljadele. Dokumendimudeli tugi on selle JSON-i sõelumiseks spetsiaalsete operaatorite pakkumine:
- atribuudi skalaarsete väärtuste eraldamiseks,
- alamdokumentide väljavõtmiseks.
Mõlema operaatori teine argument on avaldis JSONPathi sarnases süntaksis.
Abstraktselt võib öelda, et erinevalt korteežidest ei ole sel viisil salvestatud dokumendid relatsioonilises DBMS-is "esimese klassi üksused". Täpsemalt, MS SQL Serveris pole praegu JSON-dokumentide väljadel indekseid, mis raskendab nende väljade väärtusi kasutavate tabelite ühendamist ja isegi nende väärtuste abil dokumentide valimist. Küll aga on võimalik sellisele väljale luua arvutuslik veerg ja sellele indeks.
Lisaks võimaldab MS SQL Server operaatori abil tabelite sisust mugavalt koostada JSON-dokumenti - võimalus, teatud mõttes vastupidine eelmisele, tavapärasele ladustamisele. On selge, et ükskõik kui kiire RDBMS ka poleks, on selline lähenemine vastuolus dokumentide DBMS-ide ideoloogiaga, mis sisuliselt salvestavad valmis vastuseid populaarsetele päringutele ja suudavad lahendada ainult arendamise lihtsuse, kuid mitte kiiruse probleeme.
Lõpuks võimaldab MS SQL Server lahendada dokumendi koostamise vastupidise probleemi: saate JSON-i tabeliteks lagundada, kasutades . Kui dokument pole täiesti tasane, peate kasutama CROSS APPLY.
Graafiku mudel MS SQL Serveris
Graafiku (LPG) mudeli tugi on täielikult juurutatud ka Microsoft SQL Serveris : Tehakse ettepanek kasutada spetsiaalseid tabeleid sõlmede salvestamiseks ja graafiku servade salvestamiseks. Sellised tabelid luuakse avaldiste abil CREATE TABLE AS NODE и CREATE TABLE AS EDGE võrra.
Esimest tüüpi tabelid sarnanevad tavaliste kirjete salvestamise tabelitega, ainsaks väliseks erinevuseks on see, et tabel sisaldab süsteemivälja $node_id — graafiku sõlme kordumatu identifikaator andmebaasis.
Samamoodi on teist tüüpi tabelitel süsteemiväljad $from_id и $to_id, selliste tabelite kirjed määratlevad selgelt sõlmedevahelised ühendused. Igat tüüpi suhete salvestamiseks kasutatakse eraldi tabelit.
Illustreerime seda näitega. Olgu graafiku andmetel selline paigutus nagu joonisel näidatud. Seejärel tuleb andmebaasis vastava struktuuri loomiseks käivitada järgmised DDL-päringud:
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);Selliste tabelite põhispetsiifilisus seisneb selles, et nende vastu päringutes on võimalik kasutada graafilisi mustreid Cypher-sarnase süntaksiga (aga "*"jne pole veel toetatud). Jõudlusmõõtmiste põhjal võib ka eeldada, et nendes tabelites andmete salvestamise viis erineb tavalistes tabelites andmete salvestamise viisist ja on optimeeritud selliste graafikupäringute täitmiseks.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Veelgi enam, selliste tabelitega töötamisel on üsna raske neid graafiku mustreid mitte kasutada, kuna tavalistes SQL-päringutes on sarnaste probleemide lahendamiseks vaja teha täiendavaid jõupingutusi süsteemi "graafiku" sõlme identifikaatorite hankimiseks ($node_id, $from_id, $to_id; Samal põhjusel ei kuvata siin andmete sisestamise päringuid, kuna need on tarbetult tülikad).
MS SQL Serveris dokumendi- ja graafikumudelite realisatsioonide kirjelduse kokkuvõtteks märgin, et sellised ühe mudeli juurutused teise peal ei tundu edukad ja seda eelkõige keeledisaini seisukohalt. Ühte keelt on vaja teisega laiendada, keeled ei ole täiesti “ortogonaalsed”, ühilduvusreeglid võivad olla üsna veidrad.
Mitme mudeliga DBMS põhineb dokumendimudelil
Selles jaotises tahaksin illustreerida mitme mudeli rakendamist dokumendi DBMS-ides, kasutades neist mitte kõige populaarsema MongoDB näidet (nagu öeldud, sellel on ainult tingimuslikud graafioperaatorid $lookup и $graphLookup, mis ei tööta killustatud kogudega), kuid kasutades küpsema ja „ettevõtte” DBMS-i näidet .
Niisiis, las kogu sisaldab järgmist tüüpi XML-dokumentide komplekti (MarkLogic võimaldab salvestada ka JSON-dokumente):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Relatsioonimudel MarkLogicis
Dokumentide kogumi relatsioonivaate saab luua kasutades (elementide sisu value allolevas näites võib olla suvaline 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>Saate loodud vaate adresseerida SQL-päringuga (näiteks ODBC kaudu):
SELECT name, surname FROM Person WHERE name="John"Kahjuks on kuvamalli loodud relatsioonivaade kirjutuskaitstud. Selle päringu töötlemisel proovib MarkLogic kasutada . Varem olid MarkLogicul täiesti piiratud suhtelised vaated ja kirjutatavad, kuid nüüd peetakse neid aegunuks.
Graafiku mudel MarkLogicis
Graafiku (RDF) mudeli toega on kõik umbes sama. Jälle abiga Ülaltoodud näite põhjal saate luua dokumentide kogust RDF-i esituse:
<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>Saadud RDF-graafikut saate käsitleda SPARQL-i päringuga:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Erinevalt relatsioonimudelist toetab MarkLogic graafikumudelit kahel muul viisil:
- DBMS võib olla täieõiguslik eraldiseisev RDF-andmete salvestusruum (selles olevaid kolmikuid nimetatakse erinevalt ülalkirjeldatutest ).
- Spetsiaalse serialiseerimisega RDF-i saab lihtsalt sisestada XML- või JSON-dokumentidesse (ja kolmikud nimetatakse siis ). See on ilmselt alternatiiv mehhanismidele
idrefjne
Hea ettekujutuse sellest, kuidas asjad MarkLogicis "tegelikult" toimivad, annab , selles mõttes on tegemist madala tasemega, kuigi selle eesmärk on pigem vastupidine - püüda abstraheerida kasutatavast andmemudelist, tagada järjepidev töö andmetega erinevates mudelites, tehingulisus jne.
Mitme mudeli DBMS "ilma põhimudelita"
Turul on ka DBMS-e, mis positsioneerivad end algselt mitme mudelina, ilma päriliku põhimudelita. Need sisaldavad , (alates 2018. aastast kuulub arendusettevõte SAP-ile) ja (teenus Microsoft Azure'i pilveplatvormi osana).
Tegelikult on ArangoDB-s ja OrientDB-s "põhimudeleid". Mõlemal juhul on tegemist oma andmemudelitega, mis on dokumendimudeli üldistused. Üldistused on mõeldud peamiselt selleks, et hõlbustada graafilise ja relatsioonilise iseloomuga päringute sooritamist.
Need mudelid on ainsad, mis on saadaval määratud DBMS-is kasutamiseks; nende enda päringukeeled on loodud nendega töötama. Loomulikult on sellised mudelid ja DBMS-id paljulubavad, kuid ühilduvuse puudumine standardmudelite ja keeltega muudab nende DBMS-ide kasutamise pärandsüsteemides võimatuks - seal juba kasutatud DBMS-ide asendamiseks.
ArangoDB ja OrientDB kohta oli Habres juba suurepärane artikkel: .
ArangoDB
ArangoDB väidab toetust graafiku andmemudelile.
Graafi sõlmed ArangoDB-s on tavalised dokumendid ja servad on eritüüpi dokumendid, millel on koos tavaliste süsteemiväljadega (_key, _id, _rev) süsteemiväljad _from и _to. Dokumendi DBMS-ides olevad dokumendid kombineeritakse traditsiooniliselt kogumiteks. Servi esindavate dokumentide kogusid nimetatakse ArangoDB-s servakogudeks. Muide, servakogu dokumendid on ka dokumendid, nii et ArangoDB servad võivad toimida ka sõlmedena.
Toorandmed
Teeme kollektsiooni persons, mille dokumendid näevad välja järgmised:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Olgu ka kollektsioon cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Siis kollektsioon likes võib välja näha selline:
[
{
"_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
}
]Päringud ja tulemused
Graafiku stiilis päring ArangoDB-s kasutatavas AQL-keeles, mis tagastab inimesele loetaval kujul teavet selle kohta, kellele milline kohvik meeldib, näeb välja järgmine:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }Relatsioonistiilis, kus me pigem “arvutame” seoseid, mitte ei salvesta neid, saab selle päringu niimoodi ümber kirjutada (muide, ilma koguta likes saaks ilma hakkama):
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 }Tulemus on mõlemal juhul sama:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Rohkem päringuid ja tulemusi
Kui ülaltoodud tulemuse vorming tundub olevat tüüpilisem relatsioonilise DBMS-i kui dokumendi DBMS-i jaoks, võite proovida seda päringut (või kasutada ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Tulemus näeb välja selline:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
Graafikumudeli rakendamise alus OrientDB-s dokumendimudeli peal on dokumendiväljadel on lisaks enam-vähem standardsetele skalaarväärtustele ka selliseid väärtusi nagu LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Seda tüüpi väärtused on lingid või linkide kogumid dokumente.
Süsteemi määratud dokumendiidentifikaatoril on "füüsiline tähendus", mis näitab kirje asukohta andmebaasis ja näeb välja umbes selline: @rid : #3:16. Seega on võrdlusomaduste väärtused pigem osutid (nagu graafiku mudelis), mitte valikutingimused (nagu relatsioonimudelis).
Sarnaselt ArangoDB-ga on OrientDB servad esindatud eraldi dokumentidena (kuigi kui serval pole oma omadusi, saab selle teha , ja see ei vasta eraldi dokumendile).
Toorandmed
lähedases formaadis OrientDB andmebaas, ArangoDB eelmise näite andmed näeksid välja umbes sellised:
[
{
"@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"
}
]Nagu näeme, salvestavad tipud ka infot sissetulevate ja väljaminevate servade kohta. Kell Dokumendi API peab ise jälgima viidete terviklikkust ja Graph API võtab selle töö enda kanda. Kuid vaatame, kuidas näeb välja juurdepääs OrientDB-le "puhastes" päringukeeltes, mis pole programmeerimiskeeltesse integreeritud.
Päringud ja tulemused
Päring, mis sarnaneb OrientDB ArangoDB näite päringuga, näeb välja järgmine:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameTulemus saadakse järgmisel kujul:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Kui tulemuse vorming tundub jälle liiga "relatsiooniline", peate eemaldama rea :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]OrientDB päringukeelt võib kirjeldada kui SQL-i koos Gremlini-sarnaste lisadega. Versioonis 2.2 ilmus šifrilaadne päringuvorm, :
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_nameTulemuse vorming on sama, mis eelmisel päringul. Mõelge sellele, mida tuleks eemaldada, et muuta see "relatiivsemaks", nagu esimeses päringus.
Azure CosmosDB
Vähemal määral kehtib eespool ArangoDB ja OrientDB kohta öeldu ka Azure CosmosDB kohta. CosmosDB pakub järgmisi andmetele juurdepääsu API-sid: SQL, MongoDB, Gremlin ja Cassandra.
Dokumendimudeli andmetele juurdepääsuks kasutatakse SQL API-d ja MongoDB API-sid. Gremlin API ja Cassandra API – andmetele juurdepääsuks vastavalt graafiku- ja veeruvormingus. Kõikide mudelite andmed salvestatakse CosmosDB sisemudeli vormingus: (“aatom-rekord-järjestus”), mis on samuti lähedane dokumendi omale.
Kuid kasutaja valitud andmemudel ja kasutatav API on teenuses konto loomise ajal fikseeritud. Ühte mudelisse laaditud andmetele ei ole võimalik juurde pääseda teise mudeli vormingus, mida illustreerib järgmine:
Seega on Azure CosmosDB multimudel tänapäeval vaid võimalus kasutada mitut ühe tootja erinevaid mudeleid toetavaid andmebaase, mis ei lahenda kõiki mitme variandi salvestusprobleeme.
Graafikumudelil põhinev mitme mudeli DBMS?
Tähelepanuväärne on asjaolu, et turul pole veel ühtegi mitme mudeliga DBMS-i, mis põhineksid graafikumudelil (välja arvatud mitme mudeli tugi samaaegselt kahele graafikumudelile: RDF ja LPG; vaadake seda jaotisest ). Suurimaid raskusi tekitab pigem dokumendimudeli rakendamine graafilise mudeli peale, mitte relatsioonilise mudeli peale.
Küsimust, kuidas rakendada relatsioonimudelit graafimudeli peale, kaaluti juba viimase moodustamisel. Kuidas , näiteks :
Graafilisele lähenemisele ei ole omane midagi, mis takistaks graafiku andmebaasis (nt sobiva indekseerimisega) kihi loomist, mis võimaldaks relatsioonivaadet (1) tavapärastest võtmeväärtuspaaridest korteežide taastamisega ja (2) väärtuste grupeerimisega. korteid suhte tüübi järgi.
Dokumendimudeli rakendamisel graafikumudeli peale peate silmas pidama näiteks järgmist.
- JSON-massiivi elemente peetakse järjestatuks, kuid graafiku serva tipust lähtuvaid elemente mitte;
- Dokumendimudelis olevad andmed on tavaliselt denormaliseeritud; ikkagi ei soovi te sama manustatud dokumendi mitut koopiat salvestada ja alamdokumentidel ei ole tavaliselt identifikaatoreid.
- Teisest küljest on dokumendi DBMS-ide ideoloogia see, et dokumendid on valmis “agregaadid”, mida ei pea iga kord uuesti üles ehitama. Graafikumudelile tuleb anda võimalus kiiresti saada valmis dokumendile vastav alamgraafik.
Natuke reklaami
Artikli autor on seotud NitrosBase DBMS-i arendamisega, mille sisemudeliks on graaf ning välismudelid - relatsiooni- ja dokumentaalmudelid - on selle esitused. Kõik mudelid on võrdsed: peaaegu kõik andmed on saadaval kõigis neist, kasutades neile loomulikku päringukeelt. Lisaks saab andmeid igal vaatel muuta. Muudatused kajastuvad sisemudelis ja vastavalt ka muudes vaadetes.
Loodetavasti kirjeldan ühes järgmistest artiklitest, kuidas mudelite sobitamine NitrosBase'is välja näeb.
Järeldus
Loodan, et multimodelleerimiseks kutsutava üldised piirjooned on lugejale enam-vähem selgeks saanud. Mitme mudeliga DBMS-id on üsna erinevad ja mitme mudeli tugi võib olla erinev. Et mõista, mida igal konkreetsel juhul nimetatakse "mitme mudeliks", on kasulik vastata järgmistele küsimustele:
- Kas me räägime traditsiooniliste mudelite või mingi "hübriid" mudeli toetamisest?
- Kas modellid on "võrdsed" või on üks neist teiste teema?
- Kas modellid on üksteise suhtes "ükskõiksed"? Kas ühes mudelis kirjutatud andmeid saab lugeda teises mudelis või isegi üle kirjutada?
Arvan, et küsimusele mitme mudeliga DBMS-i asjakohasuse kohta saab juba praegu vastata positiivselt, kuid huvitav on küsimus, milliste tüüpide järele on lähitulevikus suurem nõudlus. Tundub, et traditsioonilisi, eeskätt relatsioonilisi mudeleid toetavate mitme mudeliga DBMS-ide järele on suurem nõudlus; Mitme mudeliga DBMS-ide populaarsus, mis pakuvad uusi mudeleid, mis ühendavad erinevate traditsiooniliste eelised, on kaugema tuleviku küsimus.
Küsitluses saavad osaleda ainult registreerunud kasutajad. palun.
Kas kasutate mitme mudeliga DBMS-i?
-
Me ei kasuta seda, vaid salvestame kõik ühte DBMS-i ja ühte mudelisse
-
Kasutame traditsiooniliste DBMS-ide mitme mudeli võimalusi
-
Harjutame polügloti püsivust
-
Kasutame uut mitme mudeliga DBMS-i (Arango, Orient, CosmosDB)
19 kasutajat hääletas. 4 kasutajat jäi erapooletuks.
Allikas: www.habr.com