Moderne informationssystemer er ret komplekse. Ikke mindst af alt skyldes deres kompleksitet kompleksiteten af de data, der behandles i dem. Kompleksiteten af data ligger ofte i de mange forskellige anvendte datamodeller. Så når for eksempel data bliver "store", er en af de problematiske egenskaber ikke kun dens volumen ("volumen"), men også dens variation ("variation").

Hvis du endnu ikke finder en fejl i begrundelsen, så læs videre.

Indhold

Polyglot vedholdenhed
Multi-model
Multi-model DBMS baseret på den relationelle model
     Dokumentmodel i MS SQL Server
     Grafmodel i MS SQL Server
Multi-model DBMS baseret på dokumentmodellen
     Relationsmodel i MarkLogic
     Grafmodel i MarkLogic
Multi-model DBMS "uden en hovedmodel"
     ArangoDB
     OrientDB
     Azure CosmosDB
Multi-model DBMS baseret på en grafmodel?
Konklusion
Опрос

Polyglot vedholdenhed

Ovenstående fører til det faktum, at det nogle gange selv inden for rammerne af et system er nødvendigt at bruge flere forskellige DBMS'er til at lagre data og løse forskellige problemer med at behandle dem, som hver understøtter sin egen datamodel. Med M. Fowlers lette hånd, forfatter en række kendte bøger og en af medforfattere Agile Manifest, kaldes denne situation multi-variant lagring ("polyglot persistens").

Fowler har også følgende eksempel på organisering af datalagring i en fuldt udstyret og høj belastningsapplikation inden for e-handel.

Dette eksempel er selvfølgelig noget overdrevet, men nogle overvejelser til fordel for at vælge et eller andet DBMS til det tilsvarende formål kan f.eks. her.

Det er klart, at det ikke er let at være tjener i sådan en zoologisk have.

Mængden af kode, der udfører datalagring, vokser i forhold til antallet af anvendte DBMS'er; mængden af kodesynkroniseringsdata er god, hvis ikke proportional med kvadratet af dette tal.
Som et multiplum af antallet af anvendte DBMS'er stiger omkostningerne ved at levere virksomhedskarakteristika (skalerbarhed, fejltolerance, høj tilgængelighed) for hver af de anvendte DBMS'er.
Det er umuligt at sikre virksomhedens karakteristika for lagerundersystemet som helhed - især transaktionalitet.

Fra zoo-direktørens synspunkt ser alt sådan ud:

En multipel stigning i omkostningerne til licenser og teknisk support fra DBMS-producenten.
Overbemanding og øgede deadlines.
Direkte økonomiske tab eller bøder på grund af datainkonsistens.

Der er en markant stigning i systemets samlede ejeromkostninger (TCO). Er der nogen vej ud af situationen med "flere opbevaringsmuligheder"?

Multi-model

Udtrykket "multivariat opbevaring" kom i brug i 2011. Bevidstheden om problemerne ved tilgangen og søgen efter en løsning tog flere år, og i 2015 blev svaret formuleret gennem Gartner-analytikeres mund:

Fra "Markedsvejledning til NoSQL DBMS'er - 2015»:
Fremtiden for DBMS'er, deres arkitekturer og måder at bruge dem på er multi-model.
Fra "Magic Quadrant til ODBMS - 2016»:
Førende operationelle DBMS'er vil tilbyde flere modeller – relationelle og ikke-relationelle – som en del af en enkelt platform.

Det ser ud til, at Gartner-analytikerne denne gang havde ret med deres prognose. Hvis du går til siden med hovedvurdering DBMS på DB-Engines, det kan du seоDe fleste af dets ledere positionerer sig specifikt som multi-model DBMS'er. Det samme kan ses på siden med enhver privat vurdering.

