Nykyaikaiset tietojärjestelmät ovat varsin monimutkaisia. Ennen kaikkea niiden monimutkaisuus johtuu niissä käsiteltyjen tietojen monimutkaisuudesta. Tietojen monimutkaisuus johtuu usein käytettyjen tietomallien moninaisuudesta. Joten esimerkiksi kun tiedosta tulee "suuri", yksi ongelmallisista ominaisuuksista ei ole vain sen määrä ("volume"), vaan myös sen monimuotoisuus ("lajike").
Jos et vielä löydä virhettä perusteluissa, lue eteenpäin.
Pitoisuus
Polyglotin sinnikkyys
Edellä oleva johtaa siihen, että joskus jopa yhden järjestelmän puitteissa on tarpeen käyttää useita erilaisia DBMS-järjestelmiä tietojen tallentamiseen ja niiden käsittelyyn liittyvien erilaisten ongelmien ratkaisemiseen, joista jokainen tukee omaa tietomalliaan. M. Fowlerin kevyellä kädellä, useita kuuluisia kirjoja ja yksi Ketterä manifesti, tätä tilannetta kutsutaan monimuotoinen tallennustila ("polyglotin pysyvyys").
Fowlerilla on myös seuraava esimerkki tietojen tallennuksen järjestämisestä monipuolisessa ja suuren kuormituksen sovelluksessa sähköisen kaupankäynnin alalla.
Tämä esimerkki on tietysti hieman liioiteltu, mutta joitain näkökohtia, jotka puoltavat yhden tai toisen DBMS:n valitsemista vastaavaan tarkoitukseen, löytyy esim. .
On selvää, että palvelijana oleminen tällaisessa eläintarhassa ei ole helppoa.
- Tietojen tallennusta suorittavan koodin määrä kasvaa suhteessa käytettyjen DBMS-järjestelmien määrään; koodin synkronointidatan määrä on hyvä, ellei verrannollinen tämän luvun neliöön.
- Käytettyjen DBMS-järjestelmien moninkertaisena yrityksen ominaisuuksien (skaalautuvuus, vikasietoisuus, korkea käytettävyys) tarjoamisen kustannukset kasvavat jokaiselle käytetylle DBMS:lle.
- On mahdotonta varmistaa koko tallennusosajärjestelmän yritysominaisuuksia - etenkään transaktiokykyä.
Eläintarhanjohtajan näkökulmasta kaikki näyttää tältä:
- Lisenssien ja DBMS-valmistajan teknisen tuen kustannusten moninkertainen nousu.
- Ylimääräinen henkilöstö ja pidennetyt määräajat.
- Tietojen epäjohdonmukaisuudesta johtuvia välittömiä taloudellisia tappioita tai sakkoja.
Järjestelmän kokonaisomistuskustannukset (TCO) ovat nousseet merkittävästi. Onko "useiden tallennusvaihtoehtojen" tilanteesta mitään ulospääsyä?
Monipuolinen malli
Termi "monimuuttujamuisti" otettiin käyttöön vuonna 2011. Lähestymistavan ongelmien tiedostaminen ja ratkaisun etsiminen kesti useita vuosia, ja vuoteen 2015 mennessä Gartnerin analyytikoiden suun kautta muotoiltiin vastaus:
- Lähettäjä "»:
DBMS-järjestelmien, niiden arkkitehtuurien ja käyttötapojen tulevaisuus on monimallinen.
- Lähettäjä "»:
Johtavat operatiiviset DBMS-järjestelmät tarjoavat useita malleja – relatiivisia ja ei-relatiivisia – osana yhtä alustaa.
Näyttää siltä, että tällä kertaa Gartnerin analyytikot olivat oikeassa ennusteessaan. Jos menet sivulle DBMS DB-Enginesissä, näet senоUseimmat sen johtajista asettavat itsensä nimenomaan monimallitietokantajärjestelmiin. Sama näkyy sivulla millä tahansa yksityisellä luokittelulla.
Alla olevassa taulukossa näkyy DBMS - johtaja jokaisessa yksityisessä luokituksessa, joka väittää olevansa monimalli. Jokaiselle DBMS:lle ilmoitetaan alkuperäinen tuettu malli (joka oli aikoinaan ainoa) ja sen mukana tällä hetkellä tuetut mallit. Luettelossa on myös DBMS-järjestelmiä, jotka asettavat itsensä "alkuperäisesti monimalliksi" ja tekijöiden mukaan niillä ei ole alkuperäistä perittyä mallia.
| DBMS | Alkuperäinen malli | Muut mallit |
|---|---|---|
| oraakkeli | suhteellinen | Graafi, dokumentti |
| MS SQL | suhteellinen | Graafi, dokumentti |
| PostgreSQL | suhteellinen | Kaavio*, asiakirja |
| MarkLogic | Dokumentti | Graafi, relaatio |
| MongoDB | Dokumentti | Avainarvo, kaavio* |
| DataStax | Leveä sarake | Dokumentti, kaavio |
| Redis | Avainarvo | Dokumentti, kaavio* |
| ArangoDB | - | Graafi, dokumentti |
| OrientDB | - | Graafi, dokumentti, relaatio |
| Azure CosmosDB | - | Graafi, dokumentti, relaatio |
Taulukon muistiinpanot
Taulukossa olevat tähdet merkitsevät varauksia vaativat lausunnot:
- PostgreSQL DBMS ei tue kaaviotietomallia, mutta tämä tuote tukee sitä , kuten AgensGraph.
- MongoDB:n suhteen on oikein puhua graafioperaattoreiden läsnäolosta kyselykielessä (, ) kuin graafimallin tukemisesta, vaikka niiden käyttöönotto tietysti vaati fyysisen tallennustason optimointeja graafimallin tukemisen suuntaan.
- Rediksen suhteen tarkoitamme laajennusta .
Seuraavaksi näytämme jokaiselle luokalle, kuinka useiden mallien tuki on toteutettu DBMS:ssä tästä luokasta. Pidämme relaatio-, dokumentti- ja graafimalleja tärkeimpinä ja käytämme esimerkkejä tietyistä DBMS-järjestelmistä näyttääksemme, kuinka "puuttuvat" on toteutettu.
Relaatiomalliin perustuva monen mallin DBMS
Tällä hetkellä johtavat DBMS:t ovat suhteellisia; Gartnerin ennustetta ei voitaisi pitää paikkansa, jos RDBMS:t eivät osoittaisi liikettä monimallinnuksen suuntaan. Ja he osoittavat. Nyt ajatus siitä, että monimalli DBMS on kuin sveitsiläinen veitsi, joka ei voi tehdä mitään hyvin, voidaan ohjata suoraan Larry Ellisonille.
Kirjoittaja pitää kuitenkin parempana monimallinnuksen toteutusta Microsoft SQL Serverissä, jonka esimerkissä kuvataan RDBMS-tuki dokumentti- ja graafimalleille.
Asiakirjan malli MS SQL Serverissä
Habresta on jo julkaistu kaksi erinomaista artikkelia siitä, kuinka MS SQL Server toteuttaa tuen dokumenttimallille; rajoitan vain lyhyeen uudelleenkertomukseen ja kommentointiin:
Tapa tukea asiakirjamallia MS SQL Serverissä on varsin tyypillinen relaatiotietokantajärjestelmille: JSON-dokumentteja ehdotetaan tallennettavaksi tavallisiin tekstikenttiin. Dokumenttimallin tuki on erikoisoperaattoreiden tarjoaminen tämän JSON:n jäsentämiseen:
- poimimaan skalaariattribuuttiarvot,
- poimia aliasiakirjoja.
Molempien operaattoreiden toinen argumentti on lauseke JSONPath-kaltaisessa syntaksissa.
Abstraktisti voidaan sanoa, että tällä tavalla tallennetut asiakirjat eivät ole "ensimmäisen luokan kokonaisuuksia" relaatiotietokantajärjestelmässä, toisin kuin monikot. Erityisesti MS SQL Serverissä ei tällä hetkellä ole indeksejä JSON-dokumenttien kentissä, mikä vaikeuttaa taulukoiden yhdistämistä näiden kenttien arvoilla ja jopa dokumenttien valitsemista näillä arvoilla. Tällaiselle kenttään on kuitenkin mahdollista luoda laskettu sarake ja indeksi siihen.
Lisäksi MS SQL Server tarjoaa mahdollisuuden kätevästi rakentaa JSON-dokumentti taulukoiden sisällöstä operaattorin avulla. - tietyssä mielessä päinvastainen mahdollisuus kuin edellinen, tavanomainen varastointi. On selvää, että riippumatta siitä, kuinka nopea RDBMS on, tämä lähestymistapa on ristiriidassa dokumenttien DBMS-järjestelmien ideologian kanssa, jotka olennaisesti tallentavat valmiita vastauksia suosittuihin kyselyihin ja voivat ratkaista vain kehittämisen helppouden, mutta ei nopeuden ongelmia.
Lopuksi MS SQL Server antaa sinun ratkaista päinvastaisen asiakirjojen rakentamisen ongelman: voit hajottaa JSONin taulukoiksi käyttämällä . Jos asiakirja ei ole täysin litteä, sinun on käytettävä CROSS APPLY.
Graafimalli MS SQL Serverissä
Myös graafisen (LPG) mallin tuki on täysin toteutettu Microsoft SQL Serverissä : Ehdotetaan käytettäväksi erikoistaulukoita solmujen ja graafin reunojen tallentamiseen. Tällaiset taulukot luodaan lausekkeiden avulla CREATE TABLE AS NODE и CREATE TABLE AS EDGE vastaavasti.
Ensimmäisen tyypin taulukot ovat samanlaisia kuin tavalliset tietueiden tallennustaulukot, ainoana ulkoisena erona on, että taulukko sisältää järjestelmäkentän $node_id — tietokannan graafisolmun yksilöllinen tunniste.
Vastaavasti toisen tyypin taulukoissa on järjestelmäkenttiä $from_id и $to_id, tällaisten taulukoiden merkinnät määrittelevät selvästi solmujen väliset yhteydet. Erillistä taulukkoa käytetään kunkin tyypin suhteiden tallentamiseen.
Havainnollistakaamme tätä esimerkillä. Olkoon kaaviotietojen asettelu kuvan mukainen. Sitten luodaksesi vastaavan rakenteen tietokantaan sinun on suoritettava seuraavat DDL-kyselyt:
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);Tällaisten taulukoiden tärkein erityispiirre on, että niitä vastaan tehdyissä kyselyissä on mahdollista käyttää kaaviokuvioita Cypher-tyyppisellä syntaksilla (kuitenkin "*"jne. ei ole vielä tuettu). Suorituskykymittausten perusteella voidaan myös olettaa, että tapa, jolla tiedot tallennetaan näihin taulukoihin, eroaa tavasta, jolla tiedot tallennetaan tavallisiin taulukoihin, ja se on optimoitu tällaisten kaaviokyselyiden suorittamiseen.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Lisäksi on melko vaikeaa olla käyttämättä näitä kaaviokuvioita työskennellessäsi tällaisten taulukoiden kanssa, koska tavallisissa SQL-kyselyissä vastaavien ongelmien ratkaisemiseksi on tehtävä lisäponnisteluja järjestelmän "kaavion" solmutunnisteiden saamiseksi ($node_id, $from_id, $to_id; Samasta syystä tietojen lisäämiskyselyjä ei näytetä tässä, koska ne ovat tarpeettoman hankalia).
Yhteenvetona kuvauksen dokumentti- ja graafimallien toteutuksista MS SQL Serverissä totean, että tällaiset yhden mallin päällekkäiset toteutukset eivät vaikuta onnistuneilta ensisijaisesti kielisuunnittelun näkökulmasta. On välttämätöntä laajentaa yhtä kieltä toisella, kielet eivät ole täysin "ortogonaalisia", yhteensopivuussäännöt voivat olla melko outoja.
Dokumenttimalliin perustuva monimallitietokantajärjestelmä
Tässä osiossa haluaisin havainnollistaa monimallin toteutusta dokumenttien DBMS-järjestelmissä käyttämällä esimerkkiä niistä ei suosituimmasta, MongoDB:stä (kuten sanottiin, siinä on vain ehdollisia graafioperaattoreita $lookup и $graphLookup, joka ei toimi sirpaloitujen kokoelmien kanssa), mutta käyttää esimerkkiä kypsemmästä ja "yritys" DBMS:stä .
Joten anna kokoelman sisältää joukko seuraavan tyyppisiä XML-dokumentteja (MarkLogic antaa sinun myös tallentaa JSON-asiakirjoja):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Relaatiomalli MarkLogicissa
Relaationäkymä asiakirjakokoelmasta voidaan luoda käyttämällä (elementtien sisältö value alla olevassa esimerkissä voi olla mielivaltainen 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>Voit käsitellä luotua näkymää SQL-kyselyllä (esimerkiksi ODBC:n kautta):
SELECT name, surname FROM Person WHERE name="John"Valitettavasti näyttömallin luoma relaationäkymä on vain luku -tilassa. Käsitellessään sitä koskevaa pyyntöä MarkLogic yrittää käyttää . Aiemmin MarkLogicilla oli rajalliset suhteelliset näkemykset kokonaan ja kirjoitettavia, mutta nyt niitä pidetään vanhentuneina.
Graafinen malli MarkLogicissa
RDF-mallin tuella kaikki on suunnilleen sama. Taas avulla Voit luoda RDF-esityksen asiakirjojen kokoelmasta yllä olevasta esimerkistä:
<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>Voit käsitellä tuloksena olevaa RDF-kaaviota SPARQL-kyselyllä:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Toisin kuin relaatiomalli, MarkLogic tukee graafimallia kahdella muulla tavalla:
- DBMS voi olla täysimittainen erillinen RDF-datan tallennustila (sisältävät kolmiot ovat ns. toisin kuin yllä kuvatut ).
- Erityinen sarjoitettu RDF voidaan yksinkertaisesti lisätä XML- tai JSON-dokumentteihin (ja kolmoset kutsutaan sitten ). Tämä on luultavasti vaihtoehto mekanismeille
idrefjne.
Hyvä käsitys siitä, miten asiat "todella" toimii MarkLogicissa, antaa , tässä mielessä se on matalatasoinen, vaikka sen tarkoitus on pikemminkin päinvastainen - yrittää abstraktiota käytetystä tietomallista, varmistaa johdonmukainen työskentely datan kanssa eri malleissa, transaktiot jne.
Monimalli DBMS "ilman päämallia"
Markkinoilla on myös DBMS-järjestelmiä, jotka asettavat itsensä alun perin monimalleiksi ilman perittyä päämallia. Nämä sisältävät , (vuodesta 2018 kehitysyhtiö kuuluu SAP:lle) ja (palvelu osana Microsoft Azure -pilvialustaa).
Itse asiassa ArangoDB:ssä ja OrientDB:ssä on "ydinmalleja". Molemmissa tapauksissa nämä ovat omia tietomallejaan, jotka ovat dokumentin yleistyksiä. Yleistykset ovat pääasiassa helpottamaan kykyä suorittaa graafisia ja relaatioluonteisia kyselyjä.
Nämä mallit ovat ainoita käytettävissä määritetyssä DBMS:ssä; niiden omat kyselykielet on suunniteltu toimimaan niiden kanssa. Tietenkin tällaiset mallit ja DBMS:t ovat lupaavia, mutta yhteensopivuuden puute standardimallien ja -kielten kanssa tekee mahdottomaksi käyttää näitä DBMS-järjestelmiä vanhoissa järjestelmissä - korvaamaan siellä jo käytetyt DBMS:t.
Habressa oli jo upea artikkeli ArangoDB:stä ja OrientDB:stä: .
ArangoDB
ArangoDB väittää tukea kaaviotietomallille.
Graafin solmut ArangoDB:ssä ovat tavallisia dokumentteja, ja reunat ovat erikoistyyppisiä dokumentteja, joilla on tavallisten järjestelmäkenttien ohella (_key, _id, _rev) järjestelmäkentät _from и _to. Asiakirjatietokantajärjestelmissä olevat asiakirjat yhdistetään perinteisesti kokoelmiksi. Reunoja edustavien asiakirjojen kokoelmia kutsutaan ArangoDB:ssä reunakokoelmiksi. Muuten, reunakokoelmadokumentit ovat myös asiakirjoja, joten ArangoDB:n reunat voivat toimia myös solmuina.
Raakatiedot
Tehdään kokoelma persons, jonka asiakirjat näyttävät tältä:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Olkoon myös kokoelma cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Sitten kokoelma likes saattaa näyttää tältä:
[
{
"_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
}
]Kyselyt ja tulokset
Kaaviotyylinen kysely ArangoDB:ssä käytetyllä AQL-kielellä, joka palauttaa ihmisen luettavassa muodossa tietoa siitä, kuka mistäkin kahvilasta pitää, näyttää tältä:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }Relaatiotyylissä, jossa "laskemme" suhteita sen sijaan, että tallennamme niitä, tämä kysely voidaan kirjoittaa uudelleen näin (muuten ilman kokoelmaa likes pärjäisi ilman):
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 }Tulos on molemmissa tapauksissa sama:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Lisää kyselyitä ja tuloksia
Jos yllä oleva tulosmuoto näyttää olevan tyypillisempi relaatiotietokantajärjestelmälle kuin asiakirjan DBMS:lle, voit kokeilla tätä kyselyä (tai voit käyttää ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Tulos näyttää tältä:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
Graafimallin toteuttamisen perusta OrientDB:n dokumenttimallin päälle on asiakirjakentillä on enemmän tai vähemmän standardi skalaariarvojen lisäksi myös arvoja tyyppejä, kuten LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Näiden tyyppien arvot ovat linkkejä tai linkkikokoelmia asiakirjoja.
Järjestelmän antamalla asiakirjatunnisteella on "fyysinen merkitys", joka osoittaa tietueen sijainnin tietokannassa, ja se näyttää suunnilleen tältä: @rid : #3:16. Siten referenssiominaisuuksien arvot ovat todella osoittimia (kuten graafimallissa) eikä valintaehtoja (kuten relaatiomallissa).
Kuten ArangoDB, myös OrientDB:n reunat esitetään erillisinä asiakirjoina (vaikka jos reunalla ei ole omia ominaisuuksia, se voidaan tehdä , ja se ei vastaa erillistä asiakirjaa).
Raakatiedot
Läheisessä muodossa OrientDB-tietokanta, edellisen esimerkin ArangoDB:n tiedot näyttäisivät suunnilleen tältä:
[
{
"@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"
}
]Kuten näemme, kärkipisteet tallentavat myös tietoa saapuvista ja lähtevistä reunoista. klo Document API:n on itse valvottava viitteiden eheyttä, ja Graph API ottaa tämän työn. Mutta katsotaanpa, miltä pääsy OrientDB:hen näyttää "puhtailla" kyselykielillä, joita ei ole integroitu ohjelmointikieliin.
Kyselyt ja tulokset
Kysely, jonka tarkoitus on samanlainen kuin OrientDB:n ArangoDB-esimerkin kysely, näyttää tältä:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameTulos saadaan seuraavassa muodossa:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Jos tuloksen muoto näyttää jälleen liian "relatiiviselta", sinun on poistettava rivi :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]OrientDB:n kyselykieltä voidaan kuvata SQL:ksi, jossa on Gremlinin kaltaisia lisäyksiä. Versiossa 2.2 ilmestyi Cypher-tyyppinen pyyntölomake, :
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_nameTulosmuoto on sama kuin edellisessä pyynnössä. Mieti, mikä on poistettava, jotta se olisi "relatiivisempi", kuten ensimmäisessä kyselyssä.
Azure CosmosDB
Vähemmässä määrin se, mitä edellä sanottiin ArangoDB:stä ja OrientDB:stä, koskee Azure CosmosDB:tä. CosmosDB tarjoaa seuraavat tietojen käyttöliittymät: SQL, MongoDB, Gremlin ja Cassandra.
SQL-sovellusliittymää ja MongoDB-sovellusliittymää käytetään asiakirjamallin tietojen käyttämiseen. Gremlin API ja Cassandra API - tietojen käyttämiseen kaavio- ja sarakemuodossa. Kaikkien mallien tiedot tallennetaan CosmosDB:n sisäisessä mallimuodossa: ("atomi-tietue-sekvenssi"), joka on myös lähellä dokumenttia.
Mutta käyttäjän valitsema tietomalli ja käytetty API ovat kiinteät tilin luomisen yhteydessä palveluun. Yhteen malliin ladattuja tietoja ei ole mahdollista käyttää toisen mallin muodossa, kuten tämä osoittaa:
Siten Azure CosmosDB:n monimalli on nykyään vain mahdollisuus käyttää useita tietokantoja, jotka tukevat yhden valmistajan eri malleja, mikä ei ratkaise kaikkia monimuunnelmien tallennusongelmia.
Monimalli DBMS perustuu kaaviomalliin?
Huomionarvoista on se tosiasia, että markkinoilla ei ole vielä monia graafiseen malliin perustuvia DBMS-järjestelmiä (lukuun ottamatta usean mallin tukea samanaikaisesti kahdelle graafimallille: RDF ja LPG; katso tämä ). Suurimpia vaikeuksia aiheuttaa dokumenttimallin toteuttaminen graafimallin päälle relaatiomallin sijaan.
Kysymys siitä, kuinka relaatiomalli toteutetaan graafimallin päälle, pohdittiin jo jälkimmäistä muodostettaessa. Miten Esimerkiksi :
Graafi-lähestymistapaan ei sisälly mitään, mikä estäisi luomasta (esim. sopivalla indeksoinnilla) graafitietokantaan kerrosta, joka mahdollistaa relaationäkymän, jossa (1) monikkopalaute tavallisista avainarvopareista ja (2) ryhmittely monikko relaatiotyypin mukaan.
Kun toteutat dokumenttimallin kaaviomallin päälle, sinun on pidettävä mielessä esimerkiksi seuraavat asiat:
- JSON-taulukon elementtejä pidetään järjestettyinä, mutta graafin reunan kärjestä lähteviä ei.
- Dokumenttimallin tiedot ovat yleensä denormalisoituja; et silti halua tallentaa useita kopioita samasta upotetusta asiakirjasta, eikä aliasiakirjoilla yleensä ole tunnisteita.
- Toisaalta dokumenttien DBMS-järjestelmien ideologia on, että asiakirjat ovat valmiita "aggregaatteja", joita ei tarvitse rakentaa joka kerta uudelleen. Graafimallille on tarjottava mahdollisuus saada nopeasti valmiita dokumentteja vastaava osagraafi.
Jotain mainontaa
Artikkelin kirjoittaja liittyy NitrosBase DBMS:n kehittämiseen, jonka sisäinen malli on graafi ja ulkoiset mallit - relaatio- ja dokumenttimallit - ovat sen esityksiä. Kaikki mallit ovat tasa-arvoisia: lähes kaikki tiedot ovat saatavilla millä tahansa niistä käyttämällä sille luontaista kyselykieltä. Lisäksi tietoja voidaan muuttaa missä tahansa näkymässä. Muutokset näkyvät sisäisessä mallissa ja vastaavasti muissa näkymissä.
Toivon, että kuvailen yhdessä seuraavista artikkeleista, miltä mallien yhteensopivuus näyttää NitrosBasessa.
Johtopäätös
Toivon, että niin sanotun monimallinnuksen yleiset linjat ovat tulleet lukijalle enemmän tai vähemmän selkeiksi. Monen mallin DBMS:t ovat melko erilaisia, ja "monimallin tuki" voi näyttää erilaiselta. Ymmärtääksesi, mitä kutsutaan "monimalliksi" kussakin tapauksessa, on hyödyllistä vastata seuraaviin kysymyksiin:
- Puhutaanko perinteisten mallien tukemisesta vai jonkinlaisesta "hybridi" mallista?
- Ovatko mallit "tasa-arvoisia" vai onko yksi niistä muiden aihe?
- Ovatko mallit "välinpitämättömiä" toisilleen? Voidaanko yhteen malliin kirjoitettua tietoa lukea toisessa tai jopa ylikirjoittaa?
Uskon, että kysymykseen usean mallin DBMS:n relevanssista voidaan jo vastata myönteisesti, mutta mielenkiintoinen kysymys on, minkä tyyppisille niistä tulee lähitulevaisuudessa enemmän kysyntää. Näyttää siltä, että perinteisiä, ensisijaisesti relaatiomalleja tukevilla monimallipohjaisilla tietokantajärjestelmillä tulee olemaan enemmän kysyntää; Monimallipohjaisten DBMS-järjestelmien suosio, joka tarjoaa uusia malleja, joissa yhdistyvät erilaisten perinteisten edut, on kaukaisemman tulevaisuuden kysymys.
Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. , ole kiltti.
Käytätkö usean mallin DBMS:ää?
Emme käytä sitä, vaan tallennamme kaiken yhteen DBMS-järjestelmään ja yhteen malliin
Käytämme perinteisten DBMS-järjestelmien monimalliominaisuuksia
Harjoittelemme monikielisyyttä
Käytämme uutta monimallitietokantajärjestelmää (Arango, Orient, CosmosDB)
19 käyttäjää äänesti. 4 käyttäjää pidättyi äänestämästä.
Lähde: will.com
