Suvremeni informacijski sustavi prilično su složeni. Ne manje od svega, njihova složenost posljedica je složenosti podataka koji se u njima obrađuju. Složenost podataka često leži u raznolikosti korištenih podatkovnih modela. Tako, primjerice, kada podaci postanu “veliki”, jedna od problematičnih karakteristika nije samo njihov volumen (“volumen”), već i njihova raznolikost (“raznolikost”).
Ako još niste pronašli nedostatak u obrazloženju, čitajte dalje.
sadržaj
Poliglotska upornost
Navedeno dovodi do činjenice da je ponekad čak iu okviru jednog sustava potrebno koristiti više različitih DBMS-ova za pohranu podataka i rješavanje različitih problema njihove obrade, od kojih svaki podržava svoj model podataka. Lakom rukom M. Fowlera, nekoliko poznatih knjiga i jedna od Ova situacija se zove Agile Manifesto viševarijantno skladištenje (“poliglotska upornost”).
Fowler također ima sljedeći primjer organiziranja pohrane podataka u potpuno opremljenoj i visokoopterećenoj aplikaciji u području e-trgovine.
Ovaj je primjer, naravno, donekle pretjeran, ali neka razmatranja u korist odabira jednog ili drugog DBMS-a za odgovarajuću svrhu mogu se naći, na primjer, .
Jasno je da nije lako biti sluga u takvom zoološkom vrtu.
- Količina koda koji obavlja pohranu podataka raste proporcionalno broju korištenih DBMS-ova; količina podataka za sinkronizaciju koda je dobra ako nije proporcionalna kvadratu ovog broja.
- Kao višestruki broj korištenih DBMS-ova, povećavaju se troškovi pružanja značajki poduzeća (skalabilnost, otpornost na greške, visoka dostupnost) svakog korištenog DBMS-a.
- Nemoguće je osigurati poslovne karakteristike podsustava za pohranu u cjelini - posebno transakcijsku.
Iz ugla direktora zoološkog vrta sve izgleda ovako:
- Višestruko povećanje troškova licenci i tehničke podrške od strane proizvođača DBMS-a.
- Višak zaposlenih i produljeni rokovi.
- Izravni financijski gubici ili kazne zbog nedosljednosti podataka.
Postoji značajan porast ukupnog troška vlasništva (TCO) sustava. Ima li izlaza iz situacije "višestrukih mogućnosti pohrane"?
Multi-model
Izraz "multivarijatno skladištenje" ušao je u upotrebu 2011. Osvještavanje problematike pristupa i potraga za rješenjem trajalo je nekoliko godina, da bi do 2015. godine, kroz usta analitičara Gartnera, formuliran odgovor:
- od "'
Budućnost DBMS-ova, njihovih arhitektura i načina korištenja je višemodelna.
- od "'
Vodeći operativni DBMS nudit će više modela - relacijskih i nerelacijskih - kao dio jedne platforme.
Čini se da su ovoga puta analitičari Gartnera bili u pravu sa svojom prognozom. Ako odete na stranicu s DBMS na DB-Engines, to možete vidjetiоVećina njegovih vođa pozicionira se posebno kao višemodelne DBMS-ove. Isto se može vidjeti na stranici s bilo kojom privatnom ocjenom.
Donja tablica prikazuje DBMS - vodeće u svakoj od privatnih ocjena, za koje se tvrdi da su multi-modeli. Za svaki DBMS naznačen je originalni podržani model (koji je nekada bio jedini) i zajedno s njim trenutno podržani modeli. Također su navedeni DBMS-ovi koji se pozicioniraju kao "izvorno višemodelni" i, prema kreatorima, nemaju nikakav početni naslijeđeni model.
| DBMS | Početni model | Dodatni modeli |
|---|---|---|
| Proročanstvo | Relacijska | Grafikon, dokument |
| MS SQL | Relacijska | Grafikon, dokument |
| PostgreSQL | Relacijska | Grafikon*, dokument |
| MarkLogic | dokumentarni film | Graf, relacijski |
| MongoDB | dokumentarni film | Ključ/vrijednost, grafikon* |
| DataStax | Široki stupac | Dokumentarac, graf |
| Redis | Ključ-vrijednost | Dokumentarac, grafikon* |
| ArangoDB | - | Grafikon, dokument |
| OrientDB | - | Graf, dokument, relacijski |
| Azure CosmosDB | - | Graf, dokument, relacijski |
Bilješke na stolu
Zvjezdice u tablici označavaju izjave koje zahtijevaju rezervu:
- PostgreSQL DBMS ne podržava model podataka grafikona, ali ga ovaj proizvod podržava , kao što je AgensGraph.
- U odnosu na MongoDB, ispravnije je govoriti o prisutnosti operatora grafa u jeziku upita (, ) nego o podršci graf modela, iako je, naravno, njihovo uvođenje zahtijevalo neke optimizacije na razini fizičke pohrane u smjeru podrške graf modela.
- U odnosu na Redis, mislimo na proširenje .
Zatim ćemo za svaku od klasa pokazati kako je podrška za nekoliko modela implementirana u DBMS iz ove klase. Relacijske modele, modele dokumenata i grafova smatrat ćemo najvažnijima i upotrijebit ćemo primjere specifičnih DBMS-ova da pokažemo kako se implementiraju "oni koji nedostaju".
Višemodelni DBMS temeljen na relacijskom modelu
Vodeći DBMS-ovi trenutno su relacijski; Gartnerova prognoza ne bi se mogla smatrati istinitom ako RDBMS-ovi ne pokazuju kretanje u smjeru višestrukog modeliranja. I demonstriraju. Sada se ideja da je DBMS s više modela poput švicarskog noža, koji ne može učiniti ništa dobro, može uputiti izravno Larryju Ellisonu.
Autor ipak preferira implementaciju višestrukog modeliranja u Microsoft SQL Serveru, na čijem će primjeru biti opisana RDBMS podrška za modele dokumenata i grafova.
Model dokumenta u MS SQL Serveru
Na Habréu su već bila dva izvrsna članka o tome kako MS SQL Server implementira podršku za model dokumenta; ograničit ću se na kratko prepričavanje i komentar:
Način podržavanja modela dokumenta u MS SQL Serveru prilično je tipičan za relacijske DBMS-ove: predlaže se da se JSON dokumenti pohranjuju u obična tekstualna polja. Podrška za model dokumenta je pružanje posebnih operatora za analizu ovog JSON-a:
- za izdvajanje skalarnih vrijednosti atributa,
- za izdvajanje poddokumenata.
Drugi argument oba operatora je izraz u sintaksi sličnoj JSONPath.
Apstraktno, možemo reći da dokumenti pohranjeni na ovaj način nisu "prvorazredni entiteti" u relacijskom DBMS-u, za razliku od torki. Naime, u MS SQL Serveru trenutno ne postoje indeksi na poljima JSON dokumenata, što otežava spajanje tablica pomoću vrijednosti ovih polja, pa čak i odabir dokumenata pomoću tih vrijednosti. Međutim, moguće je stvoriti izračunati stupac za takvo polje i indeks na njemu.
Uz to, MS SQL Server pruža mogućnost prikladne konstrukcije JSON dokumenta iz sadržaja tablica pomoću operatora - mogućnost, u određenom smislu, suprotna prethodnoj, konvencionalnoj pohrani. Jasno je da bez obzira koliko brz RDBMS bio, ovaj pristup je u suprotnosti s ideologijom dokumentnih DBMS-ova, koji u suštini pohranjuju gotove odgovore na popularne upite, i mogu riješiti samo probleme lakoće razvoja, ali ne i brzine.
Konačno, MS SQL Server vam omogućuje da riješite suprotan problem konstrukcije dokumenta: možete rastaviti JSON na tablice pomoću . Ako dokument nije potpuno ravan, morat ćete koristiti CROSS APPLY.
Grafički model u MS SQL Serveru
Podrška za model grafa (LPG) također je u potpunosti implementirana u Microsoft SQL Server : Predlaže se korištenje posebnih tablica za pohranjivanje čvorova i pohranjivanje rubova grafa. Takve se tablice izrađuju pomoću izraza CREATE TABLE AS NODE и CREATE TABLE AS EDGE respektivno.
Tablice prve vrste slične su običnim tablicama za pohranu zapisa, s jedinom vanjskom razlikom što tablica sadrži sistemsko polje $node_id — jedinstveni identifikator čvora grafa unutar baze podataka.
Slično, tablice drugog tipa imaju sistemska polja $from_id и $to_id, unosi u takvim tablicama jasno definiraju veze između čvorova. Za pohranu odnosa svake vrste koristi se posebna tablica.
Ilustrirajmo to primjerom. Neka podaci grafikona imaju izgled kao što je prikazano na slici. Zatim za stvaranje odgovarajuće strukture u bazi podataka morate pokrenuti sljedeće DDL upite:
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);Glavna specifičnost takvih tablica je da je u upitima prema njima moguće koristiti uzorke grafova sa sintaksom sličnom Cypheru (međutim, “*"itd. još nisu podržani). Na temelju mjerenja performansi također se može pretpostaviti da se način na koji se podaci pohranjuju u ovim tablicama razlikuje od načina na koji se podaci pohranjuju u uobičajenim tablicama i da je optimiziran za izvršavanje takvih grafovih upita.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Štoviše, prilično je teško ne koristiti ove uzorke grafikona pri radu s takvim tablicama, budući da će u običnim SQL upitima za rješavanje sličnih problema biti potrebno uložiti dodatne napore da se dobiju identifikatori čvorova "grafa" sustava ($node_id, $from_id, $to_id; Iz istog razloga ovdje nisu prikazani upiti za umetanje podataka jer su nepotrebno glomazni).
Rezimirajući opis implementacija modela dokumenta i grafikona u MS SQL Serveru, primijetio bih da se takve implementacije jednog modela na drugi ne čine uspješnima, prvenstveno sa stajališta jezičnog dizajna. Potrebno je proširiti jedan jezik s drugim, jezici nisu potpuno "ortogonalni", pravila kompatibilnosti mogu biti prilično bizarna.
Višemodelni DBMS temeljen na modelu dokumenta
U ovom odjeljku želio bih ilustrirati implementaciju multi-modela u DBMS-ovima dokumenata koristeći primjer ne najpopularnijeg od njih, MongoDB-a (kao što je rečeno, ima samo operatore uvjetnog grafa $lookup и $graphLookup, ne radeći na razdijeljenim zbirkama), već koristeći primjer zrelijeg i "poduzetničkog" DBMS-a .
Dakle, neka kolekcija sadrži skup XML dokumenata sljedećeg tipa (MarkLogic također omogućuje pohranu JSON dokumenata):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Relacijski model u MarkLogicu
Relacijski pogled na zbirku dokumenata može se stvoriti pomoću (sadržaj elemenata value u donjem primjeru može postojati proizvoljan 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>Stvorenom prikazu možete pristupiti pomoću SQL upita (na primjer, putem ODBC-a):
SELECT name, surname FROM Person WHERE name="John"Nažalost, relacijski prikaz stvoren predloškom prikaza samo je za čitanje. Prilikom obrade zahtjeva za to, MarkLogic će pokušati koristiti . Prethodno je MarkLogic imao potpuno ograničene relacijske poglede i pisivi, ali sada se smatraju zastarjelim.
Model grafa u MarkLogicu
Uz podršku za graf (RDF) model, sve je otprilike isto. Opet uz pomoć Možete stvoriti RDF prikaz zbirke dokumenata iz gornjeg primjera:
<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>Rezultirajućem RDF grafu možete pristupiti pomoću SPARQL upita:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Za razliku od relacijskog, MarkLogic podržava model grafa na dva druga načina:
- DBMS može biti punopravna zasebna pohrana RDF podataka (trojke u njemu će se zvati za razliku od gore opisanih ).
- RDF u posebnoj serijalizaciji može se jednostavno umetnuti u XML ili JSON dokumente (i zatim će se pozvati trostruki ). Ovo je vjerojatno alternativa mehanizmima
idrefitd.
Dobru ideju o tome kako stvari "stvarno" funkcioniraju u MarkLogicu daje , u tom smislu je niske razine, iako je njegova svrha upravo suprotna - pokušati apstrahirati od korištenog podatkovnog modela, osigurati dosljedan rad s podacima u različitim modelima, transakcijskost itd.
DBMS s više modela “bez glavnog modela”
Na tržištu postoje i DBMS-ovi koji se u početku pozicioniraju kao višemodelni, bez ikakvog naslijeđenog glavnog modela. To uključuje , (od 2018. razvojna tvrtka pripada SAP-u) i (usluga u sklopu Microsoft Azure cloud platforme).
Zapravo, postoje "core" modeli u ArangoDB i OrientDB. U oba slučaja radi se o vlastitim modelima podataka, koji su generalizacije dokumenta. Generalizacije su uglavnom za olakšavanje mogućnosti izvođenja upita grafske i relacijske prirode.
Ovi modeli su jedini dostupni za korištenje u navedenom DBMS-u; njihovi vlastiti jezici upita dizajnirani su za rad s njima. Naravno, takvi modeli i DBMS-ovi obećavaju, ali nedostatak kompatibilnosti sa standardnim modelima i jezicima onemogućuje korištenje ovih DBMS-ova u naslijeđenim sustavima—da zamijene DBMS-ove koji se tamo već koriste.
Na Habréu je već bio divan članak o ArangoDB i OrientDB: .
ArangoDB
ArangoDB tvrdi da podržava model podataka grafikona.
Čvorovi grafa u ArangoDB-u su obični dokumenti, a rubovi su dokumenti posebnog tipa koji uz regularna sistemska polja imaju (_key, _id, _rev) polja sustava _from и _to. Dokumenti u DBMS-ovima dokumenata tradicionalno se kombiniraju u zbirke. Kolekcije dokumenata koji predstavljaju rubove nazivaju se rubne kolekcije u ArangoDB-u. Usput, dokumenti kolekcije rubova također su dokumenti, tako da rubovi u ArangoDB-u također mogu djelovati kao čvorovi.
Početni podaci
Neka nam bude zbirka persons, čiji dokumenti izgledaju ovako:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Neka bude i zbirka cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Zatim zbirka likes može izgledati ovako:
[
{
"_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
}
]Upiti i rezultati
Upit u stilu grafikona u AQL jeziku koji se koristi u ArangoDB-u, vraća u obliku koji je čitljiv za ljude, informacije o tome tko voli koji kafić, izgleda ovako:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }U relacijskom stilu, gdje "računamo" odnose umjesto da ih pohranjujemo, ovaj se upit može prepisati ovako (usput, bez zbirke likes mogao i bez):
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 }Rezultat će u oba slučaja biti isti:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Više upita i rezultata
Ako se gornji format rezultata čini tipičnijim za relacijski DBMS nego za dokumentni DBMS, možete isprobati ovaj upit (ili možete koristiti ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Rezultat će izgledati ovako:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
Osnova za implementaciju modela grafa na vrhu modela dokumenta u OrientDB je polja dokumenta, osim više ili manje standardnih skalarnih vrijednosti, također imaju vrijednosti tipova kao što su LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Vrijednosti ovih vrsta su veze ili zbirke veza na dokumente.
Identifikator dokumenta koji dodjeljuje sustav ima "fizičko značenje", označavajući položaj zapisa u bazi podataka i izgleda otprilike ovako: @rid : #3:16. Stoga su vrijednosti referentnih svojstava zapravo pokazivači (kao u modelu grafikona), a ne uvjeti odabira (kao u relacijskom modelu).
Poput ArangoDB-a, rubovi u OrientDB-u predstavljeni su kao zasebni dokumenti (iako rub nema vlastita svojstva, može se napraviti , i neće odgovarati zasebnom dokumentu).
Početni podaci
U formatu bliskom OrientDB baze podataka, podaci iz prethodnog primjera za ArangoDB izgledali bi otprilike ovako:
[
{
"@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"
}
]Kao što vidimo, vrhovi također pohranjuju informacije o dolaznim i odlaznim bridovima. Na Document API mora sam nadzirati referentni integritet, a Graph API preuzima taj posao. Ali da vidimo kako pristup OrientDB-u izgleda u "čistim" upitnim jezicima koji nisu integrirani u programske jezike.
Upiti i rezultati
Upit slične namjene kao upit iz primjera za ArangoDB u OrientDB izgleda ovako:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameRezultat će se dobiti u sljedećem obliku:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Ako se format rezultata ponovno čini previše "relacijskim", trebate ukloniti redak s :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]OrientDB-ov upitni jezik može se opisati kao SQL s umetcima nalik na Gremlin. U verziji 2.2 pojavio se obrazac zahtjeva sličan Cypheru, :
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_nameFormat rezultata bit će isti kao u prethodnom zahtjevu. Razmislite o tome što treba ukloniti kako bi bilo više "relacijsko", kao u prvom upitu.
Azure CosmosDB
U manjoj mjeri, ono što je gore rečeno o ArangoDB i OrientDB odnosi se na Azure CosmosDB. CosmosDB pruža sljedeće API-je za pristup podacima: SQL, MongoDB, Gremlin i Cassandra.
Za pristup podacima u modelu dokumenta koriste se SQL API i MongoDB API. Gremlin API i Cassandra API - za pristup podacima u formatu grafikona i stupca. Podaci u svim modelima spremaju se u format internog modela CosmosDB: (“atom-record-sequence”), koji je također blizak dokumentnom.
Ali podatkovni model koji je odabrao korisnik i korišteni API fiksni su u trenutku stvaranja računa u usluzi. Nije moguće pristupiti podacima učitanim u jednom modelu u formatu drugog modela, kao što je prikazano ovako:
Dakle, multi-model u Azure CosmosDB danas je samo mogućnost korištenja nekoliko baza podataka koje podržavaju različite modele od jednog proizvođača, što ne rješava sve probleme multi-varijante pohrane.
DBMS s više modela temeljen na modelu grafa?
Zanimljiva je činjenica da na tržištu još nema DBMS-ova s više modela koji se temelje na modelu grafa (osim podrške za više modela za dva modela grafa istovremeno: RDF i LPG; pogledajte ovo u ). Najveće poteškoće uzrokuje implementacija modela dokumenta povrh modela grafa, a ne relacijskog.
Pitanje kako implementirati relacijski model povrh modela grafa razmatrano je još tijekom formiranja potonjeg. Kako , na primjer, :
Ne postoji ništa svojstveno pristupu grafa što sprječava stvaranje sloja (npr. prikladnim indeksiranjem) na bazi podataka grafa koji omogućuje relacijski prikaz s (1) obnavljanjem torki iz uobičajenih parova ključeva i vrijednosti i (2) grupiranjem torke prema vrsti relacije.
Kada implementirate model dokumenta povrh modela grafikona, morate imati na umu, na primjer, sljedeće:
- Elementi JSON niza smatraju se uređenima, ali oni koji proizlaze iz vrha ruba grafa nisu;
- Podaci u modelu dokumenta obično su denormalizirani; još uvijek ne želite pohraniti nekoliko kopija istog ugrađenog dokumenta, a poddokumenti obično nemaju identifikatore;
- S druge strane, ideologija DBMS-ova za dokumente je da su dokumenti gotovi "agregati" koje nije potrebno svaki put iznova graditi. Potrebno je osigurati modelu grafa mogućnost brzog dobivanja podgrafa koji odgovara gotovom dokumentu.
Malo reklame
Autor članka vezan je uz razvoj NitrosBase DBMS-a, čiji je interni model graf, a eksterni modeli - relacijski i dokument - njegove su reprezentacije. Svi su modeli jednaki: gotovo svi podaci dostupni su u bilo kojem od njih koristeći upitni jezik koji mu je prirodan. Štoviše, u bilo kojem pogledu podaci se mogu mijenjati. Promjene će se odraziti na interni model i, sukladno tome, na druge prikaze.
Nadam se da ću opisati kako uparivanje modela izgleda u NitrosBase u jednom od sljedećih članaka.
Zaključak
Nadam se da su čitatelju postali više-manje jasni opći obrisi onoga što se naziva multimodeliranjem. DBMS-ovi s više modela prilično su različiti, a "podrška za više modela" može izgledati drugačije. Da bismo razumjeli što se naziva "multi-model" u svakom konkretnom slučaju, korisno je odgovoriti na sljedeća pitanja:
- Govorimo li o podršci tradicionalnim modelima ili nekakvom "hibridnom" modelu?
- Jesu li modeli “ravnopravni” ili je jedan od njih predmet ostalih?
- Jesu li modeli “ravnodušni” jedni prema drugima? Mogu li se podaci zapisani u jednom modelu čitati u drugom ili čak prepisivati?
Mislim da se na pitanje o relevantnosti višemodelnih DBMS-ova već može odgovoriti pozitivno, ali zanimljivo je pitanje koje će vrste njih biti traženije u bliskoj budućnosti. Čini se da će višemodelni DBMS-ovi koji podržavaju tradicionalne modele, prvenstveno relacijske, biti traženiji; Popularnost višemodelnih DBMS-ova, koji nude nove modele koji kombiniraju prednosti raznih tradicionalnih, stvar je dalje budućnosti.
U anketi mogu sudjelovati samo registrirani korisnici. , molim.
Koristite li DBMS s više modela?
-
Mi to ne koristimo, sve spremamo u jedan DBMS i u jedan model
-
Koristimo mogućnosti više modela tradicionalnih DBMS-ova
-
Vježbamo poliglotsku upornost
-
Koristimo novi višemodelni DBMS (Arango, Orient, CosmosDB)
Glasovalo je 19 korisnika. Suzdržana su bila 4 korisnika.
Izvor: www.habr.com