Sistem informasi modern cukup rumit. Paling ora, kerumitan kasebut amarga kerumitan data sing diproses. Kompleksitas data asring dumunung ing macem-macem model data sing digunakake. Dadi, contone, nalika data dadi "gedhe", salah sawijining ciri masalah ora mung volume ("volume"), nanging uga macem-macem ("macem").

Yen sampeyan durung nemokake cacat ing nalar, banjur maca.

Isi

Polyglot terus-terusan
Multi-model
Multi-model DBMS adhedhasar model relasional
     Model dokumen ing MS SQL Server
     Model grafik ing MS SQL Server
Multi-model DBMS adhedhasar model dokumen
     Model relasional ing MarkLogic
     Model grafik ing MarkLogic
Multi-model DBMS "tanpa model utama"
     ArangoDB
     OrientDB
     Azure CosmosDB
Multi-model DBMS adhedhasar model grafik?
kesimpulan
Jajak Pendapat

Polyglot terus-terusan

Ing ndhuwur ndadékaké kanggo kasunyatan sing kadhangkala malah ing framework saka siji sistem perlu kanggo nggunakake sawetara DBMS beda kanggo nyimpen data lan ngatasi macem-macem masalah Processing, saben kang ndhukung model data dhewe. Kanthi tangan entheng M. Fowler, pengarang sawetara buku misuwur lan salah siji saka co-penulis Manifesto Agile, kahanan iki diarani panyimpenan multi-varian ("kegigihan polyglot").

Fowler uga duwe conto ing ngisor iki kanggo ngatur panyimpenan data ing aplikasi kanthi fitur lengkap lan dhuwur ing bidang e-commerce.

Conto iki, mesthi, rada exaggerated, nanging sawetara pertimbangan kanggo milih siji utawa liyane DBMS kanggo tujuan sing cocog bisa ditemokake, contone, kene.

Cetha yen dadi abdi ing kebon binatang kuwi ora gampang.

Jumlah kode sing nindakake panyimpenan data tuwuh ing proporsi kanggo jumlah DBMS digunakake; jumlah kode sinkronisasi data apik yen ora ceceg karo kothak nomer iki.
Minangka pirang-pirang jumlah DBMS sing digunakake, biaya nyedhiyakake karakteristik perusahaan (skalabilitas, toleransi kesalahan, kasedhiyan dhuwur) saben DBMS sing digunakake mundhak.
Ora mungkin kanggo mesthekake karakteristik perusahaan saka subsistem panyimpenan kanthi sakabehe - utamane transaksional.

Saka sudut pandang direktur kebun binatang, kabeh katon kaya iki:

Tambah kaping pirang-pirang ing biaya lisensi lan dhukungan teknis saka pabrikan DBMS.
Overstaffing lan tambah deadline.
Kerugian finansial langsung utawa denda amarga data ora konsisten.

Ana kenaikan sing signifikan ing total biaya kepemilikan sistem (TCO). Apa ana cara metu saka kahanan "pilihan macem-macem panyimpenan"?

Multi-model

Istilah "panyimpenan multivariate" wiwit digunakake ing taun 2011. Kesadaran babagan masalah pendekatan lan telusuran solusi njupuk sawetara taun, lan ing 2015, liwat cangkeme analis Gartner, jawaban kasebut dirumusake:

saka"Pandhuan Pasar kanggo DBMS NoSQL - 2015"

Masa depan DBMS, arsitektur lan cara nggunakake minangka multi-model.
saka"Magic Quadrant kanggo ODBMS - 2016"

DBMS operasional sing unggul bakal nawakake macem-macem model-relasional lan non-relasional-minangka bagean saka platform siji.

Kayane wektu iki analis Gartner bener karo ramalane. Yen sampeyan pindhah menyang kaca karo rating utama DBMS ing DB-Engines, sampeyan bisa ndeleng singоSebagéan gedhé pimpinané mènèhi posisi khusus minangka DBMS multi-model. Sing padha bisa dideleng ing kaca kanthi rating pribadi.

