ProHoster > Blog > Lajmet e internetit > Sistemet e shumëmodeleve të DBMS janë thelbi i sistemeve informative moderne?

Sistemet e shumëmodeleve të DBMS janë thelbi i sistemeve informative moderne?

Sistemat një informacioni moderne janë mjaft të ndërlikuara. Jo në mënyrë të vogël, kompleksiteti i tyre i atribuohet kompleksitetit të të dhënave që përpunohen prej tyre. Ndërsa, kompleksiteti i të dhënave shpesh qëndron në shumëllojshmë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ë ndikon është jo vetëm vëllimi i tyre ("volume"), por gjithashtu shumëllojshmëria e tyre ("variety").

Nëse ende nuk keni gjetur ndonjë dobësi në arsyetimet, vazhdoni të lexoni.

Sistemet e shumëmodeleve të DBMS janë thelbi i sistemeve informative moderne?


PĂ«rmbajtja

Ruajtja polyglot
Multimodel
Sistemat e menaxhimit të të dhënave multimodel në bazë të modelit relacion
     Modeli dokumentar në MS SQL Server
     Modeli grafik në MS SQL Server
Sistemat e menaxhimit të të dhënave multimodel në bazë të modelit dokumentar
     Modeli relacion në MarkLogic
     Modeli grafik në MarkLogic
Sistemat e menaxhimit të të dhënave multimodel "pa model të bazës"
     ArangoDB
     OrientDB
     Azure CosmosDB
Sistemat e menaxhimit të të dhënave multimodel në bazë të modelit grafik?
PĂ«rfundim
Anketa

Ruajtja polyglot

Ajo që u tha më sipër çon në faktin se ndonjëherë, brenda të njëjtës sistem, është e nevojshme të përdoren disa sisteme të menaxhimit të të dhënave të ndryshme për të ruajtur të dhënat dhe për të zgjidhur detyrat e tyre përpunuese, secila prej të cilave mbështet modelin e saj të të dhënave. Me ndihmën e M. Fowler, autori një sërë librash të njohur dhe njëri nga bashkautorët Agile Manifesto, kjo situatë mori emrin ruajtja shumëdimensionale ("polyglot persistence").

Fowler gjithashtu ka dhënë një shembull të organizimit të ruajtjes së të dhënave në një aplikacion të plotëfunksional dhe me ngarkesë të lartë në fushën e tregtisë elektronike.

Sistemet e shumëmodeleve të DBMS janë thelbi i sistemeve informative moderne?

Ky shembull, sigurisht, është ndoshta paksa i tepruar, por disa konsiderata për zgjedhjen e një sistemi të menaxhimit të të dhënave të caktuar për një qëllim të caktuar mund të gjenden, për shembull, këtu.

E qartë është se të jesh shërbëtori në një qoshe të tillë nuk është e lehtë.

  • VĂ«llimi i kodit qĂ« kryen ruajtjen e tĂ« dhĂ«nave rritet proporcionalisht me numrin e sistemeve tĂ« menaxhimit tĂ« tĂ« dhĂ«nave tĂ« pĂ«rdorura; vĂ«llimi i kodit qĂ« sinkronizon tĂ« dhĂ«nat - mirĂ« Ă«shtĂ« nĂ«se nuk Ă«shtĂ« proporcional katrorit tĂ« kĂ«tij numri.
  • Shpenzimet pĂ«r tĂ« garantuar karakteristikat e nivelit enterprise (skalabilitet, qĂ«ndrueshmĂ«ri, disponueshmĂ«ri e lartĂ«) tĂ« secilit nga sistemet e menaxhimit tĂ« tĂ« dhĂ«nave tĂ« pĂ«rdorura rriten shumĂ«fish me numrin e sistemeve tĂ« menaxhimit tĂ« tĂ« dhĂ«nave tĂ« pĂ«rdorura.
  • Nuk Ă«shtĂ« e mundur tĂ« sigurohet karakteristikat e nivelit enterprise tĂ« nĂ«n-sistemit tĂ« ruajtjes nĂ« tĂ«rĂ«si - veçanĂ«risht transaksionaliteti.

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

  • Rritje e madhe e kostove tĂ« licencave dhe mbĂ«shtetjes teknike nga prodhuesi i sistemit tĂ« menaxhimit tĂ« tĂ« dhĂ«nave.
  • ShpĂ«rndarja e stafit dhe rritja e afateve.
  • Humbe financiare direkte ose sanksione pĂ«r shkak tĂ« paqartĂ«sive tĂ« tĂ« dhĂ«nave.

