Sistem informasi modern cukup rumit. Teu saeutik, pajeulitna maranéhanana alatan pajeulitna data diolah di aranjeunna. Pajeulitna data sering aya dina rupa-rupa model data anu digunakeun. Janten, contona, nalika data janten "badag", salah sahiji ciri masalah henteu ngan ukur volumena ("volume"), tapi ogé ragamna ("ragam").

Upami anjeun henteu acan mendakan cacad dina nalar, teras baca.

eusi

Polyglot kegigihan
Multi-model
Multi-model DBMS dumasar kana model relational
     Modél dokumén dina MS SQL Server
     Modél grafik dina MS SQL Server
Multi-model DBMS dumasar kana model dokumén
     Modél Relational di MarkLogic
     Modél grafik dina MarkLogic
Multi-model DBMS "tanpa modél utama"
     ArangoDB
     OrientDB
     Azure CosmosDB
Multi-model DBMS dumasar kana model grafik?
kacindekan
tatanyaan

Polyglot kegigihan

Di luhur ngabalukarkeun kanyataan yén sok sanajan dina kerangka hiji sistem perlu ngagunakeun sababaraha DBMSs béda pikeun nyimpen data sarta ngajawab sagala rupa masalah ngolah aranjeunna, nu masing-masing ngarojong model data sorangan. Kalayan panangan cahaya M. Fowler, pangarang sababaraha buku kawentar tur salah sahiji pangarang babarengan Manifesto tangkas, kaayaan ieu disebut gudang multi-varian ("kegigihan polyglot").

Fowler ogé gaduh conto di handap ieu pikeun ngatur panyimpen data dina aplikasi anu lengkep sareng beban tinggi dina widang e-commerce.

Conto ieu, tangtosna, rada kaleuleuwihi, tapi sababaraha pertimbangan pikeun milih hiji atanapi anu sanés DBMS pikeun tujuan anu saluyu tiasa dipendakan, contona, di dieu.

Jelas yén janten abdi di kebon binatang sapertos kitu henteu gampang.

Jumlah kode nu ngalakukeun neundeun data tumuwuh saimbang jeung jumlah DBMSs dipaké; jumlah kode nyingkronkeun data téh alus lamun teu sabanding jeung kuadrat angka ieu.
Salaku kakalian tina jumlah DBMS dipaké, waragad nyadiakeun ciri perusahaan (scalability, kasabaran sesar, kasadiaan tinggi) unggal DBMS dipaké naek.
Teu mungkin pikeun mastikeun ciri perusahaan tina subsistem gudang sacara gembleng - khususna transactionality.

Tina sudut pandang sutradara kebon binatang, sadayana sapertos kieu:

Paningkatan sababaraha biaya lisénsi sareng dukungan téknis ti produsén DBMS.
Overstaffing sarta ngaronjat deadlines.
Karugian finansial langsung atanapi hukuman alatan inconsistency data.

Aya paningkatan anu signifikan dina total biaya kapamilikan sistem (TCO). Aya jalan kaluar tina kaayaan "sababaraha pilihan gudang"?

Multi-model

Istilah "panyimpenan multivariat" mimiti dianggo dina taun 2011. Kasadaran ngeunaan masalah pendekatan sareng milarian solusi nyandak sababaraha taun, sareng ku 2015, ngalangkungan mulut analis Gartner, jawabanna dirumuskeun:

ti"Pituduh Pasar pikeun NoSQL DBMSs - 2015»:

Masa depan DBMS, arsitéktur sareng cara ngagunakeunana nyaéta multi-modél.
ti"Magic Quadrant pikeun ODBMS - 2016»:

DBMS operasional ngarah bakal nawiskeun sababaraha model-relasional jeung non-relational-salaku bagian tina platform tunggal.

Sigana waktos ieu analis Gartner leres sareng ramalanna. Lamun buka kaca kalawan rating utama DBMS on DB-Engines, anjeun tiasa ningali étaоSeuseueurna pamimpinna ngaposisikeun dirina sacara khusus salaku DBMS multi-model. Hal anu sami tiasa ditingali dina halaman kalayan rating pribadi.

Tabel di handap nembongkeun DBMS - pamingpin di unggal ratings swasta, nu ngaku multi-model. Pikeun unggal DBMS, modél anu dirojong asli (anu ngan ukur hiji) sareng sareng modél anu ayeuna dirojong dituduhkeun. Didaptarkeun ogé DBMS anu nempatkeun dirina salaku "aslina multi-model" sareng, numutkeun panyipta, henteu ngagaduhan modél warisan awal.