Tabel ing ngisor iki nuduhake DBMS - pimpinan ing saben rating pribadi, sing ngaku dadi multi-model. Kanggo saben DBMS, model asli sing didhukung (sing biyen mung siji) lan model sing saiki didhukung dituduhake. Uga kadhaptar yaiku DBMS sing posisine dhewe minangka "asli multi-model" lan, miturut pangripta, ora duwe model warisan awal.

DBMS	Model wiwitan	Model tambahan
Oracle	Relasional	Grafik, dokumen
MS SQL	Relasional	Grafik, dokumen
PostgreSQL	Relasional	Grafik*, dokumen
MarkLogic	Dokumenter	Grafik, relasional
MongoDB	Dokumenter	Nilai kunci, grafik *
DataStax	Wide-kolom	Dokumenter, grafik
Redis	Nilai-kunci	Dokumenter, grafik*
ArangoDB	-	Grafik, dokumen
OrientDB	-	Grafik, dokumen, relasional
Azure CosmosDB	-	Grafik, dokumen, relasional

Cathetan meja

Tanda bintang ing pratelan tandha tabel sing mbutuhake reservasi:

DBMS PostgreSQL ora ndhukung model data grafik, nanging produk iki ndhukung adhedhasar iku, kayata AgensGraph.
Ing hubungan karo MongoDB, luwih bener kanggo ngomong babagan anané operator grafik ing basa pitakon ($lookup, $graphLookup) tinimbang babagan ndhukung model grafik, sanajan, mesthine, introduksi mbutuhake sawetara optimasi ing tingkat panyimpenan fisik ing arah ndhukung model grafik.
Ing hubungan karo Redis, kita tegese extension RedisGraph.

Sabanjure, kanggo saben kelas, kita bakal nuduhake carane dhukungan kanggo sawetara model dileksanakake ing DBMS saka kelas iki. Kita bakal nimbang model relasional, dokumen lan grafik minangka sing paling penting lan nggunakake conto DBMS tartamtu kanggo nuduhake carane "sing ilang" dileksanakake.

Multi-model DBMS adhedhasar model relasional

DBMS utama saiki relasional; Ramalan Gartner ora bisa dianggep bener yen RDBMS ora nuduhake gerakan menyang arah multi-modeling. Lan padha nduduhake. Saiki idea sing multi-model DBMS kaya piso Swiss, kang ora bisa nindakake apa-apa uga, bisa langsung kanggo Larry Ellison.

Penulis, Nanging, luwih seneng implementasine saka multi-modeling ing Microsoft SQL Server, ing conto kang RDBMS support kanggo document lan model grafik bakal diterangake.

Model dokumen ing MS SQL Server

Wis ana rong artikel sing apik banget babagan Habré babagan carane MS SQL Server ngleksanakake dhukungan kanggo model dokumen; Aku bakal mbatesi aku kanggo retelling lan komentar singkat:

Cara kanggo ndhukung model dokumen ing MS SQL Server cukup khas kanggo DBMS relasional: dokumen JSON diusulake kanggo disimpen ing kolom teks biasa. Dhukungan kanggo model dokumen yaiku nyedhiyakake operator khusus kanggo ngurai JSON iki:

JSON_VALUE kanggo ngekstrak nilai atribut skalar,
JSON_QUERY kanggo extract sub-dokumen.

Argumentasi kaloro operator kasebut minangka ekspresi ing sintaks kaya JSONPath.

Secara abstrak, kita bisa ngomong yen dokumen sing disimpen kanthi cara iki dudu "entitas kelas pertama" ing DBMS relasional, ora kaya tuple. Khusus, ing MS SQL Server saiki ora ana indeks ing kolom dokumen JSON, sing nggawe angel gabung karo tabel nggunakake nilai kolom kasebut lan malah milih dokumen nggunakake nilai kasebut. Nanging, sampeyan bisa nggawe kolom sing diwilang kanggo kolom kasebut lan indeks kasebut.

