ProHoster > Blog > Lajmet e internetit > Sistemet multimodel janë baza e sistemeve moderne të informacionit?

Sistemet multimodel janë baza e sistemeve moderne të informacionit?

Sistemet moderne të informacionit janë mjaft të komplikuara. Një nga arsyet kryesore për këtë kompleksitet është natyra e dhënave që ato përpunojnë. Kompleksiteti i dhënave shpesh qëndron në larmishmërinë e modeleve të dhënash që përdoren. Për shembull, kur të dhënat bëhen "të mëdha", një nga karakteristikat që shkakton shqetësim është jo vetëm volume i tyre, por edhe larmishmëria e tyre.

Nëse akoma nuk po gjeni ndonjë gabim në arsyetimet, vazhdoni të lexoni.

Sistemet multimodel janë baza e sistemeve moderne të informacionit?


PĂ«rmbajtja

Ruajtja polyglot
Multimodeliteti
Sistemet multimodel mbi bazën e modelit relacional
     Modeli dokumentar në MS SQL Server
     Modeli grafik në MS SQL Server
Sistemet multimodel mbi bazën e modelit dokumentar
     Modeli relacional në MarkLogic
     Modeli grafik në MarkLogic
Sistemet multimodel "pa modelin kryesor"
     ArangoDB
     OrientDB
     Azure CosmosDB
Sistemet multimodel mbi bazën e modelit grafik?
PĂ«rfundimi
Anketa

Ruajtja polyglot

E thënë më sipër tregon se në disa raste, madje brenda një sistemi, për ruajtjen e të dhënave dhe zgjidhjen e detyrave të ndryshme të përpunimit, duhet të përdoren disa sisteme të ndryshme menaxhimi të të dhënave, secila prej të cilave mbështet modelin e vet të të dhënave. Me kontributin e M. Fowler, autori seri librash të njohur dhe një prej bashkautorëve Agile Manifesto, kjo situatë mori emrin ruajtjes multi-model («polyglot persistence»).

Fowler gjithashtu ofron shembuj për organizimin e ruajtjes së të dhënave në një aplikacion plotësisht funksional dhe me ngarkesë të lartë në fushën e tregtisë elektronike.

Sistemet multimodel janë baza e sistemeve moderne të informacionit?

Ky shembull është, sigurisht, disi i ekzagjeruar, por disa konsiderata për zgjedhjen e një sistemi të caktuar të menaxhimit të të dhënave për qëllime të caktuara mund të gjenden, për shembull, këtu.

ËshtĂ« e qartĂ« se tĂ« jesh menaxher nĂ« njĂ« tĂ« tillĂ« ‘zoopark’ nuk Ă«shtĂ« e lehtĂ«.

  • VĂ«llimi i kodit qĂ« kryen ruajtjen e tĂ« dhĂ«nave rritet nĂ« proporcion me numrin e sistemeve tĂ« menaxhimit tĂ« tĂ« dhĂ«nave tĂ« pĂ«rdorura; vĂ«llimi i kodit qĂ« sinkronizon tĂ« dhĂ«nat - Ă«shtĂ« mirĂ« nĂ«se nuk Ă«shtĂ« nĂ« proporcion me katrorin e kĂ«tij numri.
  • Kostoja e shfrytĂ«zimit tĂ« DBMS rritet pĂ«r tĂ« siguruar karakteristika enterprise (masĂ«, qĂ«ndrueshmĂ«ri, disponueshmĂ«ri e lartĂ«) pĂ«r çdo DBMS tĂ« pĂ«rdorur.
  • Nuk Ă«shtĂ« e mundur tĂ« sigurohen karakteristikat enterprise tĂ« njĂ« nĂ«n-sistemi ruajtjeje nĂ« tĂ«rĂ«si — sidomos transaksionaliteti.

Nga këndvështrimi i drejtorit të kopshtit zoologjik, gjithçka duket kështu:

  • Rritja e kĂ«saj kostoje licencash dhe mbĂ«shtetjeje teknike nga prodhuesi i DBMS.
  • Rritja e numrit tĂ« punonjĂ«sve dhe zgjedhja e afateve.
  • Humjet direkte financiare ose sanksionet pĂ«r shkak tĂ« mos pĂ«rputhjes sĂ« tĂ« dhĂ«nave.

Ka një rritje të konsiderueshme të kostos totale të pronësisë (TCO) të sistemit. A ka një dalje nga situata e "ruajtjes së shumëllojshme"?

Multimodeliteti