Tabellen nedenfor viser DBMS - de førende i hver af de private vurderinger, som hævder at være multi-model. For hver DBMS angives den originale understøttede model (som engang var den eneste) og sammen med den de modeller, der aktuelt understøttes. Også anført er DBMS'er, der positionerer sig selv som "oprindeligt multi-model", og ifølge skaberne ikke har nogen oprindelig arvet model.

DBMS	Indledende model	Yderligere modeller
Oracle	relationelle	Graf, dokument
MSSQL	relationelle	Graf, dokument
PostgreSQL	relationelle	Graf*, dokument
MarkLogic	Dokumentar	Graf, relationel
MongoDB	Dokumentar	Nøgleværdi, graf*
DataStax	Bred kolonne	Dokumentar, graf
Omfor	Nøgle-værdi	Dokumentar, graf*
ArangoDB	—	Graf, dokument
OrientDB	—	Graf, dokument, relationel
Azure CosmosDB	—	Graf, dokument, relationel

Noter på bordet

Stjerner i tabellen markerer udsagn, der kræver forbehold:

PostgreSQL DBMS understøtter ikke grafdatamodellen, men dette produkt understøtter den baseret på det, såsom AgensGraph.
I forhold til MongoDB er det mere korrekt at tale om tilstedeværelsen af grafoperatorer i forespørgselssproget ($lookup, $graphLookup) end om at understøtte grafmodellen, selvom deres introduktion naturligvis krævede nogle optimeringer på det fysiske lagerniveau i retning af at understøtte grafmodellen.
I forhold til Redis mener vi forlængelsen RedisGraph.

Dernæst vil vi for hver af klasserne vise, hvordan understøttelse af flere modeller er implementeret i DBMS fra denne klasse. Vi vil betragte relations-, dokument- og grafmodellerne som de vigtigste og bruge eksempler på specifikke DBMS'er til at vise, hvordan de "manglende" implementeres.

Multi-model DBMS baseret på den relationelle model

De førende DBMS'er er i øjeblikket relationelle. Gartners prognose kunne ikke anses for sand, hvis RDBMS'er ikke viste bevægelse i retning af multi-modellering. Og de demonstrerer. Nu kan ideen om, at en multi-model DBMS er som en schweizisk kniv, der ikke kan gøre noget godt, rettes direkte til Larry Ellison.

Forfatteren foretrækker dog implementeringen af multi-modellering i Microsoft SQL Server, på hvilket eksempel RDBMS-understøttelse af dokument- og grafmodeller vil blive beskrevet.

Dokumentmodel i MS SQL Server

Der har allerede været to fremragende artikler om Habré om, hvordan MS SQL Server implementerer understøttelse af dokumentmodellen. Jeg vil begrænse mig til en kort genfortælling og kommentar:

Måden at understøtte dokumentmodellen i MS SQL Server er ret typisk for relationelle DBMS'er: JSON-dokumenter foreslås gemt i almindelige tekstfelter. Understøttelse af dokumentmodellen er at give specielle operatører til at parse denne JSON:

JSON_VALUE at udtrække skalære attributværdier,
JSON_QUERY at udtrække underdokumenter.

Det andet argument for begge operatorer er et udtryk i JSONPath-lignende syntaks.

Abstrakt kan vi sige, at dokumenter gemt på denne måde ikke er "førsteklasses entiteter" i et relationelt DBMS, i modsætning til tuples. Specifikt er der i MS SQL Server i øjeblikket ingen indekser på felterne i JSON-dokumenter, hvilket gør det vanskeligt at forbinde tabeller ved hjælp af værdierne i disse felter og endda vælge dokumenter ved hjælp af disse værdier. Det er dog muligt at oprette en beregnet kolonne for et sådant felt og et indeks på det.

Derudover giver MS SQL Server mulighed for bekvemt at konstruere et JSON-dokument ud fra indholdet af tabeller ved hjælp af operatoren FOR JSON PATH - en mulighed, i en vis forstand, modsat den foregående, konventionel opbevaring. Det er klart, at uanset hvor hurtig en RDBMS er, er denne tilgang i modstrid med ideologien bag dokument-DBMS'er, som i det væsentlige gemmer færdige svar på populære forespørgsler og kun kan løse problemer med nem udvikling, men ikke hastighed.