Kajaba iku, MS SQL Server nyedhiyakake kemampuan kanggo nggawe dokumen JSON kanthi gampang saka isi tabel nggunakake operator. FOR JSON PATH - kamungkinan, ing pangertèn tartamtu, ngelawan sing sadurunge, panyimpenan conventional. Cetha yen ora ketompo carane cepet RDBMS, pendekatan iki mbantah ideologi dokumen DBMS, sing ateges nyimpen jawaban siap-siap kanggo pitakonan populer, lan mung bisa ngatasi masalah gampang pembangunan, nanging ora kacepetan.

Pungkasan, MS SQL Server ngijini sampeyan kanggo ngatasi masalah ngelawan saka construction document: sampeyan bisa decompose JSON menyang tabel nggunakake OPENJSON. Yen dokumen ora rampung warata, sampeyan kudu nggunakake CROSS APPLY.

Model grafik ing MS SQL Server

Dhukungan kanggo model grafik (LPG) uga dileksanakake kanthi lengkap ing Microsoft SQL Server bisa ditebak: Disaranake nggunakake tabel khusus kanggo nyimpen simpul lan kanggo nyimpen pinggiran grafik. Tabel kasebut digawe nggunakake ekspresi CREATE TABLE AS NODE и CREATE TABLE AS EDGE masing-masing.

Tabel saka jinis pisanan padha karo tabel biasa kanggo nyimpen cathetan, karo mung prabédan njaba sing tabel ngemot kolom sistem. $node_id - pengenal unik saka simpul grafik ing basis data.

Kajaba iku, tabel jinis kapindho duwe kolom sistem $from_id и $to_id, entri ing tabel kasebut kanthi jelas nemtokake sambungan antarane simpul. Tabel kapisah digunakake kanggo nyimpen hubungan saben jinis.

Ayo kita ilustrasi iki nganggo conto. Ayo data grafik duwe tata letak kaya sing ditampilake ing gambar kasebut. Banjur kanggo nggawe struktur sing cocog ing database sampeyan kudu mbukak pitakon DDL ing ngisor iki:

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

Kekhususan utama tabel kasebut yaiku ing pitakon marang dheweke bisa nggunakake pola grafik kanthi sintaks kaya Cypher (Nanging, "*"dsb. durung didhukung). Adhedhasar pangukuran kinerja, bisa uga dianggep yen cara data disimpen ing tabel kasebut beda karo cara data disimpen ing tabel biasa lan dioptimalake kanggo nglakokake pitakon grafik kasebut.

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

Kajaba iku, cukup angel ora nggunakake pola grafik kasebut nalika nggarap tabel kasebut, amarga ing pitakon SQL biasa kanggo ngatasi masalah sing padha, kudu nggawe upaya tambahan kanggo entuk pengenal simpul "grafik" sistem ($node_id, $from_id, $to_id; Kanggo alasan sing padha, pitakon kanggo nglebokake data ora ditampilake ing kene amarga ora perlu rumit).

Kanggo ngringkes gambaran saka implementasine saka document lan model grafik ing MS SQL Server, Aku Wigati sing implementasine kuwi model siji ing ndhuwur liyane ora koyone sukses, utamané saka sudut pandang desain basa. Sampeyan perlu kanggo ngluwihi basa siji karo liyane, basa ora rampung "ortogonal", aturan kompatibilitas bisa cukup aneh.

Multi-model DBMS adhedhasar model dokumen

Ing bagean iki, aku pengin nggambarake implementasine multi-model ing dokumen DBMS nggunakake conto sing ora paling populer, MongoDB (kaya sing dikandhakake, mung duwe operator grafik kondisional. $lookup и $graphLookup, ora nggarap koleksi sharded), nanging nggunakake conto DBMS sing luwih diwasa lan "perusahaan" MarkLogic.

Dadi, koleksi kasebut ngemot set dokumen XML saka jinis ing ngisor iki (MarkLogic uga ngidini sampeyan nyimpen dokumen JSON):

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

Model relasional ing MarkLogic

Tampilan relasional saka koleksi dokumen bisa digawe nggunakake Cithakan tampilan (isi unsur value ing conto ing ngisor iki bisa uga ana XPath sing sewenang-wenang):

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