Termi "ruajtje e shumëllojshme" hyri në përdorim në vitin 2011. Kuptimi i problemeve të qasjes dhe kërkimi për një zgjidhje zgjati disa vite, dhe deri në vitin 2015, me gojën e analistëve të Gartner, përgjigjja u formulua:

Duket se kĂ«tĂ« herĂ« analistĂ«t e Gartner nuk kanĂ« gabuar me parashikimin. NĂ«se hyni nĂ« faqen me vlerĂ«simin kryesor tĂ« DB-ve nĂ« DB-Engines, mund tĂ« shihni se shumica e liderĂ«ve tĂ« tij pozicionohen si sisteme DB multimodel. E njĂ«jta gjĂ« mund tĂ« shihet edhe nĂ« faqen me çdo vlerĂ«sim tĂ« veçantĂ«.oNĂ« tabelĂ«n mĂ« poshtĂ« janĂ« renditur sistemet DB — liderĂ« nĂ« çdo vlerĂ«sim tĂ« veçantĂ«, tĂ« cilĂ«t deklarojnĂ« multimodelizimin e tyre. PĂ«r çdo sistem DB janĂ« dhĂ«nĂ« modeli fillestar i mbĂ«shtetur (dhe dikur i vetmi) dhe, pĂ«rveç tij, modelet qĂ« mbĂ«shteten tani. Gjithashtu janĂ« pĂ«rfshirĂ« sistemet DB qĂ« pozicionohen si "fillimisht multimodel", pa ndonjĂ« model tĂ« trashĂ«guar sipas deklaratave tĂ« krijuesve.

Modeli fillestar

DBMSModelet shtesëModelet shtesë
OracleRelacionalGrafik, dokumentar
MS SQLRelacionalGrafik, dokumentar
PostgreSQLRelacionalGrafik*, dokumentar
MarkLogicDokumentarGrafik, relacional
MongoDBDokumentarÇelĂ«s-vlerĂ«, grafik*
DataStaxKolonë e gjerëDokumentar, grafik
RedisÇelĂ«s-vlerĂ«Dokumentar, grafik*
ArangoDB—Grafik, dokumentar
OrientDB—Grafik, dokumentare, relacionale
Azure CosmosDB—Grafik, dokumentare, relacionale

Shënime për tabelën

Njëshja e tabelës është shënjuar me yje për përfundimet që kërkojnë sqarime:

  • Sistemi i Menaxhimit tĂ« BazĂ«s sĂ« tĂ« DhĂ«nave PostgreSQL nuk mbĂ«shtet modelin grafik tĂ« tĂ« dhĂ«nave, por njĂ« produkt i tillĂ« nĂ« bazĂ« tĂ« saj, si, pĂ«r shembull, AgensGraph.
  • Sa i pĂ«rket MongoDB, Ă«shtĂ« mĂ« e saktĂ« tĂ« flasim pĂ«r praninĂ« e operatorĂ«ve grafikĂ« nĂ« gjuhĂ«n e pyetjeve ($lookup, $graphLookup), sesa pĂ«r mbĂ«shtetje tĂ« modelit grafik, megjithĂ«se, sigurisht, hyrja e tyre kĂ«rkonte disa optimizime nĂ« nivelin e ruajtjes fizike drejt mbĂ«shtetjes sĂ« modelit grafik.
  • Sa i pĂ«rket Redis, i referohet zgjerimit RedisGraph.

MĂ« pas, pĂ«r secilĂ«n nga klasat do tĂ« tregojmĂ« se si realizohet mbĂ«shtetja pĂ«r disa modele nĂ« sistemet e menaxhimit tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave nga kjo klasĂ«. Modelet mĂ« tĂ« rĂ«ndĂ«sishme do tĂ« konsiderohen ato relacionale, dokumentare dhe grafike, dhe do tĂ« ilustrohen me shembuj nga sistemet specifike tĂ« menaxhimit tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave se si realizohen ‘tĂ« munguarit’.

Sistemet multimodel mbi bazën e modelit relacional

Sistemet më të njohura të menaxhimit të bazave të dhënash aktualisht janë ato relacional, parashikimi i Gartner-it nuk do të konsiderohej i realizuar nëse DBMS-të relacionalë nuk do të tregonin lëvizje drejt multimode. Dhe ato e bëjnë këtë. Tani, mendimet që DBMS multimoidal është si një thikë zvicerane, me të cilën nuk mund të bësh asgjë mirë, mund të drejtohen menjëherë te Larry Ellison.