Ka një rritje të konsiderueshme të kostos totale të pronësisë (TCO) të sistemit. A ka ndonjë dalje nga situata e "ruajtjes multi-opcionale"?

Multimodel

Termi "ruajtja multi-opcionale" hyri në përdorim në vitin 2011. Kuptimi i problemeve të këtij qasje dhe kërkimi i zgjidhjes zgjatën disa vite, dhe deri në vitin 2015 analistët e Gartner e formuluan përgjigjen:

Duket se këtë herë analistët e Gartner nuk gabuan në parashikimin. Nëse shkon në faqen me renditjen kryesore të DBMS-ve në DB-Engines, mund të shohish se shumica e liderëve e pozicionojnë veten pikërisht si DBMS me multimodelim. Të njëjtën gjë e sheh edhe në faqen me çdo renditje private.oNë tabelën më poshtë, janë listuar DBMS-të - liderët në çdo renditje private - që deklarojnë multimodelimin e tyre. Për çdo DBMS, është treguar modeli fillestar i mbështetur (i cili dikur ishte i vetmi) dhe përveç tij modelet që mbështeten tani. Gjithashtu janë përfshirë DBMS-të që pozicionojnë veten si "fillimisht multimodel" dhe nuk kanë, sipas pretendimeve të krijuesve, ndonjë model fillestar të trashëguar.

Modeli fillestar

DBMSModelet shtesëRelacional
OracleGrafik, dokumentarMS SQL
Grafik*, dokumentarGrafik, dokumentarMS SQL
PostgreSQLGrafik, dokumentarMarkLogic
DokumentarGrafik, relacionalÇelĂ«s-vlerĂ«, grafik*
MongoDBGrafik, relacionalDataStax
Kolona tĂ« gjeraDokumentar, grafikÇelĂ«s-vlerĂ«
RedisDokumentar, grafik*Grafik, dokumentar, relacional
ArangoDB—MS SQL
OrientDB—ShĂ«nime pĂ«r tabelĂ«n
Azure CosmosDB—ShĂ«nime pĂ«r tabelĂ«n

Yjet në tabelë shënojnë pohimet që kërkojnë sqarime:

DBMS PostgreSQL nuk mbështet modelin grafik të të dhënave, megjithatë ky produkt

Më pas për çdo klasë ne do të tregojmë se si implementohet mbështetje për disa modele në DBMS nga kjo klasë. Modelet më të rëndësishme do të konsiderohen ato relacionale, dokumentare dhe grafike, dhe do të ilustrohen me shembuj nga DBMS specifike për të treguar se si implementohen "modelet e mungesës".

Sistemat e menaxhimit të të dhënave multimodel në bazë të modelit relacion

DBMS kryesore aktualisht janë ato relacionale; parashikimi i Gartner nuk do të konsiderohej i realizuar nëse DBMS relacionale nuk do të tregonin lëvizje drejt multimodelit. Dhe ata po tregojnë. Tani konsideratat se një DBMS multimodel është si një thikë zvicerane, me të cilën nuk mund të bësh asgjë mirë, mund t'i drejtohen menjëherë Larry Ellison-it.

Autori, megjithatë, e preferon më shumë implementimin e multimodelit në Microsoft SQL Server, përmes shembullit të të cilit do të përshkruhet mbështetja për modelet dokumentare dhe grafike në DBMS relacionale.

Modeli dokumentar në MS SQL Server