Sampeyan bisa ngatasi tampilan sing digawe kanthi query SQL (contone, liwat ODBC):

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

Sayange, tampilan relasional sing digawe dening cithakan tampilan mung diwaca. Nalika ngolah panjaluk kasebut, MarkLogic bakal nyoba nggunakake indeks dokumen. Sadurunge, MarkLogic wis winates views relasional, tanggung adhedhasar indeks lan bisa ditulis, nanging saiki dianggep wis ora digunakake.

Model grafik ing MarkLogic

Kanthi dhukungan kanggo model grafik (RDF), kabeh meh padha. Maneh karo bantuan Cithakan tampilan sampeyan bisa nggawe perwakilan RDF saka koleksi dokumen saka conto ing ndhuwur:

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

Sampeyan bisa ngatasi grafik RDF sing diasilake kanthi pitakon SPARQL:

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

Ora kaya relasional, MarkLogic ndhukung model grafik kanthi rong cara liyane:

A DBMS bisa dadi panyimpenan kapisah lengkap saka data RDF (triplets ing bakal disebut ngatur beda karo sing kasebut ing ndhuwur dijupuk).
RDF ing serialisasi khusus mung bisa dilebokake menyang dokumen XML utawa JSON (lan triplet banjur bakal disebut ora diatur). Iki mbokmenawa alternatif kanggo mekanisme idref lan liyane.

Ide apik babagan cara kerjane "tenan" ing MarkLogic diwenehake dening API optik, ing pangertèn iki, iku kurang-tingkat, sanajan tujuane rodo ngelawan - kanggo nyoba kanggo abstrak saka model data digunakake, kanggo mesthekake karya konsisten karo data ing model beda, transactionality, etc.

Multi-model DBMS "tanpa model utama"

Ana uga DBMSs ing pasar sing posisi dhewe minangka wiwitane multi-model, tanpa model utama warisan. Iki kalebu ArangoDB, OrientDB (wiwit 2018 perusahaan pembangunan belongs kanggo SAP) lan CosmosDB (layanan minangka bagéan saka platform maya Microsoft Azure).

Nyatane, ana model "inti" ing ArangoDB lan OrientDB. Ing kasus kasebut, iki minangka model data dhewe, yaiku generalisasi saka dokumen kasebut. Generalisasi utamane kanggo nggampangake kemampuan kanggo nindakake pitakon babagan grafik lan sifat relasional.

Model iki mung siji-sijine sing kasedhiya kanggo digunakake ing DBMS sing ditemtokake; basa pitakon dhewe dirancang kanggo nggarap. Mesthine, model lan DBMS kasebut pancen njanjeni, nanging kekurangan kompatibilitas karo model lan basa standar ndadekake ora bisa nggunakake DBMS kasebut ing sistem warisan-kanggo ngganti DBMS sing wis digunakake ing kana.

Wis ana artikel sing apik babagan ArangoDB lan OrientDB ing Habré: GABUNGAN ing database NoSQL.

ArangoDB

ArangoDB ngaku ndhukung model data grafik.

Node saka grafik ing ArangoDB minangka dokumen biasa, lan pinggiran minangka dokumen saka jinis khusus sing, bebarengan karo kolom sistem biasa, duwe (_key, _id, _rev) lapangan sistem _from и _to. Dokumen ing DBMS dokumen biasane digabung dadi koleksi. Koleksi dokumen sing makili pinggiran diarani koleksi pinggiran ing ArangoDB. Miturut cara, dokumen koleksi pinggiran uga dokumen, saengga pinggiran ing ArangoDB uga bisa dadi simpul.

Data sumber

Ayo kita duwe koleksi persons, sing dokumen katon kaya iki:

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

Ayo ana uga koleksi cafes:

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

Banjur koleksi likes bisa uga katon kaya iki:

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

Pitakonan lan asil

Pitakonan gaya grafik ing basa AQL sing digunakake ing ArangoDB, ngasilake informasi formulir sing bisa diwaca manungsa babagan sapa sing seneng kafe, kaya mangkene:

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

