Ang mga modernong sistema ng impormasyon ay medyo kumplikado. Hindi bababa sa lahat, ang kanilang pagiging kumplikado ay dahil sa pagiging kumplikado ng data na naproseso sa kanila. Ang pagiging kumplikado ng data ay madalas na nakasalalay sa iba't ibang mga modelo ng data na ginamit. Kaya, halimbawa, kapag ang data ay naging "malaki", ang isa sa mga problemang katangian ay hindi lamang ang dami nito ("volume"), kundi pati na rin ang pagkakaiba-iba nito ("iba't-ibang").
Kung hindi ka pa nakakahanap ng isang depekto sa pangangatwiran, pagkatapos ay basahin.
nilalaman
Polyglot na pagtitiyaga
Ang nasa itaas ay humahantong sa katotohanan na kung minsan kahit na sa loob ng balangkas ng isang sistema ay kinakailangan na gumamit ng maraming iba't ibang mga DBMS upang mag-imbak ng data at malutas ang iba't ibang mga problema sa pagproseso ng mga ito, na ang bawat isa ay sumusuporta sa sarili nitong modelo ng data. Gamit ang magaan na kamay ni M. Fowler, isang bilang ng mga sikat na libro at isa sa Agile Manifesto, ang sitwasyong ito ay tinatawag multi-variant na imbakan (“pagtitiyaga ng polyglot”).
Ang Fowler ay mayroon ding sumusunod na halimbawa ng pag-aayos ng pag-iimbak ng data sa isang ganap na tampok at mataas na load na application sa larangan ng e-commerce.
Ang halimbawang ito, siyempre, ay medyo pinalaki, ngunit ang ilang mga pagsasaalang-alang na pabor sa pagpili ng isa o isa pang DBMS para sa kaukulang layunin ay matatagpuan, halimbawa, .
Malinaw na hindi madali ang pagiging utusan sa naturang zoo.
- Ang dami ng code na nagsasagawa ng pag-iimbak ng data ay lumalaki sa proporsyon sa bilang ng mga DBMS na ginamit; ang dami ng data sa pag-synchronize ng code ay mabuti kung hindi proporsyonal sa parisukat ng numerong ito.
- Bilang maramihang bilang ng mga DBMS na ginamit, ang mga gastos sa pagbibigay ng mga katangian ng enterprise (scalability, fault tolerance, mataas na availability) ng bawat isa sa mga DBMS ay tumaas.
- Imposibleng tiyakin ang mga katangian ng enterprise ng subsystem ng imbakan sa kabuuan - lalo na ang transactionality.
Mula sa pananaw ng direktor ng zoo, ang lahat ay ganito:
- Maraming pagtaas sa halaga ng mga lisensya at teknikal na suporta mula sa tagagawa ng DBMS.
- Overstaffing at tumaas na mga deadline.
- Direktang pagkalugi sa pananalapi o mga parusa dahil sa hindi pagkakapare-pareho ng data.
Mayroong malaking pagtaas sa kabuuang halaga ng pagmamay-ari (TCO) ng system. Mayroon bang anumang paraan sa labas ng sitwasyon ng "maramihang mga pagpipilian sa imbakan"?
Multi-modelo
Ang terminong "multivariate storage" ay ginamit noong 2011. Ang kamalayan sa mga problema ng diskarte at ang paghahanap para sa isang solusyon ay tumagal ng ilang taon, at noong 2015, sa pamamagitan ng bibig ng mga analyst ng Gartner, ang sagot ay nabuo:
- mula sa "»:
Ang hinaharap ng mga DBMS, ang kanilang mga arkitektura at mga paraan ng paggamit ng mga ito ay multi-modelo.
- mula sa "»:
Ang mga nangungunang operational na DBMS ay mag-aalok ng maraming modelo—relational at non-relational—bilang bahagi ng iisang platform.
Mukhang sa pagkakataong ito ang mga analyst ng Gartner ay tama sa kanilang hula. Kung pupunta ka sa page na may DBMS sa DB-Engines, makikita mo iyonоKaramihan sa mga pinuno nito ay partikular na nagpoposisyon sa kanilang sarili bilang mga multi-modelo na DBMS. Ang parehong ay makikita sa pahina na may anumang pribadong rating.
Ipinapakita ng talahanayan sa ibaba ang DBMS - ang mga nangunguna sa bawat pribadong rating, na sinasabing multi-model. Para sa bawat DBMS, ipinapahiwatig ang orihinal na sinusuportahang modelo (na dati ay isa lamang) at kasama nito ang mga modelong kasalukuyang sinusuportahan. Nakalista din ang mga DBMS na nagpoposisyon sa kanilang mga sarili bilang "orihinal na multi-modelo" at, ayon sa mga tagalikha, ay walang anumang paunang minanang modelo.
| DBMS | Paunang modelo | Mga karagdagang modelo |
|---|---|---|
| Orakulo | Relational | Graph, dokumento |
| MS SQL | Relational | Graph, dokumento |
| PostgreSQL | Relational | Graph*, dokumento |
| MarkLogic | Dokumentaryo | Graph, relational |
| MongoDB | Dokumentaryo | Key-value, graph* |
| DataStax | Malapad na hanay | Dokumentaryo, graph |
| Redis | Key-value | Dokumentaryo, graph* |
| ArangoDB | - | Graph, dokumento |
| OrientDB | - | Graph, dokumento, relational |
| Azure CosmosDB | - | Graph, dokumento, relational |
Mga tala sa mesa
Ang mga asterisk sa talahanayan ay nagmamarka ng mga pahayag na nangangailangan ng mga reserbasyon:
- Hindi sinusuportahan ng PostgreSQL DBMS ang modelo ng data ng graph, ngunit sinusuportahan ito ng produktong ito , gaya ng AgensGraph.
- Kaugnay ng MongoDB, mas tamang pag-usapan ang pagkakaroon ng mga graph operator sa query language (, ) kaysa sa tungkol sa pagsuporta sa modelo ng graph, bagaman, siyempre, ang kanilang pagpapakilala ay nangangailangan ng ilang mga pag-optimize sa antas ng pisikal na imbakan sa direksyon ng pagsuporta sa modelo ng graph.
- Kaugnay ng Redis, ang ibig naming sabihin ay ang extension .
Susunod, para sa bawat isa sa mga klase, ipapakita namin kung paano ipinatupad ang suporta para sa ilang mga modelo sa DBMS mula sa klase na ito. Isasaalang-alang namin ang mga modelong relational, dokumento at graph bilang pinakamahalaga at gagamit ng mga halimbawa ng mga partikular na DBMS upang ipakita kung paano ipinapatupad ang mga "nawawala".
Multi-modelo na DBMS batay sa relational na modelo
Ang mga nangungunang DBMS ay kasalukuyang may kaugnayan; ang hula ni Gartner ay hindi maituturing na totoo kung ang mga RDBMS ay hindi nagpakita ng paggalaw sa direksyon ng multi-modeling. At nagpapakita sila. Ngayon ang ideya na ang isang multi-modelo na DBMS ay tulad ng isang Swiss na kutsilyo, na hindi magagawang mabuti, ay maaaring direktang idirekta kay Larry Ellison.
Gayunpaman, mas pinipili ng may-akda ang pagpapatupad ng multi-modeling sa Microsoft SQL Server, sa halimbawa kung saan ilalarawan ang suporta ng RDBMS para sa mga modelo ng dokumento at graph.
Modelo ng dokumento sa MS SQL Server
Mayroon nang dalawang mahusay na artikulo sa Habré tungkol sa kung paano nagpapatupad ang MS SQL Server ng suporta para sa modelo ng dokumento; lilimitahan ko ang aking sarili sa isang maikling muling pagsasalaysay at komentaryo:
Ang paraan upang suportahan ang modelo ng dokumento sa MS SQL Server ay medyo tipikal para sa mga relational na DBMS: Ang mga dokumento ng JSON ay iminungkahi na itago sa mga ordinaryong text field. Ang suporta para sa modelo ng dokumento ay ang pagbibigay ng mga espesyal na operator para i-parse ang JSON na ito:
- upang kunin ang mga halaga ng katangian ng scalar,
- upang kunin ang mga sub-dokumento.
Ang pangalawang argumento ng parehong mga operator ay isang expression sa JSONPath-like syntax.
Sa madaling sabi, maaari nating sabihin na ang mga dokumentong nakaimbak sa ganitong paraan ay hindi "mga first-class na entity" sa isang relational na DBMS, hindi katulad ng mga tuple. Sa partikular, sa MS SQL Server ay kasalukuyang walang mga index sa mga patlang ng mga dokumento ng JSON, na nagpapahirap sa pagsali sa mga talahanayan gamit ang mga halaga ng mga patlang na ito at kahit na pumili ng mga dokumento gamit ang mga halagang ito. Gayunpaman, posible na lumikha ng isang kinakalkula na hanay para sa naturang field at isang index dito.
Bilang karagdagan, ang MS SQL Server ay nagbibigay ng kakayahang maginhawang bumuo ng isang JSON na dokumento mula sa mga nilalaman ng mga talahanayan gamit ang operator. - isang posibilidad, sa isang tiyak na kahulugan, kabaligtaran sa nauna, maginoo na imbakan. Malinaw na gaano man kabilis ang isang RDBMS, ang diskarte na ito ay sumasalungat sa ideolohiya ng mga DBMS ng dokumento, na mahalagang nag-iimbak ng mga handa na sagot sa mga sikat na query, at malulutas lamang ang mga problema ng kadalian ng pag-unlad, ngunit hindi ang bilis.
Sa wakas, pinapayagan ka ng MS SQL Server na lutasin ang kabaligtaran na problema ng pagtatayo ng dokumento: maaari mong mabulok ang JSON sa mga talahanayan gamit ang . Kung ang dokumento ay hindi ganap na flat, kakailanganin mong gamitin CROSS APPLY.
Modelo ng graph sa MS SQL Server
Ang suporta para sa graph (LPG) na modelo ay ganap ding ipinatupad sa Microsoft SQL Server : Iminumungkahi na gumamit ng mga espesyal na talahanayan upang mag-imbak ng mga node at mag-imbak ng mga gilid ng graph. Ang ganitong mga talahanayan ay nilikha gamit ang mga expression CREATE TABLE AS NODE и CREATE TABLE AS EDGE ayon sa pagkakabanggit.
Ang mga talahanayan ng unang uri ay katulad ng mga ordinaryong talahanayan para sa pag-iimbak ng mga tala, na ang tanging panlabas na pagkakaiba ay ang talahanayan ay naglalaman ng isang field ng system $node_id — natatanging identifier ng isang graph node sa loob ng database.
Katulad nito, ang mga talahanayan ng pangalawang uri ay may mga patlang ng system $from_id и $to_id, ang mga entry sa naturang mga talahanayan ay malinaw na tumutukoy sa mga koneksyon sa pagitan ng mga node. Ang isang hiwalay na talahanayan ay ginagamit upang mag-imbak ng mga relasyon ng bawat uri.
Ilarawan natin ito sa isang halimbawa. Hayaang may layout ang data ng graph tulad ng ipinapakita sa figure. Pagkatapos upang lumikha ng kaukulang istraktura sa database kailangan mong patakbuhin ang sumusunod na mga query sa DDL:
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);Ang pangunahing pagtitiyak ng naturang mga talahanayan ay na sa mga query laban sa kanila ay posible na gumamit ng mga pattern ng graph na may syntax na tulad ng Cypher (gayunpaman, "*"atbp. ay hindi pa sinusuportahan). Batay sa mga sukat ng pagganap, maaari ding ipagpalagay na ang paraan ng pag-imbak ng data sa mga talahanayang ito ay iba sa paraan ng pag-imbak ng data sa mga regular na talahanayan at na-optimize para sa pagsasagawa ng mga naturang graph na query.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Bukod dito, medyo mahirap na huwag gamitin ang mga pattern ng graph na ito kapag nagtatrabaho sa mga naturang talahanayan, dahil sa mga ordinaryong query sa SQL upang malutas ang mga katulad na problema ay kinakailangan na gumawa ng karagdagang mga pagsisikap upang makakuha ng mga "graph" node identifier ng system ($node_id, $from_id, $to_id; Para sa parehong dahilan, ang mga query para sa pagpasok ng data ay hindi ipinapakita dito dahil ang mga ito ay hindi kinakailangang masalimuot).
Upang ibuod ang paglalarawan ng mga pagpapatupad ng mga modelo ng dokumento at graph sa MS SQL Server, mapapansin ko na ang mga naturang pagpapatupad ng isang modelo sa ibabaw ng isa pa ay mukhang hindi matagumpay, pangunahin mula sa punto ng view ng disenyo ng wika. Kinakailangan na palawakin ang isang wika sa isa pa, ang mga wika ay hindi ganap na "orthogonal", ang mga patakaran sa pagiging tugma ay maaaring maging kakaiba.
Multi-modelo na DBMS batay sa modelo ng dokumento
Sa seksyong ito, nais kong ilarawan ang pagpapatupad ng multi-model sa mga DBMS ng dokumento gamit ang halimbawa ng hindi pinakasikat sa kanila, ang MongoDB (tulad ng sinabi, mayroon lamang itong mga operator ng conditional graph $lookup и $graphLookup, hindi gumagana sa mga sharded na koleksyon), ngunit gamit ang halimbawa ng isang mas mature at "enterprise" na DBMS .
Kaya, hayaan ang koleksyon na maglaman ng isang hanay ng mga XML na dokumento ng sumusunod na uri (Pinapayagan ka rin ng MarkLogic na mag-imbak ng mga dokumento ng JSON):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Relational na modelo sa MarkLogic
Ang isang relational view ng isang koleksyon ng mga dokumento ay maaaring malikha gamit ang (nilalaman ng mga elemento value sa halimbawa sa ibaba ay maaaring mayroong isang di-makatwirang 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>Maaari mong tugunan ang ginawang view gamit ang isang SQL query (halimbawa, sa pamamagitan ng ODBC):
SELECT name, surname FROM Person WHERE name="John"Sa kasamaang palad, ang relational view na nilikha ng template ng display ay read-only. Kapag nagpoproseso ng kahilingan para dito, susubukan ng MarkLogic na gamitin . Noong nakaraan, ang MarkLogic ay may limitadong mga pananaw sa relasyon, sa kabuuan at maisusulat, ngunit ngayon ay itinuturing na silang hindi na ginagamit.
Modelo ng graph sa MarkLogic
Sa suporta para sa graph (RDF) na modelo, ang lahat ay halos pareho. Muli sa tulong maaari kang lumikha ng isang representasyon ng RDF ng isang koleksyon ng mga dokumento mula sa halimbawa sa itaas:
<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>Maaari mong tugunan ang resultang RDF graph gamit ang isang query sa SPARQL:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Hindi tulad ng relational, sinusuportahan ng MarkLogic ang modelo ng graph sa dalawang iba pang paraan:
- Ang isang DBMS ay maaaring isang ganap na hiwalay na imbakan ng RDF data (tatawagin ang mga triplet sa loob nito salungat sa mga inilarawan sa itaas ).
- Ang RDF sa espesyal na serialization ay maaari lamang ipasok sa XML o JSON na mga dokumento (at ang mga triplet ay tatawagin ). Marahil ito ay isang alternatibo sa mga mekanismo
idrefat iba pa
Ang isang magandang ideya kung paano gumagana ang mga bagay na "talaga" sa MarkLogic ay ibinigay ni , sa ganitong kahulugan, ito ay mababa ang antas, bagaman ang layunin nito ay sa halip ay ang kabaligtaran - upang subukang i-abstract mula sa modelo ng data na ginamit, upang matiyak na pare-pareho ang trabaho sa data sa iba't ibang mga modelo, transactionality, atbp.
Multi-model na DBMS "walang pangunahing modelo"
Mayroon ding mga DBMS sa merkado na nagpoposisyon sa kanilang mga sarili bilang unang multi-modelo, nang walang anumang minanang pangunahing modelo. Kabilang dito ang , (mula noong 2018 ang development company ay kabilang sa SAP) at (serbisyo bilang bahagi ng Microsoft Azure cloud platform).
Sa katunayan, may mga "core" na modelo sa ArangoDB at OrientDB. Sa parehong mga kaso, ito ang kanilang sariling mga modelo ng data, na mga generalization ng dokumentong isa. Ang mga generalization ay pangunahin upang mapadali ang kakayahang magsagawa ng mga query ng isang graph at relational na kalikasan.
Ang mga modelong ito ay ang tanging magagamit para sa paggamit sa tinukoy na DBMS; ang kanilang sariling mga query na wika ay idinisenyo upang gumana sa kanila. Siyempre, ang mga naturang modelo at DBMS ay nangangako, ngunit ang kakulangan ng pagiging tugma sa mga karaniwang modelo at wika ay ginagawang imposibleng gamitin ang mga DBMS na ito sa mga legacy system—upang palitan ang mga DBMS na ginamit na doon.
Mayroon nang magandang artikulo tungkol sa ArangoDB at OrientDB sa Habré: .
ArangoDB
Inaangkin ng ArangoDB ang suporta para sa isang modelo ng data ng graph.
Ang mga node ng isang graph sa ArangoDB ay mga ordinaryong dokumento, at ang mga gilid ay mga dokumento ng isang espesyal na uri na, kasama ng mga regular na field ng system, ay mayroong (_key, _id, _rev) mga patlang ng system _from и _to. Ang mga dokumento sa mga DBMS ng dokumento ay tradisyonal na pinagsama sa mga koleksyon. Ang mga koleksyon ng mga dokumento na kumakatawan sa mga gilid ay tinatawag na mga koleksyon ng gilid sa ArangoDB. Sa pamamagitan ng paraan, ang mga dokumento sa pagkolekta ng gilid ay mga dokumento din, kaya ang mga gilid sa ArangoDB ay maaari ding kumilos bilang mga node.
Raw data
Magkaroon tayo ng koleksyon persons, na ang mga dokumento ay ganito ang hitsura:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Magkaroon din ng koleksyon cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Tapos yung collection likes maaaring ganito ang hitsura:
[
{
"_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
}
]Mga tanong at resulta
Isang graph-style na query sa wikang AQL na ginagamit sa ArangoDB, na nagbabalik sa impormasyon ng form na nababasa ng tao tungkol sa kung sino ang may gusto kung aling cafe, ganito ang hitsura:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }Sa istilong pamanggit, kung saan kami ay "nagko-compute" ng mga relasyon sa halip na iimbak ang mga ito, ang query na ito ay maaaring muling isulat nang ganito (nga pala, nang walang koleksyon likes magagawa nang wala):
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 }Magiging pareho ang resulta sa parehong mga kaso:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Higit pang mga query at resulta
Kung ang format ng resulta sa itaas ay tila mas karaniwan para sa isang relational na DBMS kaysa sa isang dokumentong DBMS, maaari mong subukan ang query na ito (o maaari mong gamitin ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Magiging ganito ang resulta:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
Ang batayan para sa pagpapatupad ng isang modelo ng graph sa tuktok ng isang modelo ng dokumento sa OrientDB ay ang mga patlang ng dokumento, bilang karagdagan sa higit pa o mas kaunting mga karaniwang halaga ng scalar, ay mayroon ding mga halaga ng mga uri tulad ng LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Ang mga halaga ng mga ganitong uri ay mga link o mga koleksyon ng mga link sa mga dokumento.
Ang pagkakakilanlan ng dokumento na itinalaga ng system ay may "pisikal na kahulugan", na nagpapahiwatig ng posisyon ng rekord sa database, at mukhang ganito: @rid : #3:16. Kaya, ang mga halaga ng mga katangian ng sanggunian ay talagang mga pointer (tulad ng sa modelo ng graph), sa halip na mga kondisyon ng pagpili (tulad ng sa relational na modelo).
Tulad ng ArangoDB, ang mga gilid sa OrientDB ay kinakatawan bilang hiwalay na mga dokumento (bagaman kung ang isang gilid ay walang sariling mga katangian, maaari itong gawin , at hindi ito tumutugma sa isang hiwalay na dokumento).
Raw data
Sa isang format na malapit sa OrientDB database, ang data mula sa nakaraang halimbawa para sa ArangoDB ay magiging ganito:
[
{
"@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"
}
]Gaya ng nakikita natin, ang mga vertex ay nag-iimbak din ng impormasyon tungkol sa mga papasok at papalabas na mga gilid. Sa Kailangang subaybayan ng Document API ang mismong integridad ng referential, at ang Graph API ay nagsasagawa ng gawaing ito. Ngunit tingnan natin kung ano ang hitsura ng pag-access sa OrientDB sa mga "purong" query na wika na hindi isinama sa mga programming language.
Mga tanong at resulta
Ang isang query na katulad ng layunin sa query mula sa halimbawa para sa ArangoDB sa OrientDB ay ganito ang hitsura:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameAng resulta ay makukuha sa sumusunod na form:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Kung ang format ng resulta ay tila masyadong "relational", kailangan mong alisin ang linya na may :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]Ang wika ng query ng OrientDB ay maaaring ilarawan bilang SQL na may mga pagsingit na parang Gremlin. Sa bersyon 2.2, lumitaw ang isang katulad na Cypher na form ng kahilingan, :
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_nameAng format ng resulta ay magiging kapareho ng sa nakaraang kahilingan. Isipin kung ano ang kailangang alisin para maging mas "relational" ito, tulad ng sa pinakaunang query.
Azure CosmosDB
Sa mas maliit na lawak, ang sinabi sa itaas tungkol sa ArangoDB at OrientDB ay nalalapat sa Azure CosmosDB. Ang CosmosDB ay nagbibigay ng mga sumusunod na data access API: SQL, MongoDB, Gremlin at Cassandra.
Ginagamit ang SQL API at MongoDB API upang ma-access ang data sa modelo ng dokumento. Gremlin API at Cassandra API - para sa pag-access ng data sa mga format ng graph at column, ayon sa pagkakabanggit. Ang data sa lahat ng mga modelo ay naka-save sa format ng panloob na modelo ng CosmosDB: (“atom-record-sequence”), na malapit din sa document one.
Ngunit ang modelo ng data na pinili ng user at ang API na ginamit ay naayos sa oras ng paggawa ng account sa serbisyo. Hindi posibleng ma-access ang data na na-load sa isang modelo sa format ng isa pang modelo, gaya ng inilalarawan ng isang bagay na tulad nito:
Kaya, ang multi-model sa Azure CosmosDB ngayon ay ang kakayahang gumamit ng ilang database na sumusuporta sa iba't ibang modelo mula sa isang tagagawa, na hindi nilulutas ang lahat ng problema ng multi-variant na storage.
Multi-modelong DBMS batay sa isang modelo ng graph?
Kapansin-pansin ang katotohanan na wala pang mga multi-model na DBMS sa merkado na nakabatay sa isang modelo ng graph (maliban sa multi-model na suporta para sa dalawang modelo ng graph nang sabay-sabay: RDF at LPG; tingnan ito sa ). Ang pinakamalaking paghihirap ay sanhi ng pagpapatupad ng isang modelo ng dokumento sa tuktok ng isang modelo ng graph, sa halip na isang relational.
Ang tanong kung paano ipatupad ang isang relational na modelo sa tuktok ng modelo ng graph ay isinasaalang-alang kahit na sa panahon ng pagbuo ng huli. Paano halimbawa :
Walang likas sa graph approach na pumipigil sa paglikha ng isang layer (hal., sa pamamagitan ng angkop na pag-index) sa isang graph database na nagbibigay-daan sa isang relational view na may (1) pagbawi ng mga tuple mula sa karaniwang mga key value pairs at (2) pagpapangkat ng tuple ayon sa uri ng kaugnayan.
Kapag nagpapatupad ng modelo ng dokumento sa ibabaw ng modelo ng graph, kailangan mong tandaan, halimbawa, ang sumusunod:
- Ang mga elemento ng isang JSON array ay itinuturing na nakaayos, ngunit ang mga nagmumula sa vertex ng isang gilid ng graph ay hindi;
- Karaniwang na-denormalize ang data sa modelo ng dokumento; hindi mo pa rin gustong mag-imbak ng ilang kopya ng parehong naka-embed na dokumento, at karaniwang walang mga identifier ang mga subdocument;
- Sa kabilang banda, ang ideolohiya ng mga DBMS ng dokumento ay ang mga dokumento ay handa nang "mga pinagsama-samang" na hindi kailangang muling buuin sa bawat oras. Kinakailangang bigyan ang modelo ng graph ng kakayahang mabilis na makakuha ng subgraph na naaayon sa natapos na dokumento.
Isang maliit na advertising
Ang may-akda ng artikulo ay nauugnay sa pagbuo ng NitrosBase DBMS, ang panloob na modelo kung saan ay graph, at ang mga panlabas na modelo - relational at dokumento - ang mga representasyon nito. Ang lahat ng mga modelo ay pantay-pantay: halos anumang data ay magagamit sa alinman sa mga ito gamit ang isang query na wika na natural dito. Bukod dito, sa anumang view, maaaring baguhin ang data. Ang mga pagbabago ay makikita sa panloob na modelo at, nang naaayon, sa iba pang mga pananaw.
Sana ay ilalarawan ko kung ano ang hitsura ng pagtutugma ng modelo sa NitrosBase sa isa sa mga sumusunod na artikulo.
Konklusyon
Umaasa ako na ang mga pangkalahatang balangkas ng tinatawag na multi-modeling ay naging mas malinaw sa mambabasa. Iba-iba ang mga multi-modelo na DBMS, at maaaring iba ang hitsura ng "suportang multi-modelo". Upang maunawaan kung ano ang tinatawag na "multi-modelo" sa bawat partikular na kaso, kapaki-pakinabang na sagutin ang mga sumusunod na tanong:
- Pinag-uusapan ba natin ang pagsuporta sa mga tradisyonal na modelo o ilang uri ng "hybrid" na modelo?
- Ang mga modelo ba ay "pantay", o isa ba sa kanila ang paksa ng iba?
- Ang mga modelo ba ay "walang malasakit" sa isa't isa? Maaari bang basahin ang data na nakasulat sa isang modelo sa isa pa o ma-overwrite pa?
Sa palagay ko ang tanong tungkol sa kaugnayan ng multi-model DBMS ay maaari nang masagot nang positibo, ngunit ang kawili-wiling tanong ay kung aling mga uri ng mga ito ang higit na hinihiling sa malapit na hinaharap. Tila ang mga multi-modelo na DBMS na sumusuporta sa mga tradisyonal na modelo, pangunahin ang relational, ay higit na hihilingin; Ang kasikatan ng mga multi-model na DBMS, na nag-aalok ng mga bagong modelo na pinagsasama ang mga pakinabang ng iba't ibang tradisyonal, ay isang bagay ng mas malayong hinaharap.
Ang mga rehistradong user lamang ang maaaring lumahok sa survey. , pakiusap
Gumagamit ka ba ng multi-model na DBMS?
-
Hindi namin ito ginagamit, iniimbak namin ang lahat sa isang DBMS at sa isang modelo
-
Gumagamit kami ng mga multi-model na kakayahan ng mga tradisyonal na DBMS
-
Nagsasagawa kami ng polyglot persistence
-
Gumagamit kami ng bagong multi-model na DBMS (Arango, Orient, CosmosDB)
19 mga gumagamit ang bumoto. 4 user ang umiwas.
Pinagmulan: www.habr.com