Sistem informasi modern cukup kompleks. Yang paling penting, kompleksitasnya disebabkan oleh kompleksitas data yang diproses di dalamnya. Kompleksitas data seringkali terletak pada beragamnya model data yang digunakan. Jadi, misalnya, ketika data menjadi “besar”, salah satu karakteristik yang bermasalah bukan hanya volumenya (“volume”), tetapi juga keragamannya (“variety”).
Jika Anda belum menemukan kesalahan dalam alasannya, baca terus.
kadar
Kegigihan poliglot
Hal di atas mengarah pada fakta bahwa kadang-kadang bahkan dalam satu sistem perlu menggunakan beberapa DBMS yang berbeda untuk menyimpan data dan memecahkan berbagai masalah pemrosesannya, yang masing-masing mendukung model datanya sendiri. Dengan tangan ringan M. Fowler, sejumlah buku terkenal dan salah satunya Agile Manifesto, situasi ini disebut penyimpanan multi-varian (“kegigihan poliglot”).
Fowler juga memiliki contoh pengorganisasian penyimpanan data dalam aplikasi berfitur lengkap dan beban tinggi berikut ini di bidang e-commerce.
Contoh ini, tentu saja, agak berlebihan, tetapi ada beberapa pertimbangan yang mendukung pemilihan DBMS tertentu untuk tujuan yang sesuai, misalnya, .
Jelas menjadi pelayan di kebun binatang seperti itu tidaklah mudah.
- Jumlah kode yang melakukan penyimpanan data bertambah sebanding dengan jumlah DBMS yang digunakan; jumlah kode sinkronisasi data bagus jika tidak sebanding dengan kuadrat angka ini.
- Sebagai kelipatan dari jumlah DBMS yang digunakan, biaya penyediaan karakteristik perusahaan (skalabilitas, toleransi kesalahan, ketersediaan tinggi) dari setiap DBMS yang digunakan meningkat.
- Tidak mungkin untuk memastikan karakteristik perusahaan dari subsistem penyimpanan secara keseluruhan - terutama transaksionalitas.
Dari sudut pandang direktur kebun binatang, semuanya terlihat seperti ini:
- Peningkatan berganda dalam biaya lisensi dan dukungan teknis dari produsen DBMS.
- Kelebihan staf dan peningkatan tenggat waktu.
- Kerugian finansial langsung atau denda karena ketidakkonsistenan data.
Ada peningkatan yang signifikan dalam total biaya kepemilikan (TCO) sistem. Apakah ada jalan keluar dari situasi “beberapa pilihan penyimpanan”?
Multi-model
Istilah “penyimpanan multivariat” mulai digunakan pada tahun 2011. Kesadaran akan masalah pendekatan dan pencarian solusi membutuhkan waktu beberapa tahun, dan pada tahun 2015, melalui mulut para analis Gartner, jawabannya dirumuskan:
- Dari "»:
Masa depan DBMS, arsitekturnya dan cara penggunaannya adalah multi-model.
- Dari "»:
DBMS operasional terkemuka akan menawarkan banyak model—relasional dan non-relasional—sebagai bagian dari satu platform.
Tampaknya kali ini perkiraan analis Gartner benar. Jika Anda pergi ke halaman dengan DBMS di DB-Engines, Anda dapat melihatnyaоSebagian besar pemimpinnya memposisikan diri mereka secara spesifik sebagai DBMS multi-model. Hal yang sama dapat dilihat pada halaman dengan peringkat pribadi apa pun.
Tabel di bawah ini menunjukkan DBMS - pemimpin di setiap peringkat swasta, yang mengklaim sebagai multi-model. Untuk setiap DBMS, model asli yang didukung (yang dulunya merupakan satu-satunya) dan model yang saat ini didukung juga ditunjukkan. Juga terdaftar adalah DBMS yang memposisikan dirinya sebagai “awalnya multi-model” dan, menurut pembuatnya, tidak memiliki model warisan awal.
| DBMS | Model awal | Model tambahan |
|---|---|---|
| Peramal | Relasional | Grafik, dokumen |
| MSSQL | Relasional | Grafik, dokumen |
| PostgreSQL | Relasional | Grafik*, dokumen |
| MarkLogic | Dokumenter | Grafik, relasional |
| MongoDB | Dokumenter | Nilai kunci, grafik* |
| DataStax | Kolom lebar | Dokumenter, grafik |
| Redis | Nilai kunci | Dokumenter, grafik* |
| ArangoDB | - | Grafik, dokumen |
| OrientDB | - | Grafik, dokumen, relasional |
| Azure CosmosDB | - | Grafik, dokumen, relasional |
Catatan meja
Tanda bintang pada tabel menandai pernyataan yang memerlukan reservasi:
- DBMS PostgreSQL tidak mendukung model data grafik, namun produk ini mendukungnya , seperti AgensGraph.
- Sehubungan dengan MongoDB, lebih tepat berbicara tentang keberadaan operator grafik dalam bahasa kueri (, ) daripada mendukung model grafik, meskipun, tentu saja, pengenalannya memerlukan beberapa optimasi pada tingkat penyimpanan fisik untuk mendukung model grafik.
- Sehubungan dengan Redis, yang kami maksud adalah ekstensi .
Selanjutnya, untuk setiap kelas, kami akan menunjukkan bagaimana dukungan untuk beberapa model diimplementasikan dalam DBMS dari kelas ini. Kami akan menganggap model relasional, dokumen, dan grafik sebagai yang paling penting dan menggunakan contoh DBMS tertentu untuk menunjukkan bagaimana “yang hilang” diimplementasikan.
DBMS multi-model berdasarkan model relasional
DBMS terkemuka saat ini bersifat relasional; perkiraan Gartner tidak dapat dianggap benar jika RDBMS tidak menunjukkan pergerakan ke arah multi-modeling. Dan mereka mendemonstrasikannya. Sekarang gagasan bahwa DBMS multi-model seperti pisau Swiss, yang tidak dapat melakukan apa pun dengan baik, dapat diarahkan langsung ke Larry Ellison.
Namun penulis lebih memilih penerapan multi-pemodelan di Microsoft SQL Server, yang akan menjelaskan contoh dukungan RDBMS untuk model dokumen dan grafik.
Model dokumen di MS SQL Server
Sudah ada dua artikel bagus di Habré tentang bagaimana MS SQL Server mengimplementasikan dukungan untuk model dokumen; Saya akan membatasi diri pada penceritaan kembali dan komentar singkat:
Cara untuk mendukung model dokumen di MS SQL Server cukup umum untuk DBMS relasional: Dokumen JSON diusulkan untuk disimpan dalam kolom teks biasa. Dukungan untuk model dokumen adalah dengan menyediakan operator khusus untuk mengurai JSON ini:
- untuk mengekstrak nilai atribut skalar,
- untuk mengekstrak sub-dokumen.
Argumen kedua dari kedua operator adalah ekspresi dalam sintaksis mirip JSONPath.
Secara abstrak, kita dapat mengatakan bahwa dokumen yang disimpan dengan cara ini bukanlah “entitas kelas satu” dalam DBMS relasional, tidak seperti tupel. Khususnya, di MS SQL Server saat ini tidak ada indeks pada bidang dokumen JSON, sehingga menyulitkan untuk menggabungkan tabel menggunakan nilai bidang ini dan bahkan memilih dokumen menggunakan nilai ini. Namun, dimungkinkan untuk membuat kolom terhitung untuk bidang tersebut dan indeks di dalamnya.
Selain itu, MS SQL Server menyediakan kemampuan untuk membuat dokumen JSON dengan mudah dari konten tabel menggunakan operator - kemungkinan, dalam arti tertentu, berlawanan dengan penyimpanan konvensional sebelumnya. Jelas bahwa tidak peduli seberapa cepat RDBMS, pendekatan ini bertentangan dengan ideologi DBMS dokumen, yang pada dasarnya menyimpan jawaban siap pakai atas pertanyaan populer, dan hanya dapat memecahkan masalah kemudahan pengembangan, bukan kecepatan.
Terakhir, MS SQL Server memungkinkan Anda memecahkan masalah kebalikan dari pembuatan dokumen: Anda dapat menguraikan JSON ke dalam tabel menggunakan . Jika dokumen tidak sepenuhnya rata, Anda perlu menggunakannya CROSS APPLY.
Model grafik di MS SQL Server
Dukungan untuk model grafik (LPG) juga diterapkan sepenuhnya di Microsoft SQL Server : Diusulkan untuk menggunakan tabel khusus untuk menyimpan node dan menyimpan tepi grafik. Tabel tersebut dibuat menggunakan ekspresi CREATE TABLE AS NODE и CREATE TABLE AS EDGE masing.
Tabel tipe pertama mirip dengan tabel biasa untuk menyimpan catatan, dengan satu-satunya perbedaan eksternal adalah bahwa tabel tersebut berisi bidang sistem $node_id — pengidentifikasi unik dari simpul grafik dalam database.
Demikian pula, tabel tipe kedua memiliki bidang sistem $from_id и $to_id, entri dalam tabel tersebut dengan jelas mendefinisikan hubungan antar node. Tabel terpisah digunakan untuk menyimpan hubungan dari setiap jenis.
Mari kita ilustrasikan hal ini dengan sebuah contoh. Biarkan data grafik memiliki tata letak seperti yang ditunjukkan pada gambar. Kemudian untuk membuat struktur yang sesuai dalam database Anda perlu menjalankan query DDL berikut:
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 dari tabel tersebut adalah bahwa dalam kueri terhadap tabel tersebut dimungkinkan untuk menggunakan pola grafik dengan sintaksis mirip Cypher (namun, “*"dll. belum didukung). Berdasarkan pengukuran kinerja, dapat juga diasumsikan bahwa cara data disimpan dalam tabel ini berbeda dengan cara data disimpan dalam tabel biasa dan dioptimalkan untuk menjalankan kueri grafik tersebut.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Selain itu, cukup sulit untuk tidak menggunakan pola grafik ini saat bekerja dengan tabel seperti itu, karena dalam kueri SQL biasa, untuk menyelesaikan masalah serupa, diperlukan upaya tambahan untuk mendapatkan pengidentifikasi simpul "grafik" sistem ($node_id, $from_id, $to_id; Untuk alasan yang sama, kueri untuk memasukkan data tidak ditampilkan di sini karena tidak terlalu rumit).
Untuk meringkas deskripsi implementasi model dokumen dan grafik di MS SQL Server, saya akan mencatat bahwa implementasi satu model di atas model lainnya tampaknya tidak berhasil, terutama dari sudut pandang desain bahasa. Penting untuk memperluas satu bahasa dengan bahasa lain, bahasa-bahasa tersebut tidak sepenuhnya “ortogonal”, aturan kompatibilitasnya bisa sangat aneh.
DBMS multi-model berdasarkan model dokumen
Pada bagian ini, saya ingin mengilustrasikan implementasi multi-model dalam DBMS dokumen menggunakan contoh yang tidak paling populer, MongoDB (seperti yang disebutkan, ia hanya memiliki operator grafik bersyarat $lookup и $graphLookup, tidak mengerjakan koleksi yang dipecah), tetapi menggunakan contoh DBMS yang lebih matang dan “perusahaan” .
Jadi, biarkan koleksi tersebut berisi sekumpulan dokumen XML dengan tipe berikut (MarkLogic juga memungkinkan Anda menyimpan dokumen JSON):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Model relasional di MarkLogic
Tampilan relasional dari kumpulan dokumen dapat dibuat menggunakan (isi elemen value dalam contoh di bawah ini mungkin ada XPath yang berubah-ubah):
<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>Anda dapat mengatasi tampilan yang dibuat dengan kueri SQL (misalnya, melalui ODBC):
SELECT name, surname FROM Person WHERE name="John"Sayangnya, tampilan relasional yang dibuat oleh templat tampilan hanya bersifat baca-saja. Saat memproses permintaannya, MarkLogic akan mencoba menggunakannya . Sebelumnya, MarkLogic memiliki pandangan relasional yang sepenuhnya terbatas dan dapat ditulis, tetapi sekarang dianggap tidak digunakan lagi.
Model grafik di MarkLogic
Dengan dukungan model grafik (RDF), semuanya hampir sama. Sekali lagi dengan bantuan Anda dapat membuat representasi RDF dari kumpulan dokumen dari contoh di atas:
<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>Anda dapat mengatasi grafik RDF yang dihasilkan dengan kueri SPARQL:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Berbeda dengan model relasional, MarkLogic mendukung model grafik dengan dua cara lain:
- DBMS dapat menjadi penyimpanan data RDF terpisah yang lengkap (ketiganya akan disebut di dalamnya berbeda dengan yang dijelaskan di atas ).
- RDF dalam serialisasi khusus dapat dengan mudah dimasukkan ke dalam dokumen XML atau JSON (dan kembar tiga akan dipanggil ). Ini mungkin merupakan alternatif dari mekanisme
idrefdan lain-lain
Ide bagus tentang cara kerja "benar-benar" di MarkLogic diberikan oleh , dalam pengertian ini, ini adalah tingkat rendah, meskipun tujuannya justru sebaliknya - untuk mencoba mengabstraksi model data yang digunakan, untuk memastikan kerja yang konsisten dengan data dalam model yang berbeda, transaksionalitas, dll.
DBMS multi-model “tanpa model utama”
Ada juga DBMS di pasaran yang pada awalnya memposisikan dirinya sebagai multi-model, tanpa model utama yang diwariskan. Ini termasuk , (sejak 2018 perusahaan pengembang menjadi milik SAP) dan (layanan sebagai bagian dari platform cloud Microsoft Azure).
Faktanya, ada model “inti” di ArangoDB dan OrientDB. Dalam kedua kasus tersebut, ini adalah model datanya sendiri, yang merupakan generalisasi dari model dokumen. Generalisasi ini terutama untuk memfasilitasi kemampuan melakukan kueri yang bersifat grafik dan relasional.
Model ini adalah satu-satunya model yang tersedia untuk digunakan dalam DBMS yang ditentukan; bahasa kuerinya sendiri dirancang untuk bekerja dengannya. Tentu saja, model dan DBMS seperti itu menjanjikan, namun kurangnya kompatibilitas dengan model dan bahasa standar membuat DBMS ini tidak mungkin digunakan dalam sistem lama—untuk menggantikan DBMS yang sudah digunakan di sana.
Sudah ada artikel bagus tentang ArangoDB dan OrientDB di Habré: .
ArangoDB
ArangoDB mengklaim dukungan untuk model data grafik.
Node grafik di ArangoDB adalah dokumen biasa, dan tepinya adalah dokumen bertipe khusus yang, bersama dengan bidang sistem reguler, memiliki (_key, _id, _rev) bidang sistem _from и _to. Dokumen dalam DBMS dokumen secara tradisional digabungkan menjadi koleksi. Koleksi dokumen yang mewakili edge disebut edge collection di ArangoDB. Omong-omong, dokumen kumpulan tepi juga merupakan dokumen, sehingga tepi di ArangoDB juga dapat bertindak sebagai node.
Data mentah
Mari kita koleksi persons, yang dokumennya terlihat seperti ini:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Biar ada juga koleksinya cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Lalu koleksinya likes mungkin terlihat seperti ini:
[
{
"_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
}
]Pertanyaan dan hasil
Kueri bergaya grafik dalam bahasa AQL yang digunakan di ArangoDB, mengembalikan informasi dalam bentuk yang dapat dibaca manusia tentang siapa yang menyukai kafe mana, terlihat seperti ini:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }Dalam gaya relasional, di mana kita “menghitung” hubungan daripada menyimpannya, kueri ini dapat ditulis ulang seperti ini (omong-omong, tanpa koleksi likes bisa melakukannya 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 }Hasil dalam kedua kasus tersebut akan sama:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Lebih banyak pertanyaan dan hasil
Jika format hasil di atas tampaknya lebih khas untuk DBMS relasional daripada DBMS dokumen, Anda dapat mencoba kueri ini (atau Anda dapat menggunakan ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Hasilnya akan terlihat seperti ini:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
Dasar untuk mengimplementasikan model grafik di atas model dokumen di OrientDB adalah bidang dokumen, selain nilai skalar yang kurang lebih standar, juga memiliki nilai tipe seperti LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Nilai dari tipe ini adalah link atau kumpulan link ke dokumen.
Pengidentifikasi dokumen yang ditetapkan oleh sistem memiliki “makna fisik”, yang menunjukkan posisi catatan dalam database, dan terlihat seperti ini: @rid : #3:16. Jadi, nilai properti referensi sebenarnya adalah penunjuk (seperti pada model grafik) dan bukan kondisi seleksi (seperti pada model relasional).
Seperti ArangoDB, edge di OrientDB direpresentasikan sebagai dokumen terpisah (walaupun jika edge tidak memiliki propertinya sendiri, edge dapat dibuat , dan itu tidak akan sesuai dengan dokumen terpisah).
Data mentah
Dalam format yang mendekati Database OrientDB, data dari contoh sebelumnya untuk ArangoDB akan terlihat seperti ini:
[
{
"@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"
}
]Seperti yang bisa kita lihat, simpul juga menyimpan informasi tentang tepi masuk dan keluar. Pada Document API harus memantau integritas referensial itu sendiri, dan Graph API mengambil alih pekerjaan ini. Tapi mari kita lihat seperti apa akses ke OrientDB dalam bahasa query “murni” yang tidak terintegrasi ke dalam bahasa pemrograman.
Pertanyaan dan hasil
Kueri yang tujuannya serupa dengan kueri dari contoh ArangoDB di OrientDB terlihat seperti ini:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameHasilnya akan diperoleh dalam bentuk berikut:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Jika format hasil lagi-lagi tampak terlalu “relasional”, Anda perlu menghapus baris dengan :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]Bahasa kueri OrientDB dapat digambarkan sebagai SQL dengan sisipan mirip Gremlin. Di versi 2.2, formulir permintaan seperti Cypher muncul, :
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_nameFormat hasilnya akan sama seperti pada permintaan sebelumnya. Pikirkan tentang apa yang perlu dihapus agar lebih “relasional”, seperti pada kueri pertama.
Azure CosmosDB
Pada tingkat lebih rendah, apa yang disebutkan di atas tentang ArangoDB dan OrientDB berlaku untuk Azure CosmosDB. CosmosDB menyediakan API akses data berikut: SQL, MongoDB, Gremlin, dan Cassandra.
SQL API dan MongoDB API digunakan untuk mengakses data dalam model dokumen. Gremlin API dan Cassandra API - masing-masing untuk mengakses data dalam format grafik dan kolom. Data di semua model disimpan dalam format model internal CosmosDB: (“urutan-catatan-atom”), yang juga dekat dengan dokumen.
Namun model data yang dipilih oleh pengguna dan API yang digunakan bersifat tetap pada saat pembuatan akun di layanan. Tidak mungkin mengakses data yang dimuat dalam satu model dalam format model lain, seperti yang diilustrasikan dengan sesuatu seperti ini:
Jadi, multi-model di Azure CosmosDB saat ini hanya kemampuan untuk menggunakan beberapa database yang mendukung model berbeda dari satu pabrikan, yang tidak menyelesaikan semua masalah penyimpanan multi-varian.
DBMS multi-model berdasarkan model grafik?
Yang perlu diperhatikan adalah fakta bahwa belum ada DBMS multi-model di pasaran yang didasarkan pada model grafik (kecuali untuk dukungan multi-model untuk dua model grafik secara bersamaan: RDF dan LPG; lihat ini di ). Kesulitan terbesar disebabkan oleh penerapan model dokumen di atas model grafik, bukan model relasional.
Pertanyaan tentang bagaimana menerapkan model relasional di atas model grafik telah dipertimbangkan bahkan selama pembentukan model grafik. Bagaimana , misalnya, :
Tidak ada yang melekat dalam pendekatan grafik yang mencegah pembuatan lapisan (misalnya, dengan pengindeksan yang sesuai) pada database grafik yang memungkinkan tampilan relasional dengan (1) pemulihan tupel dari pasangan nilai kunci biasa dan (2) pengelompokan dari tupel berdasarkan tipe relasi.
Saat mengimplementasikan model dokumen di atas model grafik, Anda perlu mengingat, misalnya, hal berikut:
- Elemen array JSON dianggap terurut, namun elemen yang berasal dari titik sudut suatu tepi grafik tidak;
- Data dalam model dokumen biasanya didenormalisasi; Anda tetap tidak ingin menyimpan beberapa salinan dari dokumen tersemat yang sama, dan subdokumen biasanya tidak memiliki pengidentifikasi;
- Di sisi lain, ideologi DBMS dokumen adalah bahwa dokumen adalah “agregat” siap pakai yang tidak perlu dibuat ulang setiap saat. Model grafik harus dilengkapi dengan kemampuan untuk dengan cepat mendapatkan subgraf yang sesuai dengan dokumen yang sudah jadi.
Beberapa iklan
Penulis artikel terkait dengan pengembangan DBMS NitrosBase, model internalnya adalah grafik, dan model eksternal - relasional dan dokumen - adalah representasinya. Semua model sama: hampir semua data tersedia di salah satu model menggunakan bahasa kueri yang alami. Apalagi dalam tampilan apapun, datanya bisa diubah. Perubahan akan tercermin dalam model internal dan pandangan lainnya.
Mudah-mudahan saya akan menjelaskan seperti apa pencocokan model di NitrosBase di salah satu artikel berikut.
Kesimpulan
Saya berharap garis besar umum tentang apa yang disebut multi-modeling menjadi kurang lebih jelas bagi pembaca. DBMS multi-model sangat berbeda, dan “dukungan multi-model” dapat terlihat berbeda. Untuk memahami apa yang disebut "multi-model" dalam setiap kasus tertentu, ada gunanya menjawab pertanyaan-pertanyaan berikut:
- Apakah kita berbicara tentang mendukung model tradisional atau semacam model “hibrida”?
- Apakah model-model tersebut “setara”, atau apakah salah satu model merupakan subjek dari model yang lain?
- Apakah model-model tersebut “acuh tak acuh” satu sama lain? Bisakah data yang ditulis dalam satu model dibaca di model lain atau bahkan ditimpa?
Saya rasa pertanyaan tentang relevansi DBMS multi-model sudah dapat dijawab secara positif, namun pertanyaan yang menarik adalah jenis DBMS mana yang akan lebih diminati dalam waktu dekat. Tampaknya DBMS multi-model yang mendukung model tradisional, terutama relasional, akan lebih banyak diminati; Popularitas DBMS multi-model, yang menawarkan model-model baru yang menggabungkan keunggulan berbagai model tradisional, adalah masalah masa depan yang lebih jauh.
Hanya pengguna terdaftar yang dapat berpartisipasi dalam survei. , silakan.
Apakah Anda menggunakan DBMS multi-model?
-
Kami tidak menggunakannya, kami menyimpan semuanya dalam satu DBMS dan dalam satu model
-
Kami menggunakan kemampuan multi-model DBMS tradisional
-
Kami mempraktikkan ketekunan poliglot
-
Kami menggunakan DBMS multi-model baru (Arango, Orient, CosmosDB)
19 pengguna memilih. 4 pengguna abstain.
Sumber: www.habr.com