Megjithatë, autorit i pëlqen më shumë implementimi i multimodelit në Microsoft SQL Server, për shembullin e të cilit do të përshkruhet mbështetje e DBMS-ve për modelet dokumentar dhe grafike.

Modeli dokumentar në MS SQL Server

Për atë se si është realizuar mbështetja e modelit dokumentar në MS SQL Server, në Habrë tashmë ka qenë dy artikuj të shkëlqyer, do të bëj një përmbledhje të shkurtër dhe një koment:

Mënyra e mbështetjes së modelit dokumentar në MS SQL Server është mjaft tipike për DBMS-të relacional: dokumentet JSON propozohet të ruhen në fusha të zakonshme të tekstit. Mbështetja e modelit dokumentar konsiston në ofrimin e operatorëve të veçantë për analizimin e këtij JSON:

  • JSON_VALUE pĂ«r tĂ« nxjerrĂ« vlera skalarĂ« tĂ« atributeve,
  • JSON_QUERY pĂ«r tĂ« nxjerrĂ« nĂ«n-dokumentet.

Argumenti i dytë i të dy operatorëve është një shprehje në sintaksën e ngjashme me JSONPath.

Në mënyrë abstrakte, mund të thuhet se dokumentet e ruajtura në këtë mënyrë nuk janë "entitete të klasës së parë" në një DBMS relational, për dallim nga tuple. Konkretisht, në MS SQL Server aktualisht mungojnë indekset për fushat e dokumenteve JSON, gjë që e bën të vështirë kryerjen e operacioneve të bashkimeve të tabelave mbi vlerat e këtyre fushave dhe madje edhe marrjen e dokumenteve mbi këto vlera. Megjithatë, është e mundur të krijohet një kolonë e llogaritur mbi një fushë të tillë dhe një indeks mbi të.

PĂ«r mĂ« tepĂ«r, MS SQL Server ofron mundĂ«sinĂ« e ndĂ«rtimit tĂ« lehtĂ« tĂ« njĂ« dokumenti JSON nga pĂ«rmbajtja e tabelave me ndihmĂ«n e operatorit FOR JSON PATH — njĂ« mundĂ«si, nĂ« njĂ« farĂ« mĂ«nyre e kundĂ«rt me ruajtjen konvencionale. ËshtĂ« e qartĂ« se, sa do e shpejtĂ« tĂ« jetĂ« RDBMS, ky qasje Ă«shtĂ« nĂ« kundĂ«rshtim me ideologjinĂ« e DBMS-ve dokumentar, qĂ« nĂ« thelb ruajnĂ« pĂ«rgjigje tĂ« gatshme pĂ«r kĂ«rkesat popullore, dhe mund tĂ« zgjidhĂ« vetĂ«m probleme tĂ« zhvillimit tĂ« lehtĂ«, por jo tĂ« shpejtĂ«sisĂ«.

Më në fund, MS SQL Server lejon zgjidhjen e detyrës, e cila është e kundërt me ndërtimin e dokumentit: është e mundur të shpërndahen të dhënat JSON në tabela me ndihmën e OPENJSON. Nëse dokumenti nuk është plote flat, do të nevojitet përdorimi i CROSS APPLY.

Modeli grafik në MS SQL Server

Mbështetje për modelin grafik (LPG) është realizuar gjithashtu në Microsoft SQL Server parashikueshëm: rekomandohet përdorimi i tabelave speciale për ruajtjen e node-ve dhe për ruajtjen e skajet e grafit. Të tilla tabela krijohen duke përdorur shprehjet CREATE TABLE AS NODE dhe CREATE TABLE AS EDGE përkatësisht.

TĂ« dhĂ«nat e llojit tĂ« parĂ« janĂ« tĂ« ngjashme me tabelat e zakonshme pĂ«r ruajtjen e regjistrimeve me atĂ« ndryshim tĂ« jashtĂ«m qĂ« nĂ« tabelĂ« ka njĂ« fushĂ« sistematike $node_id — njĂ« identifikues unik brenda bazĂ«s sĂ« tĂ« dhĂ«nave pĂ«r nodet e grafit.

Po ashtu, tabelat e llojit të dytë kanë fusha sistematike $from_id dhe $to_id, regjistrimet në këto tabela në mënyrë të qartë përcaktojnë lidhjet midis node-ve. Për ruajtjen e lidhjeve të çdo lloji përdoret një tabelë e veçantë.

