Informazio sistema modernoak nahiko konplexuak dira. Hori gutxi balitz, haien konplexutasuna horietan prozesatutako datuen konplexutasunari zor zaio. Datuen konplexutasuna askotan erabiltzen diren datu-ereduen aniztasunean datza. Beraz, adibidez, datuak "handia" bihurtzen direnean, ezaugarri arazotsuetako bat bere bolumena ("bolumena") ez ezik, bere barietatea ere ("barietatea") da.
Arrazoibidean oraindik akatsik aurkitzen ez baduzu, jarraitu irakurri.
Edukia
Poliglota iraunkortasuna
Aurrekoak, batzuetan sistema baten esparruan ere beharrezkoa dela hainbat DBMS erabiltzea datuak gordetzeko eta haiek prozesatzeko hainbat arazo konpontzeko, bakoitzak bere datu-eredua onartzen duela. M. Fowlerren esku argiarekin, liburu ospetsu batzuk eta horietako bat Agile Manifesto, egoera honi deitzen zaio aldaera anitzeko biltegiratzea (“poliglota iraunkortasuna”).
Fowler-ek honako adibide hau ere badu merkataritza elektronikoaren alorrean datuen biltegiratzea antolatzeko ezaugarri osoko eta karga handiko aplikazio batean.
Adibide hau, noski, gehiegizkoa da, baina dagokion helbururako DBMS bat edo beste aukeratzearen aldeko gogoeta batzuk aurki daitezke, adibidez, .
Argi dago halako zoo batean morroi izatea ez dela erraza.
- Datuen biltegiratzea egiten duen kode kopurua erabiltzen den DBMS kopuruaren proportzioan hazten da; kodea sinkronizatzeko datu kopurua ona da zenbaki honen karratuarekiko proportzionala ez bada.
- Erabilitako DBMS-kopuruaren multiplo gisa, erabiltzen diren DBMS bakoitzaren enpresa-ezaugarriak eskaintzearen kostuak (eskalagarritasuna, akatsen tolerantzia, erabilgarritasun handia) handitzen dira.
- Ezinezkoa da biltegiratze azpisistemaren enpresa-ezaugarriak bere osotasunean ziurtatzea - batez ere transakzionaltasuna.
Zooko zuzendariaren ikuspuntutik, dena honela ikusten da:
- DBMS fabrikatzailearen lizentzien eta laguntza teknikoaren kostuaren igoera anitz.
- Langileen gehiegikeria eta epeak handitzea.
- Zuzeneko diru-galerak edo zigorrak datuen koherentzia ezagatik.
Sistemaren jabetza-kostu osoaren (TCO) igoera nabarmena da. Ba al dago "biltegiratze-aukera anitz" egoeratik ateratzeko modurik?
Eredu anitzekoa
"Aldari anitzeko biltegiratze" terminoa 2011n hasi zen erabili. Planteamenduaren arazoez jabetzeak eta konponbidearen bilaketak hainbat urte behar izan zituen, eta 2015erako, Gartnerreko analisten ahotan, erantzuna formulatu zen:
- "tik'
DBMSen etorkizuna, haien arkitekturak eta horiek erabiltzeko moduak eredu anitzekoa da.
- "tik'
DBMS operatibo nagusiek hainbat eredu eskainiko dituzte —erlazionalak eta ez-erlazionalak— plataforma bakar baten barruan.
Badirudi oraingoan Gartner-eko analistek arrazoia zutela euren iragarpenarekin. orrialdera joaten bazara DBMS-en DB-Engines-en, hori ikus dezakezuоBere buruzagi gehienek beren burua eredu anitzeko DBMS gisa kokatzen dute. Gauza bera orrialdean ikus daiteke edozein balorazio pribatuarekin.
Beheko taulak DBMS erakusten du: balorazio pribatu bakoitzeko liderrak, eredu anitzekoak direla diotenak. DBMS bakoitzeko, jatorrizko onartzen den eredua (behin batean bakarra zena) eta horrekin batera gaur egun onartzen diren ereduak adierazten dira. Halaber, "jatorriz eredu anitzeko" gisa kokatzen diren eta, sortzaileen arabera, hasierako heredatutako eredurik ez duten DBMSak ere zerrendatzen dira.
| DBMS | Hasierako eredua | Eredu osagarriak |
|---|---|---|
| Oracle | erlazionala | Grafikoa, dokumentua |
| MS SQL | erlazionala | Grafikoa, dokumentua |
| PostgreSQL | erlazionala | Grafikoa*, dokumentua |
| MarkLogic | Dokumentala | Grafikoa, erlazionala |
| MongoDB | Dokumentala | Gako-balioa, grafikoa* |
| DataStax | Zutabe zabala | Dokumentala, grafikoa |
| Birbanaketa | Gako-balioa | Dokumentala, grafikoa* |
| ArangoDB | - | Grafikoa, dokumentua |
| OrientDB | - | Grafikoa, dokumentua, erlazionala |
| Azure CosmosDB | - | Grafikoa, dokumentua, erlazionala |
Oharrak mahai gainean
Taulan dauden izartxoek erreserbak eskatzen dituzten adierazpenak markatzen dituzte:
- PostgreSQL DBMS-k ez du onartzen grafikoen datu-eredua, baina produktu honek onartzen du , hala nola AgensGraph.
- MongoDB-ri dagokionez, zuzenagoa da kontsulta-lengoaian grafiko-operadoreen presentziaz hitz egitea (, ) grafiko-eredua onartzeari buruz baino, nahiz eta, noski, haien sarrerak optimizazio batzuk behar izan zituen biltegiratze fisikoaren mailan grafiko-ereduari eusteko norabidean.
- Redis-i dagokionez, luzapena esan nahi dugu .
Ondoren, klase bakoitzerako, klase honetatik hainbat ereduren euskarria DBMSan nola inplementatzen den erakutsiko dugu. Erlazio-, dokumentu- eta grafiko-ereduak kontuan hartuko ditugu garrantzitsuenak eta DBMS espezifikoen adibideak erabiliko ditugu, "falta daudenak" nola inplementatzen diren erakusteko.
Erlazio-ereduan oinarritutako eredu anitzeko DBMS
Gaur egun DBMS nagusiak erlazionalak dira; Gartner-en iragarpena ezin da egiatzat hartu RDBMS-ek eredu anitzeko norabidean mugimendurik erakusten ez balu. Eta erakusten dute. Orain, eredu anitzeko DBMS bat Suitzako labana bat bezalakoa den ideia, ezer ondo egin ezin duena, zuzenean Larry Ellisonengana bideratu daiteke.
Egileak, ordea, nahiago du Microsoft SQL Server-en multimodeladoa ezartzea, eta horren adibidea deskribatuko da dokumentu eta grafiko ereduetarako RDBMS laguntza.
Dokumentu eredua MS SQL Server-en
Dagoeneko bi artikulu bikain egon dira Habré-ri buruz MS SQL Server zerbitzariak dokumentu-ereduaren euskarria nola inplementatzen duen buruz; Berriro eta iruzkin labur batera mugatuko naiz:
MS SQL Server-en dokumentu-eredua onartzeko modua nahiko ohikoa da DBMS erlazionaletan: JSON dokumentuak testu-eremu arruntetan gordetzea proposatzen da. Dokumentu ereduaren euskarria JSON hau analizatzeko operadore bereziak eskaintzea da:
- Atributu-balio eskalarrak ateratzeko,
- azpidokumentuak ateratzeko.
Bi operadoreen bigarren argumentua JSONPath moduko sintaxiko adierazpena da.
Abstrakzioan, esan dezakegu modu honetan gordetako dokumentuak ez direla "lehen mailako entitateak" erlazio DBMS batean, tuplak ez bezala. Zehazki, MS SQL Server-en gaur egun ez dago JSON dokumentuen eremuetan indizerik, eta horrek zaildu egiten du eremu horien balioak erabiliz taulak batzea eta baita balio horiek erabiliz dokumentuak hautatzea ere. Hala ere, posible da eremu horretarako kalkulatutako zutabe bat sortzea eta horren indizea.
Gainera, MS SQL Server-ek operadorea erabiliz JSON dokumentu bat eroso eraikitzeko gaitasuna eskaintzen du taulen edukietatik. - aukera bat, zentzu jakin batean, aurrekoaren aurkakoa, ohiko biltegiratzea. Argi dago RDBMS bat zenbaterainokoa den, ikuspegi honek dokumentuen DBMSen ideologiarekin kontraesanean dagoela, funtsean kontsulta ezagunetarako prest egindako erantzunak gordetzen baitituzte, eta garapen errazteko arazoak baino ezin ditu konpondu, baina ez abiadura.
Azkenik, MS SQL Server-ek dokumentuen eraikuntzaren aurkako arazoa konpontzeko aukera ematen du: JSON tauletan deskonposa dezakezu. . Dokumentua guztiz laua ez bada, erabili beharko duzu CROSS APPLY.
Grafiko eredua MS SQL Server-en
Grafikoaren (LPG) ereduaren euskarria Microsoft SQL Server-en ere guztiz inplementatuta dago : Nodoak gordetzeko eta grafikoen ertzak gordetzeko taula bereziak erabiltzea proposatzen da. Horrelako taulak esapideak erabiliz sortzen dira CREATE TABLE AS NODE и CREATE TABLE AS EDGE hurrenez hurren.
Lehenengo motako taulak erregistroak gordetzeko taula arrunten antzekoak dira, kanpoko desberdintasun bakarra taulak sistema-eremu bat duela da. $node_id — Datu-basearen nodo grafiko baten identifikatzaile bakarra.
Era berean, bigarren motako taulek sistema-eremuak dituzte $from_id и $to_id, horrelako tauletako sarrerek argi definitzen dituzte nodoen arteko loturak. Taula bereizi bat erabiltzen da mota bakoitzeko erlazioak gordetzeko.
Adibide batekin ilustratu dezagun. Utzi grafikoaren datuek irudian agertzen denaren antzeko diseinua izan. Ondoren, datu-basean dagokion egitura sortzeko DDL kontsulta hauek exekutatu behar dituzu:
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);Taulen berezitasun nagusia hauen aurkako kontsultetan Cypher-en antzeko sintaxiarekin grafiko-ereduak erabil daitezkeela da (hala ere, "*"eta abar ez dira oraindik onartzen). Errendimenduaren neurketetan oinarrituta, gainera, pentsa daiteke taula hauetan datuak biltegiratzeko modua bestelakoa dela datuak taula arruntetan gordetzeko modua eta grafikoen kontsultak egiteko optimizatuta dagoela.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Gainera, nahiko zaila da grafiko-eredu hauek ez erabiltzea horrelako taulekin lan egitean, antzeko arazoak konpontzeko SQL kontsulta arruntetan beharrezkoa izango baita sistemaren "grafiko" nodoen identifikatzaileak lortzeko ahalegin gehigarriak ($node_id, $from_id, $to_id; Arrazoi beragatik, datuak txertatzeko kontsultak ez dira hemen erakusten, alferrikako astunak baitira).
MS SQL Server-en dokumentu eta grafiko-ereduen inplementazioen deskribapena laburbiltzeko, kontuan izango nuke eredu baten gainean bestearen gainean halako inplementazioek ez dutela arrakastarik ematen, hizkuntza-diseinuaren ikuspuntutik batez ere. Beharrezkoa da hizkuntza bat beste batekin zabaltzea, hizkuntzak ez dira guztiz "ortogonalak", bateragarritasun arauak nahiko bitxiak izan daitezke.
Dokumentu ereduan oinarritutako eredu anitzeko DBMS
Atal honetan, eredu anitzeko dokumentuen DBMSen inplementazioa ilustratu nahiko nuke horietako ezagunenetakoa ez den MongoDB adibidea erabiliz (esan bezala, baldintza grafikoen operadoreak bakarrik ditu. $lookup и $graphLookup, ez da zatitutako bildumak lantzen), baina helduago eta "enpresa" DBMS baten adibidea erabiliz .
Beraz, utzi bildumak honako mota honetako XML dokumentu multzo bat edukitzea (MarkLogic-ek JSON dokumentuak gordetzeko aukera ere ematen dizu):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Erlazio eredua MarkLogic-en
Dokumentu bilduma baten ikuspegi erlazional bat sor daiteke erabiliz (elementuen edukia value beheko adibidean XPath arbitrario bat egon daiteke):
<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>Sortutako ikuspegia SQL kontsulta batekin zuzendu dezakezu (adibidez, ODBC bidez):
SELECT name, surname FROM Person WHERE name="John"Zoritxarrez, pantaila txantiloiak sortutako erlazio-ikuspegia irakurtzeko soilik da. Eskaera bat prozesatzen denean, MarkLogic erabiltzen saiatuko da . Aurretik, MarkLogic-ek harreman-ikuspegi mugatuak zituen, guztiz eta idazteko modukoak, baina orain zaharkitutzat jotzen dira.
MarkLogic-en eredu grafikoa
Grafikoaren (RDF) ereduaren laguntzarekin, dena berdina da. Berriz ere laguntzarekin dokumentu bilduma baten RDF irudikapena sor dezakezu goiko adibidetik:
<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>Sortutako RDF grafikoa SPARQL kontsulta batekin zuzendu dezakezu:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Erlazionalak ez bezala, MarkLogic-ek grafiko-eredua onartzen du beste bi modutan:
- DBMS bat RDF datuen biltegiratze bereizia izan daiteke (bertan dauden hirukoteak deituko dira goian azaldutakoen aldean ).
- Serializazio berezian RDF XML edo JSON dokumentuetan txerta daiteke (eta hirukoteak deituko dira ). Hau mekanismoen alternatiba da ziurrenik
idrefeta abar.
MarkLogic-en gauzak "benetan" nola funtzionatzen duten jakiteko ideia ona da , zentzu honetan, maila baxua da, nahiz eta bere helburua alderantzizkoa den -erabilitako datu-eredutik abstrakzioa egiten saiatzea, eredu ezberdinetako datuekin lan koherentea bermatzea, transakzionaltasuna, etab.
Eredu anitzeko DBMS "eredu nagusirik gabe"
Merkatuan ere badaude DBMSak hasieran eredu anitzeko moduan kokatzen direnak, herentziazko eredu nagusirik gabe. Horien artean daude , (2018tik garapen enpresa SAPekoa da) eta (Microsoft Azure hodeiko plataformaren parte den zerbitzua).
Izan ere, ArangoDB-n eta OrientDB-en badira "oinarrizko" ereduak. Bi kasuetan, horiek beren datu-ereduak dira, dokumentuaren orokortzeak. Orokortzeak, batez ere, grafiko eta harreman izaerako kontsultak egiteko gaitasuna errazteko dira.
Eredu hauek zehaztutako DBMSan erabiltzeko eskuragarri dauden bakarrak dira; beren kontsulta-lengoaia haiekin lan egiteko diseinatuta daude. Jakina, horrelako ereduak eta DBMSak itxaropentsuak dira, baina eredu eta lengoaia estandarrekin bateragarritasun faltak ezinezkoa egiten du DBMS horiek sistema tradizionaletan erabiltzea, lehendik erabiltzen diren DBMSak ordezkatzeko.
ArangoDBri eta OrientDBri buruzko artikulu zoragarri bat zegoen jada Habré-n: .
ArangoDB
ArangoDB-k grafikoen datu-eredu baten laguntza eskatzen du.
ArangoDBko grafiko baten nodoak dokumentu arruntak dira, eta ertzak mota bereziko dokumentuak, sistema arrunteko eremuekin batera (_key, _id, _rev) sistema-eremuak _from и _to. Dokumentu DBMS-etako dokumentuak tradizioz bildumetan konbinatzen dira. Ertzak adierazten dituzten dokumentuen bildumak ertz bildumak deitzen dira ArangoDBn. Bide batez, ertz-bilketaren dokumentuak ere dokumentuak dira, beraz, ArangoDB-ko ertzek nodo gisa ere jardun dezakete.
Datu gordinak
Egin dezagun bilduma persons, zeinaren dokumentuak honelakoak diren:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Izan dadila bilduma bat ere cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Ondoren, bilduma likes itxura hau izan dezake:
[
{
"_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
}
]Kontsultak eta emaitzak
ArangoDB-n erabiltzen den AQL hizkuntzan grafiko-estiloko kontsulta batek, gizakiek irakur daitekeen moduan zein kafetegi gustatzen zaionari buruzko informazioa itzultzen du:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }Erlazional estilo batean, non harremanak gorde beharrean “konputatzen” ari garen, kontsulta hau honela berridatzi daiteke (bide batez, bildumarik gabe likes gabe egin liteke):
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 }Bi kasuetan emaitza berdina izango da:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Kontsulta eta emaitza gehiago
Goiko emaitza formatua ohikoagoa dela DBMS erlazional baterako dokumentu DBMS baterako baino ohikoagoa dela dirudi, kontsulta hau proba dezakezu (edo erabil dezakezu ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Emaitza honela izango da:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
OrientDB-n dokumentu-eredu baten gainean grafiko-eredu bat ezartzeko oinarria hauxe da dokumentu-eremuek, gutxi gorabehera balio eskalar estandarrez gain, motako balioak ere badituzte LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Mota hauen balioak estekak edo estekak bildumak dira dokumentuak.
Sistemak esleitutako dokumentu-identifikatzaileak "esanahi fisikoa" du, erregistroaren posizioa datu-basean adierazten duena, eta honelako itxura du: @rid : #3:16. Beraz, erreferentzia-propietateen balioak erakusleak dira (grafiko-ereduan bezala) eta ez hautapen-baldintzak (erlazio-ereduan bezala).
ArangoDB bezala, OrientDB-n ertzak dokumentu bereizi gisa irudikatzen dira (nahiz eta ertz batek bere propietaterik ez badu, egin daiteke , eta ez da aparteko dokumentu batekin bat etorriko).
Datu gordinak
Formatu hurbilean OrientDB datu-basea, ArangoDBrako aurreko adibideko datuak honelakoak izango lirateke:
[
{
"@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"
}
]Ikus dezakegunez, erpinek sarrerako eta irteerako ertzei buruzko informazioa ere gordetzen dute. At Dokumentu APIak osotasun erreferentziala bera kontrolatu behar du, eta Graph APIak bere gain hartzen du lan hori. Baina ikus dezagun nolakoa den OrientDBrako sarbidea programazio lengoaietan integratuta ez dauden kontsulta-lengoaia "puruetan".
Kontsultak eta emaitzak
OrientDB-ko ArangoDB-rako adibideko kontsultaren helburuen antzekoa da honakoa:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameEmaitza forma honetan lortuko da:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Emaitza formatua berriro "erlazional"egia iruditzen bazaio, lerroa kendu behar duzu :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]OrientDB-ren kontsulta-lengoaia SQL gisa deskriba daiteke Gremlin antzeko txertatzeekin. 2.2 bertsioan, Cypher moduko eskaera-inprimakia agertu zen, :
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_nameEmaitza formatua aurreko eskaeraren berdina izango da. Pentsa ezazu zer kendu behar den "erlazionalagoa" izan dadin, lehen kontsultan bezala.
Azure CosmosDB
Neurri txikiagoan, ArangoDBri eta OrientDBri buruz goian esandakoa Azure CosmosDB-ri aplikatzen zaio. CosmosDB-k datuetara sartzeko API hauek eskaintzen ditu: SQL, MongoDB, Gremlin eta Cassandra.
SQL APIa eta MongoDB APIa dokumentuaren ereduko datuak atzitzeko erabiltzen dira. Gremlin API eta Cassandra API - datuak grafiko eta zutabe formatuetan atzitzeko, hurrenez hurren. Eredu guztietako datuak CosmosDB barne-ereduaren formatuan gordetzen dira: (“atomo-erregistro-sekuentzia”), dokumentutik hurbil dagoena ere.
Baina erabiltzaileak aukeratutako datu-eredua eta erabilitako APIa zerbitzuan kontu bat sortzeko unean finkatzen dira. Ezin da eredu batean kargatutako datuak beste eredu baten formatuan sartu, honelako zerbaitek erakusten duen moduan:
Horrela, gaur egun Azure CosmosDB-en eredu anitzeko gaitasuna fabrikatzaile baten eredu desberdinak onartzen dituzten hainbat datu-base erabiltzeko gaitasuna da, eta horrek ez ditu aldaera anitzeko biltegiratze arazo guztiak konpontzen.
Eredu anitzeko DBMS eredu grafiko batean oinarrituta?
Aipagarria da merkatuan eredu anitzeko DBMSrik ez dagoela oraindik grafiko-eredu batean oinarritzen dena (modelo anitzeko euskarria izan ezik, aldi berean bi grafiko-eredutarako: RDF eta LPG; ikus hau atalean). ). Zailtasun handienak dokumentu-eredu bat grafiko-eredu baten gainean ezartzeak sortzen ditu, erlazio-eredua baino.
Eredu grafikoaren gainean eredu erlazional bat nola inplementatu galdera azken hau eratzean ere kontuan hartu zen. Nola adibidez :
Ez dago grafikoaren ikuspegiaren berezko ezer geruza bat sortzea eragozten duen grafiko-datu-base batean (adibidez, indexazio egokiaren bidez) harreman-ikuspegia ahalbidetzen duena (1) tuplak berreskuratzeko ohiko gako-balio bikoteetatik eta (2) taldekatzearekin. tuplak erlazio motaren arabera.
Dokumentu-eredu bat grafiko-eredu baten gainean ezartzean, kontuan izan behar duzu, adibidez, honako hau:
- JSON array bateko elementuak ordenatuta hartzen dira, baina grafikoaren erpin baten erpinetik ateratzen direnak ez;
- Dokumentu-ereduko datuak normalean desnormalizatu egiten dira; oraindik ez dituzu kapsulatutako dokumentu beraren hainbat kopia gorde nahi, eta azpidokumentuek normalean ez dute identifikatzailerik;
- Bestalde, dokumentu DBMSen ideologia da dokumentuak prest egindako "agregatuak" direla, eta aldi bakoitzean berriro eraiki behar ez direnak. Beharrezkoa da grafiko-ereduari amaitutako dokumentuari dagokion azpigrafoa azkar lortzeko gaitasuna ematea.
Publizitate apur bat
Artikuluaren egilea NitrosBase DBMS-aren garapenarekin lotuta dago, barne-eredua grafikoa dena, eta kanpoko ereduak -erlazionalak eta dokumentuak- bere irudikapenak dira. Eredu guztiak berdinak dira: ia edozein datu eskuragarri dago horietako edozeinetan berezkoa den kontsulta-lengoaia erabiliz. Gainera, edozein ikuspegitan, datuak alda daitezke. Aldaketak barne ereduan islatuko dira eta, horren arabera, beste ikuspegi batzuetan.
Zorionez, NitrosBase-n eredu bat etortzea nolakoa den deskribatuko dut hurrengo artikuluetako batean.
Ondorioa
Espero dut eredu anitzeko deritzonaren eskema orokorrak irakurleari gehiago edo gutxiago argitzea. Eredu anitzeko DBMSak nahiko desberdinak dira, eta "modelo anitzeko euskarria" itxura desberdina izan dezake. Kasu zehatz bakoitzean "multi-model" deritzona ulertzeko, komeni da galdera hauei erantzutea:
- Eredu tradizionalak edo eredu “hibrido” motaren bat onartzeaz ari al gara?
- Ereduak “berdinak” al dira, ala horietako bat besteen gaia da?
- Ereduak elkarri “axolagabeak” al dira? Eredu batean idatzitako datuak beste batean irakur daitezke ala gainidatzi ere?
Uste dut eredu anitzeko DBMSen garrantziari buruzko galdera positiboki erantzun daitekeela, baina galdera interesgarria da etorkizun hurbilean zein motatako eskaera gehiago izango diren. Badirudi eredu tradizionalak onartzen dituzten eredu anitzeko DBMSek, batez ere erlazionalak, eskaera handiagoa izango dutela; Eredu anitzeko DBMSen ospea, tradizional ezberdinen abantailak uztartzen dituzten eredu berriak eskainiz, etorkizun urrunagoko kontua da.
Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. , mesedez.
Eredu anitzeko DBMS erabiltzen al duzu?
-
Ez dugu erabiltzen, dena DBMS batean eta modelo batean gordetzen dugu
-
DBMS tradizionalen eredu anitzeko gaitasunak erabiltzen ditugu
-
Poliglota iraunkortasuna lantzen dugu
-
Eredu anitzeko DBMS berria erabiltzen dugu (Arango, Orient, CosmosDB)
19 erabiltzailek eman dute botoa. 4 erabiltzaile abstenitu ziren.
Iturria: www.habr.com