Moderna informationssystem är ganska komplexa. Inte minst av allt beror deras komplexitet på komplexiteten hos de data som behandlas i dem. Datans komplexitet ligger ofta i mängden datamodeller som används. Så, till exempel, när data blir "stora", är en av de problematiska egenskaperna inte bara dess volym ("volym"), utan också dess variation ("variation").
Om du ännu inte hittar en brist i resonemanget, läs vidare.
Innehåll
Polyglott uthållighet
Ovanstående leder till det faktum att det ibland även inom ramen för ett system är nödvändigt att använda flera olika DBMS:er för att lagra data och lösa olika problem med att bearbeta dem, som var och en stöder sin egen datamodell. Med M. Fowlers lätta hand, ett antal kända böcker och en av Agile Manifesto kallas denna situation lagring med flera varianter ("polyglot persistens").
Fowler har också följande exempel på att organisera datalagring i en fullfjädrad och högbelastningsapplikation inom e-handelsområdet.
Detta exempel är förstås något överdrivet, men vissa överväganden som talar för att välja ett eller annat DBMS för motsvarande ändamål kan t.ex. .
Det är klart att det inte är lätt att vara tjänare i en sådan djurpark.
- Mängden kod som utför datalagring växer i proportion till antalet använda DBMS; mängden kodsynkroniseringsdata är bra om inte proportionell mot kvadraten på detta tal.
- Som en multipel av antalet använda DBMS ökar kostnaderna för att tillhandahålla företagsegenskaper (skalbarhet, feltolerans, hög tillgänglighet) för var och en av de använda DBMS.
- Det är omöjligt att säkerställa företagsegenskaperna för lagringsdelsystemet som helhet - särskilt transaktionalitet.
Ur djurparksdirektörens synvinkel ser allt ut så här:
- En multipel ökning av kostnaden för licenser och teknisk support från DBMS-tillverkaren.
- Överbemanning och ökade deadlines.
- Direkta ekonomiska förluster eller påföljder på grund av datainkonsekvens.
Det finns en betydande ökning av systemets totala ägandekostnad (TCO). Finns det någon väg ut ur situationen med "flera lagringsalternativ"?
Multimodell
Termen "multivariatlagring" kom i bruk 2011. Medvetenheten om problemen med tillvägagångssättet och sökandet efter en lösning tog flera år, och 2015 formulerades svaret genom Gartners analytikers mun:
- Från "»:
Framtiden för DBMS, deras arkitekturer och sätt att använda dem är multi-modell.
- Från "»:
Ledande operativa DBMS kommer att erbjuda flera modeller – relationella och icke-relationella – som en del av en enda plattform.
Det verkar som att Gartners analytiker denna gång hade rätt med sin prognos. Om du går till sidan med DBMS på DB-Engines, det kan du seоDe flesta av dess ledare positionerar sig specifikt som multi-modell DBMS. Detsamma kan ses på sidan med valfritt privat betyg.
Tabellen nedan visar DBMS - de ledande i var och en av de privata betygen, som påstår sig vara multimodeller. För varje DBMS anges den ursprungliga stödda modellen (som en gång var den enda) och tillsammans med den de modeller som stöds för närvarande. Också listade är DBMS som positionerar sig som "ursprungligen multi-modell" och, enligt skaparna, inte har någon initial ärvd modell.
| DBMS | Initial modell | Ytterligare modeller |
|---|---|---|
| Oracle | Relationellt | Graf, dokument |
| MSSQL | Relationellt | Graf, dokument |
| PostgreSQL | Relationellt | Graf*, dokument |
| Marklogic | Dokumentär | Graf, relationell |
| MongoDB | Dokumentär | Nyckel-värde, diagram* |
| DataStax | Bred kolumn | Dokumentär, graf |
| Redis | Nyckelvärde | Dokumentär, graf* |
| ArangoDB | - | Graf, dokument |
| OrientDB | - | Graf, dokument, relationell |
| Azure CosmosDB | - | Graf, dokument, relationell |
Tabellanteckningar
Asterisker i tabellen markerar uttalanden som kräver reservationer:
- PostgreSQL DBMS stöder inte grafdatamodellen, men den här produkten stöder det , såsom AgensGraph.
- I förhållande till MongoDB är det mer korrekt att tala om förekomsten av grafoperatorer i frågespråket (, ) än om att stödja grafmodellen, även om deras införande naturligtvis krävde vissa optimeringar på den fysiska lagringsnivån i riktning mot att stödja grafmodellen.
- I förhållande till Redis menar vi förlängningen .
Därefter kommer vi för var och en av klasserna att visa hur stöd för flera modeller implementeras i DBMS från denna klass. Vi kommer att betrakta relations-, dokument- och grafmodellerna som de viktigaste och använda exempel på specifika DBMS:er för att visa hur de "saknade" implementeras.
Multi-modell DBMS baserat på relationsmodellen
De ledande DBMS:erna är för närvarande relationella; Gartners prognos kunde inte anses vara sann om RDBMS:erna inte visade rörelse i riktning mot multimodellering. Och de demonstrerar. Nu kan tanken att en multimodell DBMS är som en schweizisk kniv, som inte kan göra något bra, riktas direkt till Larry Ellison.
Författaren föredrar dock implementeringen av multimodellering i Microsoft SQL Server, på vilket exemplet RDBMS-stöd för dokument- och grafmodeller kommer att beskrivas.
Dokumentmodell i MS SQL Server
Det har redan funnits två utmärkta artiklar om Habré om hur MS SQL Server implementerar stöd för dokumentmodellen; Jag kommer att begränsa mig till en kort återberättelse och kommentar:
Sättet att stödja dokumentmodellen i MS SQL Server är ganska typiskt för relationella DBMS:er: JSON-dokument föreslås lagras i vanliga textfält. Stöd för dokumentmodellen är att tillhandahålla speciella operatörer för att analysera denna JSON:
- för att extrahera skalära attributvärden,
- att extrahera underdokument.
Det andra argumentet för båda operatorerna är ett uttryck i JSONPath-liknande syntax.
Sammanfattningsvis kan vi säga att dokument som lagras på detta sätt inte är "förstklassiga enheter" i ett relationellt DBMS, till skillnad från tupler. Specifikt i MS SQL Server finns det för närvarande inga index på fälten för JSON-dokument, vilket gör det svårt att sammanfoga tabeller med värdena för dessa fält och till och med välja dokument med dessa värden. Det är dock möjligt att skapa en beräknad kolumn för ett sådant fält och ett index på det.
Dessutom ger MS SQL Server möjligheten att bekvämt konstruera ett JSON-dokument från innehållet i tabeller med hjälp av operatorn - en möjlighet, i viss mening, motsatt den tidigare, konventionell lagring. Det är uppenbart att oavsett hur snabbt ett RDBMS är så motsäger detta tillvägagångssätt ideologin för dokument-DBMS, som i huvudsak lagrar färdiga svar på populära frågor, och kan bara lösa problem med enkel utveckling, men inte hastighet.
Slutligen låter MS SQL Server dig lösa det motsatta problemet med dokumentkonstruktion: du kan dekomponera JSON i tabeller med . Om dokumentet inte är helt platt måste du använda CROSS APPLY.
Grafmodell i MS SQL Server
Stöd för grafmodellen (LPG) är också fullt implementerat i Microsoft SQL Server : Det föreslås att använda speciella tabeller för att lagra noder och för att lagra grafkanter. Sådana tabeller skapas med hjälp av uttryck CREATE TABLE AS NODE и CREATE TABLE AS EDGE respektive.
Tabeller av den första typen liknar vanliga tabeller för lagring av poster, med den enda externa skillnaden är att tabellen innehåller ett systemfält $node_id — unik identifierare för en grafnod i databasen.
På liknande sätt har tabeller av den andra typen systemfält $from_id и $to_id, poster i sådana tabeller definierar tydligt kopplingarna mellan noder. En separat tabell används för att lagra relationer av varje typ.
Låt oss illustrera detta med ett exempel. Låt grafdata ha en layout som den som visas i figuren. För att sedan skapa motsvarande struktur i databasen måste du köra följande DDL-frågor:
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 huvudsakliga specificiteten för sådana tabeller är att det i frågor mot dem är möjligt att använda grafmönster med Cypher-liknande syntax (dock "*"etc. stöds inte ännu). Baserat på prestandamätningar kan det också antas att sättet som data lagras i dessa tabeller skiljer sig från hur data lagras i vanliga tabeller och är optimerat för att utföra sådana graffrågor.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Dessutom är det ganska svårt att inte använda dessa grafmönster när man arbetar med sådana tabeller, eftersom det i vanliga SQL-frågor för att lösa liknande problem kommer att vara nödvändigt att göra ytterligare ansträngningar för att erhålla systemets "graf"-nodidentifierare ($node_id, $from_id, $to_id; Av samma anledning visas inte frågor för att infoga data här eftersom de är onödigt krångliga).
För att sammanfatta beskrivningen av implementeringarna av dokument- och grafmodellerna i MS SQL Server, vill jag notera att sådana implementeringar av en modell ovanpå en annan inte verkar framgångsrika, främst ur språkdesignsynpunkt. Det är nödvändigt att utöka ett språk med ett annat, språken är inte helt "ortogonala", kompatibilitetsreglerna kan vara ganska bisarra.
Multi-modell DBMS baserat på dokumentmodellen
I det här avsnittet skulle jag vilja illustrera implementeringen av multimodell i dokument-DBMS med exemplet på den inte mest populära av dem, MongoDB (som sagt, den har bara villkorade grafoperatorer $lookup и $graphLookup, arbetar inte med fragmenterade samlingar), utan använder exemplet med ett mer mogen och "företagande" DBMS .
Så låt samlingen innehålla en uppsättning XML-dokument av följande typ (MarkLogic låter dig också lagra JSON-dokument):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Relationsmodell i MarkLogic
En relationsvy av en samling dokument kan skapas med hjälp av (innehåll av element value i exemplet nedan kan det finnas en godtycklig 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 adressera den skapade vyn med en SQL-fråga (till exempel via ODBC):
SELECT name, surname FROM Person WHERE name="John"Tyvärr är den relationsvy som skapas av visningsmallen skrivskyddad. Vid bearbetning av en begäran om det kommer MarkLogic att försöka använda . Tidigare hade MarkLogic begränsade relationella åsikter, helt och hållet och skrivbara, men nu anses de föråldrade.
Grafmodell i MarkLogic
Med stöd för grafmodellen (RDF) är allt ungefär sig likt. Återigen med hjälp du kan skapa en RDF-representation av en samling dokument från exemplet ovan:
<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 adressera den resulterande RDF-grafen med en SPARQL-fråga:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Till skillnad från den relationella stöder MarkLogic grafmodellen på två andra sätt:
- Ett DBMS kan vara en fullfjädrad separat lagring av RDF-data (tripletter i den kommer att anropas i motsats till de ovan beskrivna ).
- RDF i speciell serialisering kan helt enkelt infogas i XML- eller JSON-dokument (och tripletter kommer då att anropas ). Detta är förmodligen ett alternativ till mekanismer
idrefetc.
En bra uppfattning om hur saker "verkligen" fungerar i MarkLogic ges av , i denna mening är det lågnivå, även om dess syfte snarare är det motsatta - att försöka abstrahera från den använda datamodellen, för att säkerställa konsekvent arbete med data i olika modeller, transaktionalitet, etc.
Multi-modell DBMS "utan en huvudmodell"
Det finns även DBMS på marknaden som positionerar sig som initialt multimodeller, utan någon ärvd huvudmodell. Dessa inkluderar , (sedan 2018 tillhör utvecklingsbolaget SAP) och (tjänst som en del av Microsoft Azure molnplattform).
Faktum är att det finns "kärnmodeller" i ArangoDB och OrientDB. I båda fallen är det deras egna datamodeller, som är generaliseringar av dokument ett. Generaliseringarna är främst till för att underlätta möjligheten att utföra frågor av grafisk och relationell karaktär.
Dessa modeller är de enda som är tillgängliga för användning i det angivna DBMS; deras egna frågespråk är designade för att fungera med dem. Naturligtvis är sådana modeller och DBMS lovande, men bristen på kompatibilitet med standardmodeller och språk gör det omöjligt att använda dessa DBMS i äldre system – för att ersätta de DBMS som redan används där.
Det fanns redan en underbar artikel om ArangoDB och OrientDB på Habré: .
ArangoDB
ArangoDB hävdar stöd för en grafdatamodell.
Noderna i en graf i ArangoDB är vanliga dokument, och kanterna är dokument av en speciell typ som tillsammans med vanliga systemfält har (_key, _id, _rev) systemfält _from и _to. Dokument i dokument-DBMS kombineras traditionellt till samlingar. Samlingar av dokument som representerar kanter kallas kantsamlingar i ArangoDB. Kantsamlingsdokument är förresten också dokument, så kanter i ArangoDB kan också fungera som noder.
Rå data
Låt oss ha en samling persons, vars dokument ser ut så här:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Låt det också finnas en samling cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Sedan samlingen likes kan se ut så här:
[
{
"_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
}
]Frågor och resultat
En fråga i grafisk stil i AQL-språket som används i ArangoDB, som returnerar information i läsbar form om vem som gillar vilket kafé, ser ut så här:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }I en relationsstil, där vi "beräknar" relationer snarare än att lagra dem, kan denna fråga skrivas om så här (förresten, utan samlingen likes kunde klara sig utan):
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 båda fallen blir detsamma:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Fler frågor och resultat
Om resultatformatet ovan verkar vara mer typiskt för en relations-DBMS än för ett dokument-DBMS, kan du prova den här frågan (eller så kan du använda ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Resultatet kommer att se ut så här:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
Grunden för att implementera en grafmodell ovanpå en dokumentmodell i OrientDB är dokumentfält har, förutom mer eller mindre standardskalära värden, även värden av typer som t.ex LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Värdena för dessa typer är länkar eller samlingar av länkar till dokument.
Dokumentidentifieraren som tilldelas av systemet har en "fysisk betydelse", som indikerar postens position i databasen, och ser ut ungefär så här: @rid : #3:16. Således är värdena för referensegenskaper egentligen pekare (som i grafmodellen) snarare än urvalsvillkor (som i relationsmodellen).
Liksom ArangoDB representeras kanter i OrientDB som separata dokument (även om en kant inte har sina egna egenskaper kan den göras , och det kommer inte att motsvara ett separat dokument).
Rå data
I ett format nära OrientDB databas, data från föregående exempel för ArangoDB skulle se ut ungefär så här:
[
{
"@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 lagrar hörn också information om inkommande och utgående kanter. På Document API måste själv övervaka referensintegriteten, och Graph API tar på sig detta arbete. Men låt oss se hur åtkomst till OrientDB ser ut i "rena" frågespråk som inte är integrerade i programmeringsspråk.
Frågor och resultat
En fråga som till sin syfte liknar frågan från exemplet för ArangoDB i OrientDB ser ut så här:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameResultatet kommer att erhållas i följande form:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Om resultatformatet igen verkar för "relationellt", måste du ta bort raden med :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]OrientDB:s frågespråk kan beskrivas som SQL med Gremlin-liknande inlägg. I version 2.2 dök ett Cypher-liknande begärandeformulär upp, :
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 kommer att vara detsamma som i föregående begäran. Tänk på vad som behöver tas bort för att göra det mer "relationellt", som i den allra första frågan.
Azure CosmosDB
I mindre utsträckning gäller det som sades ovan om ArangoDB och OrientDB för Azure CosmosDB. CosmosDB tillhandahåller följande dataåtkomst-API:er: SQL, MongoDB, Gremlin och Cassandra.
SQL API och MongoDB API används för att komma åt data i dokumentmodellen. Gremlin API och Cassandra API - för åtkomst av data i graf- respektive kolumnformat. Data i alla modeller sparas i CosmosDBs interna modellformat: ("atom-rekord-sekvens"), som också ligger nära dokumentet en.
Men datamodellen som valts av användaren och API:et som används är fasta vid tidpunkten för att skapa ett konto i tjänsten. Det är inte möjligt att komma åt data som laddats i en modell i en annan modells format, vilket illustreras av något i stil med detta:
Således, multi-modell i Azure CosmosDB idag är bara möjligheten att använda flera databaser som stöder olika modeller från en tillverkare, vilket inte löser alla problem med multi-variant lagring.
Multi-modell DBMS baserat på en grafmodell?
Anmärkningsvärt är det faktum att det ännu inte finns några flermodells-DBMS på marknaden som är baserade på en grafmodell (förutom stöd för flera modeller för samtidigt två grafmodeller: RDF och LPG; se detta i ). De största svårigheterna orsakas av implementeringen av en dokumentmodell ovanpå en grafmodell, snarare än en relationsmodell.
Frågan om hur man implementerar en relationsmodell ovanpå grafmodellen övervägdes även under bildandet av den senare. Hur Till exempel, :
Det finns inget inneboende i grafmetoden som hindrar att skapa ett lager (t.ex. genom lämplig indexering) på en grafdatabas som möjliggör en relationsvy med (1) återhämtning av tupler från de vanliga nyckelvärdesparen och (2) gruppering av tupler efter relationstyp.
När du implementerar en dokumentmodell ovanpå en grafmodell måste du till exempel tänka på följande:
- Element i en JSON-array anses vara ordnade, men de som kommer från spetsen på en kant av grafen är det inte;
- Data i dokumentmodellen denormaliseras vanligtvis; du vill fortfarande inte lagra flera kopior av samma inbäddade dokument, och underdokument har vanligtvis inga identifierare;
- Å andra sidan är ideologin med dokument-DBMS:er att dokument är färdiga "aggregat" som inte behöver byggas på nytt varje gång. Det krävs att grafmodellen har möjlighet att snabbt få en subgraf som motsvarar det färdiga dokumentet.
En del reklam
Författaren till artikeln är relaterad till utvecklingen av NitrosBase DBMS, vars interna modell är graf, och de externa modellerna - relationella och dokument - är dess representationer. Alla modeller är lika: nästan all data är tillgänglig i någon av dem med ett frågespråk som är naturligt för det. Dessutom kan data ändras i vilken vy som helst. Förändringar kommer att återspeglas i den interna modellen och följaktligen i andra synpunkter.
Jag kommer förhoppningsvis att beskriva hur modellmatchning ser ut i NitrosBase i någon av följande artiklar.
Slutsats
Jag hoppas att de allmänna konturerna av det som kallas multimodellering har blivit mer eller mindre tydliga för läsaren. Multi-modell DBMS är ganska olika, och "multi-model support" kan se olika ut. För att förstå vad som kallas "multimodell" i varje specifikt fall är det användbart att svara på följande frågor:
- Pratar vi om att stödja traditionella modeller eller någon form av "hybrid" modell?
- Är modellerna "lika", eller är en av dem föremål för de andra?
- Är modellerna "likgiltiga" för varandra? Kan data skrivna i en modell läsas i en annan eller till och med skrivas över?
Jag tror att frågan om relevansen av multi-modell DBMS redan kan besvaras positivt, men den intressanta frågan är vilka typer av dem som kommer att vara mer efterfrågade inom en snar framtid. Det verkar som om DBMS med flera modeller som stöder traditionella modeller, i första hand relationsbaserade, kommer att ha större efterfrågan; Populariteten hos multi-modell DBMS, som erbjuder nya modeller som kombinerar fördelarna med olika traditionella, är en fråga om en längre framtid.
Endast registrerade användare kan delta i undersökningen. , Snälla du.
Använder du multi-model DBMS?
-
Vi använder det inte, vi lagrar allt i ett DBMS och i en modell
-
Vi använder flera modeller av traditionella DBMS:er
-
Vi övar polyglott uthållighet
-
Vi använder nya multi-modell DBMS (Arango, Orient, CosmosDB)
19 användare röstade. 4 användare avstod från att rösta.
Källa: will.com