Sistemet multimodel janë baza e sistemeve moderne të informacionit? Le të ilustrojmë këtë me një shembull. Supozoni se të dhënat grafike kanë një skemë si në figurën e dhënë. Atëherë, për të krijuar strukturën përkatëse në bazën e të dhënave, duhet të ekzekutoni kërkesat DDL-të vijues:

KRIJONI TABELËN Person (
  ID INTEGER NOT NULL,
  emër VARCHAR(100)
) SI NODE;

KRIJONI TABELËN Cafe (
  ID INTEGER NOT NULL, 
  emër VARCHAR(100), 
) SI NODE;

KRIJONI TABELËN likes (
  vlerësim INTEGER
) SI EDGE;

KRIJONI TABELËN friendOf
  SI EDGE;

MODIFIKO TABELËN likes
  SHTO KUSHTIN EC_LIKES LIDHJE (Person TE Cafe);

Specifika kryesore e këtyre tabelave është se në kërkesat ndaj tyre është e mundur të përdoren modele grafike me sintaksë të ngjashme me Cypher (me sa duket, "*" dhe të tjera akoma nuk mbështeten). Në bazë të matjeve të performancës, gjithashtu mund të supozojmë se mënyra e ruajtjes së të dhënave në këto tabela ndryshon nga mekanizmi i ruajtjes së të dhënave në tabelat e zakonshme dhe është optimizuar për realizimin e kërkesave të tilla grafike.

ZGJIDH CAFE.emër
  NGA Person, likes, Cafe
  KU KALON (Person-(friendOf)-(likes)->Cafe)
  DHE Person.emër = 'John';

PĂ«r mĂ« tepĂ«r, Ă«shtĂ« mjaft e vĂ«shtirĂ« gjatĂ« punĂ«s me kĂ«to tabela tĂ« mos pĂ«rdoren kĂ«to modele grafike, pasi nĂ« kĂ«rkesat e zakonshme SQL pĂ«r zgjidhjen e detyrave tĂ« ngjashme do tĂ« nevojitet tĂ« bĂ«hen pĂ«rpjekje tĂ« tjera pĂ«r tĂ« marrĂ« identifikuesit ‘grafik’ sistematikĂ« tĂ« nyjeve ($node_id, $from_id, $to_id; pĂ«r kĂ«tĂ« arsye, kĂ«rkesat pĂ«r futjen e tĂ« dhĂ«nave nuk janĂ« paraqitur kĂ«tu si tepĂ«r tĂ« ngarkuara).

Duke pĂ«rmbledhjes sĂ« realizimeve tĂ« modeleve dokumentar dhe grafik nĂ« MS SQL Server, do tĂ« theksoja se kĂ«to realizime tĂ« njĂ« modeli mbi njĂ« tjetĂ«r nuk duken tĂ« suksesshme kryesisht nga pikĂ«pamja e dizajnit gjuhĂ«sor. ËshtĂ« e nevojshme qĂ« njĂ« gjuhĂ« tĂ« shtrihet mbi tjetrĂ«n, gjuhĂ«t nuk janĂ« plotĂ«sisht "ortogonale", rregullat e pĂ«rputhshmĂ«risĂ« mund tĂ« jenĂ« mjaft tĂ« çuditshme.

Sistemet multimodel mbi bazën e modelit dokumentar

Në këtë seksion, dua të ilustroj realizimin e multimodelitetit në DBMS dokumentar duke marrë si shembull një nga ato më pak të njohura, MongoDB (siç u tha, ajo ka vetëm operatorë të kushtëzuar grafikë, $lookup dhe $graphLookup, që nuk funksionojnë në koleksionet e ndara), por duke bërë krahasimin me një DBMS më të pjekur dhe "enterprise". MarkLogic.

Prandaj, le të themi se koleksioni përmban një grup XML-dokumentesh të këtij lloji (MarkLogic po ashtu lejon ruajtjen e dokumenteve JSON):

John
  Smith

Modeli relacional në MarkLogic

Paraqitja relacionale e koleksionit të dokumenteve mund të krijohet me anë të modelit të shqyrtimit (përmbajtja e elementeve vlera në shembullin më poshtë mund të jetë një XPath të rastësishëm):

/Person
  
    
      Person
      
        
          SSN
          @SSN
          string
        
        
          emri
          name
        
        
          mbiemri
          surname

SQL- Đ·Đ°ĐżŃ€ĐŸŃ mund tĂ« adresohet nĂ« pamjen e krijuar (pĂ«r shembull, pĂ«rmes ODBC):

