Mae systemau gwybodaeth modern yn eithaf cymhleth. Yn anad dim, cymhlethdod y data a brosesir ynddynt sy'n gyfrifol am eu cymhlethdod. Mae cymhlethdod data yn aml yn gorwedd yn yr amrywiaeth o fodelau data a ddefnyddir. Felly, er enghraifft, pan ddaw data yn “fawr”, un o’r nodweddion problematig yw nid yn unig ei gyfaint (“cyfaint”), ond hefyd ei amrywiaeth (“amrywiaeth”).
Os nad ydych chi wedi dod o hyd i ddiffyg yn y rhesymu eto, darllenwch ymlaen.
Cynnwys
Dyfalbarhad polyglot
Mae'r uchod yn arwain at y ffaith, weithiau hyd yn oed o fewn fframwaith un system, mae angen defnyddio sawl DBMS gwahanol i storio data a datrys problemau amrywiol wrth eu prosesu, ac mae pob un ohonynt yn cefnogi ei fodel data ei hun. Gyda llaw ysgafn M. Fowler, nifer o lyfrau enwog ac un o Maniffesto Agile, gelwir y sefyllfa hon storfa aml-amrywiad (“dyfalbarhad polyglot”).
Mae gan Fowler hefyd yr enghraifft ganlynol o drefnu storio data mewn cymhwysiad llawn sylw a llwyth uchel ym maes e-fasnach.
Mae'r enghraifft hon, wrth gwrs, wedi'i gorliwio rhywfaint, ond gellir dod o hyd i rai ystyriaethau o blaid dewis un neu'r llall DBMS at y diben cyfatebol, er enghraifft, .
Mae'n amlwg nad yw bod yn was mewn sw o'r fath yn hawdd.
- Mae swm y cod sy'n perfformio storio data yn tyfu yn gymesur â nifer y DBMSs a ddefnyddir; mae swm y data cydamseru cod yn dda os nad yn gymesur â sgwâr y rhif hwn.
- Fel lluosrif o nifer y DBMSs a ddefnyddir, mae costau darparu nodweddion menter (scalability, goddefgarwch namau, argaeledd uchel) pob un o'r DBMSs a ddefnyddir yn cynyddu.
- Mae'n amhosibl sicrhau nodweddion menter yr is-system storio yn ei chyfanrwydd - yn enwedig trafodion.
O safbwynt cyfarwyddwr y sw, mae popeth yn edrych fel hyn:
- Cynnydd lluosog yng nghost trwyddedau a chymorth technegol gan wneuthurwr DBMS.
- Gorstaffio a mwy o derfynau amser.
- Colledion ariannol uniongyrchol neu gosbau oherwydd anghysondeb data.
Mae cynnydd sylweddol yng nghyfanswm cost perchnogaeth y system (TCO). A oes unrhyw ffordd allan o'r sefyllfa o "opsiynau storio lluosog"?
Aml-fodel
Daeth y term “storfa aml-newidyn” i rym yn 2011. Cymerodd ymwybyddiaeth o broblemau'r dull gweithredu a chwilio am ateb sawl blwyddyn, ac erbyn 2015, trwy enau dadansoddwyr Gartner, lluniwyd yr ateb:
- O "'
Mae dyfodol DBMSs, eu saernïaeth a ffyrdd o'u defnyddio yn aml-fodel.
- O "'
Bydd DBMSs gweithredol blaenllaw yn cynnig modelau lluosog - perthynol ac amherthnasol - fel rhan o un platfform.
Mae'n ymddangos bod dadansoddwyr Gartner y tro hwn yn iawn gyda'u rhagolwg. Os ewch chi i'r dudalen gyda DBMS ar DB-Engines, gallwch weld hynnyоMae'r rhan fwyaf o'i arweinwyr yn gosod eu hunain yn benodol fel DBMSs aml-fodel. Gellir gweld yr un peth ar y dudalen gydag unrhyw sgôr preifat.
Mae'r tabl isod yn dangos y DBMS - yr arweinwyr ym mhob un o'r graddfeydd preifat, sy'n honni eu bod yn aml-fodel. Ar gyfer pob DBMS, nodir y model cefnogi gwreiddiol (a oedd unwaith yr unig un) ac ynghyd ag ef y modelau a gefnogir ar hyn o bryd. Rhestrir hefyd DBMSs sy'n gosod eu hunain yn "fodel aml-fodel gwreiddiol" ac, yn ôl y crewyr, nid oes ganddynt unrhyw fodel etifeddol cychwynnol.
| DBMS | Model cychwynnol | Modelau ychwanegol |
|---|---|---|
| Oracle | perthynol | Graff, dogfen |
| MS SQL | perthynol | Graff, dogfen |
| PostgreSQL | perthynol | Graff*, dogfen |
| MarkLogic | Rhaglen ddogfen | Graff, perthynol |
| MongoDB | Rhaglen ddogfen | Gwerth-allwedd, graff* |
| Stax Data | Colofn lydan | Dogfen, graff |
| Redis | Gwerth allweddol | Rhaglen ddogfen, graff* |
| ArangoDB | - | Graff, dogfen |
| OrientDB | - | Graff, dogfen, perthynol |
| CosmosDB Azure | - | Graff, dogfen, perthynol |
Nodiadau ar y bwrdd
Mae seren yn y tabl yn nodi datganiadau y mae angen eu cadw:
- Nid yw'r DBMS PostgreSQL yn cefnogi'r model data graff, ond mae'r cynnyrch hwn yn ei gefnogi , megis AgensGraph.
- Mewn perthynas â MongoDB, mae'n fwy cywir siarad am bresenoldeb gweithredwyr graff yn yr iaith ymholiad (, ) nag am gefnogi'r model graff, er, wrth gwrs, roedd eu cyflwyniad yn gofyn am rai optimizations ar y lefel storio ffisegol i gyfeiriad cefnogi'r model graff.
- Mewn perthynas â Redis, rydym yn golygu'r estyniad .
Nesaf, ar gyfer pob un o'r dosbarthiadau, byddwn yn dangos sut mae cefnogaeth ar gyfer sawl model yn cael ei weithredu yn y DBMS o'r dosbarth hwn. Byddwn yn ystyried y modelau perthynol, dogfen a graff fel y rhai pwysicaf ac yn defnyddio enghreifftiau o DBMSs penodol i ddangos sut mae’r “rhai coll” yn cael eu gweithredu.
DBMS aml-fodel yn seiliedig ar y model perthynol
Perthynol yw'r prif DBMSs ar hyn o bryd; ni ellid ystyried rhagolwg Gartner yn wir pe na bai RDBMSs yn dangos symudiad i gyfeiriad aml-fodelu. Ac maent yn dangos. Nawr gellir cyfeirio'r syniad bod DBMS aml-fodel fel cyllell Swistir, na all wneud unrhyw beth yn dda, yn uniongyrchol at Larry Ellison.
Mae'n well gan yr awdur, fodd bynnag, weithredu aml-fodelu yn Microsoft SQL Server, ar yr enghraifft y disgrifir cefnogaeth RDBMS ar gyfer modelau dogfen a graff.
Model dogfen yn MS SQL Server
Bu dwy erthygl ragorol eisoes ar Habré am sut mae MS SQL Server yn gweithredu cefnogaeth ar gyfer model y ddogfen; Byddaf yn cyfyngu fy hun i ailadrodd a sylwebaeth fer:
Mae'r ffordd i gefnogi'r model dogfen yn MS SQL Server yn eithaf nodweddiadol ar gyfer DBMSs perthynol: Cynigir storio dogfennau JSON mewn meysydd testun cyffredin. Cefnogaeth i'r model dogfen yw darparu gweithredwyr arbennig i ddosrannu'r JSON hwn:
- i echdynnu gwerthoedd priodoledd sgalar,
- i echdynnu is-ddogfennau.
Mae ail ddadl y ddau weithredwr yn fynegiant mewn cystrawen tebyg i JSONPath.
Yn gryno, gallwn ddweud nad yw dogfennau sy'n cael eu storio yn y modd hwn yn “endidau o'r radd flaenaf” mewn DBMS perthynol, yn wahanol i tuples. Yn benodol, yn MS SQL Server nid oes mynegeion ar hyn o bryd ar feysydd dogfennau JSON, sy'n ei gwneud hi'n anodd ymuno â thablau gan ddefnyddio gwerthoedd y meysydd hyn a hyd yn oed ddewis dogfennau gan ddefnyddio'r gwerthoedd hyn. Fodd bynnag, mae'n bosibl creu colofn wedi'i chyfrifo ar gyfer maes o'r fath a mynegai arno.
Yn ogystal, mae MS SQL Server yn darparu'r gallu i adeiladu dogfen JSON yn gyfleus o gynnwys tablau gan ddefnyddio'r gweithredwr - posibilrwydd, mewn ystyr arbennig, gyferbyn â'r un blaenorol, storio confensiynol. Mae'n amlwg, ni waeth pa mor gyflym yw RDBMS, mae'r dull hwn yn gwrth-ddweud ideoleg DBMSs dogfen, sydd yn ei hanfod yn storio atebion parod i ymholiadau poblogaidd, a gallant ond datrys problemau o ran rhwyddineb datblygiad, ond nid cyflymder.
Yn olaf, mae MS SQL Server yn caniatáu ichi ddatrys y broblem gyferbyn o adeiladu dogfennau: gallwch ddadelfennu JSON yn dablau gan ddefnyddio . Os nad yw'r ddogfen yn hollol wastad, bydd angen i chi ei defnyddio CROSS APPLY.
Model graff yn MS SQL Server
Mae cefnogaeth i'r model graff (LPG) hefyd yn cael ei weithredu'n llawn yn Microsoft SQL Server : Cynigir defnyddio tablau arbennig i storio nodau ac i storio ymylon graff. Mae tablau o'r fath yn cael eu creu gan ddefnyddio mynegiadau CREATE TABLE AS NODE и CREATE TABLE AS EDGE yn y drefn honno.
Mae tablau o'r math cyntaf yn debyg i dablau cyffredin ar gyfer storio cofnodion, a'r unig wahaniaeth allanol yw bod y tabl yn cynnwys maes system $node_id — dynodwr unigryw nod graff o fewn y gronfa ddata.
Yn yr un modd, mae gan dablau o'r ail fath feysydd system $from_id и $to_id, mae cofnodion mewn tablau o'r fath yn diffinio'n glir y cysylltiadau rhwng nodau. Defnyddir tabl ar wahân i storio perthnasoedd o bob math.
Gadewch i ni egluro hyn gydag enghraifft. Gadewch i'r data graff gael cynllun tebyg i'r un a ddangosir yn y ffigur. Yna i greu'r strwythur cyfatebol yn y gronfa ddata mae angen i chi redeg yr ymholiadau DDL canlynol:
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);Prif benodolrwydd tablau o’r fath yw, mewn ymholiadau yn eu herbyn, mae’n bosibl defnyddio patrymau graff gyda chystrawen tebyg i Cypher (fodd bynnag, “*" ac ati heb eu cefnogi eto). Yn seiliedig ar fesuriadau perfformiad, gellir tybio hefyd bod y ffordd y mae data'n cael ei storio yn y tablau hyn yn wahanol i'r ffordd y mae data'n cael ei storio mewn tablau rheolaidd ac yn cael ei optimeiddio ar gyfer gweithredu ymholiadau graff o'r fath.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Ar ben hynny, mae'n eithaf anodd peidio â defnyddio'r patrymau graff hyn wrth weithio gyda thablau o'r fath, oherwydd mewn ymholiadau SQL cyffredin i ddatrys problemau tebyg bydd angen gwneud ymdrechion ychwanegol i gael dynodwyr nodau “graff” system ($node_id, $from_id, $to_id; Am yr un rheswm, ni ddangosir ymholiadau am fewnosod data yma gan eu bod yn ddiangen o feichus).
I grynhoi'r disgrifiad o weithrediad y modelau dogfen a graff yn MS SQL Server, hoffwn nodi nad yw gweithrediadau o'r fath o un model ar ben y llall yn ymddangos yn llwyddiannus, yn bennaf o safbwynt dylunio iaith. Mae angen ymestyn un iaith i'r llall, nid yw'r ieithoedd yn gwbl "orthogonal", gall y rheolau cydweddoldeb fod yn eithaf rhyfedd.
DBMS aml-fodel yn seiliedig ar fodel y ddogfen
Yn yr adran hon, hoffwn ddangos gweithrediad aml-fodel mewn DBMSs dogfen gan ddefnyddio'r enghraifft o'r rhai mwyaf poblogaidd ohonynt, MongoDB (fel y dywedwyd, dim ond gweithredwyr graffiau amodol sydd ganddo $lookup и $graphLookup, ddim yn gweithio ar gasgliadau wedi’u torri), ond yn defnyddio’r enghraifft o DBMS mwy aeddfed a “menter” .
Felly, gadewch i'r casgliad gynnwys set o ddogfennau XML o'r math canlynol (mae MarkLogic hefyd yn caniatáu ichi storio dogfennau JSON):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Model perthynol yn MarkLogic
Gellir creu golwg perthynol o gasgliad o ddogfennau gan ddefnyddio (cynnwys elfennau value yn yr enghraifft isod gall fod XPath mympwyol):
<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>Gallwch fynd i'r afael â'r olygfa a grëwyd gydag ymholiad SQL (er enghraifft, trwy ODBC):
SELECT name, surname FROM Person WHERE name="John"Yn anffodus, mae'r olygfa berthynol a grëwyd gan y templed arddangos yn ddarllenadwy yn unig. Wrth brosesu cais amdano, bydd MarkLogic yn ceisio ei ddefnyddio . Yn flaenorol, roedd gan MarkLogic safbwyntiau perthynol cyfyngedig, yn gyfan gwbl ac yn ysgrifenadwy, ond yn awr ystyrir hwynt yn anghymeradwy.
Model graff yn MarkLogic
Gyda chefnogaeth i'r model graff (RDF), mae popeth tua'r un peth. Eto gyda chymorth gallwch greu cynrychiolaeth RDF o gasgliad o ddogfennau o'r enghraifft uchod:
<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>Gallwch fynd i'r afael â'r graff RDF canlyniadol gydag ymholiad SPARQL:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Yn wahanol i'r un perthynol, mae MarkLogic yn cefnogi'r model graff mewn dwy ffordd arall:
- Gall DBMS fod yn storfa gyflawn ar wahân o ddata RDF (gelwir tripledi ynddo yn wahanol i'r rhai a ddisgrifir uchod ).
- Yn syml, gellir mewnosod RDF mewn cyfresoli arbennig i ddogfennau XML neu JSON (a bydd tripledi wedyn yn cael eu galw ). Mae'n debyg bod hwn yn ddewis arall i fecanweithiau
idrefac ati
Mae syniad da o sut mae pethau “go iawn” yn gweithio yn MarkLogic yn cael ei roi gan , yn yr ystyr hwn, mae'n lefel isel, er bod ei bwrpas braidd i'r gwrthwyneb - ceisio tynnu o'r model data a ddefnyddir, er mwyn sicrhau gwaith cyson gyda data mewn gwahanol fodelau, trafodion, ac ati.
DBMS aml-fodel “heb brif fodel”
Mae yna hefyd DBMSs ar y farchnad sy'n gosod eu hunain yn aml-fodel i ddechrau, heb unrhyw brif fodel a etifeddwyd. Mae'r rhain yn cynnwys , (ers 2018 mae'r cwmni datblygu yn perthyn i SAP) a (gwasanaeth fel rhan o blatfform cwmwl Microsoft Azure).
Mewn gwirionedd, mae modelau “craidd” yn ArangoDB ac OrientDB. Yn y ddau achos, eu modelau data eu hunain yw'r rhain, sef cyffredinoliadau o ddogfen un. Mae'r cyffredinoliadau yn bennaf i hwyluso'r gallu i berfformio ymholiadau o natur graff a pherthynasol.
Y modelau hyn yw'r unig rai sydd ar gael i'w defnyddio yn y DBMS penodedig; mae eu hieithoedd ymholiad eu hunain wedi'u cynllunio i weithio gyda nhw. Wrth gwrs, mae modelau o’r fath a DBMSs yn addawol, ond mae’r diffyg cydnawsedd â modelau ac ieithoedd safonol yn ei gwneud hi’n amhosibl defnyddio’r DBMSs hyn mewn systemau etifeddol—i ddisodli’r DBMSs a ddefnyddiwyd eisoes yno.
Roedd erthygl wych eisoes am ArangoDB ac OrientDB ar Habré: .
ArangoDB
Mae ArangoDB yn hawlio cefnogaeth ar gyfer model data graff.
Mae nodau graff yn ArangoDB yn ddogfennau cyffredin, ac mae'r ymylon yn ddogfennau o fath arbennig sydd, ynghyd â meysydd system arferol, â (_key, _id, _rev) meysydd system _from и _to. Mae dogfennau mewn dogfennau DBMS yn cael eu cyfuno'n draddodiadol i gasgliadau. Gelwir casgliadau o ddogfennau sy'n cynrychioli ymylon yn gasgliadau ymylol yn ArangoDB. Gyda llaw, mae dogfennau casglu ymyl hefyd yn ddogfennau, felly gall ymylon yn ArangoDB hefyd weithredu fel nodau.
Data crai
Gadewch inni gael casgliad persons, y mae eu dogfennau yn edrych fel hyn:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Bydded hefyd gasgliad cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Yna y casgliad likes gallai edrych fel hyn:
[
{
"_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
}
]Ymholiadau a chanlyniadau
Mae ymholiad arddull graff yn yr iaith AQL a ddefnyddir yn ArangoDB, sy'n dychwelyd ar ffurf y gellir ei darllen gan bobl wybodaeth am bwy sy'n hoffi pa gaffi, yn edrych fel hyn:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }Mewn arddull perthynol, lle rydym yn “cyfrifiaduro” perthnasoedd yn hytrach na'u storio, gellir ailysgrifennu'r ymholiad hwn fel hyn (gyda llaw, heb y casgliad likes gallai wneud heb):
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 }Bydd y canlyniad yn y ddau achos yr un peth:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Mwy o ymholiadau a chanlyniadau
Os yw'n ymddangos bod fformat y canlyniad uchod yn fwy nodweddiadol ar gyfer DBMS perthynol nag ar gyfer dogfen DBMS, gallwch roi cynnig ar yr ymholiad hwn (neu gallwch ddefnyddio ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Bydd y canlyniad yn edrych fel hyn:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
Y sail ar gyfer gweithredu model graff ar ben model dogfen yn OrientDB yw meysydd dogfen, yn ychwanegol at fwy neu lai o werthoedd sgalar safonol, hefyd yn meddu ar werthoedd o fathau megis LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Mae gwerthoedd y mathau hyn yn ddolenni neu gasgliadau o ddolenni i dogfennau.
Mae gan y dynodwr dogfen a neilltuwyd gan y system “ystyr corfforol”, sy'n nodi lleoliad y cofnod yn y gronfa ddata, ac mae'n edrych fel hyn: @rid : #3:16. Felly, mae gwerthoedd priodweddau cyfeirio yn awgrymiadau mewn gwirionedd (fel yn y model graff) yn hytrach nag amodau dethol (fel yn y model perthynol).
Fel ArangoDB, cynrychiolir ymylon yn OrientDB fel dogfennau ar wahân (er os nad oes gan ymyl ei briodweddau ei hun, gellir ei wneud , ac ni fydd yn cyfateb i ddogfen ar wahân).
Data crai
Mewn fformat yn agos i Cronfa ddata OrientDB, byddai'r data o'r enghraifft flaenorol ar gyfer ArangoDB yn edrych fel hyn:
[
{
"@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"
}
]Fel y gallwn weld, mae fertigau hefyd yn storio gwybodaeth am ymylon sy'n dod i mewn ac allan. Yn Mae'n rhaid i API y Ddogfen fonitro cywirdeb cyfeiriol ei hun, ac mae'r API Graff yn ymgymryd â'r gwaith hwn. Ond gadewch i ni weld sut olwg sydd ar fynediad i OrientDB mewn ieithoedd ymholiad “pur” nad ydyn nhw wedi'u hintegreiddio i ieithoedd rhaglennu.
Ymholiadau a chanlyniadau
Mae ymholiad tebyg o ran pwrpas i'r ymholiad o'r enghraifft ar gyfer ArangoDB yn OrientDB yn edrych fel hyn:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameBydd y canlyniad i'w gael yn y ffurf ganlynol:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Os yw fformat y canlyniad eto'n ymddangos yn rhy "berthynol", mae angen i chi ddileu'r llinell gyda :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]Gellir disgrifio iaith ymholiad OrientDB fel SQL gyda mewnosodiadau tebyg i Gremlin. Yn fersiwn 2.2, ymddangosodd ffurflen gais tebyg i 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_nameBydd fformat y canlyniad yr un fath ag yn y cais blaenorol. Meddyliwch am yr hyn sydd angen ei ddileu i'w wneud yn fwy “perthynol”, fel yn yr ymholiad cyntaf un.
CosmosDB Azure
I raddau llai, mae'r hyn a ddywedwyd uchod am ArangoDB ac OrientDB yn berthnasol i Azure CosmosDB. Mae CosmosDB yn darparu'r APIs mynediad data canlynol: SQL, MongoDB, Gremlin a Cassandra.
Defnyddir SQL API ac API MongoDB i gyrchu data yn y model dogfen. API Gremlin ac API Cassandra - ar gyfer cyrchu data mewn fformatau graff a cholofn, yn y drefn honno. Mae data ym mhob model yn cael ei gadw yn fformat model mewnol CosmosDB: (“atom-record-sequence”), sydd hefyd yn agos at y ddogfen un.
Ond mae'r model data a ddewiswyd gan y defnyddiwr a'r API a ddefnyddir yn sefydlog ar adeg creu cyfrif yn y gwasanaeth. Nid yw'n bosibl cyrchu data sydd wedi'i lwytho mewn un model mewn fformat model arall, fel y dangosir gan rywbeth fel hyn:
Felly, aml-fodel yn Azure CosmosDB heddiw dim ond y gallu i ddefnyddio nifer o gronfeydd data cefnogi modelau gwahanol o un gwneuthurwr, nad yw'n datrys yr holl broblemau o storio aml-amrywiad.
DBMS aml-fodel yn seiliedig ar fodel graff?
Yn nodedig yw'r ffaith nad oes DBMSs aml-fodel ar y farchnad eto sy'n seiliedig ar fodel graff (ac eithrio cefnogaeth aml-fodel ar gyfer dau fodel graff ar yr un pryd: RDF ac LPG; gweler hyn yn ). Achosir yr anawsterau mwyaf gan weithrediad model dogfen ar ben model graff, yn hytrach nag un perthynol.
Ystyriwyd y cwestiwn o sut i weithredu model perthynol ar ben y model graff hyd yn oed wrth ffurfio'r olaf. Sut er enghraifft :
Nid oes unrhyw beth cynhenid yn y dull graff sy'n atal creu haen (ee, trwy fynegeio addas) ar gronfa ddata graff sy'n galluogi golwg berthynol gyda (1) adennill tuples o'r parau gwerth allweddol arferol a (2) grwpio o tuples yn ôl math o berthynas.
Wrth weithredu model dogfen ar ben model graff, mae angen i chi gadw mewn cof, er enghraifft, y canlynol:
- Ystyrir bod elfennau o arae JSON yn drefnus, ond nid yw'r rhai sy'n deillio o fertig ymyl y graff;
- Mae data yn y model dogfen fel arfer yn cael ei ddadnormaleiddio; nid ydych chi eisiau storio sawl copi o'r un ddogfen wreiddiedig o hyd, ac fel arfer nid oes gan is-ddogfennau ddynodwyr;
- Ar y llaw arall, ideoleg dogfennau DBMS yw bod dogfennau yn “agregau” parod nad oes angen eu hadeiladu o'r newydd bob tro. Mae'n ofynnol darparu'r model graff gyda'r gallu i gael subgraff sy'n cyfateb i'r ddogfen orffenedig yn gyflym.
Ychydig o hysbysebu
Mae awdur yr erthygl yn gysylltiedig â datblygiad y NitrosBase DBMS, y mae ei fodel mewnol yn graff, a'r modelau allanol - perthynol a dogfen - yw ei gynrychioliadau. Mae pob model yn gyfartal: mae bron unrhyw ddata ar gael mewn unrhyw un ohonynt gan ddefnyddio iaith ymholiad sy'n naturiol iddo. Ar ben hynny, mewn unrhyw olwg, gellir newid y data. Adlewyrchir newidiadau yn y model mewnol ac, yn unol â hynny, mewn safbwyntiau eraill.
Gobeithio y byddaf yn disgrifio sut olwg sydd ar gyfateb model yn NitrosBase yn un o'r erthyglau canlynol.
Casgliad
Rwy’n gobeithio bod amlinelliadau cyffredinol yr hyn a elwir yn aml-fodelu wedi dod yn fwy neu lai yn glir i’r darllenydd. Mae DBMSs aml-fodel yn dra gwahanol, a gall “cymorth aml-fodel” edrych yn wahanol. Er mwyn deall yr hyn a elwir yn "aml-fodel" ym mhob achos penodol, mae'n ddefnyddiol ateb y cwestiynau canlynol:
- A ydym yn sôn am gefnogi modelau traddodiadol neu ryw fath o fodel “hybrid”?
- A yw'r modelau'n “gyfartal”, neu a yw un ohonynt yn destun y lleill?
- Ydy’r modelau’n “ddifater” i’w gilydd? A ellir darllen data a ysgrifennwyd mewn un model mewn model arall neu hyd yn oed trosysgrifo?
Credaf y gellir ateb y cwestiwn ynghylch perthnasedd DBMS aml-fodel yn gadarnhaol eisoes, ond y cwestiwn diddorol yw pa fathau ohonynt y bydd mwy o alw amdanynt yn y dyfodol agos. Mae'n ymddangos y bydd mwy o alw am DBMSs aml-fodel sy'n cefnogi modelau traddodiadol, perthynol yn bennaf; Mae poblogrwydd DBMSs aml-fodel, sy'n cynnig modelau newydd sy'n cyfuno manteision amrywiol rai traddodiadol, yn fater o'r dyfodol pell.
Dim ond defnyddwyr cofrestredig all gymryd rhan yn yr arolwg. os gwelwch yn dda.
Ydych chi'n defnyddio DBMS aml-fodel?
-
Nid ydym yn ei ddefnyddio, rydym yn storio popeth mewn un DBMS ac mewn un model
-
Rydym yn defnyddio galluoedd aml-fodel o DBMSs traddodiadol
-
Rydym yn ymarfer dyfalbarhad polyglot
-
Rydym yn defnyddio DBMS aml-fodel newydd (Arango, Orient, CosmosDB)
Pleidleisiodd 19 o ddefnyddwyr. Ymataliodd 4 o ddefnyddwyr.
Ffynhonnell: hab.com