Për mënyrën se si në MS SQL Server është implementuar mbështetje për modelin dokumentar, në Habrë janë publikuar dy artikuj të shkëlqyer, do të përmbahëm me 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 relacionale: dokumentet JSON propozohet të ruhen në fusha tekstuale të zakonshme. Mbështetja për modelin dokumentar përfshin ofrimin e operatorëve special për analizimin e këtij JSON:

  • JSON_VALUE pĂ«r nxjerrjen e vlerave skalarĂ« tĂ« atributeve,
  • JSON_QUERY pĂ«r nxjerrjen e nĂ«n-dokumenteve.

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

Në mënyrë abstrakte, mund të thuhet se dokumentet e ruajtur në këtë mënyrë nuk janë "entitete të klasës së parë" në DBMS relacionale, në krahasim me tuple-t. Konkretisht në MS SQL Server aktualisht mungojnë indekset mbi fushat e dokumenteve JSON, gjë që e bën të vështirë operacionet e bashkimit të tabelave sipas vlerave të këtyre fushave dhe madje nxjerrjen e dokumenteve sipas këtyre vlerave. Megjithatë, është e mundur të krijohet një kolonë e llogaritur mbi një fushë të tillë dhe të krijohet një indeks mbi të.

PĂ«rveç kĂ«saj, MS SQL Server ofron mundĂ«sinĂ« pĂ«r tĂ« ndĂ«rtuar lehtĂ«sisht njĂ« dokument JSON nga pĂ«rmbajtja e tabelave me ndihmĂ«n e operatorit FOR JSON PATH — mundĂ«si, nĂ« njĂ« sens tĂ« njohur, e kundĂ«rt me ruajtjen e zakonshme. ËshtĂ« e qartĂ« se sa do tĂ« shpejtĂ« tĂ« jetĂ« njĂ« RDBMS, ky qasje bie ndesh me ideologjinĂ« e DBMS-ve dokumentarĂ«, nĂ« thelb duke ruajtur pĂ«rgjigje tĂ« gatshme pĂ«r kĂ«rkesat populare, dhe mund tĂ« zgjidhĂ« vetĂ«m problemet e komfortit tĂ« zhvillimit, por jo tĂ« shpejtĂ«sisĂ«.

Në fund, MS SQL Server lejon të zgjidhet problemi, i kundërt me ndërtimin e dokumenteve: mund të shpërndash JSON në tabela duke përdorur OPENJSON. Nëse dokumenti nuk është krejtësisht i sheshtë, do të nevojitet të përdorësh MIRATIM.

Modeli grafik në MS SQL Server

Përkrahja e modelit grafik (LPG) është implementuar në Microsoft SQL Server gjithashtu në mënyrë të qartë parashikueshme: propozohet të përdoren tabela speciale për ruajtjen e nyjave dhe për ruajtjen e skajeve të grafikut. Të tilla tabela krijohen duke përdorur shprehjet CREATE TABLE AS NODE dhe CREATE TABLE AS EDGE përkatësisht.

Tabela e llojit tĂ« parĂ« janĂ« tĂ« ngjashme me tabelat normale pĂ«r ruajtjen e regjistrimeve me atĂ« vetĂ«m dallim ekstern, qĂ« nĂ« tabelĂ« ka fushĂ«n sistemike $node_id — identifikues unik brenda bazĂ«s sĂ« tĂ« dhĂ«nave pĂ«r nyjĂ«n e grafikut.

Në mënyrë të ngjashme, tabelat e llojit të dytë kanë fusha sistemike $from_id dhe $to_id, regjistrimet në këto tabela në mënyrë të qartë përcaktojnë lidhjet midis nyjave. Për ruajtjen e lidhjeve të secilit lloj përdoret një tabelë e veçantë.