Ing gaya relasional, ing ngendi kita "ngetung" hubungan tinimbang nyimpen, pitakon iki bisa ditulis maneh kaya iki (kanthi cara, tanpa koleksi likes bisa 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 }

Asil ing loro kasus bakal padha:

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

Pitakon lan asil liyane

Yen format asil ing ndhuwur katon luwih khas kanggo DBMS relasional tinimbang DBMS dokumen, sampeyan bisa nyoba pitakon iki (utawa sampeyan bisa nggunakake COLLECT):

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

Asil bakal katon kaya iki:

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

OrientDB

Basis kanggo ngetrapake model grafik ing ndhuwur model dokumen ing OrientDB yaiku kesempatan kolom dokumen, saliyane kanggo nilai skalar standar luwih utawa kurang, uga duwe nilai jinis kayata LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Nilai saka jinis iki minangka pranala utawa koleksi pranala menyang pengenal sistem dokumen.

Pengenal dokumen sing ditugasake dening sistem nduweni "makna fisik", sing nuduhake posisi rekaman ing basis data, lan katon kaya iki: @rid : #3:16. Mangkono, nilai-nilai properti referensi pancen minangka penunjuk (kaya ing model grafik) tinimbang kondisi pilihan (kaya ing model relasional).

Kaya ArangoDB, pinggiran ing OrientDB diwakili minangka dokumen sing kapisah (sanajan yen pinggiran ora nduweni sifat dhewe, bisa digawe entheng, lan ora cocog karo dokumen sing kapisah).

Data sumber

Ing format cedhak format dump Database OrientDB, data saka conto sadurunge kanggo ArangoDB bakal katon kaya iki:

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

Minangka kita bisa ndeleng, vertex uga nyimpen informasi babagan pinggiran mlebu lan metu. Ing nggunakake API Dokumen kudu ngawasi integritas referensial dhewe, lan API Graph njupuk karya iki. Nanging ayo ndeleng kaya apa akses menyang OrientDB ing basa pitakon "murni" sing ora digabungake menyang basa pamrograman.

Pitakonan lan asil

Pitakonan sing padha karo pitakon saka conto kanggo ArangoDB ing OrientDB katon kaya iki:

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

Asil bakal dipikolehi ing wangun ing ngisor iki:

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

Yen format asil maneh katon banget "relasional", sampeyan kudu mbusak baris karo UNWIND():

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

Basa pitakon OrientDB bisa diterangake minangka SQL kanthi sisipan kaya Gremlin. Ing versi 2.2, formulir panyuwunan kaya Cypher katon, 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 asil bakal padha karo panyuwunan sadurunge. Coba pikirake apa sing kudu dibusak supaya luwih "relasional", kaya ing pitakon pisanan.

Azure CosmosDB

Kanggo sing luwih cilik, apa sing dicritakake ing ndhuwur babagan ArangoDB lan OrientDB ditrapake kanggo Azure CosmosDB. CosmosDB nyedhiyakake API akses data ing ngisor iki: SQL, MongoDB, Gremlin lan Cassandra.

SQL API lan MongoDB API digunakake kanggo ngakses data ing model document. Gremlin API lan Cassandra API - kanggo ngakses data ing format grafik lan kolom, mungguh. Data ing kabeh model disimpen ing format model internal CosmosDB: ARS ("atom-record-sequence"), sing uga cedhak karo dokumen siji.

Nanging model data sing dipilih dening pangguna lan API sing digunakake tetep nalika nggawe akun ing layanan kasebut. Ora bisa ngakses data sing dimuat ing model siji ing format model liyane, kaya sing digambarake kaya iki:

Mangkono, multi-model ing Azure CosmosDB saiki mung kemampuan kanggo nggunakake sawetara database ndhukung model beda saka siji pabrikan, kang ora ngatasi kabeh masalah panyimpenan multi-varian.

Multi-model DBMS adhedhasar model grafik?