DBMS	Modél awal	Modél tambahan
Oracle	Relasional	Grafik, dokumén
MS SQL	Relasional	Grafik, dokumén
PostgreSQL	Relasional	Grafik*, dokumén
MarkLogic	Dokumenter	Grafik, rélasional
MongoDB	Dokumenter	Nilai konci, grafik*
DataStax	Lega-kolom	Dokuménter, grafik
Redis	Key-nilai	Dokuméntasi, grafik*
ArangoDB	-	Grafik, dokumén
OrientDB	-	Grafik, dokumén, relasional
Azure CosmosDB	-	Grafik, dokumén, relasional

Catetan dina méja

Tanda bintang dina pernyataan tanda tabel anu peryogi reservasi:

DBMS PostgreSQL henteu ngadukung modél data grafik, tapi produk ieu ngadukung éta dumasar kana eta, sapertos AgensGraph.
Dina hubunganana sareng MongoDB, langkung leres nyarios ngeunaan ayana operator grafik dina basa query ($lookup, $graphLookup) ti ngeunaan ngarojong model grafik, sanajan, tangtosna, bubuka maranéhna diperlukeun sababaraha optimizations di tingkat gudang fisik dina arah ngarojong model grafik.
Dina hubungan Redis, urang hartosna extension RedisGraph.

Salajengna, pikeun unggal kelas, urang bakal nunjukkeun kumaha dukungan pikeun sababaraha modél dilaksanakeun dina DBMS ti kelas ieu. Urang bakal nganggap model relational, dokumén jeung grafik anu pangpentingna sarta ngagunakeun conto DBMS husus pikeun nembongkeun kumaha "leuwih leungit" anu dilaksanakeun.

Multi-model DBMS dumasar kana model relational

DBMSs ngarah ayeuna relational; ramalan Gartner urang teu bisa dianggap bener lamun RDBMSs teu némbongkeun gerakan dina arah multi-modeling. Sareng aranjeunna nunjukkeun. Ayeuna pamanggih yén multi-model DBMS téh kawas péso Swiss, nu teu bisa ngalakukeun nanaon ogé, bisa diarahkeun langsung ka Larry Ellison.

Nu nulis, kumaha oge, prefers palaksanaan multi-modeling di Microsoft SQL Server, dina conto nu RDBMS rojongan pikeun dokumén jeung grafik model bakal dijelaskeun.

Modél dokumén dina MS SQL Server

Parantos aya dua tulisan anu saé ngeunaan Habré ngeunaan kumaha MS SQL Server ngalaksanakeun dukungan pikeun modél dokumén; Kuring bakal ngabatesan diri pikeun nyarioskeun deui sareng koméntar ringkes:

Cara pikeun ngadukung modél dokumén dina MS SQL Server cukup khas pikeun DBMS relasional: dokumén JSON diusulkeun pikeun disimpen dina widang téks biasa. Rojongan pikeun modél dokumén nyaéta nyayogikeun operator khusus pikeun ngémutan JSON ieu:

JSON_VALUE pikeun nimba nilai atribut skalar,
JSON_QUERY pikeun nimba sub-dokumen.

Argumen kadua duanana operator mangrupa éksprési dina JSONPath-kawas sintaksis.

Sacara abstrak, urang tiasa nyarios yén dokumén anu disimpen ku cara ieu sanés "éntitas kelas munggaran" dina DBMS relasional, teu sapertos tuples. Husus, dina MS SQL Server ayeuna teu aya indéks dina widang dokumén JSON, nu ngajadikeun hésé pikeun gabung tabel ngagunakeun nilai widang ieu komo milih dokumén ngagunakeun nilai ieu. Sanajan kitu, kasebut nyaéta dimungkinkeun pikeun nyieun kolom diitung keur widang sapertos na hiji indéks dina eta.

Salaku tambahan, MS SQL Server nyayogikeun kamampuan pikeun ngawangun dokumen JSON tina eusi tabel nganggo operator. FOR JSON PATH - kamungkinan, dina rasa nu tangtu, sabalikna ti saméméhna, gudang konvensional. Ieu jelas yén euweuh urusan sabaraha gancang hiji RDBMS, pendekatan ieu contradicts idéologi dokumen DBMSs, nu dasarna nyimpen jawaban siap-dijieun pikeun queries populér, sarta ngan bisa ngajawab masalah betah ngembangkeun, tapi teu speed.