Sistemet e shumëmodeleve të DBMS janë thelbi i sistemeve informative moderne? Le të ilustrojmë atë që u tha me një shembull. Le të themi se të dhënat grafike kanë skemën 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 nevojitet të kryhen kërkesat DDL si vijon:

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);

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 (ndonëse, "*" etj. ende nuk mbështeten). Bazuar në matjet e performancës, mund të supozohet gjithashtu se mënyra e ruajtjes së të dhënave në këto tabela është ndryshe nga mekanizmi i ruajtjes së të dhënave në tabelat normale dhe optimizuar për kryerjen e kërkesave të tilla grafike.

SELECT Cafe.name
  FROM Person, likes, Cafe
  WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
  AND Person.name = 'John';

Për më tepër, është mjaft e vështirë të mos përdoren këto modele grafike kur punoni me tabela të tilla, pasi në kërkesat e zakonshme SQL për të zgjidhur detyra të ngjashme do të nevojiten përpjekje të shtuara për të marrë identifikuesit sistemikë të "grafik" të nyjave ($node_id, $from_id, $to_id; për këtë arsye, kërkesat për futjen e të dhënave nuk janë përfshirë këtu si tepër të ngarkuara).

Duke përmbledhur përshkrimin e zbatimeve të modeleve dokumentare dhe grafike në MS SQL Server, do të theksoja se zbatimi i tillë i një modeli mbi një tjetër nuk duket i suksesshëm kryesisht nga pikëpamja e dizajnit gjuhësor. Një gjuhë duhet të zgjerojë një tjetër, gjuhët nuk janë krejtësisht "ortogonale", rregullat e kombinoshmërisë mund të jenë mjaft të çuditshme.

Sistemat e menaxhimit të të dhënave multimodel në bazë të modelit dokumentar

NĂ« kĂ«tĂ« seksion do tĂ« dĂ«shiroja tĂ« ilustroja realizimin e multimodelitetit nĂ« DBMS dokumentar duke marrĂ« si shembull njĂ« nga DBMS mĂ« tĂ« njohura, MongoDB (siç u tha, ajo ka vetĂ«m operatorĂ« grafike tĂ« kushtezuar, $graphLookup dhe ), se sa pĂ«r mbĂ«shtetje tĂ« modelit grafik, megjithatĂ«, sigurisht, futja e tyre kĂ«rkonte disa optimizime nĂ« nivelin e ruajtjes fizike nĂ« drejtimin e mbĂ«shtetjes sĂ« modelit grafik.tĂ« cilĂ«t nuk punojnĂ« nĂ« koleksione tĂ« ndara), pĂ«rmes njĂ« DBMS mĂ« tĂ« pjekur dhe "enterpriz“ Dokumentar.

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

John
  Smith

Modeli relacion në MarkLogic

Prezantimi relacional i koleksionit të dokumenteve mund të krijohet me anë të shembujve të mënyrës (përmbajtja e elementeve vlera në shembullin më poshtë mund të jetë një XPath i çfarëdo lloji):

/Person
  
    
      Person
      
        
          SSN
          @SSN
          string
        
        
          name
          name
        
        
          surname
          surname

Kërkesa SQL mund të drejtohet në pamjen e krijuar (për shembull, përmes ODBC):

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

Fatkeqësisht, pamja relacional e krijuar me anë të shembujve të mënyrës është vetëm për lexim. Kur për të trajtuar një kërkesë ndaj saj, MarkLogic do të përpiqet të përdorë indeksat dokumentarë.Më parë, MarkLogic kishte edhe pamje relacionale të kufizuara, krejtësisht të bazuara në indekse dhe të aksesueshme për shkrim, por tani ato konsiderohen të përdorura.

Modeli grafik në MarkLogic

Me mbështetje të modelit grafor (RDF), gjithçka është në mënyrë të ngjashme. Sërish me ndihmën e shembujve të mënyrës mund të krijoni një përfaqësim 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 )

Në grafikun RDF të marrë, mund të adresoni një kërkesë SPARQL:

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