Endelig giver MS SQL Server dig mulighed for at løse det omvendte problem med dokumentkonstruktion: du kan dekomponere JSON i tabeller ved hjælp af OPENJSON. Hvis dokumentet ikke er helt fladt, skal du bruge CROSS APPLY.

Grafmodel i MS SQL Server

Understøttelse af grafmodellen (LPG) er også fuldt implementeret i Microsoft SQL Server forudsigelig: Det foreslås at bruge specielle tabeller til lagring af noder og til lagring af grafkanter. Sådanne tabeller oprettes ved hjælp af udtryk CREATE TABLE AS NODE и CREATE TABLE AS EDGE hhv.

Tabeller af den første type ligner almindelige tabeller til lagring af poster, med den eneste eksterne forskel er, at tabellen indeholder et systemfelt $node_id — entydig identifikator for en grafknude i databasen.

På samme måde har tabeller af den anden type systemfelter $from_id и $to_id, indgange i sådanne tabeller definerer klart forbindelserne mellem noder. En separat tabel bruges til at gemme relationer af hver type.

Lad os illustrere dette med et eksempel. Lad grafdataene have et layout som det vist på figuren. For at oprette den tilsvarende struktur i databasen skal du køre følgende DDL-forespørgsler:

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);

Den vigtigste specificitet ved sådanne tabeller er, at det i forespørgsler mod dem er muligt at bruge grafmønstre med Cypher-lignende syntaks (dog "*"osv. er endnu ikke understøttet). Baseret på præstationsmålinger kan det også antages, at måden data gemmes i disse tabeller er forskellig fra måden data gemmes i almindelige tabeller og er optimeret til at udføre sådanne grafforespørgsler.

SELECT Cafe.name
  FROM Person, likes, Cafe
  WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
  AND Person.name = 'John';

Desuden er det ret svært ikke at bruge disse grafmønstre, når man arbejder med sådanne tabeller, da det i almindelige SQL-forespørgsler for at løse lignende problemer vil være nødvendigt at gøre yderligere bestræbelser på at opnå system-"graf"-node-identifikatorer ($node_id, $from_id, $to_id; Af samme grund vises forespørgsler til indsættelse af data ikke her, da de er unødvendigt besværlige).

For at opsummere beskrivelsen af implementeringerne af dokument- og grafmodellerne i MS SQL Server, vil jeg bemærke, at sådanne implementeringer af en model oven på en anden ikke ser ud til at være vellykket, primært set ud fra et sprogdesigns synspunkt. Det er nødvendigt at udvide et sprog med et andet, sprogene er ikke helt "ortogonale", kompatibilitetsreglerne kan være ret bizarre.

Multi-model DBMS baseret på dokumentmodellen

I dette afsnit vil jeg gerne illustrere implementeringen af multi-model i dokument DBMS'er ved at bruge eksemplet på den ikke mest populære af dem, MongoDB (som det blev sagt, den har kun betingede grafoperatorer $lookup и $graphLookup, arbejder ikke på opdelte samlinger), men bruger eksemplet med en mere moden og "virksomhed" DBMS MarkLogic.

Så lad samlingen indeholde et sæt XML-dokumenter af følgende type (MarkLogic giver dig også mulighed for at gemme JSON-dokumenter):

<Person INN="631803299804">
  <name>John</name>
  <surname>Smith</surname>
</Person>

Relationsmodel i MarkLogic

