Savremeni informacioni sistemi su prilično složeni. Ne manje od svega, njihova složenost je posljedica složenosti podataka koji se u njima obrađuju. Složenost podataka često leži u različitim modelima podataka koji se koriste. Tako, na primjer, kada podaci postanu „veliki“, jedna od problematičnih karakteristika nije samo njihov volumen („volumen“), već i njihova raznolikost („raznovrsnost“).
Ako još uvijek ne pronađete nedostatak u obrazloženju, čitajte dalje.
Sadržaj
Poliglotska upornost
Navedeno dovodi do činjenice da je ponekad čak iu okviru jednog sistema potrebno koristiti više različitih DBMS-a za pohranjivanje podataka i rješavanje različitih problema njihove obrade, od kojih svaki podržava svoj model podataka. Lakom rukom M. Fowlera, niz poznatih knjiga i jedna od Agile Manifest, ova situacija se zove viševarijantno skladištenje („upornost poliglota“).
Fowler također ima sljedeći primjer organiziranja pohrane podataka u potpuno opremljenoj aplikaciji s velikim opterećenjem u polju e-trgovine.
Ovaj primjer je, naravno, pomalo preuveličan, ali se mogu naći neka razmatranja u korist odabira jednog ili drugog DBMS-a za odgovarajuću svrhu, npr. .
Jasno je da u takvom zoološkom vrtu nije lako biti sluga.
- Količina koda koji obavlja skladištenje podataka raste proporcionalno broju korištenih DBMS-ova; količina podataka za sinhronizaciju koda je dobra ako nije proporcionalna kvadratu ovog broja.
- Kao višekratnik broja korišćenih DBMS-ova, troškovi obezbeđivanja karakteristika preduzeća (skalabilnost, tolerancija grešaka, visoka dostupnost) svakog od korišćenih DBMS-a rastu.
- Nemoguće je osigurati poslovne karakteristike podsistema za skladištenje u cjelini – posebno transakcionost.
Iz ugla direktora zoološkog vrta, sve izgleda ovako:
- Višestruko povećanje troškova licenci i tehničke podrške proizvođača DBMS-a.
- Prekomjerno osoblje i povećani rokovi.
- Direktni finansijski gubici ili kazne zbog nedosljednosti podataka.
Postoji značajno povećanje ukupnih troškova vlasništva sistema (TCO). Postoji li izlaz iz situacije „više opcija za skladištenje“?
Multi-model
Termin „multivarijantno skladištenje“ ušao je u upotrebu 2011. Osvješćivanje problema pristupa i traženje rješenja trajalo je nekoliko godina, a do 2015. godine, kroz usta analitičara Gartnera, formulisan je odgovor:
- Od ""
Budućnost DBMS-a, njihove arhitekture i načina njihovog korištenja je multimodelna.
- Od ""
Vodeći operativni DBMS-ovi će ponuditi više modela – relacionih i nerelacionih – kao deo jedne platforme.
Čini se da su ovog puta analitičari Gartnera bili u pravu sa svojom prognozom. Ako odete na stranicu sa DBMS na DB-Engines, to možete vidjetiоVećina njegovih lidera se pozicionira posebno kao multimodelni DBMS. Isto se može vidjeti na stranici sa bilo kojom privatnom ocjenom.
U tabeli ispod prikazani su DBMS - lideri u svakoj od privatnih ocjena, koji tvrde da su multimodelni. Za svaki DBMS je naznačen originalni podržani model (koji je nekada bio jedini) i zajedno sa njim trenutno podržani modeli. Navedeni su i DBMS-ovi koji se pozicioniraju kao „prvobitno multimodelni“ i, prema kreatorima, nemaju nikakav inicijalni naslijeđeni model.
| DBMS | Početni model | Dodatni modeli |
|---|---|---|
| proročanstvo | relacijski | Grafikon, dokument |
| MSSQL | relacijski | Grafikon, dokument |
| PostgreSQL | relacijski | Grafikon*, dokument |
| MarkLogic | Dokumentarac | Grafikon, relacioni |
| MongoDB | Dokumentarac | Ključ/vrijednost, grafikon* |
| DataStax | Široka kolona | Dokumentarac, graf |
| Redis | Ključ/vrijednost | dokumentarac, graf* |
| ArangoDB | - | Grafikon, dokument |
| OrientDB | - | Grafikon, dokument, relacija |
| Azure CosmosDB | - | Grafikon, dokument, relacija |
Bilješke na stolu
Zvezdice u tabeli označavaju izjave koje zahtevaju rezervacije:
- PostgreSQL DBMS ne podržava model podataka grafa, 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 modelu grafa, iako je, naravno, njihovo uvođenje zahtevalo neke optimizacije na nivou fizičkog skladištenja u pravcu podrške modelu grafa.
- 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. Smatrat ćemo relacijske, dokumentne i grafičke modele najvažnijim i koristiti primjere specifičnih DBMS-a da pokažemo kako se implementiraju oni koji nedostaju.
Višemodelni DBMS zasnovan na relacionom modelu
Vodeći DBMS-ovi trenutno su relacijski. Gartnerova prognoza ne bi se mogla smatrati istinitom ako RDBMS-ovi ne pokazuju kretanje u pravcu višestrukog modeliranja. I demonstriraju. Sada se ideja da je multimodelni DBMS poput švicarskog noža, koji ne može učiniti ništa dobro, može direktno uputiti Larryju Ellisonu.
Autor, međutim, preferira implementaciju multimodeliranja u Microsoft SQL Server, na čijem će primjeru biti opisana podrška RDBMS za modele dokumenata i grafova.
Model dokumenta u MS SQL Serveru
Na Habréu su već bila dva odlična članka o tome kako MS SQL Server implementira podršku za model dokumenta Ograničit ću se na kratko prepričavanje i komentare;
Način podrške modelu dokumenta u MS SQL Serveru prilično je tipičan za relacijske DBMS: predlaže se da se JSON dokumenti pohranjuju u obična tekstualna polja. Podrška za model dokumenta je obezbjeđivanje posebnih operatora za raščlanjivanje ovog JSON-a:
- za izdvajanje vrijednosti skalarnih atributa,
- za izdvajanje poddokumenata.
Drugi argument oba operatora je izraz u JSONPath-sličnoj sintaksi.
Apstraktno, možemo reći da dokumenti pohranjeni na ovaj način nisu “prvoklasni entiteti” u relacijskom DBMS-u, za razliku od tuple-a. Konkretno, u MS SQL Serveru trenutno nema indeksa na poljima JSON dokumenata, što otežava spajanje tabela koristeći vrijednosti ovih polja, pa čak i odabir dokumenata koristeći te vrijednosti. Međutim, moguće je kreirati izračunatu kolonu za takvo polje i indeks na njemu.
Dodatno, MS SQL Server pruža mogućnost pogodne izrade JSON dokumenta iz sadržaja tabela koristeći operator - mogućnost, u određenom smislu, suprotna prethodnoj, konvencionalno skladištenje. Jasno je da bez obzira na to koliko je brz RDBMS, ovaj pristup je u suprotnosti sa ideologijom dokumentnih DBMS-a, 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ćava da riješite suprotan problem konstrukcije dokumenta: možete rastaviti JSON u tabele koristeći . Ako dokument nije potpuno ravan, morat ćete ga koristiti CROSS APPLY.
Grafički model u MS SQL Serveru
Podrška za model grafa (LPG) je također u potpunosti implementirana u Microsoft SQL Server : Predlaže se korištenje posebnih tablica za pohranjivanje čvorova i pohranjivanje rubova grafa. Takve tabele se kreiraju pomoću izraza CREATE TABLE AS NODE и CREATE TABLE AS EDGE respektivno.
Tabele prvog tipa su slične običnim tablicama za pohranjivanje zapisa, s jedinom vanjskom razlikom što tablica sadrži sistemsko polje $node_id — jedinstveni identifikator čvora grafa unutar baze podataka.
Slično, tabele drugog tipa imaju sistemska polja $from_id и $to_id, unosi u takvim tabelama jasno definišu veze između čvorova. Za pohranjivanje relacija svakog tipa koristi se posebna tabela.
Ilustrirajmo to primjerom. Neka podaci na grafikonu imaju izgled kao što je prikazano na slici. Zatim da biste kreirali odgovarajuću strukturu 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 ovakvih tabela je da je u upitima protiv njih moguće koristiti obrasce grafova sa sintaksom sličnom Cypher (međutim, “*"itd. još nisu podržani). Na osnovu mjerenja performansi, također se može pretpostaviti da se način na koji se podaci pohranjuju u ovim tabelama razlikuje od načina na koji se podaci pohranjuju u regularnim tabelama i optimiziran za izvršavanje takvih upita na grafu.
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 obrasce grafova kada radite s takvim tabelama, jer će u običnim SQL upitima za rješavanje sličnih problema biti potrebno uložiti dodatne napore da se dobiju identifikatori čvorova "grafa" sistema ($node_id, $from_id, $to_id; Iz istog razloga, upiti za umetanje podataka ovdje nisu prikazani jer su nepotrebno glomazni).
Da sumiramo opis implementacija modela dokumenta i grafova u MS SQL Serveru, napomenuo bih da se ovakve implementacije jednog modela na drugi ne čine uspješnim, prvenstveno sa stanovišta jezičkog dizajna. Potrebno je proširiti jedan jezik drugim, jezici nisu potpuno „ortogonalni“, pravila kompatibilnosti mogu biti prilično bizarna.
Višemodelni DBMS zasnovan na modelu dokumenta
U ovom odeljku, želeo bih da ilustrujem implementaciju multimodela u dokument DBMS na primeru ne najpopularnijeg od njih, MongoDB (kao što je rečeno, ima samo uslovne operatore grafa $lookup и $graphLookup, ne radeći na podijeljenim kolekcijama), ali koristeći primjer zrelijeg i „poduzetničkog“ DBMS-a .
Dakle, neka kolekcija sadrži skup XML dokumenata sljedećeg tipa (MarkLogic vam također omogućava pohranjivanje JSON dokumenata):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Relacioni model u MarkLogic-u
Relacioni prikaz zbirke dokumenata može se kreirati pomoću (sadržaj elemenata value u primjeru ispod 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>Možete adresirati kreirani pogled pomoću SQL upita (na primjer, putem ODBC-a):
SELECT name, surname FROM Person WHERE name="John"Nažalost, relacijski prikaz kreiran predloškom prikaza je samo za čitanje. Prilikom obrade zahtjeva za to, MarkLogic će pokušati koristiti . Ranije je MarkLogic u potpunosti imao ograničene relacijske poglede i upisivi, ali se sada smatraju zastarjelim.
Grafički model u MarkLogic-u
Uz podršku za graf (RDF) model, sve je otprilike isto. Opet uz pomoć možete kreirati RDF reprezentaciju kolekcije 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ći RDF graf možete adresirati sa SPARQL upitom:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Za razliku od relacionog, MarkLogic podržava model grafa na dva druga načina:
- DBMS može biti potpuno odvojeno skladište 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 tripleti će se tada zvati ). Ovo je vjerovatno alternativa mehanizmima
idrefi drugi.
Dobra ideja o tome kako stvari "stvarno" funkcionišu u MarkLogicu daje , u tom smislu je niskog nivoa, iako je njegova svrha pre suprotna - da pokuša da se apstrahuje od modela podataka koji se koristi, da osigura konzistentan rad sa podacima u različitim modelima, transakcionost itd.
Multi-model DBMS “bez glavnog modela”
Postoje i DBMS-ovi na tržištu koji se pozicioniraju kao inicijalno multimodelni, bez ikakvog naslijeđenog glavnog modela. To uključuje , (od 2018 razvojna kompanija pripada SAP-u) i (usluga kao dio Microsoft Azure cloud platforme).
U stvari, postoje „osnovni“ modeli u ArangoDB i OrientDB. U oba slučaja radi se o vlastitim modelima podataka, koji su generalizacije dokumentnog. Generalizacije uglavnom služe za olakšavanje mogućnosti izvođenja upita grafske i relacijske prirode.
Ovi modeli su jedini dostupni za upotrebu u navedenom DBMS-u, dizajnirani su za rad s njima. Naravno, takvi modeli i DBMS-ovi obećavaju, ali nedostatak kompatibilnosti sa standardnim modelima i jezicima onemogućava korištenje ovih DBMS-a u naslijeđenim sistemima – da bi se zamijenili DBMS-ovi koji se već koriste.
Već je postojao divan članak o ArangoDB i OrientDB na Habréu: .
ArangoDB
ArangoDB tvrdi da podržava model podataka grafa.
Čvorovi grafa u ArangoDB-u su obični dokumenti, a ivice su dokumenti posebnog tipa koji, uz redovna sistemska polja, imaju (_key, _id, _rev) sistemska polja _from и _to. Dokumenti u DBMS-ovima dokumenata tradicionalno se kombinuju u kolekcije. Kolekcije dokumenata koji predstavljaju ivice nazivaju se kolekcije rubova u ArangoDB-u. Usput, dokumenti za prikupljanje rubova su također dokumenti, tako da ivice u ArangoDB-u također mogu djelovati kao čvorovi.
Sirovi podaci
Dajte nam kolekciju 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 kolekcija 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 grafa na AQL jeziku koji se koristi u ArangoDB-u, koji vraća u čovjeku čitljivom obliku informacije o tome ko voli koji kafić, izgleda ovako:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }U relacionom stilu, gde „računamo“ odnose umesto da ih pohranjujemo, ovaj upit se može prepisati ovako (usput, bez kolekcije likes mogao 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 dokument 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, pored manje-više standardnih skalarnih vrijednosti, imaju i vrijednosti tipova kao npr LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Vrijednosti ovih tipova su veze ili kolekcije veza ka dokumenti.
Identifikator dokumenta koji je dodijelio sistem ima "fizičko značenje", što ukazuje na poziciju zapisa u bazi podataka, i izgleda otprilike ovako: @rid : #3:16. Dakle, vrijednosti referentnih svojstava su zapravo pokazivači (kao u modelu grafa), a ne uvjeti odabira (kao u relacijskom modelu).
Kao i ArangoDB, ivice u OrientDB-u su predstavljene kao zasebni dokumenti (iako ako ivica nema svoja svojstva, može se napraviti , i neće odgovarati posebnom dokumentu).
Sirovi podaci
U formatu bliskom OrientDB baze podataka, podaci iz prethodnog primjera za ArangoDB bi izgledali 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 možemo vidjeti, vrhovi također pohranjuju informacije o dolaznim i odlaznim rubovima. At Document API mora sam nadgledati referentni integritet, a Graph API preuzima ovaj posao. Ali hajde da vidimo kako izgleda pristup OrientDB-u u "čistim" jezicima upita koji nisu integrisani u programske jezike.
Upiti i rezultati
Upit sličan po svrsi upitu 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 opet čini previše „relacionim“, morate ukloniti liniju sa :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]OrientDB-ov jezik upita može se opisati kao SQL sa umetcima sličnim Gremlinu. U verziji 2.2 pojavio se obrazac zahtjeva sličan Cypher, :
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 će biti isti kao u prethodnom zahtjevu. Razmislite o tome šta treba ukloniti da bi bilo više "relacijski", 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.
SQL API i MongoDB API se koriste za pristup podacima u modelu dokumenta. Gremlin API i Cassandra API - za pristup podacima u formatima grafikona i kolona, respektivno. Podaci u svim modelima se čuvaju u CosmosDB internom formatu modela: (“atom-record-sequence”), koji je takođe blizak dokumentu.
Ali model podataka koji je odabrao korisnik i korišteni API su fiksni u trenutku kreiranja naloga u servisu. Nije moguće pristupiti podacima učitanim u jednom modelu u formatu drugog modela, što ilustruje nešto poput ovoga:
Dakle, multi-model u Azure CosmosDB danas je samo mogućnost korištenja nekoliko baza podataka koje podržavaju različite modele jednog proizvođača, što ne rješava sve probleme viševarijantnog skladištenja.
Multi-model DBMS zasnovan na modelu grafa?
Zanimljiva je činjenica da na tržištu još nema višemodelnih DBMS-ova koji su zasnovani na grafičkom modelu (osim podrške za više modela za istovremeno dva modela grafa: RDF i LPG; pogledajte ovo u ). Najveće poteškoće izaziva implementacija modela dokumenta iznad modela grafa, a ne relacionog.
Pitanje kako implementirati relacioni model na vrhu grafskog modela razmatrano je još tokom formiranja potonjeg. Kako , na primjer, :
Ne postoji ništa svojstveno pristupu grafa što sprečava kreiranje sloja (npr. odgovarajućim indeksiranjem) na bazi podataka grafova koji omogućava relacioni pogled sa (1) obnavljanjem torki iz uobičajenih parova vrednosti ključa i (2) grupisanjem tuple po tipu relacije.
Kada implementirate model dokumenta na model grafa, morate imati na umu, na primjer, sljedeće:
- Elementi JSON niza se smatraju uređenim, ali oni koji izlaze iz vrha ivice 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 dokumentnih DBMS-a je da su dokumenti gotovi „agregati“ koje ne treba svaki put iznova graditi. Potrebno je obezbediti model grafa sa mogućnošću brzog dobijanja podgrafa koji odgovara gotovom dokumentu.
Malo reklame
Autor članka se odnosi na razvoj NitrosBase DBMS-a, čiji je interni model graf, a eksterni modeli – relacijski i dokument – su njegove reprezentacije. Svi modeli su jednaki: gotovo svi podaci dostupni su u bilo kojem od njih koristeći jezik upita koji mu je prirodan. Štaviše, u bilo kojem prikazu podaci se mogu mijenjati. Promjene će se odraziti na interni model i, shodno tome, na druge poglede.
Nadam se da ću opisati kako uparivanje modela izgleda u NitrosBaseu u jednom od sljedećih članaka.
zaključak
Nadam se da su opšti obrisi onoga što se naziva multimodeliranjem postali manje-više jasni čitaocu. Višemodelni DBMS-ovi su prilično različiti, a „podrška za više modela“ može izgledati drugačije. Da bismo razumjeli šta se u svakom konkretnom slučaju naziva "multi-modelom", korisno je odgovoriti na sljedeća pitanja:
- Govorimo li o podršci tradicionalnim modelima ili nekoj vrsti “hibridnog” modela?
- Da li su modeli „jednaki“, ili je jedan od njih predmet ostalih?
- Da li su modeli “ravnodušni” jedni prema drugima? Da li se podaci napisani u jednom modelu mogu pročitati u drugom ili čak prepisati?
Mislim da se na pitanje o relevantnosti multimodelnih DBMS-a već može pozitivno odgovoriti, ali je interesantno pitanje koje vrste njih će biti traženije u bliskoj budućnosti. Čini se da će višemodelni DBMS koji podržavaju tradicionalne modele, prvenstveno relacijske, biti traženiji; Popularnost multimodelnih DBMS-a, koji nude nove modele koji kombinuju prednosti raznih tradicionalnih, pitanje je daleke budućnosti.
Samo registrovani korisnici mogu učestvovati u anketi. molim.
Da li koristite multi-model DBMS?
Mi to ne koristimo, sve pohranjujemo u jedan DBMS i u jedan model
Koristimo multimodelne mogućnosti tradicionalnih DBMS-ova
Prakticiramo poliglotsku upornost
Koristimo novi multi-model DBMS (Arango, Orient, CosmosDB)
Glasalo je 19 korisnika. 4 korisnika je bila uzdržana.
izvor: www.habr.com
