Moderní informační systémy jsou poměrně složité. V neposlední řadě je jejich složitost dána složitostí v nich zpracovávaných dat. Složitost dat často spočívá v rozmanitosti použitých datových modelů. Když se tedy například data stanou „velkými“, jednou z problematických charakteristik je nejen jejich objem („objem“), ale také jejich rozmanitost („rozmanitost“).
Pokud ještě nenajdete chybu ve zdůvodnění, čtěte dále.
Obsah
Polyglotní vytrvalost
Výše uvedené vede k tomu, že někdy i v rámci jednoho systému je nutné pro ukládání dat a řešení různých problémů jejich zpracování použít více různých DBMS, z nichž každý podporuje svůj vlastní datový model. Lehkou rukou M. Fowlera řada slavných knih a jedna z nich Agilní manifest, tato situace se nazývá vícevariantní úložiště ("polyglotní perzistence").
Fowler má také následující příklad organizace ukládání dat v plnohodnotné a vysoce zatěžované aplikaci v oblasti elektronického obchodování.
Tento příklad je samozřejmě poněkud přehnaný, ale lze nalézt některé úvahy ve prospěch výběru té či oné DBMS pro odpovídající účel, např. .
Je jasné, že být sluhou v takové zoo není jednoduché.
- Množství kódu, který provádí ukládání dat, roste úměrně s počtem použitých DBMS; množství dat synchronizujících kód je dobré, pokud není přímo úměrné druhé mocnině tohoto čísla.
- Jako násobek počtu použitých DBMS rostou náklady na poskytování podnikových charakteristik (škálovatelnost, odolnost proti chybám, vysoká dostupnost) každého z používaných DBMS.
- Je nemožné zajistit podnikové charakteristiky úložného subsystému jako celku – zejména transakční.
Z pohledu ředitele zoo vše vypadá takto:
- Mnohonásobné zvýšení nákladů na licence a technickou podporu od výrobce DBMS.
- Přebytek zaměstnanců a zvýšené termíny.
- Přímé finanční ztráty nebo sankce v důsledku nekonzistence údajů.
Došlo k výraznému nárůstu celkových nákladů na vlastnictví systému (TCO). Existuje nějaké východisko ze situace „možností více úložišť“?
Vícemodelový
Termín „vícerozměrné úložiště“ se začal používat v roce 2011. Uvědomění si problémů přístupu a hledání řešení trvalo několik let a do roku 2015 byla ústy analytiků Gartner formulována odpověď:
- Z "»:
Budoucnost DBMS, jejich architektur a způsobů jejich použití je multimodelová.
- Z "»:
Přední provozní DBMS budou nabízet více modelů – relačních i nerelačních – jako součást jediné platformy.
Zdá se, že tentokrát měli analytici Gartner pravdu se svou prognózou. Pokud přejdete na stránku s DBMS na DB-Engines, můžete to vidětоVětšina jeho vůdců se staví konkrétně jako multimodelové DBMS. Totéž lze vidět na stránce s jakýmkoli soukromým hodnocením.
Níže uvedená tabulka ukazuje DBMS - lídry v každém ze soukromých hodnocení, které tvrdí, že jsou multimodelové. U každého DBMS je uveden původní podporovaný model (který byl kdysi jediný) a spolu s ním aktuálně podporované modely. Také jsou uvedeny DBMS, které se staví jako „původně multimodelové“ a podle tvůrců nemají žádný původní zděděný model.
| DBMS | Počáteční model | Další modely |
|---|---|---|
| Věštec | vztahový | Graf, dokument |
| MS SQL | vztahový | Graf, dokument |
| PostgreSQL | vztahový | Graf*, dokument |
| MarkLogic | Dokumentární | Graf, vztahový |
| MongoDB | Dokumentární | Pár klíč–hodnota, graf* |
| DataStax | Široký sloupec | Dokument, graf |
| Redestilát | Klíč-hodnota | Dokumentární, graf* |
| ArangoDB | - | Graf, dokument |
| OrientDB | - | Graf, dokument, vztah |
| Azure CosmosDB | - | Graf, dokument, vztah |
Poznámky ke stolu
Hvězdičky v tabulce označují příkazy, které vyžadují rezervaci:
- PostgreSQL DBMS nepodporuje grafový datový model, ale tento produkt jej podporuje , jako je AgensGraph.
- Ve vztahu k MongoDB je správnější mluvit o přítomnosti grafových operátorů v dotazovacím jazyce (, ) než o podporu grafového modelu, i když jejich zavedení si samozřejmě vyžádalo určité optimalizace na úrovni fyzického úložiště ve směru podpory grafového modelu.
- Ve vztahu k Redis máme na mysli rozšíření .
Dále si pro každou z tříd ukážeme, jak je v DBMS z této třídy implementována podpora několika modelů. Za nejdůležitější budeme považovat relační, dokumentové a grafové modely a na příkladech konkrétních DBMS ukážeme, jak jsou implementovány ty „chybějící“.
Vícemodelové DBMS založené na relačním modelu
Vedoucí DBMS v současnosti jsou relační; předpověď Gartneru by nemohla být považována za pravdivou, pokud by RDBMS nevykazovaly pohyb ve směru multi-modelování. A demonstrují. Myšlenku, že multimodelový DBMS je jako švýcarský nůž, který neumí nic dobrého, lze nyní směřovat přímo k Larrymu Ellisonovi.
Autor však preferuje implementaci multi-modelování v Microsoft SQL Server, na jehož příkladu bude popsána podpora RDBMS pro dokumentové a grafové modely.
Model dokumentu v MS SQL Server
O tom, jak MS SQL Server implementuje podporu pro model dokumentu, o Habrém již byly dva vynikající články, omezím se na krátké převyprávění a komentář:
Způsob podpory dokumentového modelu v MS SQL Server je zcela typický pro relační DBMS: JSON dokumenty jsou navrženy tak, aby byly uloženy v běžných textových polích. Podpora pro model dokumentu spočívá v poskytování speciálních operátorů pro analýzu tohoto JSON:
- extrahovat hodnoty skalárních atributů,
- extrahovat dílčí dokumenty.
Druhým argumentem obou operátorů je výraz v syntaxi podobné JSONPath.
Abstraktně lze říci, že takto uložené dokumenty nejsou „prvotřídními entitami“ v relačním DBMS, na rozdíl od n-tic. Konkrétně v MS SQL Server v současné době neexistují žádné indexy na polích dokumentů JSON, což ztěžuje spojování tabulek pomocí hodnot těchto polí a dokonce i výběr dokumentů pomocí těchto hodnot. Pro takové pole je ale možné vytvořit počítaný sloupec a na něm index.
MS SQL Server navíc poskytuje možnost pohodlně sestavit dokument JSON z obsahu tabulek pomocí operátoru - možnost, v určitém smyslu, opačná k předchozímu, konvenčnímu skladování. Je jasné, že bez ohledu na to, jak rychlý je RDBMS, tento přístup je v rozporu s ideologií dokumentových DBMS, které v podstatě ukládají hotové odpovědi na oblíbené dotazy a mohou řešit pouze problémy s jednoduchostí vývoje, nikoli však s rychlostí.
A konečně, MS SQL Server vám umožňuje vyřešit opačný problém konstrukce dokumentu: můžete rozložit JSON do tabulek pomocí . Pokud dokument není zcela plochý, budete muset použít CROSS APPLY.
Grafový model v MS SQL Server
Podpora pro grafový (LPG) model je také plně implementována v Microsoft SQL Server : Pro ukládání uzlů a pro ukládání hran grafu se navrhuje používat speciální tabulky. Takové tabulky se vytvářejí pomocí výrazů CREATE TABLE AS NODE и CREATE TABLE AS EDGE resp.
Tabulky prvního typu jsou podobné běžným tabulkám pro ukládání záznamů s jediným vnějším rozdílem, že tabulka obsahuje systémové pole $node_id — jedinečný identifikátor uzlu grafu v databázi.
Podobně tabulky druhého typu mají systémová pole $from_id и $to_id, záznamy v takových tabulkách jasně definují spojení mezi uzly. K uložení vztahů každého typu se používá samostatná tabulka.
Ukažme si to na příkladu. Nechte data grafu mít rozložení jako na obrázku. Poté, abyste vytvořili odpovídající strukturu v databázi, musíte spustit následující 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 specifikem těchto tabulek je, že v dotazech na ně je možné použít grafové vzory se syntaxí podobnou Cypher (avšak „*"atd. zatím nejsou podporovány). Na základě měření výkonu lze také předpokládat, že způsob ukládání dat v těchto tabulkách se liší od způsobu ukládání dat v běžných tabulkách a je optimalizován pro provádění takových dotazů na grafy.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Navíc je poměrně obtížné tyto grafové vzory při práci s takovými tabulkami nepoužívat, protože v běžných SQL dotazech k řešení podobných problémů bude nutné vynaložit další úsilí na získání systémových „grafových“ identifikátorů uzlů ($node_id, $from_id, $to_id; Ze stejného důvodu se zde nezobrazují dotazy na vkládání dat, protože jsou zbytečně těžkopádné).
Abych shrnul popis implementací dokumentových a grafových modelů v MS SQL Server, podotýkám, že takovéto implementace jednoho modelu nad druhým se nejeví úspěšné, a to především z hlediska jazykového designu. Je nutné rozšířit jeden jazyk o druhý, jazyky nejsou zcela „ortogonální“, pravidla kompatibility mohou být docela bizarní.
Vícemodelové DBMS založené na modelu dokumentu
V této části bych rád ilustroval implementaci multi-modelu v dokumentových DBMS na příkladu ne nejoblíbenějšího z nich, MongoDB (jak bylo řečeno, má pouze podmíněné grafové operátory $lookup и $graphLookup, nepracují na sharded sbírkách), ale na příkladu vyspělejšího a „podnikového“ DBMS .
Nechte tedy kolekci obsahovat sadu dokumentů XML následujícího typu (MarkLogic vám také umožňuje ukládat dokumenty JSON):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Relační model v MarkLogic
Relační pohled na kolekci dokumentů lze vytvořit pomocí (obsah prvků value v níže uvedeném příkladu může být libovolná 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>Vytvořený pohled můžete adresovat pomocí SQL dotazu (například přes ODBC):
SELECT name, surname FROM Person WHERE name="John"Relační pohled vytvořený šablonou zobrazení je bohužel pouze pro čtení. Při zpracování požadavku na něj se MarkLogic pokusí použít . Dříve měl MarkLogic zcela omezené vztahové pohledy a zapisovatelné, ale nyní jsou považovány za zastaralé.
Grafový model v MarkLogic
S podporou modelu grafu (RDF) je vše přibližně stejné. Opět s pomocí můžete vytvořit RDF reprezentaci sbírky dokumentů z výše uvedeného pří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 řešit dotazem SPARQL:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Na rozdíl od relačního podporuje MarkLogic grafový model dvěma dalšími způsoby:
- DBMS může být plnohodnotným odděleným úložištěm dat RDF (trojice v něm budou nazývány na rozdíl od výše popsaných ).
- RDF ve speciální serializaci lze jednoduše vložit do dokumentů XML nebo JSON (a pak budou volány trojice ). Toto je pravděpodobně alternativa k mechanismům
idrefatd.
Dobrá představa o tom, jak věci „skutečně“ fungují v MarkLogic, je dána , v tomto smyslu je nízkoúrovňový, i když jeho účel je spíše opačný – pokusit se abstrahovat od použitého datového modelu, zajistit konzistentní práci s daty v různých modelech, transakčnost atp.
Vícemodelové DBMS „bez hlavního modelu“
Na trhu jsou také DBMS, které se staví jako zpočátku vícemodelové, bez jakéhokoli zděděného hlavního modelu. Tyto zahrnují , (od roku 2018 patří developerská společnost SAP) a (služba jako součást cloudové platformy Microsoft Azure).
Ve skutečnosti existují „základní“ modely v ArangoDB a OrientDB. V obou případech se jedná o vlastní datové modely, které jsou zobecněním toho dokumentového. Zobecnění mají především usnadnit schopnost provádět dotazy grafové a relační povahy.
Tyto modely jsou jediné dostupné pro použití ve specifikovaných DBMS; jejich vlastní dotazovací jazyky jsou navrženy tak, aby s nimi pracovaly. Takové modely a DBMS jsou samozřejmě slibné, ale nedostatek kompatibility se standardními modely a jazyky znemožňuje použití těchto DBMS ve starších systémech – k nahrazení již používaných DBMS.
Na Habré už byl nádherný článek o ArangoDB a OrientDB: .
ArangoDB
ArangoDB požaduje podporu pro grafový datový model.
Uzly grafu v ArangoDB jsou běžné dokumenty a okraje jsou dokumenty speciálního typu, které spolu s běžnými systémovými poli mají (_key, _id, _rev) systémová pole _from и _to. Dokumenty v dokumentových DBMS se tradičně spojují do kolekcí. Kolekce dokumentů představujících hrany se v ArangoDB nazývají kolekce okrajů. Mimochodem, dokumenty kolekce hran jsou také dokumenty, takže hrany v ArangoDB mohou také fungovat jako uzly.
Počáteční data
Udělejme sbírku persons, jehož dokumenty vypadají takto:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Ať je také sbírka cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Pak sbírka likes může vypadat 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 ve stylu grafu v jazyce AQL používaný v ArangoDB, vracející informace v podobě čitelné pro člověka o tom, kdo má rád kterou kavárnu, vypadá takto:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }V relačním stylu, kde vztahy spíše „počítáme“, než je ukládáme, lze tento dotaz přepsat takto (mimochodem, bez kolekce likes obejde se bez):
FOR p IN persons
FOR l IN likes
FILTER p._key == l._from
FOR c IN cafes
FILTER l._to == c._key
RETURN { person : p.name , likes : c.name }Výsledek bude v obou případech stejný:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Další dotazy a výsledky
Pokud se výše uvedený formát výsledku zdá být typičtější pro relační DBMS než pro dokumentový DBMS, můžete zkusit tento dotaz (nebo můžete použít ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Výsledek bude vypadat takto:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
Základem pro implementaci grafového modelu nad model dokumentu v OrientDB je pole dokumentu mají kromě víceméně standardních skalárních hodnot také hodnoty typů jako např LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Hodnoty těchto typů jsou odkazy nebo kolekce odkazů na dokumenty.
Identifikátor dokumentu přidělený systémem má „fyzický význam“, který označuje pozici záznamu v databázi, a vypadá asi takto: @rid : #3:16. Hodnoty referenčních vlastností jsou tedy ve skutečnosti ukazatele (jako v grafovém modelu) spíše než podmínky výběru (jako v relačním modelu).
Stejně jako ArangoDB jsou hrany v OrientDB reprezentovány jako samostatné dokumenty (ačkoli pokud hrana nemá své vlastní vlastnosti, lze ji vytvořit a nebude odpovídat samostatnému dokumentu).
Počáteční data
Ve formátu blízkém Databázi OrientDB by data z předchozího příkladu pro ArangoDB vypadala nějak 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"
}
]Jak vidíme, vrcholy také uchovávají informace o příchozích a odchozích hranách. Na Rozhraní Document API musí samo monitorovat referenční integritu a tuto práci přebírá rozhraní Graph API. Ale podívejme se, jak vypadá přístup k OrientDB v „čistých“ dotazovacích jazycích, které nejsou integrovány do programovacích jazyků.
Dotazy a výsledky
Dotaz podobný účelu jako dotaz z příkladu pro ArangoDB v OrientDB vypadá takto:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameVýsledek bude získán v následující podobě:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Pokud se vám formát výsledku opět zdá příliš „relační“, musíte řádek s odstranit :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]Dotazovací jazyk OrientDB lze popsat jako SQL s vložkami podobnými Gremlin. Ve verzi 2.2 se objevil formulář žádosti podobný Cypheru, :
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 stejný jako v předchozím požadavku. Přemýšlejte o tom, co je třeba odstranit, aby to bylo více „relační“, jako v úplně prvním dotazu.
Azure CosmosDB
To, co bylo řečeno výše o ArangoDB a OrientDB, platí v menší míře pro Azure CosmosDB. CosmosDB poskytuje následující rozhraní API pro přístup k datům: SQL, MongoDB, Gremlin a Cassandra.
SQL API a MongoDB API se používají pro přístup k datům v modelu dokumentu. Gremlin API a Cassandra API – pro přístup k datům ve formátu grafů a sloupců. Data ve všech modelech jsou uložena ve formátu interního modelu CosmosDB: („atom-record-sequence“), který je také blízký dokumentovému.
Datový model zvolený uživatelem a použité API jsou však fixní v době vytvoření účtu ve službě. Není možné přistupovat k datům načteným v jednom modelu ve formátu jiného modelu, jak je znázorněno například takto:
Multi-model v Azure CosmosDB je tedy dnes pouze možnost používat více databází podporujících různé modely od jednoho výrobce, což neřeší všechny problémy multivariantního úložiště.
Vícemodelové DBMS založené na grafovém modelu?
Pozoruhodný je fakt, že na trhu zatím nejsou žádné multimodelové DBMS založené na grafovém modelu (kromě multimodelové podpory současně dvou grafových modelů: RDF a LPG; viz. ). Největší potíže způsobuje implementace modelu dokumentu nad grafový model spíše než relační.
Otázka, jak implementovat relační model nad grafový model, byla zvažována již při jeho vytváření. Jak Například, :
V přístupu grafů není nic, co by bránilo vytvoření vrstvy (např. vhodnou indexací) na grafové databázi, která umožňuje relační pohled s (1) obnovou n-tic z obvyklých párů klíčů a hodnot a (2) seskupováním n-tice podle typu vztahu.
Při implementaci modelu dokumentu nad model grafu je třeba mít na paměti například následující:
- Prvky pole JSON jsou považovány za uspořádané, ale prvky vycházející z vrcholu okraje grafu nikoli;
- Data v modelu dokumentu jsou obvykle denormalizovaná; přesto nechcete ukládat několik kopií stejného vloženého dokumentu a vnořené dokumenty obvykle nemají identifikátory;
- Na druhé straně ideologie dokumentů DBMS spočívá v tom, že dokumenty jsou hotové „agregáty“, které není nutné pokaždé budovat znovu. Je nutné poskytnout grafovému modelu schopnost rychle získat podgraf odpovídající hotovému dokumentu.
Trochu reklamy
Autor článku souvisí s vývojem NitrosBase DBMS, jehož vnitřním modelem je graf a vnější modely - relační a dokumentové - jsou jeho reprezentacemi. Všechny modely jsou si rovny: téměř všechna data jsou dostupná v kterémkoli z nich pomocí dotazovacího jazyka, který je pro něj přirozený. Navíc v jakémkoli pohledu lze data změnit. Změny se projeví v interním modelu a podle toho i v dalších pohledech.
Jak vypadá párování modelů v NitrosBase snad popíšu v některém z následujících článků.
Závěr
Doufám, že obecné obrysy toho, čemu se říká multi-modelování, jsou čtenáři víceméně jasné. Vícemodelové DBMS jsou zcela odlišné a „podpora více modelů“ může vypadat jinak. Abychom porozuměli tomu, co se v každém konkrétním případě nazývá „multi-model“, je užitečné odpovědět na následující otázky:
- Mluvíme o podpoře tradičních modelů nebo o nějakém druhu „hybridního“ modelu?
- Jsou si modely „rovné“, nebo je jeden z nich předmětem ostatních?
- Jsou si modelky navzájem „lhostejné“? Lze data zapsaná v jednom modelu číst v jiném nebo dokonce přepisovat?
Myslím, že na otázku o relevanci vícemodelových DBMS lze již dnes odpovědět kladně, ale zajímavá je otázka, které typy z nich budou v blízké budoucnosti více žádané. Zdá se, že vícemodelové DBMS, které podporují tradiční modely, primárně relační, budou žádanější; Obliba vícemodelových DBMS nabízejících nové modely spojující výhody různých tradičních je otázkou vzdálenější budoucnosti.
Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. , prosím.
Používáte multi-model DBMS?
-
My to nepoužíváme, vše ukládáme do jednoho DBMS a do jednoho modelu
-
Využíváme vícemodelové schopnosti tradičních DBMS
-
Cvičíme polyglotní vytrvalost
-
Používáme nové multimodelové DBMS (Arango, Orient, CosmosDB)
Hlasovalo 19 uživatelů. 4 uživatelů se zdrželo hlasování.
Zdroj: www.habr.com