Ang modernong mga sistema sa impormasyon medyo komplikado. Dili labing gamay sa tanan, ang ilang pagkakomplikado tungod sa pagkakomplikado sa mga datos nga giproseso sa kanila. Ang pagkakomplikado sa datos sagad anaa sa lain-laing mga modelo sa datos nga gigamit. Busa, pananglitan, kung ang datos mahimong "dako", usa sa mga problema nga kinaiya dili lamang ang gidaghanon niini ("volume"), kondili usab ang lainlain niini ("variety").
Kung wala ka pa makit-an nga sayup sa pangatarungan, basaha.
Mga sulod
Polyglot nga pagpadayon
Ang naa sa ibabaw nagdala sa kamatuoran nga usahay bisan sa sulod sa balangkas sa usa ka sistema kinahanglan nga mogamit daghang lainlaing mga DBMS sa pagtipig sa datos ug pagsulbad sa lainlaing mga problema sa pagproseso niini, nga ang matag usa nagsuporta sa kaugalingon nga modelo sa datos. Uban sa gaan nga kamot ni M. Fowler, ubay-ubay nga sikat nga libro ug usa sa Agile Manifesto, kini nga sitwasyon gitawag multi-variant nga pagtipig (“pagpadayon sa polyglot”).
Adunay usab si Fowler sa mosunod nga pananglitan sa pag-organisar sa pagtipig sa datos sa usa ka bug-os nga bahin ug taas nga karga nga aplikasyon sa natad sa e-commerce.
Kini nga pananglitan, siyempre, medyo gipasobrahan, apan ang pipila ka mga konsiderasyon pabor sa pagpili sa usa o lain nga DBMS alang sa katugbang nga katuyoan makita, pananglitan, .
Klaro nga dili sayon ang pagka sulogoon sa maong zoo.
- Ang gidaghanon sa code nga nagpahigayon sa pagtipig sa datos motubo sa proporsiyon sa gidaghanon sa mga DBMS nga gigamit; maayo ang gidaghanon sa datos sa pag-synchronize sa code kung dili proporsyonal sa square niini nga numero.
- Isip usa ka multiple sa gidaghanon sa mga DBMS nga gigamit, ang mga gasto sa paghatag sa mga kinaiya sa negosyo (scalability, fault tolerance, taas nga pagkaanaa) sa matag usa sa mga DBMS nga gigamit motaas.
- Imposible nga masiguro ang mga kinaiya sa negosyo sa subsystem sa pagtipig sa kinatibuk-an - labi na ang transactionality.
Gikan sa punto sa panglantaw sa direktor sa zoo, ang tanan ingon niini:
- Daghang pagtaas sa gasto sa mga lisensya ug teknikal nga suporta gikan sa tiggama sa DBMS.
- Pag-overstaff ug dugang nga mga deadline.
- Direkta nga pagkawala sa pinansyal o mga silot tungod sa pagkadili makanunayon sa datos.
Adunay dakong pagtaas sa kinatibuk-ang gasto sa pagpanag-iya (TCO) sa sistema. Aduna bay bisan unsang paagi gikan sa sitwasyon sa "daghang mga kapilian sa pagtipig"?
Daghang modelo
Ang termino nga "multivariate storage" gigamit sa 2011. Ang pagkahibalo sa mga problema sa pamaagi ug ang pagpangita alang sa usa ka solusyon gikuha daghang tuig, ug sa 2015, pinaagi sa mga baba sa mga analista sa Gartner, ang tubag naporma:
- gikan sa"»:
Ang kaugmaon sa mga DBMS, ang ilang mga arkitektura ug mga paagi sa paggamit niini usa ka multi-modelo.
- gikan sa"»:
Ang nanguna nga operational DBMSs motanyag ug daghang mga modelo—relational ug non-relational—isip kabahin sa usa ka plataporma.
Ingon og kini nga panahon ang mga analista sa Gartner husto sa ilang panagna. Kung moadto ka sa panid nga adunay DBMS sa DB-Engines, makita nimo kanaоKadaghanan sa mga lider niini nagbutang sa ilang kaugalingon nga espesipiko isip mga multi-modelo nga DBMS. Ang parehas nga makita sa panid nga adunay bisan unsang pribado nga rating.
Ang lamesa sa ubos nagpakita sa DBMS - ang mga lider sa matag usa sa mga pribadong rating, nga nag-angkon nga multi-modelo. Alang sa matag DBMS, ang orihinal nga gisuportahan nga modelo (nga kaniadto usa ra) ug kauban niini ang mga modelo nga gisuportahan karon gipakita. Gilista usab ang mga DBMS nga nagbutang sa ilang kaugalingon isip "orihinal nga multi-modelo" ug, sumala sa mga tiglalang, walay bisan unsang inisyal nga napanunod nga modelo.
| DBMS | Inisyal nga modelo | Dugang nga mga modelo |
|---|---|---|
| pulong sa Dios | Relasyon | Graph, dokumento |
| MS SQL | Relasyon | Graph, dokumento |
| PostgreSQL | Relasyon | Graph*, dokumento |
| MarkLogic | Dokumentaryo | Graph, relatibo |
| MongoDB | Dokumentaryo | Key-value, graph* |
| Data Stax | Lapad nga kolum | Dokumentaryo, graph |
| Redis | Key-bili | Dokumentaryo, graph* |
| ArangoDB | - | Graph, dokumento |
| OrientDB | - | Graph, dokumento, relational |
| Azure CosmosDB | - | Graph, dokumento, relational |
Mga nota sa lamesa
Ang mga asterisk sa lamesa nagtimaan sa mga pahayag nga nanginahanglan mga reserbasyon:
- Ang PostgreSQL DBMS wala mosuporta sa graph data model, apan kini nga produkto nagsuporta niini , sama sa AgensGraph.
- Kalabot sa MongoDB, mas husto ang paghisgot bahin sa presensya sa mga graph operator sa pangutana nga lengguwahe (, ) kaysa bahin sa pagsuporta sa modelo sa graph, bisan pa, siyempre, ang ilang pagpaila nanginahanglan pipila nga mga pag-optimize sa lebel sa pisikal nga pagtipig sa direksyon sa pagsuporta sa modelo sa graph.
- May kalabotan sa Redis, gipasabut namon ang extension .
Sunod, alang sa matag usa sa mga klase, among ipakita kung giunsa ang suporta alang sa daghang mga modelo gipatuman sa DBMS gikan sa kini nga klase. Atong tagdon ang relational, dokumento ug graph nga mga modelo nga labing importante ug gamiton ang mga pananglitan sa piho nga mga DBMS aron ipakita kung giunsa ang "mga nawala" gipatuman.
Multi-modelo nga DBMS base sa relational nga modelo
Ang nanguna nga mga DBMS sa pagkakaron kay relational; Ang forecast ni Gartner dili maisip nga tinuod kung ang mga RDBMS wala magpakita sa paglihok sa direksyon sa multi-modeling. Ug gipakita nila. Karon ang ideya nga ang usa ka multi-modelo nga DBMS sama sa usa ka Swiss kutsilyo, nga dili makahimo sa bisan unsa nga maayo, mahimong direktang idirekta ngadto kang Larry Ellison.
Ang tagsulat, bisan pa, gipalabi ang pagpatuman sa multi-modeling sa Microsoft SQL Server, sa panig-ingnan diin ang suporta sa RDBMS alang sa mga modelo sa dokumento ug graph ihulagway.
Modelo sa dokumento sa MS SQL Server
Adunay na duha ka maayo kaayo nga mga artikulo sa Habré bahin sa kung giunsa pagpatuman sa MS SQL Server ang suporta alang sa modelo sa dokumento; Limitahan nako ang akong kaugalingon sa usa ka mubo nga pagsaysay pag-usab ug komentaryo:
Ang paagi sa pagsuporta sa modelo sa dokumento sa MS SQL Server kasagaran alang sa mga relational nga DBMS: Ang mga dokumento sa JSON gisugyot nga tipigan sa ordinaryong mga natad sa teksto. Ang suporta alang sa modelo sa dokumento mao ang paghatag ug espesyal nga mga operator aron ma-parse kini nga JSON:
- aron makuha ang scalar attribute values,
- aron makuha ang mga sub-dokumento.
Ang ikaduhang argumento sa duha ka operators usa ka ekspresyon sa JSONPath-like syntax.
Abstract, makaingon kita nga ang mga dokumento nga gitipigan niining paagiha dili "first-class entities" sa usa ka relational DBMS, dili sama sa tuples. Sa partikular, sa MS SQL Server sa pagkakaron walay mga indeks sa mga natad sa mga dokumento sa JSON, nga nagpalisud sa pag-apil sa mga lamesa gamit ang mga bili niini nga mga natad ug bisan sa pagpili sa mga dokumento gamit kini nga mga bili. Bisan pa, posible nga maghimo usa ka kalkulado nga kolum alang sa ingon nga uma ug usa ka indeks niini.
Dugang pa, ang MS SQL Server naghatag og katakus sa paghimo sa usa ka JSON nga dokumento gikan sa sulod sa mga lamesa gamit ang operator. - usa ka posibilidad, sa usa ka piho nga diwa, sukwahi sa nauna, naandan nga pagtipig. Klaro nga bisan unsa ka paspas ang usa ka RDBMS, kini nga pamaagi sukwahi sa ideolohiya sa mga dokumento nga DBMS, nga hinungdanon nga nagtipig sa andam nga mga tubag sa mga sikat nga pangutana, ug makasulbad lamang sa mga problema sa kadali sa pag-uswag, apan dili katulin.
Sa katapusan, gitugotan ka sa MS SQL Server nga masulbad ang kaatbang nga problema sa pagtukod sa dokumento: mahimo nimong madunot ang JSON sa mga lamesa gamit ang . Kung ang dokumento dili hingpit nga patag, kinahanglan nimo nga gamiton CROSS APPLY.
Modelo sa graph sa MS SQL Server
Ang suporta alang sa graph (LPG) nga modelo hingpit usab nga gipatuman sa Microsoft SQL Server : Gisugyot nga gamiton ang mga espesyal nga mga lamesa sa pagtipig sa mga node ug sa pagtipig sa mga kilid sa graph. Ang ingon nga mga lamesa gihimo gamit ang mga ekspresyon CREATE TABLE AS NODE и CREATE TABLE AS EDGE sumala niana.
Ang mga lamesa sa una nga tipo parehas sa ordinaryong mga lamesa alang sa pagtipig sa mga rekord, nga ang bugtong kalainan sa gawas mao nga ang lamesa adunay sulud nga sistema. $node_id - talagsaon nga identifier sa usa ka graph node sulod sa database.
Sa susama, ang mga lamesa sa ikaduha nga tipo adunay mga natad sa sistema $from_id и $to_id, ang mga entry sa ingon nga mga lamesa tin-aw nga naghubit sa mga koneksyon tali sa mga node. Ang usa ka bulag nga lamesa gigamit sa pagtipig sa mga relasyon sa matag tipo.
Atong iilustrar kini pinaagig usa ka pananglitan. Himoa nga ang data sa graph adunay usa ka layout sama sa gipakita sa numero. Unya aron makahimo sa katugbang nga istruktura sa database kinahanglan nimo nga ipadagan ang mosunod nga mga pangutana 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 panguna nga espesipiko sa ingon nga mga lamesa mao nga sa mga pangutana batok kanila posible nga mogamit mga pattern sa graph nga adunay syntax nga sama sa Cypher (bisan pa, "*"ug uban pa wala pa gisuportahan). Base sa mga pagsukod sa performance, mahimo usab nga isipon nga ang paagi sa pagtipig sa datos niini nga mga lamesa lahi sa paagi nga ang datos gitipigan sa regular nga mga lamesa ug gi-optimize alang sa pagpatuman sa maong mga pangutana sa graph.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Dugang pa, lisud nga dili gamiton kini nga mga pattern sa graph kung magtrabaho sa ingon nga mga lamesa, tungod kay sa ordinaryong mga pangutana sa SQL aron masulbad ang parehas nga mga problema kinahanglan nga maghimo dugang nga mga paningkamot aron makuha ang sistema nga "graph" node identifiers ($node_id, $from_id, $to_id; Sa parehas nga hinungdan, ang mga pangutana alang sa pagsulud sa datos wala gipakita dinhi tungod kay kini dili kinahanglan nga hasol).
Sa pag-summarize sa paghulagway sa mga implementasyon sa dokumento ug graph nga mga modelo sa MS SQL Server, akong timan-an nga ang maong mga pagpatuman sa usa ka modelo sa ibabaw sa lain daw dili malampuson, nag-una gikan sa punto sa panglantaw sa pinulongan design. Kinahanglan nga i-extend ang usa ka lengguwahe sa lain, ang mga lengguwahe dili hingpit nga "orthogonal", ang mga lagda sa pagpahiangay mahimong katingad-an.
Multi-modelo nga DBMS base sa modelo sa dokumento
Niini nga seksyon, gusto nakong iilustrar ang pagpatuman sa multi-modelo sa mga dokumento nga DBMS gamit ang panig-ingnan sa dili labing popular niini, MongoDB (sama sa giingon, kini adunay conditional graph operators lamang. $lookup и $graphLookup, wala magtrabaho sa mga sharded nga koleksyon), apan naggamit sa panig-ingnan sa usa ka mas hamtong ug "enterprise" nga DBMS .
Busa, himoa nga ang koleksyon adunay usa ka set sa XML nga mga dokumento sa mosunod nga matang (MarkLogic usab nagtugot kanimo sa pagtipig sa mga dokumento sa JSON):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Relational nga modelo sa MarkLogic
Ang usa ka relational nga pagtan-aw sa usa ka koleksyon sa mga dokumento mahimong mabuhat gamit (mga sulod sa mga elemento value sa panig-ingnan sa ubos mahimong adunay usa ka arbitraryong 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>Mahimo nimong sulbaron ang gibuhat nga pagtan-aw gamit ang usa ka pangutana sa SQL (pananglitan, pinaagi sa ODBC):
SELECT name, surname FROM Person WHERE name="John"Ikasubo, ang relational nga pagtan-aw nga gihimo sa template nga gipakita kay read-only. Kung giproseso ang usa ka hangyo alang niini, ang MarkLogic mosulay sa paggamit . Kaniadto, ang MarkLogic adunay limitado nga pagtan-aw sa relasyon, sa tibuuk ug masulat, apan karon sila giisip nga wala na gigamit.
Modelo sa graph sa MarkLogic
Uban sa suporta alang sa graph (RDF) nga modelo, ang tanan halos parehas. Pag-usab uban sa tabang makahimo ka og representasyon sa RDF sa usa ka koleksyon sa mga dokumento gikan sa panig-ingnan sa ibabaw:
<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>Mahimo nimong sulbaron ang resulta nga RDF graph gamit ang SPARQL nga pangutana:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Dili sama sa relational, gisuportahan sa MarkLogic ang modelo sa graph sa duha pa ka paagi:
- Ang usa ka DBMS mahimong usa ka bug-os nga bulag nga pagtipig sa datos sa RDF (mga triplet sa sulod niini tawgon sukwahi sa gihulagway sa ibabaw ).
- Ang RDF sa espesyal nga serialization mahimo ra nga isal-ot sa XML o JSON nga mga dokumento (ug ang mga triplets unya tawgon ). Tingali kini usa ka alternatibo sa mga mekanismo
idrefug uban pa.
Usa ka maayong ideya kung giunsa ang mga butang nga "tinuod" nga nagtrabaho sa MarkLogic gihatag ni , sa niini nga diwa, kini mao ang ubos nga lebel, bisan tuod ang katuyoan niini mao ang hinoon sa kaatbang - sa pagsulay sa abstract gikan sa data modelo nga gigamit, aron sa pagsiguro sa makanunayon nga buhat uban sa data sa lain-laing mga modelo, transactionality, etc.
Daghang-modelo nga DBMS "walay panguna nga modelo"
Adunay usab mga DBMS sa merkado nga nagbutang sa ilang kaugalingon ingon sa una nga multi-modelo, nga wala’y napanunod nga panguna nga modelo. Kini naglakip sa , (sukad sa 2018 ang kompanya sa pagpalambo iya sa SAP) ug (serbisyo isip kabahin sa Microsoft Azure cloud platform).
Sa tinuud, adunay mga "kinauyokan" nga mga modelo sa ArangoDB ug OrientDB. Sa duha nga mga kaso, kini ang ilang kaugalingon nga mga modelo sa datos, nga mga generalization sa usa nga dokumento. Ang mga generalization nag-una aron mapadali ang abilidad sa paghimo sa mga pangutana sa usa ka graph ug relational nga kinaiya.
Kini nga mga modelo mao lamang ang magamit sa piho nga DBMS; ang ilang kaugalingon nga pangutana nga mga lengguwahe gidesinyo aron magtrabaho uban kanila. Siyempre, ang ingon nga mga modelo ug mga DBMS nagsaad, apan ang kakulang sa pagkaangay sa mga sumbanan nga modelo ug mga lengguwahe naghimo nga imposible nga gamiton kini nga mga DBMS sa mga sistema sa kabilin-aron ilisan ang mga DBMS nga gigamit na didto.
Adunay na usa ka nindot nga artikulo bahin sa ArangoDB ug OrientDB sa Habré: .
ArangoDB
Giangkon sa ArangoDB ang suporta alang sa usa ka modelo sa datos sa graph.
Ang mga node sa usa ka graph sa ArangoDB mga ordinaryo nga mga dokumento, ug ang mga ngilit mga dokumento sa usa ka espesyal nga tipo nga, kauban ang regular nga mga natad sa sistema, adunay (_key, _id, _rev) mga natad sa sistema _from и _to. Ang mga dokumento sa mga dokumento nga DBMS tradisyonal nga gihiusa sa mga koleksyon. Ang mga koleksyon sa mga dokumento nga nagrepresentar sa mga ngilit gitawag nga mga koleksyon sa ngilit sa ArangoDB. Pinaagi sa dalan, ang mga dokumento sa pagkolekta sa sulab mga dokumento usab, busa ang mga sulud sa ArangoDB mahimo usab nga molihok ingon mga node.
Raw data
Naa tay koleksiyon persons, kansang mga dokumento ingon niini:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Kabay pa nga may koleksyon man cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Unya ang koleksyon likes mahimong ingon niini:
[
{
"_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 pangutana ug resulta
Usa ka graph-style nga pangutana sa AQL nga pinulongan nga gigamit sa ArangoDB, nga nagbalik sa mabasa sa tawo nga porma nga impormasyon bahin sa kung kinsa ang ganahan kung asa nga cafe, ingon niini:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }Sa usa ka istilo sa relasyon, diin kita "nag-compute" nga mga relasyon imbes nga tipigan kini, kini nga pangutana mahimong isulat pag-usab sama niini (sa paagi, kung wala ang koleksyon likes mahimo nga 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 }Ang resulta sa duha ka mga kaso managsama:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Dugang pangutana ug resulta
Kung ang resulta nga pormat sa ibabaw daw mas kasagaran alang sa usa ka relational nga DBMS kay sa usa ka dokumento nga DBMS, mahimo nimong sulayan kini nga pangutana (o mahimo nimong gamiton ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Ang resulta mahimong sama niini:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
Ang sukaranan sa pagpatuman sa usa ka modelo sa graph sa ibabaw sa usa ka modelo sa dokumento sa OrientDB mao ang mga natad sa dokumento, dugang pa sa mas daghan o dili kaayo standard nga mga kantidad sa scalar, adunay mga kantidad usab sa mga tipo sama sa LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Ang mga kantidad niini nga mga tipo mga link o koleksyon sa mga link sa mga dokumento.
Ang identifier sa dokumento nga gi-assign sa sistema adunay "pisikal nga kahulugan", nga nagpakita sa posisyon sa rekord sa database, ug ingon niini: @rid : #3:16. Sa ingon, ang mga kantidad sa mga kabtangan sa reperensiya mga pointer gyud (sama sa modelo sa graph) kaysa sa mga kondisyon sa pagpili (sama sa modelo nga relational).
Sama sa ArangoDB, ang mga ngilit sa OrientDB girepresentahan isip bulag nga mga dokumento (bisan kung ang usa ka sulud wala’y kaugalingon nga mga kabtangan, mahimo kini. , ug dili kini katumbas sa usa ka bulag nga dokumento).
Raw data
Sa usa ka format nga duol sa Ang database sa OrientDB, ang datos gikan sa miaging pananglitan alang sa ArangoDB ingon niini:
[
{
"@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"
}
]Sama sa atong makita, ang mga vertex nagtipig usab og impormasyon mahitungod sa umaabot ug paggawas nga mga kilid. Sa Kinahanglang bantayan sa Document API ang iyang kaugalingon nga integridad sa referential, ug ang Graph API ang mobuhat niini nga trabaho. Apan tan-awon nato kung unsa ang hitsura sa pag-access sa OrientDB sa "putli" nga mga pinulongan sa pangutana nga wala gisagol sa mga programming language.
Mga pangutana ug resulta
Ang usa ka pangutana nga susama sa katuyoan sa pangutana gikan sa panig-ingnan alang sa ArangoDB sa OrientDB ingon niini:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameAng resulta makuha sa mosunod nga porma:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Kung ang format sa resulta pag-usab ingon og "relasyonal", kinahanglan nimo nga tangtangon ang linya nga adunay :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]Ang pangutana nga pinulongan sa OrientDB mahimong gihulagway nga SQL nga adunay mga pagsal-ot nga sama sa Gremlin. Sa bersyon 2.2, usa ka porma sa hangyo nga sama sa Cypher nagpakita, :
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 pormat sa resulta mahimong parehas sa miaging hangyo. Hunahunaa kung unsa ang kinahanglan nga tangtangon aron mahimo kini nga labi ka "relasyon", sama sa una nga pangutana.
Azure CosmosDB
Sa gamay nga gidak-on, ang gisulti sa ibabaw bahin sa ArangoDB ug OrientDB magamit sa Azure CosmosDB. Ang CosmosDB naghatag sa mosunod nga data access APIs: SQL, MongoDB, Gremlin ug Cassandra.
Ang SQL API ug MongoDB API gigamit sa pag-access sa datos sa modelo sa dokumento. Gremlin API ug Cassandra API - para sa pag-access sa datos sa graph ug column formats, matag usa. Ang datos sa tanang modelo gitipigan sa CosmosDB internal model format: ("atom-record-sequence"), nga duol usab sa usa ka dokumento.
Apan ang modelo sa datos nga gipili sa tiggamit ug ang gigamit nga API gitakda sa panahon sa paghimo og account sa serbisyo. Dili mahimo ang pag-access sa datos nga gikarga sa usa ka modelo sa lain nga modelo sa format, ingon sa gihulagway sa usa ka butang nga sama niini:
Busa, ang multi-modelo sa Azure CosmosDB karon mao lamang ang abilidad sa paggamit sa daghang mga database nga nagsuporta sa lain-laing mga modelo gikan sa usa ka tiggama, nga dili makasulbad sa tanang mga problema sa multi-variant storage.
Daghang modelo nga DBMS nga gibase sa usa ka modelo sa graph?
Talalupangdon ang kamatuoran nga wala pa'y daghang modelo nga DBMS sa merkado nga gibase sa usa ka modelo sa graph (gawas sa suporta nga daghang modelo alang sa dungan nga duha nga mga modelo sa graph: RDF ug LPG; tan-awa kini sa ). Ang pinakadako nga kalisud tungod sa pagpatuman sa usa ka modelo sa dokumento sa ibabaw sa usa ka modelo sa graph, kay sa usa ka relational.
Ang pangutana kung unsaon pagpatuman ang usa ka relational nga modelo sa ibabaw sa modelo sa graph gikonsiderar bisan sa panahon sa pagporma sa naulahi. Giunsa alang sa panig-ingnan :
Walay kinaiyanhon sa graph approach nga makapugong sa paghimo og layer (pananglitan, pinaagi sa angay nga pag-index) sa usa ka graph database nga makapahimo sa usa ka relational nga panglantaw sa (1) pagbawi sa mga tuple gikan sa naandan nga yawe nga mga pares sa bili ug (2) paggrupo sa tuple pinaagi sa matang sa relasyon.
Kung nag-implementar sa usa ka modelo sa dokumento sa ibabaw sa usa ka modelo sa graph, kinahanglan nimong hinumdoman, pananglitan, ang mosunod:
- Ang mga elemento sa JSON array gikonsiderar nga ordered, apan kadtong gikan sa vertex sa usa ka ngilit sa graph dili;
- Ang datos sa modelo sa dokumento kasagarang gi-denormalize; dili gihapon nimo gusto nga magtipig og daghang mga kopya sa parehas nga naka-embed nga dokumento, ug ang mga subdocument kasagarang walay mga identifier;
- Sa laing bahin, ang ideolohiya sa mga dokumento nga DBMS mao nga ang mga dokumento andam nang gihimo nga "mga aggregate" nga dili kinahanglan nga tukuron pag-usab sa matag higayon. Gikinahanglan nga mahatagan ang modelo sa graph nga adunay katakus nga dali nga makakuha usa ka subgraph nga katumbas sa nahuman nga dokumento.
Usa ka gamay nga advertising
Ang tagsulat sa artikulo adunay kalabutan sa pag-uswag sa NitrosBase DBMS, ang internal nga modelo nga graph, ug ang mga eksternal nga modelo - relational ug dokumento - ang mga representasyon niini. Ang tanan nga mga modelo managsama: halos bisan unsang datos anaa sa bisan hain niini gamit ang pangutana nga pinulongan nga natural niini. Dugang pa, sa bisan unsa nga panglantaw, ang data mahimong mausab. Ang mga pagbag-o makita sa internal nga modelo ug, sa ingon, sa ubang mga panan-aw.
Gilauman nako nga ihulagway kung unsa ang hitsura sa pagpares sa modelo sa NitrosBase sa usa sa mosunod nga mga artikulo.
konklusyon
Nanghinaut ko nga ang kinatibuk-ang mga outline sa gitawag nga multi-modeling nahimong mas o dili kaayo klaro sa magbabasa. Ang mga multi-modelo nga DBMS lahi kaayo, ug ang "multi-model nga suporta" mahimong lahi tan-awon. Aron masabtan kung unsa ang gitawag nga "multi-modelo" sa matag piho nga kaso, mapuslanon ang pagtubag sa mosunod nga mga pangutana:
- Naghisgot ba kita mahitungod sa pagsuporta sa tradisyonal nga mga modelo o usa ka matang sa "hybrid" nga modelo?
- Ang mga modelo ba "parehas", o usa ba kanila ang hilisgutan sa uban?
- Ang mga modelo ba "walay pagtagad" sa usag usa? Mabasa ba ang datos nga gisulat sa usa ka modelo sa lain o ma-overwrit pa?
Sa akong hunahuna nga ang pangutana bahin sa kalabotan sa multi-modelo nga DBMS mahimo nang matubag nga positibo, apan ang makapaikag nga pangutana kung unsang mga tipo niini ang labi nga gipangayo sa umaabot nga umaabot. Mopatim-aw nga ang mga multi-modelo nga DBMS nga nagsuporta sa tradisyonal nga mga modelo, labi na ang relational, mas dako nga panginahanglan; Ang pagkapopular sa mga multi-modelo nga DBMS, nga nagtanyag sa mga bag-ong modelo nga naghiusa sa mga bentaha sa lainlaing mga tradisyonal, usa ka butang sa labi ka layo nga umaabot.
Ang mga rehistradong tiggamit lamang ang makaapil sa survey. , walay sapayan.
Gigamit ba nimo ang daghang modelo nga DBMS?
-
Dili namo kini gamiton, among gitipigan ang tanan sa usa ka DBMS ug sa usa ka modelo
-
Gigamit namo ang mga kapabilidad sa daghang modelo sa tradisyonal nga mga DBMS
-
Nagpraktis kami sa polyglot nga pagpadayon
-
Gigamit namo ang bag-ong multi-model nga DBMS (Arango, Orient, CosmosDB)
19 ka tiggamit ang miboto. 4 ka tiggamit ang nag- abstain.
Source: www.habr.com