Tungtungna, MS SQL Server ngidinan Anjeun pikeun ngajawab masalah tibalik tina konstruksi dokumén: Anjeun bisa decompose JSON kana tabel ngagunakeun OPENJSON. Upami dokumenna henteu lengkep datar, anjeun kedah nganggo CROSS APPLY.

Modél grafik dina MS SQL Server

Rojongan pikeun model grafik (LPG) ogé pinuh dilaksanakeun dina Microsoft SQL Server bisa diprediksi: Disarankeun ngagunakeun tabel husus pikeun nyimpen titik jeung nyimpen edges grafik. tabél sapertos dijieun maké éksprési CREATE TABLE AS NODE и CREATE TABLE AS EDGE sasuai.

Tabél tipe kahiji sami sareng tabel biasa pikeun nyimpen rékaman, ngan ukur bédana éksternal nyaéta méja ngandung médan sistem. $node_id - identifier unik tina titik grafik dina database.

Nya kitu, tabel tipe kadua boga widang sistem $from_id и $to_id, éntri dina tabel sapertos jelas nangtukeun sambungan antara titik. A tabel misah dipaké pikeun nyimpen hubungan unggal jenis.

Hayu urang ngagambarkeun ieu ku conto. Hayu data grafik boga perenah kawas hiji ditémbongkeun dina gambar. Teras pikeun nyiptakeun struktur anu aya dina pangkalan data anjeun kedah ngajalankeun patarosan DDL ieu:

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

Spésifisitas utama tabel sapertos kitu nyaéta dina patarosan ngalawan aranjeunna tiasa nganggo pola grafik kalayan sintaksis sapertos Cypher (tapi, "*"jeung sajabana teu acan didukung). Dumasar ukuran kinerja, éta ogé bisa dianggap yén cara data disimpen dina tabel ieu béda ti cara data disimpen dina tabel biasa na dioptimalkeun pikeun executing queries grafik misalna.

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

Leuwih ti éta, rada hese henteu nganggo pola grafik ieu nalika damel sareng tabel sapertos kitu, sabab dina query SQL biasa pikeun ngabéréskeun masalah anu sami bakal peryogi usaha tambahan pikeun kéngingkeun identifier titik "grafik" sistem ($node_id, $from_id, $to_id; Pikeun alesan anu sarua, queries pikeun inserting data teu ditémbongkeun di dieu sabab unnecessarily bagong).

Pikeun nyimpulkeun katerangan ngeunaan palaksanaan model dokumen sareng grafik dina MS SQL Server, kuring bakal dicatet yén palaksanaan sapertos hiji modél di luhur sanés sigana henteu suksés, utamina tina sudut pandang desain basa. Perlu manjangkeun hiji basa sareng anu sanés, basa-basana henteu lengkep "ortogonal", aturan kasaluyuan tiasa rada anéh.

Multi-model DBMS dumasar kana model dokumén

Dina bagian ieu, abdi hoyong ngagambarkeun palaksanaan multi-modél dina DBMSs dokumén ngagunakeun conto teu pang populerna di antarana, MongoDB (sakumaha ieu ceuk, éta ngan boga operator grafik kondisional. $lookup и $graphLookup, henteu dianggo dina kumpulan beling), tapi nganggo conto DBMS anu langkung dewasa sareng "perusahaan" MarkLogic.

Janten, hayu koleksi ngandung sakumpulan dokumén XML tina jinis ieu (MarkLogic ogé ngamungkinkeun anjeun pikeun nyimpen dokumén JSON):

<Person INN="631803299804">
  <name>John</name>
  <surname>Smith</surname>
</Person>

Modél Relational di MarkLogic

A view relational tina kumpulan dokumén bisa dijieun maké tampilan template (eusi unsur value dina conto di handap tiasa aya XPath sawenang):

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

Anjeun tiasa alamat panempoan dijieun ku query SQL (contona, via ODBC):

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

Hanjakalna, pintonan relasional anu diciptakeun ku citakan tampilan ngan ukur dibaca. Nalika ngolah pamundut éta, MarkLogic bakal nyobian nganggo indéks dokumén. Saméméhna, MarkLogic kagungan pintonan relational kawates, sagemblengna indéks dumasar sarta bisa ditulis, tapi ayeuna maranéhna dianggap deprecated.