Wigati yaiku kasunyatan manawa durung ana DBMS multi-model ing pasar sing adhedhasar model grafik (kajaba dhukungan multi-model kanggo rong model grafik bebarengan: RDF lan LPG; deleng iki ing publikasi sadurungé). Kesulitan paling gedhe disebabake dening implementasi model dokumen ing ndhuwur model grafik, tinimbang model relasional.

Pitakonan babagan carane ngleksanakake model relasional ing ndhuwur model grafik dianggep sanajan nalika pambentukan sing terakhir. Carane ngandikacontone David McGovern:

Ora ana apa-apa sing ana ing pendekatan grafik sing ngalangi nggawe lapisan (contone, kanthi indeksasi sing cocog) ing basis data grafik sing ngidini tampilan relasional kanthi (1) pemulihan tuple saka pasangan nilai kunci sing biasa lan (2) klompok tuple miturut jinis relasi.

Nalika ngetrapake model dokumen ing ndhuwur model grafik, sampeyan kudu ngelingi, contone, ing ngisor iki:

Unsur saka array JSON dianggep diurutake, nanging sing metu saka pucuk pinggiran grafik ora;
Data ing model dokumen biasane ora normal, sampeyan isih ora pengin nyimpen sawetara salinan dokumen sing padha, lan subdokumen biasane ora duwe pengenal;
Ing tangan liyane, ideologi document DBMSs iku dokumen siap-digawe "agregat" sing ora perlu dibangun maneh saben wektu. Dibutuhake kanggo nyedhiyakake model grafik kanthi kemampuan kanggo entuk subgraph kanthi cepet sing cocog karo dokumen sing wis rampung.

Sawetara iklan

Penulis artikel kasebut ana gandhengane karo pangembangan DBMS NitrosBase, model internal yaiku grafik, lan model eksternal - relasional lan dokumen - minangka perwakilan. Kabeh model padha: meh kabeh data kasedhiya ing salah sawijining model nggunakake basa pitakon sing alami. Kajaba iku, ing tampilan apa wae, data bisa diganti. Owah-owahan bakal dibayangke ing model internal lan, kanthi mangkono, ing tampilan liyane.

Muga-muga aku bakal njlèntrèhaké apa sing cocog karo model ing NitrosBase ing salah sawijining artikel ing ngisor iki.

kesimpulan

Mugi-mugi gambaran umum babagan ingkang dipunsebat multi-modeling punika langkung cetha tumrap pamaos. Multi-model DBMSs cukup beda, lan "multi-model support" bisa katon beda. Kanggo mangerteni apa sing diarani "multi-model" ing saben kasus tartamtu, migunani kanggo njawab pitakonan ing ngisor iki:

Apa kita ngomong babagan ndhukung model tradisional utawa sawetara model "hibrida"?
Apa model "padha", utawa salah sijine subyek liyane?
Apa model "ora peduli" siji liyane? Apa data sing ditulis ing model siji bisa diwaca ing model liyane utawa malah ditimpa?

Aku mikir yen pitakonan babagan relevansi DBMS multi-model wis bisa dijawab kanthi positif, nanging pitakonan sing menarik yaiku jinis apa sing bakal dikarepake ing mangsa ngarep. Iku misale jek sing multi-model DBMSs sing ndhukung model tradisional, utamané relasional, bakal ing dikarepake luwih; Popularitas DBMS multi-model, nawakake model anyar sing nggabungake kaluwihan saka macem-macem tradisional, minangka masalah ing mangsa ngarep sing luwih adoh.

Mung pangguna pangguna sing bisa melu survey. mlebunggih.

Apa sampeyan nggunakake DBMS multi-model?

Kita ora nggunakake, kita nyimpen kabeh ing siji DBMS lan ing siji model
Kita nggunakake kemampuan multi-model saka DBMS tradisional
Kita nglatih kegigihan polyglot
Kita nggunakake DBMS multi-model anyar (Arango, Orient, CosmosDB)

19 pangguna milih. 4 pangguna abstain.

Source: www.habr.com

Apa multi-model DBMS basis saka sistem informasi modern?