Moderné informačné systémy sú pomerne zložité. V neposlednom rade je ich komplexnosť spôsobená komplexnosťou údajov v nich spracovaných. Zložitosť údajov často spočíva v rôznorodosti použitých dátových modelov. Keď sa teda napríklad údaje stanú „veľkými“, jednou z problematických charakteristík je nielen ich objem („objem“), ale aj ich rozmanitosť („rozmanitosť“).
Ak ešte nenájdete chybu v zdôvodnení, čítajte ďalej.
Obsah
Polyglotná vytrvalosť
Vyššie uvedené vedie k tomu, že niekedy aj v rámci jedného systému je potrebné na ukladanie údajov a riešenie rôznych problémov ich spracovania použiť viacero rôznych DBMS, z ktorých každý podporuje svoj vlastný dátový model. S ľahkou rukou M. Fowlera, množstvo slávnych kníh a jedna z nich Agile Manifesto, nazýva sa táto situácia multivariantné úložisko („polyglotná vytrvalosť“).
Fowler má aj nasledujúci príklad organizácie ukladania dát v plnohodnotnej a vysoko zaťaženej aplikácii v oblasti elektronického obchodu.
Tento príklad je, samozrejme, trochu prehnaný, ale možno nájsť niekoľko úvah v prospech výberu jedného alebo druhého DBMS na zodpovedajúci účel, napr. .
Je jasné, že byť sluhom v takejto zoo nie je jednoduché.
- Množstvo kódu, ktorý vykonáva ukladanie údajov, rastie úmerne s počtom použitých DBMS; množstvo údajov na synchronizáciu kódu je dobré, ak nie je úmerné druhej mocnine tohto čísla.
- Ako násobok počtu použitých DBMS sa zvyšujú náklady na poskytovanie podnikových charakteristík (škálovateľnosť, odolnosť voči chybám, vysoká dostupnosť) každého z použitých DBMS.
- Nie je možné zabezpečiť podnikové charakteristiky úložného subsystému ako celku – najmä transakčnú.
Z pohľadu riaditeľa zoo všetko vyzerá takto:
- Viacnásobné zvýšenie nákladov na licencie a technickú podporu od výrobcu DBMS.
- Prebytok zamestnancov a zvýšené termíny.
- Priame finančné straty alebo sankcie v dôsledku nesúladu údajov.
Došlo k výraznému zvýšeniu celkových nákladov na vlastníctvo systému (TCO). Existuje nejaké východisko zo situácie „možností viacerých úložných priestorov“?
Viacmodelový
Termín „multivariačné úložisko“ sa začal používať v roku 2011. Uvedomenie si problémov prístupu a hľadanie riešenia trvalo niekoľko rokov a do roku 2015 bola ústami analytikov Gartner sformulovaná odpoveď:
- Od "»:
Budúcnosť DBMS, ich architektúry a spôsobov ich využitia je multimodelová.
- Od "»:
Popredné prevádzkové DBMS budú ponúkať viacero modelov – relačných aj nerelačných – ako súčasť jedinej platformy.
Zdá sa, že tentoraz mali analytici Gartner pravdu so svojou prognózou. Ak prejdete na stránku s DBMS na DB-Engines, môžete to vidieťоVäčšina jej lídrov sa stavia špecificky ako multimodelové DBMS. To isté možno vidieť na stránke s akýmkoľvek súkromným hodnotením.
Nasledujúca tabuľka ukazuje DBMS – lídrov v každom zo súkromných ratingov, ktoré tvrdia, že sú multimodelové. Pre každý DBMS je uvedený pôvodný podporovaný model (kedysi jediný) a spolu s ním aj aktuálne podporované modely. Uvedené sú aj DBMS, ktoré sa stavajú ako „pôvodne multimodelové“ a podľa tvorcov nemajú žiadny pôvodný zdedený model.
| DBMS | Počiatočný model | Ďalšie modely |
|---|---|---|
| veštec | Relačný | Graf, dokument |
| MS SQL | Relačný | Graf, dokument |
| PostgreSQL | Relačný | Graf*, dokument |
| MarkLogic | Dokumentárny | Graf, vzťahový |
| MongoDB | Dokumentárny | Pár kľúč – hodnota, graf* |
| DataStax | Široký stĺpec | Dokumentárny film, graf |
| Redis | Kľúč – hodnota | Dokumentárny film, graf* |
| ArangoDB | - | Graf, dokument |
| OrientDB | - | Graf, dokument, vzťah |
| Azure CosmosDB | - | Graf, dokument, vzťah |
Poznámky na stole
Hviezdičky v tabuľke označujú výroky, ktoré vyžadujú rezerváciu:
- PostgreSQL DBMS nepodporuje grafový dátový model, ale tento produkt ho podporuje , ako je napríklad AgensGraph.
- Vo vzťahu k MongoDB je správnejšie hovoriť o prítomnosti grafových operátorov v dopytovacom jazyku (, ) než o podporu grafového modelu, aj keď si ich zavedenie samozrejme vyžiadalo určité optimalizácie na úrovni fyzického úložiska v smere podpory grafového modelu.
- Vo vzťahu k Redis máme na mysli rozšírenie .
Ďalej si pre každú z tried ukážeme, ako je v DBMS z tejto triedy implementovaná podpora viacerých modelov. Za najdôležitejšie budeme považovať relačné, dokumentové a grafové modely a na príkladoch konkrétnych DBMS ukážeme, ako sa implementujú tie „chýbajúce“.
Viacmodelové DBMS založené na relačnom modeli
Popredné DBMS sú v súčasnosti relačné; Predpoveď Gartnera by sa nedala považovať za pravdivú, ak by RDBMS nevykazovali pohyb v smere multi-modelovania. A demonštrujú. Myšlienku, že viacmodelový DBMS je ako švajčiarsky nôž, ktorý nič nedokáže dobre, možno nasmerovať priamo na Larryho Ellisona.
Autor však preferuje implementáciu multi-modelovania v Microsoft SQL Server, na príklade ktorého bude popísaná podpora RDBMS pre dokumentové a grafové modely.
Model dokumentu na MS SQL Server
O tom, ako MS SQL Server implementuje podporu pre model dokumentu, už boli na Habré dva vynikajúce články, obmedzím sa na krátke prerozprávanie a komentár:
Spôsob podpory modelu dokumentu v MS SQL Server je celkom typický pre relačné DBMS: dokumenty JSON sa navrhujú na uloženie v bežných textových poliach. Podpora pre model dokumentu má poskytnúť špeciálne operátory na analýzu tohto JSON:
- extrahovať hodnoty skalárnych atribútov,
- extrahovať čiastkové dokumenty.
Druhým argumentom oboch operátorov je výraz v syntaxi podobnej JSONPath.
Abstraktne môžeme povedať, že takto uložené dokumenty nie sú „prvotriedne entity“ v relačnej DBMS, na rozdiel od n-tic. Konkrétne na serveri MS SQL Server v súčasnosti neexistujú žiadne indexy v poliach dokumentov JSON, čo sťažuje spájanie tabuliek pomocou hodnôt týchto polí a dokonca aj výber dokumentov pomocou týchto hodnôt. Je však možné vytvoriť vypočítaný stĺpec pre takéto pole a index na ňom.
MS SQL Server navyše poskytuje možnosť pohodlne zostaviť JSON dokument z obsahu tabuliek pomocou operátora - možnosť, v určitom zmysle, opačná k predchádzajúcemu konvenčnému skladovaniu. Je jasné, že bez ohľadu na to, aký rýchly je RDBMS, tento prístup je v rozpore s ideológiou dokumentových DBMS, ktoré v podstate uchovávajú hotové odpovede na obľúbené otázky a môžu vyriešiť len problémy s jednoduchosťou vývoja, ale nie rýchlosťou.
Nakoniec, MS SQL Server vám umožňuje vyriešiť opačný problém konštrukcie dokumentu: JSON môžete rozložiť na tabuľky pomocou . Ak dokument nie je úplne plochý, budete musieť použiť CROSS APPLY.
Grafový model v MS SQL Server
Podpora pre grafový (LPG) model je plne implementovaná aj v Microsoft SQL Server : Navrhuje sa použiť špeciálne tabuľky na ukladanie uzlov a na ukladanie hrán grafu. Takéto tabuľky sa vytvárajú pomocou výrazov CREATE TABLE AS NODE и CREATE TABLE AS EDGE resp.
Tabuľky prvého typu sú podobné bežným tabuľkám na ukladanie záznamov s jediným vonkajším rozdielom, že tabuľka obsahuje systémové pole $node_id — jedinečný identifikátor uzla grafu v databáze.
Podobne tabuľky druhého typu majú systémové polia $from_id и $to_id, záznamy v takýchto tabuľkách jasne definujú spojenia medzi uzlami. Na uloženie vzťahov každého typu sa používa samostatná tabuľka.
Ilustrujme si to na príklade. Nech majú údaje grafu usporiadanie, ako je znázornené na obrázku. Potom na vytvorenie zodpovedajúcej štruktúry v databáze musíte spustiť nasledujúce DDL dotazy:
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);Hlavným špecifikom takýchto tabuliek je, že v dopytoch proti nim je možné použiť vzory grafov so syntaxou podobnou Cypher (avšak „*"atď. zatiaľ nie sú podporované). Na základe meraní výkonnosti možno tiež predpokladať, že spôsob ukladania údajov v týchto tabuľkách je odlišný od spôsobu ukladania údajov v bežných tabuľkách a je optimalizovaný na vykonávanie takýchto grafových dotazov.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Okrem toho je dosť ťažké nepoužívať tieto vzory grafov pri práci s takýmito tabuľkami, pretože pri bežných SQL dotazoch na riešenie podobných problémov bude potrebné vynaložiť ďalšie úsilie na získanie systémových identifikátorov uzlov „grafu“ ($node_id, $from_id, $to_id; Z rovnakého dôvodu sa tu nezobrazujú dopyty na vkladanie údajov, pretože sú zbytočne ťažkopádne).
Aby som zhrnul popis implementácií modelov dokumentov a grafov v MS SQL Server, poznamenal by som, že takéto implementácie jedného modelu nad druhým sa nezdajú byť úspešné, a to predovšetkým z hľadiska jazykového dizajnu. Je potrebné rozšíriť jeden jazyk o druhý, jazyky nie sú úplne „ortogonálne“, pravidlá kompatibility môžu byť dosť bizarné.
Multi-model DBMS založený na modeli dokumentov
V tejto časti by som rád ilustroval implementáciu multi-modelu v dokumentových DBMS na príklade nie najobľúbenejšieho z nich, MongoDB (ako bolo povedané, má iba podmienené grafové operátory $lookup и $graphLookup, ktorá nepracuje na roztrhaných zbierkach), ale na príklade vyspelejšej a „podnikovej“ DBMS .
Nechajte teda kolekciu obsahovať sadu dokumentov XML nasledujúceho typu (MarkLogic vám tiež umožňuje ukladať dokumenty JSON):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Relačný model v MarkLogic
Relačný pohľad na zbierku dokumentov je možné vytvoriť pomocou (obsah prvkov value v nižšie uvedenom príklade môže byť ľubovoľná 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>Vytvorené zobrazenie môžete adresovať dotazom SQL (napríklad cez ODBC):
SELECT name, surname FROM Person WHERE name="John"Bohužiaľ, relačné zobrazenie vytvorené šablónou zobrazenia je len na čítanie. Pri spracovaní žiadosti o to sa MarkLogic pokúsi použiť . Predtým mal MarkLogic úplne obmedzené vzťahové názory a zapisovateľné, ale teraz sa považujú za zastarané.
Grafický model v MarkLogic
S podporou modelu grafu (RDF) je všetko približne rovnaké. Opäť s pomocou môžete vytvoriť RDF reprezentáciu zbierky dokumentov z vyššie uvedeného príkladu:
<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>Výsledný graf RDF môžete adresovať dotazom SPARQL:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Na rozdiel od relačného, MarkLogic podporuje grafový model dvoma ďalšími spôsobmi:
- DBMS môže byť plnohodnotným oddeleným úložiskom dát RDF (triplety v ňom budú tzv na rozdiel od vyššie popísaných ).
- RDF v špeciálnej serializácii možno jednoducho vložiť do dokumentov XML alebo JSON (a potom sa zavolajú trojice ). Toto je pravdepodobne alternatíva k mechanizmom
idrefatď
Dobrá predstava o tom, ako veci „naozaj“ fungujú v MarkLogic, je daná , je v tomto zmysle nízkoúrovňový, hoci jeho účel je skôr opačný – snažiť sa abstrahovať od použitého dátového modelu, zabezpečiť konzistentnú prácu s dátami v rôznych modeloch, transakčnosť a pod.
Viacmodelový DBMS „bez hlavného modelu“
Na trhu sú aj DBMS, ktoré sa stavajú ako pôvodne multimodelové, bez akéhokoľvek zdedeného hlavného modelu. Tie obsahujú , (od roku 2018 patrí developerská spoločnosť SAP) a (služba ako súčasť cloudovej platformy Microsoft Azure).
V skutočnosti existujú „základné“ modely v ArangoDB a OrientDB. V oboch prípadoch ide o ich vlastné dátové modely, ktoré sú zovšeobecnením toho dokumentového. Zovšeobecnenia slúžia najmä na uľahčenie schopnosti vykonávať dotazy grafovej a relačnej povahy.
Tieto modely sú jediné dostupné na použitie v špecifikovanom DBMS; ich vlastné dopytovacie jazyky sú navrhnuté tak, aby s nimi pracovali. Takéto modely a DBMS sú, samozrejme, sľubné, ale nedostatočná kompatibilita so štandardnými modelmi a jazykmi znemožňuje použitie týchto DBMS v starších systémoch – aby nahradili DBMS, ktoré sa tam už používajú.
Na Habré už bol nádherný článok o ArangoDB a OrientDB: .
ArangoDB
ArangoDB tvrdí, že podporuje grafový dátový model.
Uzly grafu v ArangoDB sú bežné dokumenty a okraje sú dokumenty špeciálneho typu, ktoré spolu s bežnými systémovými poľami majú (_key, _id, _rev) systémové polia _from и _to. Dokumenty v DBMS dokumentov sa tradične spájajú do zbierok. Kolekcie dokumentov reprezentujúcich hrany sa v ArangoDB nazývajú kolekcie okrajov. Mimochodom, dokumenty kolekcie okrajov sú tiež dokumenty, takže okraje v ArangoDB môžu fungovať aj ako uzly.
Surové údaje
Urobme si zbierku persons, ktorého dokumenty vyzerajú takto:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Nech je aj zbierka cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Potom zbierka likes môže vyzerať takto:
[
{
"_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
}
]Dotazy a výsledky
Dotaz v štýle grafu v jazyku AQL používanom v ArangoDB, ktorý vracia v čitateľnej forme informácie o tom, kto má rád ktorú kaviareň, vyzerá takto:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }V relatívnom štýle, kde vzťahy „počítame“ a nie ich ukladáme, možno tento dotaz prepísať takto (mimochodom, bez kolekcie likes mohol by sa bez neho zaobísť):
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 }Výsledok bude v oboch prípadoch rovnaký:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Ďalšie otázky a výsledky
Ak sa formát výsledkov vyššie zdá byť typickejší pre relačný DBMS ako pre dokumentový DBMS, môžete skúsiť tento dotaz (alebo môžete použiť ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Výsledok bude vyzerať takto:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
Základom implementácie grafového modelu nad model dokumentu v OrientDB je polia dokumentu okrem viac-menej štandardných skalárnych hodnôt majú aj hodnoty typov ako napr LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Hodnoty týchto typov sú odkazy alebo kolekcie odkazov na Dokumenty.
Identifikátor dokumentu pridelený systémom má „fyzický význam“ označujúci polohu záznamu v databáze a vyzerá asi takto: @rid : #3:16. Hodnoty referenčných vlastností sú teda v skutočnosti ukazovatele (ako v grafovom modeli) a nie výberové podmienky (ako v relačnom modeli).
Rovnako ako ArangoDB, hrany v OrientDB sú reprezentované ako samostatné dokumenty (hoci ak hrana nemá svoje vlastné vlastnosti, môže byť vytvorená a nebude zodpovedať samostatnému dokumentu).
Surové údaje
Vo formáte blízkom Databáza OrientDB, údaje z predchádzajúceho príkladu pre ArangoDB by vyzerali asi takto:
[
{
"@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"
}
]Ako vidíme, vrcholy ukladajú aj informácie o prichádzajúcich a odchádzajúcich hranách. o Rozhranie Document API musí monitorovať referenčnú integritu samo a túto prácu preberá rozhranie Graph API. Pozrime sa však, ako vyzerá prístup k OrientDB v „čistých“ dotazovacích jazykoch, ktoré nie sú integrované do programovacích jazykov.
Dotazy a výsledky
Dotaz podobný účelu ako dotaz z príkladu pre ArangoDB v OrientDB vyzerá takto:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameVýsledok sa získa v nasledujúcej forme:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Ak sa vám formát výsledku opäť zdá príliš „relačný“, musíte odstrániť riadok s :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]Dopytovací jazyk OrientDB možno opísať ako SQL s vložkami podobnými Gremlin. Vo verzii 2.2 sa objavil formulár žiadosti podobný 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_nameFormát výsledku bude rovnaký ako v predchádzajúcej žiadosti. Zamyslite sa nad tým, čo je potrebné odstrániť, aby to bolo viac „relačné“, ako v úplne prvom dotaze.
Azure CosmosDB
V menšej miere to, čo bolo povedané vyššie o ArangoDB a OrientDB, platí pre Azure CosmosDB. CosmosDB poskytuje nasledujúce rozhrania API na prístup k údajom: SQL, MongoDB, Gremlin a Cassandra.
SQL API a MongoDB API sa používajú na prístup k údajom v modeli dokumentu. Gremlin API a Cassandra API – pre prístup k údajom vo formáte grafov a stĺpcov. Údaje vo všetkých modeloch sú uložené vo formáte interného modelu CosmosDB: („atom-record-sequence“), ktorý je tiež blízky dokumentovému.
Dátový model zvolený používateľom a použité API sú však fixné v čase vytvorenia účtu v službe. Nie je možné pristupovať k údajom načítaným v jednom modeli vo formáte iného modelu, ako je znázornené takto:
Multi-model v Azure CosmosDB je teda dnes už len možnosť využívať viacero databáz podporujúcich rôzne modely od jedného výrobcu, čo nerieši všetky problémy multivariantného úložiska.
Viacmodelové DBMS založené na grafovom modeli?
Pozoruhodný je fakt, že na trhu zatiaľ nie sú žiadne multimodelové DBMS, ktoré sú založené na grafovom modeli (okrem multimodelovej podpory súčasne dvoch grafových modelov: RDF a LPG; pozri ). Najväčšie ťažkosti spôsobuje implementácia modelu dokumentu nad grafový model, a nie relačný.
Otázka, ako implementovať relačný model nad grafový model, bola zvažovaná už pri jeho vytváraní. Ako napríklad, :
V grafovom prístupe nie je nič vlastné, čo by bránilo vytvoreniu vrstvy (napr. vhodnou indexáciou) na grafovej databáze, ktorá umožňuje relačný pohľad s (1) obnovou n-tic z obvyklých párov kľúčových hodnôt a (2) zoskupením n-tice podľa typu vzťahu.
Pri implementácii modelu dokumentu nad grafový model musíte mať na pamäti napríklad nasledovné:
- Prvky poľa JSON sa považujú za usporiadané, ale prvky vychádzajúce z vrcholu okraja grafu nie sú;
- Údaje v modeli dokumentu sú zvyčajne denormalizované; stále nechcete ukladať niekoľko kópií toho istého vloženého dokumentu a vedľajšie dokumenty zvyčajne nemajú identifikátory;
- Na druhej strane ideológia dokumentov DBMS spočíva v tom, že dokumenty sú hotové „agregáty“, ktoré nie je potrebné zakaždým vytvárať nanovo. Je potrebné poskytnúť grafovému modelu schopnosť rýchlo získať podgraf zodpovedajúci hotovému dokumentu.
Trochu reklamy
Autor článku súvisí s vývojom NitrosBase DBMS, ktorého interným modelom je graf a vonkajšie modely – relačný a dokumentový – sú jeho reprezentáciami. Všetky modely sú rovnaké: takmer všetky údaje sú dostupné v ktoromkoľvek z nich pomocou jazyka dotazov, ktorý je preň prirodzený. Navyše, v akomkoľvek pohľade je možné údaje zmeniť. Zmeny sa prejavia v internom modeli a podľa toho aj v iných pohľadoch.
Ako vyzerá párovanie modelov v NitrosBase snáď popíšem v niektorom z nasledujúcich článkov.
Záver
Dúfam, že všeobecné obrysy toho, čo sa nazýva multi-modelovanie, sú čitateľovi viac-menej jasné. Viacmodelové DBMS sú celkom odlišné a „podpora viacerých modelov“ môže vyzerať inak. Na pochopenie toho, čo sa v každom konkrétnom prípade nazýva „multi-model“, je užitočné odpovedať na nasledujúce otázky:
- Hovoríme o podpore tradičných modelov alebo o nejakom „hybridnom“ modeli?
- Sú si modely „rovnaké“, alebo je jeden z nich predmetom ostatných?
- Sú modelky k sebe „ľahostajné“? Dajú sa dáta zapísané v jednom modeli prečítať v inom alebo dokonca prepísať?
Myslím si, že na otázku o relevantnosti multimodelových DBMS sa už dá odpovedať kladne, no zaujímavá je otázka, po ktorých typoch bude v blízkej budúcnosti väčší dopyt. Zdá sa, že viac-modelové DBMS, ktoré podporujú tradičné modely, predovšetkým relačné, budú viac žiadané; Obľúbenosť multimodelových DBMS, ponúkajúcich nové modely, ktoré kombinujú výhody rôznych tradičných, je otázkou vzdialenejšej budúcnosti.
Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prosím.
Používate viacmodelové DBMS?
-
My to nepoužívame, všetko ukladáme do jedného DBMS a do jedného modelu
-
Využívame multi-modelové schopnosti tradičných DBMS
-
Cvičíme polyglotnú vytrvalosť
-
Používame nový multimodelový DBMS (Arango, Orient, CosmosDB)
Hlasovalo 19 užívateľov. 4 používatelia sa zdržali hlasovania.
Zdroj: hab.com