Modél grafik dina MarkLogic

Kalayan dukungan pikeun modél grafik (RDF), sadayana sami. Deui kalayan pitulung tampilan template Anjeun tiasa ngadamel perwakilan RDF tina kumpulan dokumén tina conto di luhur:

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

Anjeun tiasa alamat grafik RDF anu dihasilkeun ku pamundut SPARQL:

PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
  :631803299804 :name ?name ; :surname ?surname .
}

Beda sareng rélasional, MarkLogic ngadukung modél grafik ku dua cara:

DBMS tiasa janten panyimpen data RDF lengkep lengkep (triplets di jerona bakal disebut junun kontras jeung pamadegan di luhur sasari).
RDF dina serialization husus bisa saukur diasupkeun kana dokumén XML atawa JSON (jeung triplets lajeng bakal disebut. henteu diatur). Ieu meureun alternatif pikeun mékanisme idref jeung saterusna.

Ide anu sae kumaha hal-hal anu "saleresna" jalanna di MarkLogic dipasihkeun ku API optik, Dina rasa ieu, éta low-tingkat, sanajan tujuanana rada sabalikna - nyoba abstrak tina model data dipaké, pikeun mastikeun karya konsisten kalayan data dina model béda, transactionality, jsb.

Multi-model DBMS "tanpa modél utama"

Aya ogé DBMS di pasar anu nempatkeun diri salaku mimitina multi-modél, tanpa model utama anu diwariskeun. Ieu kaasup ArangoDB, OrientDB (saprak 2018 parusahaan ngembangkeun milik SAP) jeung CosmosDB (jasa salaku bagian tina platform awan Microsoft Azure).

Nyatana, aya modél "inti" dina ArangoDB sareng OrientDB. Dina duanana kasus, ieu model data sorangan, nu generalisasi tina hiji dokumen. Generalisasi utamana pikeun ngagampangkeun kamampuhan pikeun ngalakukeun queries tina grafik jeung alam relational.

Modél ieu mangrupikeun hiji-hijina anu sayogi pikeun dianggo dina DBMS anu ditangtukeun; basa query sorangan dirancang pikeun dianggo sareng aranjeunna. Tangtosna, modél sareng DBMS sapertos kitu ngajangjikeun, tapi kurangna kasaluyuan sareng modél standar sareng basa ngajantenkeun teu mungkin ngagunakeun DBMS ieu dina sistem warisan-pikeun ngagentos DBMS anu parantos dianggo di dinya.

Geus aya tulisan anu saé ngeunaan ArangoDB sareng OrientDB on Habré: JOIN dina database NoSQL.

ArangoDB

ArangoDB nyatakeun dukungan pikeun modél data grafik.

Titik-titik grafik dina ArangoDB mangrupikeun dokumén biasa, sareng ujung-ujungna mangrupikeun dokumén tina jinis khusus anu, sareng widang sistem biasa, gaduh (_key, _id, _rev) widang sistem _from и _to. Dokumén dina dokumén DBMS sacara tradisional digabungkeun kana kumpulan. Koléksi dokumén anu ngalambangkeun tepi disebut koléksi tepi di ArangoDB. Ku jalan kitu, dokumén koleksi tepi ogé dokumén, jadi edges di ArangoDB ogé bisa meta salaku titik.

Sumber data

Hayu urang gaduh koleksi persons, anu dokuménna siga kieu:

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "Алиса"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Боб"  
  }
]

Hayu aya ogé kumpulan cafes:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "Джон Донн"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Жан-Жак"
  }
]

Lajeng ngumpulkeun likes sigana siga kieu:

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

Patarosan jeung hasil

Paménta gaya grafik dina basa AQL anu dianggo dina ArangoDB, uih deui dina inpormasi bentuk anu tiasa dibaca manusa ngeunaan saha anu resep kafe mana, sapertos kieu:

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

Dina gaya relasional, dimana urang "ngitung" hubungan tinimbang nyimpen éta, pamundut ieu tiasa ditulis deui sapertos kieu (ku jalan kitu, tanpa koleksi likes bisa ngalakukeun tanpa):

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 }

Hasilna dina dua kasus bakal sami:

[
  { "person" : "Алиса" , likes : "Жан-Жак" } ,
  { "person" : "Алиса" , likes : "Джон Донн" } ,
  { "person" : "Боб" , likes : "Джон Донн" }
]

Langkung seueur patarosan sareng hasil

Upami format hasil di luhur sigana langkung khas pikeun DBMS relasional tibatan DBMS dokumen, anjeun tiasa nyobian pamundut ieu (atanapi anjeun tiasa nganggo COLLECT):

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

hasilna bakal kasampak kawas kieu:

[
  { "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"]  } ,
  { "person" : "Боб" , likes : ["Джон Донн"] }
]

OrientDB

Dasar pikeun nerapkeun modél grafik dina luhureun modél dokumén dina OrientDB nyaéta kasempetan widang dokumen, salian leuwih atawa kirang nilai skalar baku, ogé mibanda nilai tipe kayaning LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Nilai-nilai tina jinis ieu mangrupikeun tautan atanapi kumpulan tautan ka identifiers Sistim dokumén.

Identifier dokumen anu ditugaskeun ku sistem ngagaduhan "harti fisik", nunjukkeun posisi catetan dina pangkalan data, sareng sapertos kieu: @rid : #3:16. Ku kituna, nilai sipat rujukan bener pointers (saperti dina model grafik) tinimbang kaayaan pilihan (saperti dina model relational).

Kawas ArangoDB, edges di OrientDB digambarkeun salaku dokumén misah (sanajan lamun an edge teu mibanda sipat sorangan, éta bisa dijieun. hampang, sarta eta moal pakait jeung dokumen misah).

Sumber data

Dina format deukeut format dump Database OrientDB, data tina conto sateuacana pikeun ArangoDB bakal katingali sapertos kieu:

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

Sakumaha urang tiasa tingali, vertex ogé nyimpen inpormasi ngeunaan sisi asup sareng kaluar. Di ngagunakeun API Dokumén kedah ngawas integritas rujukan sorangan, sareng API Graph nyandak padamelan ieu. Tapi hayu urang tingali kumaha aksés ka OrientDB dina basa query "murni" anu henteu terpadu kana basa pamrograman.

Patarosan jeung hasil

Paménta anu sami tujuanana kana pamundut ti conto pikeun ArangoDB di OrientDB sapertos kieu:

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

Hasilna bakal diala dina bentuk ieu:

[
  { "person_name": "Алиса", "cafe_name": "Джон Донн" },
  { "person_name": "Алиса", "cafe_name": "Жан-Жак" },
  { "person_name": "Боб",  "cafe_name": "Жан-Жак" }
]

Lamun format hasilna deui sigana teuing "relasional", anjeun kudu nyabut garis kalawan UNWIND():