SELECT name, surname FROM Person WHERE name="John"

Fatkeqësisht, pamja e marrë nga modeli është vetëm për lexim. Kur trajton një kërkesë ndaj saj, MarkLogic do të përpiqet të përdorë indeksin e dokumenteve. Përpara, MarkLogic kishte dhe pamje të kufizuara relacionale, të ndërtuara krejtësisht në baza indekse dhe të aksesueshme për shkrim, por tani ato konsiderohen si të vjetra.

Modeli grafik në MarkLogic

Me mbështetje për modelin grafik (RDF) situata është shumë e ngjashme. Po ashtu me ndihmën e modelit të shqyrtimit mund të krijoni një pamje RDF të koleksionit të dokumenteve nga shembulli më sipër:

/Person
    
      
        PREFIX
        "http://example.org/example#"
      
    
  
    
      sem:iri( $PREFIX || @SSN )
      sem:iri( $PREFIX || surname )
      xs:string( surname )
    
    
      sem:iri( $PREFIX || @SSN )
      sem:iri( $PREFIX || name )
      xs:string( name )

SPARQL-i mund të dërgohet në grafikun RDF të përfituar:

PREFIX : 
SELECT ?name ?surname {
  :631803299804 :name ?name ; :surname ?surname .
}

Ndryshe nga modeli relacional, modeli grafik i MarkLogic mbështet gjithashtu në dy mënyra të tjera:

  1. DBMS mund të jetë një depo e plotë e të dhënave RDF (trupat në të do të quhen managed në kundërshtim me ato të përshkruara më sipër extracted).
  2. RDF në një serializim të veçantë mund të thjesht shtohet në dokumente XML ose JSON (dhe trupat atëherë do të quhen unmanaged). Një alternativë e tillë është mekanizmat idref etj.

Një ide e mirë se si 'realiteti' funksionon në MarkLogic jep Optic API, në këtë kuptim ajo është me nivel të ulët, megjithatë qëllimi i saj është më shumë anomal, për të provuar të abstrahojë nga modelimi i të dhënave të përdorur, për të siguruar një funksionim të qëndrushëm me të dhënat në modele të ndryshme, transaksionet etj.

Sistemet multimodel "pa modelin kryesor"

Në treg gjithashtu janë të pranishme DBMS të cilat pozicionohen si fillimisht multimodel, pa pasur ndonjë model bazë të trashëguar. Ndër to janë ArangoDB, OrientDB (që nga viti 2018, kompania zhvilluese i përket SAP) dhe CosmosDB (shërbim pjesë e platformës cloud Microsoft Azure).

Në të vërtetë, modelet "themelore" në ArangoDB dhe OrientDB ekzistojnë. Në të dy rastet, janë modelet e veta të të dhënave, të cilat janë përmbledhje të modelit dokumentar. Përmbledhjet lidhen kryesisht me lehtësimin e mundësive për të bërë kërkesa grafike dhe relacionale.

KĂ«to modele janĂ« tĂ« vetmet tĂ« disponueshme pĂ«r pĂ«rdorim nĂ« sistemet e specifikuara tĂ« menaxhimit tĂ« tĂ« dhĂ«nave, dhe janĂ« destinuar pĂ«r t'u pĂ«rdorur me gjuhĂ«t e tyre tĂ« kĂ«rkimit. Pa dyshim, kĂ«to modele dhe sistemet e menaxhimit tĂ« tĂ« dhĂ«nave janĂ« tĂ« perspektivshme, megjithatĂ« mungesa e pĂ«rputhshmĂ«risĂ« me modelet dhe gjuhĂ«t standarde e bĂ«n tĂ« pamundur pĂ«rdorimin e kĂ«tyre sistemeve tĂ« menaxhimit tĂ« tĂ« dhĂ«nave nĂ« sistemet trashĂ«guese — zĂ«vendĂ«simi i sistemeve tĂ« menaxhimit tĂ« tĂ« dhĂ«nave tĂ« pĂ«rdorura atje.

Për ArangoDB dhe OrientDB në Habra ka pasur një artikull të shkëlqyer: JOIN në bazat e të dhënave NoSQL.

ArangoDB

ArangoDB deklaron mbështetje për modelin e të dhënave grafike.