Në krahasim me modelin relacional, modelin grafor MarkLogic e mbështet edhe në dy mënyra të tjera:

  1. DBMS mund të jetë një depo e plotë e dhënash RDF (tripletët do të quhen managed në krahasim me ato të përshkruara më sipër extracted).
  2. RDF në një serializim të veçantë mund të futur thjesht në dokumente XML ose JSON (dhe tripletët do të quhen unmanaged). Ndërkaq, kjo është një alternativë ndaj mekanizmave idref Lidhja e këtyre instancave të predicate-ve me predicate-n e përgjithshëm vendoset me tripleta të tipit

NjĂ« pĂ«rfaqĂ«sim i mirĂ« se si "e vĂ«rteta" funksionon nĂ« MarkLogic jep Optic API, nĂ« kĂ«tĂ« sens Ă«shtĂ« me nivel tĂ« ulĂ«t, megjithĂ«se qĂ«llimi i tij Ă«shtĂ« pikĂ«risht i kundĂ«rt — tĂ« provojĂ« tĂ« abstenojĂ« nga modeli i dhĂ«nash tĂ« pĂ«rdorur, tĂ« sigurojĂ« njĂ« funksionim tĂ« qĂ«ndrueshĂ«m me tĂ« dhĂ«nat nĂ« modele tĂ« ndryshme, transaksionalitetin etj.

Sistemat e menaxhimit të të dhënave multimodel "pa model të bazës"

Në treg janë gjithashtu DBMS që pozicionohen si fillimisht multimodale, pa ndonjë model të trashëguar. Një numër i tillë përfshin ArangoDB, OrientDB (që nga 2018, kompania zhvillues është në pronësi të SAP) dhe CosmosDB (shërbimi si pjesë e platformës së re cloud të Microsoft Azure).

Në të vërtetë "modelet kryesore" në ArangoDB dhe OrientDB ekzistojnë. Kjo është njësoj për të dy rastet, modelet e dhënash janë të tipit të tyre, duke u bërë përmbledhje të modelit dokumentar. Përmbledhjet përfshijnë kryesisht lehtësimin e mundësive për të kryer kërkesa me natyrë grafike dhe relacional.

Këto modele janë të vetmet të disponueshme për përdorim në SGBD-të e përmendura, për të punuar me to janë të dedikuar gjuhët e tyre të kërkimit. Pa dyshim, këto modele dhe SGBD-të janë të perspektivë, megjithatë mungesa e përputhshmërisë me modelet dhe gjuhët standarde e bën të pamundur përdorimin e këtyre SGBD-ve në sistemet e trashëguara - zëvendësimin e SGBD-ve që janë tashmë të përdorura atje.

Për ArangoDB dhe OrientDB në Habr kishte një artikull të mrekullueshëm: JOIN në bazat e të dhënave NoSQL.

ArangoDB

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

Nodet e grafit në ArangoDB janë dokumente të zakonshme, ndërsa skajet janë dokumente të natyrës speciale, që kanë përveç fushave të zakonshme sistemore (_key, _id, _rev) fusha sistemore _from dhe _to. Dokumentet në SGBD-të dokumentare tradicionalisht grumbullohen në koleksione. Koleksionet e dokumenteve që përfaqësojnë skajet në ArangoDB quhen koleksione edge. Për ta thënë ndryshe, dokumentet e koleksioneve edge janë gjithashtu dokumente, kështu që skajet në ArangoDB mund të shërbejnë gjithashtu si nodet.

Të dhënat burimore

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

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

Le të ketë gjithashtu një koleksion cafes:

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

Atëherë koleksioni likes mund të duket si më poshtë:

[
  {
    "_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 grafik në gjuhën e përdorur në ArangoDB, që kthehet në një format të lexueshëm për njerëzit rreth atyre 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 thjesht "llogarisim" lidhjet, përndryshe i ruajmë ato, kjo kërkesë mund të ri-shkruhet kështu (përfshirë, pa koleksionin likes mund të binim dakord):

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ë dy rastet do të jetë i njëjtë:

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

Kërkesa të tjera dhe rezultate

Nëse duket se formati i rezultatit më sipër është më karakteristik për një DBMS relacional sesa për një dokument, mund të provoni këtë kërkesë (ose mund të përdorni KOPJO):

PËR p NË persona
  KTHIM {
    person : p.emri,
    pëlqime : (
      PËR c NË DALJ p pĂ«lqime
      KTHIM c.emri
    )
}

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

[
  { "person" : "Alicia" , pëlqime : ["Jean-Jacques" , "John Donne"]  } ,
  { "person" : "Bob" , pëlqime : ["John Donne"] }
]

OrientDB

NĂ« themel tĂ« implementimit tĂ« modelit grafik mbi dokumentar nĂ« OrientDB qĂ«ndron mundĂ«sia fushat e dokumenteve tĂ« kenĂ« pĂ«rveç vlerave mĂ« tĂ« zakonshme skalar mĂ« shumĂ« edhe vlera tĂ« tilla si LINK, LISTA LINK, GRUPE LINK, MAP LINK dhe ÇANTË LINK. Vlerat e kĂ«tyre tipeve janĂ« lidhje ose koleksione lidhjesh pĂ«r identifikuesit e sistemit dokumenteve.

Identifikuesi i caktuar nga sistemi për dokumentin ka "kuptim fizik", duke treguar pozitën e regjistrimit në bazë, dhe duket përafërsisht kështu: @rid : #3:16. Kështu, vlerat e vetive lidhëse janë në të vërtetë më shumë tregues (si në modelin grafik), sesa kushte për filtrin (si në relacional).

Si në ArangoDB, në OrientDB, skellet paraqiten si dokumente të veçanta (ndonëse nëse skela nuk ka vetitë e saj, mund ta bëni më të lehta, dhe nuk do t'i përkasë një dokumenti të veçantë).

Të dhënat burimore

Në një format që iu afron formatit të dump-it të bazës OrientDB, të dhënat nga shembulli i mëparshëm për ArangoDB do të duken përafërsisht kështu:

[
     {
      "@tip": "dokument",
      "@rid": "#11:0",
      "@klasa": "Person",
      "emri": "Alicia",
      "dalje_pëlqime": [
        "#30:1",
        "#30:2"
      ],
      "@tipet_e_fushĂ«s": "dalje_pĂ«lqime=ÇANTË LINK"
    },
    {
      "@tip": "dokument",
      "@rid": "#12:0",
      "@klasa": "Person",
      "emri": "Bob",
      "dalje_pëlqime": [
        "#30:3"
      ],
      "@tipet_e_fushĂ«s": "dalje_pĂ«lqime=ÇANTË LINK"
    },
    {
      "@tip": "dokument",
      "@rid": "#21:0",
      "@klasa": "Cafe",
      "emri": "Jean-Jacques",
      "në_pëlqime": [
        "#30:2",
        "#30:3"
      ],
      "@tipet_e_fushĂ«s": "nĂ«_pĂ«lqime=ÇANTË LINK"
    },
    {
      "@tip": "dokument",
      "@rid": "#22:0",
      "@klasa": "Cafe",
      "emri": "John Donne",
      "në_pëlqime": [
        "#30:1"
      ],
      "@tipet_e_fushĂ«s": "nĂ«_pĂ«lqime=ÇANTË LINK"
    },
    {
      "@tip": "dokument",
      "@rid": "#30:1",
      "@klasa": "pëlqime",
      "në": "#22:0",
      "dalje": "#11:0",
      "që nga": 1262286000000,
      "@tipet_e_fushës": "në=LINK,dashuri=LINK,që nga=data"
    },
    {
      "@tip": "dokument",
      "@rid": "#30:2",
      "@klasa": "pëlqime",
      "në": "#21:0",
      "dalje": "#11:0",
      "që nga": 1293822000000,
      "@tipet_e_fushës": "në=LINK,dashuri=LINK,që nga=data"
    },
    {
      "@tip": "dokument",
      "@rid": "#30:3",
      "@klasa": "pëlqime",
      "në": "#21:0",
      "dalje": "#12:0",
      "që nga": 1325354400000,
      "@tipet_e_fushës": "në=LINK,dashuri=LINK,që nga=data"
    }
  ]

Siç e shohim, kulmet ruajnë gjithashtu informacione mbi skellet e hyra dhe të dalë. Në përdorimi API i Dokumenteve për ruajtjen e integritetit referencial kërkon monitorim të vet, ndërsa Graph API e merr këtë punë mbi vete. Le të shohim se si duken thirrjet në OrientDB në gjuhët e pyetjeve "të pastra", të paintegruara në gjuhët e programimit.

KĂ«rkesat dhe rezultatet

Një pyetje, e ngjashme me qëllimin e pyetjes nga shembulli 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ë të njëjtën formë:

[
  { "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 tepër "relacionar", është e nevojshme të hiqni rreshtin me UNWIND():

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

Gjuha e pyetjeve të OrientDB mund të përshkruhet si SQL me implikime të ngjashme me Gremlin. Në versionin 2.2 u shfaq një formë pyetjeje 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ë pyetjen e mëparshme. Mendoni se çfarë duhet hequr për ta bërë atë më "relacionar", si në pyetjen e parë.

Azure CosmosDB

Më pak sa i përket ArangoDB dhe OrientDB, kjo përfshin Azure CosmosDB. CosmosDB ofron API të ndryshëm për qasjen në të dhëna: SQL, MongoDB, Gremlin dhe Cassandra.

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

Sistemet e shumëmodeleve të DBMS janë thelbi i sistemeve informative moderne?

Por modeli i të dhënave të zgjedhur nga përdoruesi dhe API e përdorur fiksohen në momentin e krijimit të llogarisë në shërbim. Nuk është e mundur të aksesoni të dhënat e ngarkuara në një model, në formatin e një modeli tjetër, që do të ilustrohej më pak më këtë figurë:

Sistemet e shumëmodeleve të DBMS janë thelbi i sistemeve informative moderne?

Kështu, multimodeliteti në Azure CosmosDB deri më sot paraqet vetëm mundësinë për të përdorur disa baza të dhënash që mbështesin modele të ndryshme nga një prodhues, që nuk e zgjidh të gjitha problemet e ruajtjes multivariant.

Sistemat e menaxhimit të të dhënave multimodel në bazë të modelit grafik?

Vlen të theksohet se në treg ende nuk ka DBMS multimodel që ka si bazë modelin grafik (përveç mbështetjes multimodel për njëkohësisht dy modele grafike: RDF dhe LPG; shih për këtë në publikimit të mëparshëm). Realizimi mbi një model grafik dokumentar dhe jo relacional paraqet pengesat më të mëdha.

Çështja se si tĂ« realizohet mbi njĂ« model grafik njĂ« relacional Ă«shtĂ« shqyrtuar qĂ« nga kohĂ«t e formimit tĂ« kĂ«tij tĂ« fundit. Si nga, pĂ«r shembull, David McGovern:

Nuk ka asgjë të natyrshme në qasjen grafike që e pengon krijimin e një shtrese (p.sh., me indeksimin e duhur) mbi një bazë të dhënash grafike që lejon një pamje relacional me (1) shërimin e tupleve nga çiftet e zakonshëm të çelësit dhe (2) grupimin e tupleve sipas llojit të marrëdhënies.

Kur realizohet modeli dokumentar mbi grafik duhet të kihet parasysh, për shembull, e suivantes:

  • Elementet e masĂ«s JSON konsiderohen tĂ« renditura, dalin nga maja e skelĂ«s grafike — jo;
  • TĂ« dhĂ«nat nĂ« modelin dokumentar zakonisht janĂ« denormalizuar, nuk dĂ«shirojmĂ« tĂ« ruajmĂ« disa kopje tĂ« njĂ« dokumenti tĂ« njĂ«jtĂ« tĂ« ndĂ«rlikuar, ndĂ«rsa identifikuesit e nĂ«n-dokumenteve zakonisht nuk ekzistojnĂ«;
  • Nga ana tjetĂ«r, ideologjia e DBMS-ve dokumentar Ă«shtĂ« se dokumentet janĂ« 'agregate' tĂ« gatshme qĂ« nuk kanĂ« nevojĂ« tĂ« ndĂ«rtohen rishtazi çdo herĂ«. Duhet tĂ« sigurohet nĂ« modelin grafik mundĂ«sia pĂ«r tĂ« marrĂ« shpejt njĂ« nĂ«ngraf qĂ« i pĂ«rgjigjet dokumentit tĂ« gatshĂ«m.

Pak reklame

Autori i artikullit ka lidhje me zhvillimin e DBMS-sĂ« NitrosBase, modeli i brendshĂ«m i sĂ« cilĂ«s Ă«shtĂ« grafik, ndĂ«rsa modelet e jashtme — relacional dhe dokumentar — janĂ« pĂ«rfaqĂ«simet e saj. TĂ« gjitha modelet janĂ« tĂ« barabarta: pothuajse çdo tĂ« dhĂ«nĂ« Ă«shtĂ« e aksesueshme nĂ« secilĂ«n prej tyre duke pĂ«rdorur gjuhĂ«n e saj natyrore tĂ« kĂ«rkimeve. PĂ«r mĂ« tepĂ«r, nĂ« çdo pĂ«rfaqĂ«sim tĂ« dhĂ«nat mund tĂ« ndryshohen. Ndryshimet do tĂ« reflektohen nĂ« modelin e brendshĂ«m dhe, pĂ«rkatĂ«sisht, nĂ« pĂ«rfaqĂ«simet e tjera.

Si duket pĂ«rputhja e modeleve nĂ« NitrosBase — shpresoj ta pĂ«rshkruaj nĂ« njĂ« nga artikujt e ardhshĂ«m.

PĂ«rfundim

Shpresoj qĂ« konturat e pĂ«rgjithshme tĂ« asaj qĂ« quhet multimodeli, t’i jenĂ« bĂ«rĂ« lexuesit mĂ« shumĂ« ose mĂ« pak tĂ« qarta. DBMS-tĂ« multimodel janĂ« mjaft tĂ« ndryshme, dhe 'mbĂ«shtetja e disa modeleve' mund tĂ« duket ndryshe. PĂ«r tĂ« kuptuar atĂ« qĂ« quhet 'multimodeli' nĂ« çdo rast konkret, Ă«shtĂ« e dobishme tĂ« pĂ«rgjigjet nĂ« pyetjet e mĂ«poshtme:

  1. A bëhet fjalë për mbështetje të modeleve tradicionale apo për një 'model hibrid'?
  2. A janë modelet 'të barabarta', apo njëra prej tyre është nënorin për të tjerat?
  3. A janë modelet indiferente ndaj njëra-tjetrës? A mund të lexohen të dhënat e shkruara në një model në një tjetër ose madje të përsëriten?

Mendoj se tani mund të japim një përgjigje pozitive për pyetjen mbi rëndësinë e DBMS-ve multimonedha, por është interesante të dimë se cilat lloje të tyre do të jenë më të kërkuara në të ardhmen e afërt. Duke dukur se DBMS-të multimonedha që mbështesin modelet tradicionale, së pari ato relacionale, do të jenë më të kërkuara; popullariteti i DBMS-ve multimonedha që ofrojnë modele të reja, duke kombinuar përfitimet e disa tradicionaleve, është një çështje më e largët.

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

A përdorni DBMS multimonedha?

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

  • PĂ«rdorim mundĂ«sitĂ« multimonedha tĂ« DBMS-ve tradicionale.

  • PraktikojmĂ« ruajtjen shumĂ«variantĂ«sh (polyglot persistence).

  • PĂ«rdorim DBMS tĂ« reja multimonedha (Arango, Orient, CosmosDB).

19 përdorues votuan. 4 përdorues u abstenuan.

Burimi: habr.com

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