[
  { "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
  { "person_name": "Боб",  "cafe_name": [ "Жан-Жак" ' }
]

Basa pamundut OrientDB tiasa didadarkeun salaku SQL sareng sisipan sapertos Gremlin. Dina versi 2.2, formulir pamundut kawas Cypher mucunghul, 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

Format hasilna bakal sami sareng pamundut sateuacana. Pikirkeun naon anu kedah dipiceun supados langkung "relasional", sapertos dina pamundut anu munggaran.

Azure CosmosDB

Ka extent Lesser, naon ieu ceuk di luhur ngeunaan ArangoDB na OrientDB manglaku ka Azure CosmosDB. CosmosDB nyayogikeun API aksés data ieu: SQL, MongoDB, Gremlin sareng Cassandra.

SQL API sareng MongoDB API dianggo pikeun ngaksés data dina modél dokumén. Gremlin API sareng Cassandra API - masing-masing pikeun ngakses data dina format grafik sareng kolom. Data dina sadaya modél disimpen dina format modél internal CosmosDB: Ars ("atom-record-sequence"), anu ogé deukeut jeung dokumen hiji.

Tapi modél data anu dipilih ku pangguna sareng API anu dianggo tetep dina waktos nyiptakeun akun dina jasa éta. Teu mungkin pikeun ngaksés data anu dimuat dina hiji modél dina format modél sanés, sapertos anu digambarkeun ku hal sapertos kieu:

Ku kituna, multi-model di Azure CosmosDB kiwari ngan kamampuhan pikeun ngagunakeun sababaraha basis data ngarojong model béda ti hiji produsén, nu teu ngajawab sagala masalah gudang multi-varian.

Multi-model DBMS dumasar kana model grafik?

Catet nyaéta kanyataan yén teu acan aya DBMS multi-modél dina pasaran anu dumasar kana modél grafik (iwal dukungan multi-modél pikeun dua modél grafik sakaligus: RDF sareng LPG; tingali ieu dina publikasi saméméhna). Kasusah pangbadagna disababkeun ku palaksanaan model dokumen dina luhureun model grafik, tinimbang hiji relational.

Patarosan ngeunaan kumaha carana nerapkeun model relational dina luhureun model grafik ieu dianggap malah salila formasi dimungkinkeun. Kumaha nyarioscontona David McGovern:

Teu aya anu alami dina pendekatan grafik anu nyegah nyiptakeun lapisan (contona, ku indéksing anu cocog) dina database grafik anu ngamungkinkeun tempoan relasional sareng (1) pamulihan tuple tina pasangan nilai konci biasa sareng (2) pengelompokan tupel dumasar jenis hubungan.

Nalika nerapkeun modél dokumén dina luhureun modél grafik, anjeun kedah émut, contona, ieu:

Unsur tina hiji Asép Sunandar Sunarya JSON dianggap maréntahkeun, tapi maranéhanana emanating ti vertex hiji ujung grafik henteu;
Data dina modél dokumén biasana dinormalisasi; anjeun masih teu hoyong nyimpen sababaraha salinan dokumén anu dipasang anu sami, sareng subdokumén biasana henteu gaduh identifier;
Di sisi séjén, idéologi DBMSs dokumén yén dokumén téh siap-dijieun "aggregates" nu teu perlu diwangun anew unggal waktu. Diperlukeun nyadiakeun modél grafik kamampuhan pikeun gancang ménta subgraph pakait jeung dokumén rengse.

Iklan saeutik

Panulis artikel aya hubunganana sareng pamekaran NitrosBase DBMS, modél internalna nyaéta grafik, sareng modél éksternal - hubungan sareng dokumen - mangrupikeun perwakilan na. Sadaya model sarua: ampir sagala data sadia dina salah sahiji aranjeunna ngagunakeun basa query nu lumrah pikeun eta. Leuwih ti éta, dina pintonan naon, data bisa dirobah. Parobihan bakal ditingali dina modél internal sareng, sasuai, dina pandangan anu sanés.

Kuring mudahan bakal ngajelaskeun naon model cocog Sigana mah di NitrosBase dina salah sahiji artikel di handap ieu.

kacindekan

Kuring miharep yén outlines umum naon anu disebut multi-modeling geus jadi leuwih atawa kirang jelas ka nu maca. Multi-model DBMSs rada béda, sarta "multi-model rojongan" bisa kasampak béda. Pikeun ngartos naon anu disebut "multi-model" dina unggal kasus khusus, mangpaat pikeun ngajawab patarosan ieu:

Naha urang ngobrol ngeunaan ngadukung modél tradisional atanapi sababaraha jinis modél "hibrida"?
Naha modélna "sarua", atanapi salah sahijina mangrupikeun subjek anu sanés?
Naha modél "acuh" ka unggal anu sanés? Naha data anu ditulis dina hiji modél tiasa dibaca dina anu sanés atanapi malah ditimpa?

Kuring nyangka yén patarosan ngeunaan relevansi multi-modél DBMS parantos tiasa dijawab sacara positip, tapi patarosan anu pikaresepeun nyaéta jinis-jinisna anu bakal langkung dipikaresep dina waktos anu caket. Sigana mah multi-model DBMSs nu ngarojong model tradisional, utamana relational, bakal di paménta gede; Popularitas multi-modél DBMSs, nawarkeun model anyar nu ngagabungkeun kaunggulan tina rupa-rupa tradisional, nyaeta masalah masa depan leuwih jauh.

Ngan pamaké nu kadaptar bisa ilubiung dina survey. Daptar, Punten.

Naha anjeun nganggo multi-model DBMS?

Kami henteu nganggo éta, kami nyimpen sadayana dina hiji DBMS sareng dina hiji modél
Kami nganggo kamampuan multi-modél DBMS tradisional
Urang latihan kegigihan polyglot
Kami nganggo DBMS multi-model anyar (Arango, Orient, CosmosDB)

19 pamaké milih. 4 pamaké abstained.

sumber: www.habr.com

Naha multi-modél DBMS mangrupikeun dasar sistem inpormasi modern?