En relationel visning af en samling af dokumenter kan oprettes vha display skabelon (indhold af elementer value i eksemplet nedenfor kan der 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 oprettede visning med en SQL-forespørgsel (for eksempel via ODBC):

SELECT name, surname FROM Person WHERE name="John"

Desværre er den relationelle visning, der er oprettet af visningsskabelonen, skrivebeskyttet. Ved behandling af en anmodning om det, vil MarkLogic forsøge at bruge dokumentindekser. Tidligere havde MarkLogic fuldstændig begrænsede relationelle synspunkter indeks baseret og skrivbare, men nu betragtes de som forældede.

Grafmodel i MarkLogic

Med understøttelse af grafmodellen (RDF) er alt omtrent det samme. Igen med hjælp display skabelon Du kan oprette en RDF-repræsentation af en samling af 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-graf med en SPARQL-forespørgsel:

PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
  :631803299804 :name ?name ; :surname ?surname .
}

I modsætning til den relationelle understøtter MarkLogic grafmodellen på to andre måder:

Et DBMS kan være en fuldgyldig separat lagring af RDF-data (tripletter i det vil blive kaldt lykkedes i modsætning til de ovenfor beskrevne ekstraheret).
RDF i speciel serialisering kan simpelthen indsættes i XML- eller JSON-dokumenter (og tripletter vil så blive kaldt ikke-administreret). Dette er sandsynligvis et alternativ til mekanismer idref etc.

En god idé om, hvordan tingene "virkelig" fungerer i MarkLogic, er givet af Optisk API, i denne forstand er det lavt niveau, selvom formålet snarere er det modsatte - at forsøge at abstrahere fra den anvendte datamodel, at sikre ensartet arbejde med data i forskellige modeller, transaktionalitet mv.

Multi-model DBMS "uden en hovedmodel"

Der er også DBMS'er på markedet, der positionerer sig som oprindeligt multi-model, uden nogen nedarvet hovedmodel. Disse omfatter ArangoDB, OrientDB (siden 2018 har udviklingsselskabet tilhørt SAP) og KosmosDB (tjeneste som en del af Microsoft Azure cloud-platformen).

Faktisk er der "kerne"-modeller i ArangoDB og OrientDB. I begge tilfælde er der tale om deres egne datamodeller, som er generaliseringer af dokumentet en. Generaliseringerne skal hovedsageligt lette muligheden for at udføre forespørgsler af grafisk og relationel karakter.

Disse modeller er de eneste, der er tilgængelige til brug i det angivne DBMS, deres egne forespørgselssprog er designet til at arbejde med dem. Selvfølgelig er sådanne modeller og DBMS'er lovende, men manglen på kompatibilitet med standardmodeller og -sprog gør det umuligt at bruge disse DBMS'er i ældre systemer - for at erstatte de DBMS'er, der allerede bruges der.

Der var allerede en vidunderlig artikel om ArangoDB og OrientDB på Habré: JOIN i NoSQL-databaser.

ArangoDB

ArangoDB hævder støtte til en grafdatamodel.

Noderne i en graf i ArangoDB er almindelige dokumenter, og kanterne er dokumenter af en speciel type, der sammen med almindelige systemfelter har (_key, _id, _rev) systemfelter _from и _to. Dokumenter i dokument-DBMS'er kombineres traditionelt til samlinger. Samlinger af dokumenter, der repræsenterer kanter, kaldes kantsamlinger i ArangoDB. Edgesamlingsdokumenter er i øvrigt også dokumenter, så kanter i ArangoDB kan også fungere som noder.

Indledende data

Lad os få en samling persons, hvis dokumenter ser sådan ud:

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "Алиса"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Боб"  
  }
]

Lad der også være en samling cafes:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "Джон Донн"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Жан-Жак"
  }
]

Så indsamlingen likes kan se sådan ud:

[
  {
    "_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 
  }
]

Forespørgsler og resultater

En forespørgsel i grafisk stil i AQL-sproget, der bruges i ArangoDB, der returnerer i menneskelæselig form information om, hvem der kan lide hvilken cafe, ser sådan ud:

FOR p IN persons
  FOR c IN OUTBOUND p likes
  RETURN { person : p.name , likes : c.name }