Njësitë e grafit në ArangoDB janë dokumente të zakonshme, ndërsa dhjetëra janë dokumente të një lloji të veçantë, të cilat kanë, përveç fushave të zakonshme sistemike (_key, _id, _rev) fusha sistemike _from dhe _to. Dokumentet në sistemet e menaxhimit të të dhënave dokumente tradicionale grupohen në koleksione. Koleksionet e dokumenteve që përfaqësojnë dhjetëra në ArangoDB quhen edge-koleksione. Për më tepër, dokumentet e edge-koleksioneve janë gjithashtu dokumente, kështu që dhjetëra në ArangoDB mund të funksionojnë edhe si njësitë.

Të dhënat fillestare

Le të supozojmë se kemi një koleksion persons, dokumentet e të cilit duken kështu:

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "Alisa"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Bob"  
  }
]

Të ketë gjithashtu një koleksion kafesh:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "John Donne"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Jean-Jacques"
  }
]

Atëherë koleksioni pëlqime mund të duket si në vijim:

[
  {
    "_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 
  }
]

KĂ«rkesat dhe rezultatet

Një kërkesë në stilin grafit në gjuhën AQL të përdorur në ArangoDB, e cila kthen në një format të lexueshëm nga njeriu informacionet se kujt i pëlqen cila kafe, duket kështu:

FOR p IN persons
  FOR c IN OUTBOUND p likes
  RETURN { person : p.name , likes : c.name }

Në stilin relacionale, kur ne të bëjmë më shumë "lidhje" të llogaritur, sesa i ruajmë ato, kjo kërkesë mund të rishtrohet kështu (duke e përmendur, pa koleksionin pëlqime mund të ishim mjaftuar):

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 }

Rezultati në të dyja rastet do të jetë i njëjtë:

[
  { "person" : "Alice" , likes : "Jean-Jacques" } ,
  { "person" : "Alice" , likes : "John Donne" } ,
  { "person" : "Bob" , likes : "John Donne" }
]

Kërkesa dhe rezultate të tjera

Nëse duket se formati i rezultatit më shumë i përshtatet një DBMS relacional sesa një dokumentar, mund të provoni kështu një kërkesë (ose mund të përdorni KOMBE):

PËR p NË persons
  KTHYER {
    person : p.name,
    likes : (
      PËR c NË OUTBOUND p likes
      KTHYER c.name
    )
}

Rezultati do të ketë këtë pamje:

[
  { "person" : "Alisa" , likes : ["Jean-Jacques" , "John Donne"] } ,
  { "person" : "Bob" , likes : ["John Donne"] }
]

OrientDB

NĂ« thelb tĂ« implementimit tĂ« modelit grafik mbi dokumentar nĂ« OrientDB qĂ«ndron mundĂ«sia fushat e dokumenteve tĂ« kenĂ« pĂ«rveç vlerave standarde skalarĂ«, edhe vlera tĂ« tilla si LIDHJE, LISTA E LIDHJVE, GRUPI I LIDHJVE, MAPA E LIDHJVE dhe ÇANTË LIDHJESH. Vlerat e kĂ«tyre tipeve janĂ« referenca ose koleksione referencash ndaj identifikuesve tĂ« sistemit e dokumenteve.

Identifikuesi që i cakton sistemi dokumentit ka "kuptim fizik", duke treguar pozitat e regjistrimit në bazë, dhe duket diçka si: @rid : #3:16. Kështu, vlerat e pronave referencuese me të vërtetë janë më shumë si tregues (si në modelin grafik), sesa kushte filtrimi (si në relacionale).

Si në ArangoDB, në OrientDB qoshet paraqiten si dokumente të veçanta (ndonëse nëse një qoshe nuk ka pronarët e saj, mund ta bëni të lehtë., dhe nuk do të përputhet me një dokument të veçantë).

Të dhënat fillestare

Në një format më të afërt me formatin e dump-it të bazës OrientDB, të dhënat nga shembulli i mëparshëm për ArangoDB do të duken kështu:

