Moderne informasjonssystemer er ganske komplekse. Ikke minst skyldes kompleksiteten deres kompleksiteten til dataene som behandles i dem. Kompleksiteten til data ligger ofte i mangfoldet av datamodeller som brukes. Så, for eksempel, når data blir "store", er en av de problematiske egenskapene ikke bare volum ("volum"), men også variasjon ("variasjon").
Hvis du ennå ikke finner en feil i resonnementet, så les videre.
Innhold
Polyglot utholdenhet
Ovennevnte fører til det faktum at noen ganger selv innenfor rammen av ett system er det nødvendig å bruke flere forskjellige DBMS-er for å lagre data og løse ulike problemer med å behandle dem, som hver støtter sin egen datamodell. Med den lette hånden til M. Fowler, en rekke kjente bøker og en av Agile Manifesto, kalles denne situasjonen lagring med flere varianter ("polyglot persistens").
Fowler har også følgende eksempel på organisering av datalagring i en fullverdig og høybelastningsapplikasjon innen e-handel.
Dette eksemplet er selvfølgelig noe overdrevet, men noen vurderinger til fordel for å velge en eller annen DBMS for tilsvarende formål kan f.eks. .
Det er tydelig at det ikke er lett å være tjener i en slik dyrehage.
- Mengden kode som utfører datalagring vokser i forhold til antall DBMS-er som brukes; mengden kodesynkroniseringsdata er god om ikke proporsjonal med kvadratet av dette tallet.
- Som et multiplum av antall DBMS-er som brukes, øker kostnadene ved å tilby bedriftskarakteristikker (skalerbarhet, feiltoleranse, høy tilgjengelighet) for hver av DBMS-ene som brukes.
- Det er umulig å sikre bedriftskarakteristikkene til lagringsundersystemet som helhet - spesielt transaksjonalitet.
Fra dyrehagedirektørens synspunkt ser alt slik ut:
- En multippel økning i kostnadene for lisenser og teknisk støtte fra DBMS-produsenten.
- Overbemanning og økte frister.
- Direkte økonomiske tap eller straffer på grunn av datainkonsekvens.
Det er en betydelig økning i systemets totale eierkostnader (TCO). Er det noen vei ut av situasjonen med "flere lagringsalternativer"?
Multi-modell
Begrepet "multivariatlagring" ble tatt i bruk i 2011. Bevissthet om problemene med tilnærmingen og søket etter en løsning tok flere år, og innen 2015, gjennom munnen til Gartner-analytikere, ble svaret formulert:
- Fra "'
Fremtiden til DBMS, deres arkitekturer og måter å bruke dem på er multi-modell.
- Fra "'
Ledende operative DBMS-er vil tilby flere modeller – relasjonelle og ikke-relasjonelle – som en del av en enkelt plattform.
Det ser ut til at Gartner-analytikerne denne gangen hadde rett med prognosen. Hvis du går til siden med DBMS på DB-Engines, det kan du seоDe fleste av lederne posisjonerer seg spesifikt som multi-modell DBMS. Det samme kan sees på siden med enhver privat vurdering.
Tabellen nedenfor viser DBMS - lederne i hver av de private vurderingene, som hevder å være multimodeller. For hver DBMS angis den opprinnelige støttede modellen (som en gang var den eneste) og sammen med modellene som støttes for øyeblikket. Også oppført er DBMS-er som posisjonerer seg som "opprinnelig multi-modell" og, ifølge skaperne, ikke har noen opprinnelig arvet modell.
| DBMS | Opprinnelig modell | Ekstra modeller |
|---|---|---|
| Oracle | Relasjonell | Graf, dokument |
| MS SQL | Relasjonell | Graf, dokument |
| PostgreSQL | Relasjonell | Graf*, dokument |
| Marklogic | Dokumentar | Graf, relasjonell |
| MongoDB | Dokumentar | Nøkkelverdi, graf* |
| DataStax | Bred kolonne | Dokumentar, graf |
| Redis | Nøkkelverdi | Dokumentar, graf* |
| ArangoDB | - | Graf, dokument |
| OrientDB | - | Graf, dokument, relasjonell |
| Azure CosmosDB | - | Graf, dokument, relasjonell |
Notater på bordet
Stjerner i tabellen markerer utsagn som krever reservasjoner:
- PostgreSQL DBMS støtter ikke grafdatamodellen, men dette produktet støtter det , for eksempel AgensGraph.
- I forhold til MongoDB er det mer riktig å snakke om tilstedeværelsen av grafoperatorer i spørringsspråket (, ) enn om å støtte grafmodellen, selv om introduksjonen deres selvfølgelig krevde noen optimaliseringer på det fysiske lagringsnivået i retning av å støtte grafmodellen.
- I forhold til Redis mener vi utvidelsen .
Deretter vil vi for hver av klassene vise hvordan støtte for flere modeller er implementert i DBMS fra denne klassen. Vi vil vurdere relasjons-, dokument- og grafmodellene som de viktigste og bruke eksempler på spesifikke DBMS-er for å vise hvordan de «manglende» implementeres.
Multi-modell DBMS basert på relasjonsmodellen
De ledende DBMS-ene for øyeblikket er relasjonelle; Gartners prognose kunne ikke betraktes som sann hvis RDBMS-er ikke viste bevegelse i retning av multimodellering. Og de demonstrerer. Nå kan ideen om at en multi-modell DBMS er som en sveitsisk kniv, som ikke kan gjøre noe godt, rettes direkte til Larry Ellison.
Forfatteren foretrekker imidlertid implementeringen av multi-modellering i Microsoft SQL Server, på eksemplet som RDBMS-støtte for dokument- og grafmodeller vil bli beskrevet.
Dokumentmodell i MS SQL Server
Det har allerede vært to utmerkede artikler om Habré om hvordan MS SQL Server implementerer støtte for dokumentmodellen; Jeg vil begrense meg til en kort gjenfortelling og kommentar:
Måten å støtte dokumentmodellen i MS SQL Server på er ganske typisk for relasjonelle DBMSer: JSON-dokumenter foreslås lagret i vanlige tekstfelt. Støtte for dokumentmodellen er å gi spesielle operatører for å analysere denne JSON:
- for å trekke ut skalære attributtverdier,
- å trekke ut underdokumenter.
Det andre argumentet til begge operatorene er et uttrykk i JSONPath-lignende syntaks.
Abstrakt kan vi si at dokumenter som er lagret på denne måten, ikke er "førsteklasses enheter" i en relasjonell DBMS, i motsetning til tuples. Spesifikt, i MS SQL Server er det for øyeblikket ingen indekser på feltene til JSON-dokumenter, noe som gjør det vanskelig å slå sammen tabeller ved å bruke verdiene til disse feltene og til og med velge dokumenter som bruker disse verdiene. Det er imidlertid mulig å lage en beregnet kolonne for et slikt felt og en indeks på det.
I tillegg gir MS SQL Server muligheten til å enkelt konstruere et JSON-dokument fra innholdet i tabeller ved å bruke operatøren - en mulighet, i en viss forstand, motsatt av den forrige, konvensjonell lagring. Det er klart at uansett hvor raskt en RDBMS er, motsier denne tilnærmingen ideologien til dokument-DBMS, som i hovedsak lagrer ferdige svar på populære spørsmål, og kan bare løse problemer med enkel utvikling, men ikke hastighet.
Til slutt lar MS SQL Server deg løse det omvendte problemet med dokumentkonstruksjon: du kan dekomponere JSON til tabeller ved å bruke . Hvis dokumentet ikke er helt flatt, må du bruke CROSS APPLY.
Grafmodell i MS SQL Server
Støtte for grafmodellen (LPG) er også fullt implementert i Microsoft SQL Server : Det foreslås å bruke spesielle tabeller for å lagre noder og for å lagre grafkanter. Slike tabeller lages ved hjelp av uttrykk CREATE TABLE AS NODE и CREATE TABLE AS EDGE henholdsvis.
Tabeller av den første typen ligner på vanlige tabeller for lagring av poster, med den eneste eksterne forskjellen er at tabellen inneholder et systemfelt $node_id – unik identifikator for en grafnode i databasen.
På samme måte har tabeller av den andre typen systemfelt $from_id и $to_id, oppføringer i slike tabeller definerer klart forbindelsene mellom noder. En separat tabell brukes til å lagre relasjoner av hver type.
La oss illustrere dette med et eksempel. La grafdataene ha en layout som den som er vist på figuren. For å lage den tilsvarende strukturen i databasen må du kjøre følgende DDL-spørringer:
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);Hovedspesifisiteten til slike tabeller er at i spørringer mot dem er det mulig å bruke grafmønstre med Cypher-lignende syntaks (men "*"osv. støttes ikke ennå). Basert på ytelsesmålinger kan det også antas at måten data lagres på i disse tabellene er forskjellig fra måten data lagres i vanlige tabeller og er optimalisert for å utføre slike grafspørringer.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Dessuten er det ganske vanskelig å ikke bruke disse grafmønstrene når du arbeider med slike tabeller, siden i vanlige SQL-spørringer for å løse lignende problemer vil det være nødvendig å gjøre ytterligere anstrengelser for å skaffe system-"graf"-node-identifikatorer ($node_id, $from_id, $to_id; Av samme grunn vises ikke spørringer for å sette inn data her da de er unødvendig tungvinte).
For å oppsummere beskrivelsen av implementeringene av dokument- og grafmodellene i MS SQL Server, vil jeg bemerke at slike implementeringer av en modell på toppen av en annen ikke virker vellykket, først og fremst fra et språkdesignsynspunkt. Det er nødvendig å utvide ett språk med et annet, språkene er ikke helt "ortogonale", kompatibilitetsreglene kan være ganske bisarre.
Multi-modell DBMS basert på dokumentmodellen
I denne delen vil jeg illustrere implementeringen av multi-modell i dokument-DBMS-er ved å bruke eksemplet på den ikke mest populære av dem, MongoDB (som det ble sagt, den har bare betingede grafoperatorer $lookup и $graphLookup, jobber ikke med oppdelte samlinger), men bruker eksemplet på en mer moden og "bedrift" DBMS .
Så la samlingen inneholde et sett med XML-dokumenter av følgende type (MarkLogic lar deg også lagre JSON-dokumenter):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Relasjonsmodell i MarkLogic
En relasjonell visning av en samling av dokumenter kan opprettes ved hjelp av (innhold av elementer value i eksemplet nedenfor kan det være en vilkårlig 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>Du kan adressere den opprettede visningen med en SQL-spørring (for eksempel via ODBC):
SELECT name, surname FROM Person WHERE name="John"Dessverre er relasjonsvisningen opprettet av visningsmalen skrivebeskyttet. Når du behandler en forespørsel om det, vil MarkLogic prøve å bruke . Tidligere hadde MarkLogic begrensede relasjonssyn, helt og skrivbare, men nå anses de som utdaterte.
Grafmodell i MarkLogic
Med støtte for grafmodellen (RDF) er alt omtrent det samme. Igjen med hjelp Du kan lage en RDF-representasjon av en samling dokumenter fra eksemplet ovenfor:
<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>Du kan adressere den resulterende RDF-grafen med en SPARQL-spørring:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}I motsetning til den relasjonelle, støtter MarkLogic grafmodellen på to andre måter:
- En DBMS kan være en fullverdig separat lagring av RDF-data (tripletter i den vil bli kalt i motsetning til de som er beskrevet ovenfor ).
- RDF i spesiell serialisering kan ganske enkelt settes inn i XML- eller JSON-dokumenter (og trillinger vil da bli kalt ). Dette er trolig et alternativ til mekanismer
idrefetc.
En god idé om hvordan ting "virkelig" fungerer i MarkLogic er gitt av , i denne forstand er det lavt nivå, selv om formålet er snarere det motsatte - å prøve å abstrahere fra datamodellen som brukes, for å sikre konsistent arbeid med data i forskjellige modeller, transaksjonalitet, etc.
Multi-modell DBMS "uten en hovedmodell"
Det finnes også DBMS-er på markedet som posisjonerer seg som i utgangspunktet multimodell, uten noen nedarvet hovedmodell. Disse inkluderer , (siden 2018 tilhører utviklingsselskapet SAP) og (tjeneste som en del av Microsoft Azure-skyplattformen).
Faktisk er det "kjerne"-modeller i ArangoDB og OrientDB. I begge tilfeller er dette deres egne datamodeller, som er generaliseringer av dokumentet en. Generaliseringene er hovedsakelig for å lette muligheten til å utføre spørringer av grafisk og relasjonell karakter.
Disse modellene er de eneste tilgjengelige for bruk i spesifisert DBMS; deres egne spørringsspråk er designet for å fungere med dem. Selvfølgelig er slike modeller og DBMS-er lovende, men mangelen på kompatibilitet med standardmodeller og språk gjør det umulig å bruke disse DBMS-ene i eldre systemer - for å erstatte DBMS-ene som allerede er brukt der.
Det var allerede en fantastisk artikkel om ArangoDB og OrientDB på Habré: .
ArangoDB
ArangoDB hevder støtte for en grafdatamodell.
Nodene til en graf i ArangoDB er vanlige dokumenter, og kantene er dokumenter av en spesiell type som sammen med vanlige systemfelt har (_key, _id, _rev) systemfelt _from и _to. Dokumenter i dokument-DBMS er tradisjonelt kombinert til samlinger. Samlinger av dokumenter som representerer kanter kalles kantsamlinger i ArangoDB. Kantsamlingsdokumenter er forresten også dokumenter, så kanter i ArangoDB kan også fungere som noder.
Innledende data
La oss ha en samling persons, hvis dokumenter ser slik ut:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]La det også bli en samling cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Så samlingen likes kan se slik ut:
[
{
"_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
}
]Spørsmål og resultater
En spørring i grafisk stil på AQL-språket som brukes i ArangoDB, som returnerer i menneskelesbar form informasjon om hvem som liker hvilken kafé, ser slik ut:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }I en relasjonell stil, der vi "beregner" relasjoner i stedet for å lagre dem, kan denne spørringen skrives om slik (forresten, uten samlingen likes kunne klare seg uten):
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 }Resultatet i begge tilfeller vil være det samme:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Flere spørsmål og resultater
Hvis resultatformatet ovenfor ser ut til å være mer typisk for et relasjons-DBMS enn for et dokument-DBMS, kan du prøve denne spørringen (eller du kan bruke ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Resultatet vil se slik ut:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
Grunnlaget for å implementere en grafmodell på toppen av en dokumentmodell i OrientDB er dokumentfelt, i tillegg til mer eller mindre standard skalarverdier, har også verdier av typer som f.eks LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Verdiene til disse typene er lenker eller samlinger av lenker til dokumenter.
Dokumentidentifikatoren som er tildelt av systemet har en "fysisk betydning", som indikerer posisjonen til posten i databasen, og ser omtrent slik ut: @rid : #3:16. Dermed er verdiene til referanseegenskaper egentlig pekere (som i grafmodellen) snarere enn utvalgsbetingelser (som i relasjonsmodellen).
Som ArangoDB er kanter i OrientDB representert som separate dokumenter (selv om en kant ikke har sine egne egenskaper, kan den lages , og det vil ikke tilsvare et eget dokument).
Innledende data
I et format nært OrientDB-databasen, dataene fra det forrige eksemplet for ArangoDB ville se omtrent slik ut:
[
{
"@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"
}
]Som vi kan se, lagrer toppunkter også informasjon om innkommende og utgående kanter. På Document API må selv overvåke referanseintegritet, og Graph API tar på seg dette arbeidet. Men la oss se hvordan tilgang til OrientDB ser ut i "rene" spørringsspråk som ikke er integrert i programmeringsspråk.
Spørsmål og resultater
En spørring som ligner på hensikten med spørringen fra eksemplet for ArangoDB i OrientDB ser slik ut:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameResultatet vil bli oppnådd i følgende skjema:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Hvis resultatformatet igjen virker for "relasjonelt", må du fjerne linjen med :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]OrientDBs spørringsspråk kan beskrives som SQL med Gremlin-lignende inserts. I versjon 2.2 dukket det opp et Cypher-lignende forespørselsskjema, :
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_nameResultatformatet vil være det samme som i forrige forespørsel. Tenk på hva som må fjernes for å gjøre det mer "relasjonelt", som i den aller første spørringen.
Azure CosmosDB
I mindre grad gjelder det som ble sagt ovenfor om ArangoDB og OrientDB for Azure CosmosDB. CosmosDB gir følgende datatilgangs-APIer: SQL, MongoDB, Gremlin og Cassandra.
SQL API og MongoDB API brukes for å få tilgang til data i dokumentmodellen. Gremlin API og Cassandra API - for tilgang til data i henholdsvis graf- og kolonneformater. Data i alle modeller lagres i CosmosDB interne modellformat: ("atom-rekord-sekvens"), som også ligger nær dokumentet en.
Men datamodellen valgt av brukeren og API-en som brukes, er løst på tidspunktet for opprettelse av en konto i tjenesten. Det er ikke mulig å få tilgang til data lastet i én modell i en annen modells format, som illustrert av noe sånt som dette:
Dermed er multi-modell i Azure CosmosDB i dag kun muligheten til å bruke flere databaser som støtter ulike modeller fra én produsent, noe som ikke løser alle problemene med multi-variant lagring.
Multi-modell DBMS basert på en grafmodell?
Bemerkelsesverdig er det faktum at det ennå ikke finnes flere DBMS-er på markedet som er basert på en grafmodell (bortsett fra støtte for flere modeller for samtidig to grafmodeller: RDF og LPG; se dette i ). De største vanskelighetene forårsakes av implementeringen av en dokumentmodell på toppen av en grafmodell, snarere enn en relasjonell.
Spørsmålet om hvordan man implementerer en relasjonsmodell på toppen av grafmodellen ble vurdert selv under dannelsen av sistnevnte. Hvordan For eksempel, :
Det er ingenting iboende i graftilnærmingen som hindrer å lage et lag (f.eks. ved passende indeksering) på en grafdatabase som muliggjør en relasjonsvisning med (1) gjenoppretting av tupler fra de vanlige nøkkelverdiparene og (2) gruppering av tupler etter relasjonstype.
Når du implementerer en dokumentmodell på toppen av en grafmodell, må du for eksempel huske på følgende:
- Elementer i en JSON-matrise anses som ordnet, men de som kommer fra toppunktet til en kant av grafen er det ikke;
- Data i dokumentmodellen er vanligvis denormalisert; du vil fortsatt ikke lagre flere kopier av det samme innebygde dokumentet, og underdokumenter har vanligvis ikke identifikatorer;
- På den annen side er ideologien til dokument-DBMS-er at dokumenter er ferdige "aggregater" som ikke trenger å bygges på nytt hver gang. Det kreves å gi grafmodellen muligheten til raskt å få en subgraf som tilsvarer det ferdige dokumentet.
Litt reklame
Forfatteren av artikkelen er relatert til utviklingen av NitrosBase DBMS, hvis interne modell er graf, og de eksterne modellene - relasjonelle og dokument - er representasjonene. Alle modeller er like: nesten alle data er tilgjengelige i noen av dem ved å bruke et spørringsspråk som er naturlig for det. Dessuten kan dataene endres i alle visninger. Endringer vil gjenspeiles i den interne modellen og følgelig i andre synspunkter.
Jeg vil forhåpentligvis beskrive hvordan modellmatching ser ut i NitrosBase i en av de følgende artiklene.
Konklusjon
Jeg håper at de generelle konturene av det som kalles multimodellering har blitt mer eller mindre tydelige for leseren. Multi-modell DBMS er ganske forskjellige, og "multi-model support" kan se annerledes ut. For å forstå hva som kalles "multi-modell" i hvert enkelt tilfelle, er det nyttig å svare på følgende spørsmål:
- Snakker vi om å støtte tradisjonelle modeller eller en slags "hybrid" modell?
- Er modellene «like», eller er en av dem gjenstand for de andre?
- Er modellene «likegyldige» til hverandre? Kan data skrevet i en modell leses i en annen eller til og med overskrives?
Jeg tror at spørsmålet om relevansen av multi-modell DBMS allerede kan besvares positivt, men det interessante spørsmålet er hvilke typer av dem som vil være mer etterspurt i nær fremtid. Det ser ut til at multi-modell DBMS som støtter tradisjonelle modeller, primært relasjonelle, vil være etterspurt; Populariteten til multi-modell DBMS, som tilbyr nye modeller som kombinerer fordelene til ulike tradisjonelle, er et spørsmål om en lengre fremtid.
Kun registrerte brukere kan delta i undersøkelsen. , vær så snill.
Bruker du multi-modell DBMS?
Vi bruker det ikke, vi lagrer alt i ett DBMS og i en modell
Vi bruker multi-modell evner av tradisjonelle DBMS
Vi trener polyglot utholdenhet
Vi bruker ny multi-modell DBMS (Arango, Orient, CosmosDB)
19 brukere stemte. 4 brukere avsto.
Kilde: www.habr.com