I en relationel stil, hvor vi "beregner" relationer i stedet for at gemme dem, kan denne forespørgsel omskrives sådan (i øvrigt uden samlingen likes kunne undvære):

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 tilfælde vil være det samme:

[
  { "person" : "Алиса" , likes : "Жан-Жак" } ,
  { "person" : "Алиса" , likes : "Джон Донн" } ,
  { "person" : "Боб" , likes : "Джон Донн" }
]

Flere forespørgsler og resultater

Hvis resultatformatet ovenfor ser ud til at være mere typisk for et relationelt DBMS end for et dokument DBMS, kan du prøve denne forespørgsel (eller du kan bruge COLLECT):

FOR p IN persons
  RETURN {
    person : p.name,
    likes : (
      FOR c IN OUTBOUND p likes
      RETURN c.name
    )
}

Resultatet vil se således ud:

[
  { "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"]  } ,
  { "person" : "Боб" , likes : ["Джон Донн"] }
]

OrientDB

Grundlaget for at implementere en grafmodel oven på en dokumentmodel i OrientDB er lejlighed dokumentfelter har udover mere eller mindre standard skalarværdier også værdier af typer som f.eks LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Værdierne af disse typer er links eller samlinger af links til systemidentifikatorer Dokumenter.

Dokumentidentifikationen, der er tildelt af systemet, har en "fysisk betydning", der angiver postens position i databasen og ser sådan ud: @rid : #3:16. Værdierne af referenceegenskaber er således virkelig pointere (som i grafmodellen) snarere end udvælgelsesbetingelser (som i relationsmodellen).

Ligesom ArangoDB er kanter i OrientDB repræsenteret som separate dokumenter (selvom hvis en kant ikke har sine egne egenskaber, kan den laves letvægts, og det vil ikke svare til et separat dokument).

Indledende data

I et format tæt på dump-format OrientDB database, dataene fra det forrige eksempel for ArangoDB ville se sådan ud:

[
     {
      "@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, gemmer toppunkter også information om indgående og udgående kanter. På ved brug af Document API'et skal selv overvåge referenceintegriteten, og Graph API'en påtager sig dette arbejde. Men lad os se, hvordan adgang til OrientDB ser ud i "rene" forespørgselssprog, der ikke er integreret i programmeringssprog.

Forespørgsler og resultater

En forespørgsel svarende til formålet med forespørgslen fra eksemplet for ArangoDB i OrientDB ser sådan ud:

SELECT name AS person_name, OUT('likes').name AS cafe_name
   FROM Person
   UNWIND cafe_name

Resultatet vil blive opnået i følgende form:

[
  { "person_name": "Алиса", "cafe_name": "Джон Донн" },
  { "person_name": "Алиса", "cafe_name": "Жан-Жак" },
  { "person_name": "Боб",  "cafe_name": "Жан-Жак" }
]

Hvis resultatformatet igen virker for "relationelt", skal du fjerne stregen med UNWIND():

[
  { "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
  { "person_name": "Боб",  "cafe_name": [ "Жан-Жак" ' }
]

OrientDBs forespørgselssprog kan beskrives som SQL med Gremlin-lignende inserts. I version 2.2 dukkede en Cypher-lignende anmodningsformular op, MATCH :

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_name

Resultatformatet vil være det samme som i den tidligere anmodning. Tænk over, hvad der skal fjernes for at gøre det mere "relationelt", som i den allerførste forespørgsel.

Azure CosmosDB

I mindre grad gælder det, der blev sagt ovenfor om ArangoDB og OrientDB, for Azure CosmosDB. CosmosDB leverer følgende dataadgangs-API'er: SQL, MongoDB, Gremlin og Cassandra.

SQL API og MongoDB API bruges til at få adgang til data i dokumentmodellen. Gremlin API og Cassandra API - til at få adgang til data i henholdsvis graf- og kolonneformater. Data i alle modeller gemmes i CosmosDB interne modelformat: ARS ("atom-record-sekvens"), som også ligger tæt på dokumentet en.

Men datamodellen valgt af brugeren og den anvendte API er faste på tidspunktet for oprettelse af en konto i tjenesten. Det er ikke muligt at få adgang til data indlæst i én model i en anden models format, som illustreret af noget som dette:

Således er multi-model i Azure CosmosDB i dag kun muligheden for at bruge flere databaser, der understøtter forskellige modeller fra én producent, hvilket ikke løser alle problemerne med multi-variant storage.

Multi-model DBMS baseret på en grafmodel?

Bemærkelsesværdigt er det faktum, at der endnu ikke er multi-model DBMS'er på markedet, der er baseret på en grafmodel (medmindre vi overvejer multi-model support for to grafmodeller samtidigt: RDF og LPG; se dette i tidligere udgivelse). De største vanskeligheder skyldes implementeringen af en dokumentmodel oven på en grafmodel, snarere end en relationel.

Spørgsmålet om, hvordan man implementerer en relationel model oven på grafmodellen, blev overvejet selv under dannelsen af sidstnævnte. Hvordan Han sagdeFor eksempel David McGovern:

Der er intet iboende i graftilgangen, der forhindrer oprettelse af et lag (f.eks. ved passende indeksering) på en grafdatabase, der muliggør en relationel visning med (1) gendannelse af tupler fra de sædvanlige nøgleværdipar og (2) gruppering af tupler efter relationstype.

Når du implementerer en dokumentmodel oven på en grafmodel, skal du for eksempel huske på følgende:

Elementer i et JSON-array betragtes som ordnede, men dem, der udgår fra toppen af en kant af grafen, er det ikke;
Data i dokumentmodellen er normalt denormaliseret, du vil stadig ikke gemme flere kopier af det samme indlejrede dokument, og underdokumenter har normalt ikke identifikatorer;
På den anden side er ideologien med dokument-DBMS'er, at dokumenter er færdige "aggregater", der ikke skal bygges på ny hver gang. Det er påkrævet at give grafmodellen mulighed for hurtigt at få en undergraf svarende til det færdige dokument.

Lidt reklame

Artiklens forfatter er relateret til udviklingen af NitrosBase DBMS, hvis interne model er graf, og de eksterne modeller - relationelle og dokument - er dens repræsentationer. Alle modeller er ens: Næsten alle data er tilgængelige i enhver af dem ved hjælp af et forespørgselssprog, der er naturligt for det. Desuden kan dataene ændres i enhver visning. Ændringer vil blive afspejlet i den interne model og følgelig i andre synspunkter.

Jeg vil forhåbentlig beskrive, hvordan modelmatching ser ud i NitrosBase i en af de følgende artikler.

Konklusion

Jeg håber, at de generelle konturer af det, man kalder multimodellering, er blevet mere eller mindre tydelige for læseren. Multi-model DBMS'er er ret forskellige, og "multi-model support" kan se anderledes ud. For at forstå, hvad der kaldes "multi-model" i hvert enkelt tilfælde, er det nyttigt at besvare følgende spørgsmål:

Taler vi om at understøtte traditionelle modeller eller en slags "hybrid" model?
Er modellerne "lige", eller er en af dem genstand for de andre?
Er modellerne "ligeglade" med hinanden? Kan data skrevet i én model læses i en anden eller endda overskrives?

Jeg tror, at spørgsmålet om relevansen af multi-model DBMS allerede kan besvares positivt, men det interessante spørgsmål er, hvilke typer af dem der vil være mere efterspurgte i den nærmeste fremtid. Det ser ud til, at multi-model DBMS'er, der understøtter traditionelle modeller, primært relationelle, vil være i større efterspørgsel; Populariteten af multi-model DBMS'er, der tilbyder nye modeller, der kombinerer fordelene ved forskellige traditionelle, er et spørgsmål om en længere fremtid.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.