[
     {
      "@type": "document",
      "@rid": "#11:0",
      "@class": "Person",
      "name": "Alisa",
      "out_likes": [
        "#30:1",
        "#30:2"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#12:0",
      "@class": "Person",
      "name": "Bob",
      "out_likes": [
        "#30:3"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#21:0",
      "@class": "Cafe",
      "name": "Zhan-Zhak",
      "in_likes": [
        "#30:2",
        "#30:3"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#22:0",
      "@class": "Cafe",
      "name": "Xhon Don",
      "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"
    }
  ]

Siç shohim, edhe kulmet mbajnë informacion rreth skajeve që hyjnë dhe dalin. Me përdorimin API i dokumenteve për integritetin e lidhjeve kërkon mbikëqyrje manuale, ndërsa Graph API merr këtë punë mbi vete. Por le të shikojmë se si duket një kërkesë për OrientDB në gjuhë kërkese "të pastër", të paintegruara në gjuhët e programimit.

KĂ«rkesat dhe rezultatet

Një kërkesë e ngjashme me atë që u dha për ArangoDB, në OrientDB duket kështu:

SELECT name AS person_name, OUT('likes').name AS cafe_name
   FROM Person
   UNWIND cafe_name

Rezultati do të merret në formën e mëposhtme:

[
  { "person_name": "Alisa", "cafe_name": "John Donne" },
  { "person_name": "Alisa", "cafe_name": "Jean-Jacques" },
  { "person_name": "Bob",  "cafe_name": "Jean-Jacques" }
]

Nëse formati i rezultatit përsëri duket shumë "relacional", duhet të hiqet rreshti me UNWIND():

[
  { "person_name": "Alisa", "cafe_name": [ "John Donne", "Jean-Jacques" ] },
  { "person_name": "Bob",  "cafe_name": [ "Jean-Jacques" ] }
]

Gjuha e kërkesave për OrientDB mund të karakterizohet si SQL me shtesa të ngjashme me Gremlin. Në versionin 2.2 u prezantua një formë kërkese e ngjashme me Cypher, MATCH :

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_name

Formati i rezultatit do të jetë i njëjtë si në kërkesën e mëparshme. Mendoni se çfarë duhet të hiqet për ta bërë atë më "relacional", si në kërkesën e parë.

Azure CosmosDB

Në një masë më të vogël, ajo që u tha më lart për ArangoDB dhe OrientDB i referohet gjithashtu Azure CosmosDB. CosmosDB ofron këto API për qasje në të dhëna: SQL, MongoDB, Gremlin dhe Cassandra.

SQL API dhe MongoDB API pĂ«rdoren pĂ«r qasje nĂ« tĂ« dhĂ«na nĂ« modelin dokumentar. Gremlin API dhe Cassandra API — pĂ«r qasje nĂ« tĂ« dhĂ«na pĂ«rkatĂ«sisht nĂ« modelin grafik dhe kolumnar. TĂ« dhĂ«nat nĂ« tĂ« gjitha modelet ruhen nĂ« formatin e modelit tĂ« brendshĂ«m tĂ« CosmosDB: ARS («atom-record-sequence»), i cili Ă«shtĂ« gjithashtu i ngjashĂ«m me modelin dokumentar.

Sistemet multimodel janë baza e sistemeve moderne të informacionit?

Por modeli i të dhënave të zgjedhur nga përdoruesi dhe API e përdorur janë të fiksuara në momentin e krijimit të llogarisë në shërbim. Nuk është e mundur të aksesosh të dhënat e ngarkuara në një model, në formatin e një modeli tjetër, gjë që do të ilustrohej me një skicë të tillë:

Sistemet multimodel janë baza e sistemeve moderne të informacionit?

Në këtë mënyrë, multimodeliteti në Azure CosmosDB aktualisht paraqet vetëm një mundësi për të përdorur disa baza të dhënash, që mbështesin modele të ndryshme, nga një prodhues, gjë që nuk zgjidh të gjitha problemet e ruajtjes multi-variant.

Sistemet multimodel mbi bazën e modelit grafik?

Tërheq vëmendjen fakti se ende nuk ka DBM multisenoriale në treg që ka si bazë modelin graf. (përveç nëse numërojmë mbështetje multisenoriale për dy modele grafike: RDF dhe LPG; shihni për këtë në publikimi i mëparshëm). Zhvillimi më i madh paraqet realizimin mbi modelin graf të dokumentit dhe jo të relacionit.

Çështja se si tĂ« realizohet njĂ« model relacioni mbi modelin graf u shqyrtua qĂ« nĂ« kohĂ«t e formimit tĂ« kĂ«tij tĂ« fundit. Si tha, pĂ«r shembull, David McGovern:

Nuk ka asgjë të inherentë në qasjen grafike që ndalon krijimin e një shtrese (e.g., me indeksem të duhur) mbi një bazë të të dhënash grafike që lejon një pamje relacioni me (1) rikuperimin e tupleve nga çifti i zakonshëm të çelësit dhe (2) grupimin e tupleve sipas llojit të relacionit.

Në realizimin e modelit të dokumentit mbi graf duhet të kemi parasysh, për shembull, gjithashtu:

  • Elementet e JSON-array merren si tĂ« renditura, ndĂ«rsa ato qĂ« dalin nga maja e skelĂ«s grafike — nuk janĂ«;
  • TĂ« dhĂ«nat nĂ« modelin e dokumentit zakonisht janĂ« denormalizuar, nuk do tĂ« doja tĂ« ruaja disa kopje tĂ« njĂ« dokumenti tĂ« njĂ«jtĂ« tĂ« thelluar, ndĂ«rsa pĂ«r nĂ«n-dokumentet zakonisht nuk ka identifikues.
  • NĂ« anĂ«n tjetĂ«r, ideologjia e DBMS dokumenteve qĂ«ndron nĂ« faktin se dokumentet janĂ« "agregate" tĂ« gatshme qĂ« nuk kĂ«rkojnĂ« ndĂ«rtim tĂ« ri çdo herĂ«. Duhet tĂ« sigurohet qĂ« nĂ« modelin graf i jepet mundĂ«sia pĂ«r tĂ« marrĂ« shpejt njĂ« nĂ«n-graf qĂ« pĂ«rputhet me dokumentin e gatshĂ«m.

Pak reklamë

Autori i artikullit Ă«shtĂ« i pĂ«rfshirĂ« nĂ« zhvillimin e DBMS NitrosBase, modeli i brendshĂ«m i tĂ« cilit Ă«shtĂ« grafor, ndĂ«rsa modelet e jashtme — relacional dhe dokumentar — janĂ« pĂ«rfaqĂ«sime tĂ« tij. TĂ« gjitha modelet janĂ« tĂ« barabarta: pothuajse çdo tĂ« dhĂ«na Ă«shtĂ« e disponueshme nĂ« cilĂ«ndo prej tyre duke pĂ«rdorur gjuhĂ«n e kĂ«rkimit qĂ« i pĂ«rshtatet. MĂ« shumĂ« se kaq, nĂ« çfarĂ«do pĂ«rfaqĂ«simi, tĂ« dhĂ«nat mund tĂ« ndryshojnĂ«. Ndryshimet do tĂ« reflektohen nĂ« modelin e brendshĂ«m dhe, pĂ«r rrjedhojĂ«, nĂ« pĂ«rfaqĂ«simet e tjera.

Se si duket pĂ«rputhja e modeleve nĂ« NitrosBase — do ta pĂ«rshkruaj, shpresoj, nĂ« njĂ« nga artikujt e ardhshĂ«m.

PĂ«rfundimi

Shpresoj se konturet e përgjithshme të asaj që quhet multimodelitet janë bërë më të qarta për lexuesin. SBU vazhdojnë të jenë mjaft të ndryshme, dhe "mbështetje për modele të shumta" mund të duket në mënyra të ndryshme. Për të kuptuar se çfarë quhet "multimodelitet" në çdo rast të caktuar, ndihmon të përgjigjemi për pyetje të mëposhtme:

  1. "A bëhet fjalë për mbështetje të modeleve tradicionale apo për një lloj "modeli hibrid"?"
  2. "A janë modelet "të barabarta", apo njëra prej tyre është e nënshtroshme për të tjerat?"
  3. "A janë modelet "të padëshirueshme" për njëra-tjetrën? A mund të lexohen të dhënat e shkruara në një model në një tjetër apo madje të rishkruhen?"

Mendoj se tashmë është e mundur të jepet një përgjigje pozitive për pyetjen në lidhje me relevancën e DBM-multimodel, por është interesante të dimë se cilat variacione të tyre do të kërkohen më shumë në të ardhmen e afërt. Duket se do të jenë më të kërkuara DBM-multimodel që mbështesin modelet tradicionale, së pari, atë relacional; popullariteti i DBM-multimodel që ofrojnë modele të reja që kombinojnë përfitimet e modeleve tradicionale, është një çështje e një të ardhmeje më të largët.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutemi.

A përdorni DBM-multimodel?

  • Nuk pĂ«rdorim, ruajmĂ« gjithçka nĂ« njĂ« DBM dhe nĂ« njĂ« model.

  • PĂ«rdorim mundĂ«sitĂ« multimodel tĂ« DBM tradicionale.

  • PraktikojmĂ« ruajtjen e shumĂ«llojshme (polyglot persistence).

  • PĂ«rdorim DBM-multimodel tĂ« reja (Arango, Orient, CosmosDB).

Votuan 19 përdorues. I abstenuan 4 përdorues.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster