Sistem maklumat moden agak kompleks. Tidak kurang daripada semua, kerumitan mereka adalah disebabkan oleh kerumitan data yang diproses di dalamnya. Kerumitan data selalunya terletak pada kepelbagaian model data yang digunakan. Jadi, sebagai contoh, apabila data menjadi "besar", salah satu ciri yang bermasalah bukan sahaja kelantangannya ("isipadu"), tetapi juga kepelbagaiannya ("pelbagai").
Jika anda masih belum menemui kelemahan dalam penaakulan, maka bacalah.
Содержание
Kegigihan poliglot
Perkara di atas membawa kepada fakta bahawa kadang-kadang walaupun dalam rangka kerja satu sistem adalah perlu untuk menggunakan beberapa DBMS yang berbeza untuk menyimpan data dan menyelesaikan pelbagai masalah memprosesnya, yang setiap satunya menyokong model datanya sendiri. Dengan tangan ringan M. Fowler, beberapa buku terkenal dan salah satunya Manifesto Tangkas, keadaan ini dipanggil storan pelbagai varian (“kegigihan poliglot”).
Fowler juga mempunyai contoh berikut untuk mengatur penyimpanan data dalam aplikasi berciri penuh dan muatan tinggi dalam bidang e-dagang.
Contoh ini, sudah tentu, agak dibesar-besarkan, tetapi beberapa pertimbangan yang memihak kepada memilih satu atau satu lagi DBMS untuk tujuan yang sepadan boleh didapati, contohnya, .
Jelas bahawa menjadi hamba di zoo sebegitu bukanlah mudah.
- Jumlah kod yang melakukan storan data meningkat mengikut kadar bilangan DBMS yang digunakan; jumlah data penyegerakan kod adalah baik jika tidak berkadar dengan kuasa dua nombor ini.
- Sebagai gandaan bilangan DBMS yang digunakan, kos untuk menyediakan ciri perusahaan (kebolehskalaan, toleransi kesalahan, ketersediaan tinggi) bagi setiap DBMS yang digunakan meningkat.
- Adalah mustahil untuk memastikan ciri perusahaan subsistem storan secara keseluruhan - terutamanya transaksi.
Dari sudut pandangan pengarah zoo, semuanya kelihatan seperti ini:
- Peningkatan berganda dalam kos lesen dan sokongan teknikal daripada pengilang DBMS.
- Berlebihan kakitangan dan peningkatan tarikh akhir.
- Kerugian kewangan langsung atau penalti akibat ketidakkonsistenan data.
Terdapat peningkatan yang ketara dalam jumlah kos pemilikan (TCO) sistem. Adakah terdapat sebarang jalan keluar daripada situasi "pilihan storan berbilang"?
Pelbagai model
Istilah "storan pelbagai jenis" mula digunakan pada tahun 2011. Kesedaran tentang masalah pendekatan dan pencarian penyelesaian mengambil masa beberapa tahun, dan menjelang 2015, melalui mulut penganalisis Gartner, jawapannya telah dirumuskan:
- daripada ""
Masa depan DBMS, seni bina dan cara menggunakannya adalah pelbagai model.
- daripada ""
DBMS operasi terkemuka akan menawarkan berbilang model—hubungan dan bukan hubungan—sebagai sebahagian daripada satu platform.
Nampaknya kali ini penganalisis Gartner betul dengan ramalan mereka. Jika anda pergi ke halaman dengan DBMS pada DB-Engines, anda boleh melihatnyaоKebanyakan pemimpinnya meletakkan diri mereka secara khusus sebagai DBMS berbilang model. Perkara yang sama boleh dilihat pada halaman dengan sebarang penilaian peribadi.
Jadual di bawah menunjukkan DBMS - peneraju dalam setiap penilaian peribadi, yang mendakwa sebagai berbilang model. Bagi setiap DBMS, model asal yang disokong (yang dahulunya satu-satunya) dan bersama-sama model yang disokong pada masa ini ditunjukkan. Turut disenaraikan ialah DBMS yang meletakkan diri mereka sebagai "berbilang model asal" dan, menurut pencipta, tidak mempunyai sebarang model warisan awal.
| DBMS | Model awal | Model tambahan |
|---|---|---|
| Oracle | perhubungan | Graf, dokumen |
| MS SQL | perhubungan | Graf, dokumen |
| PostgreSQL | perhubungan | Graf*, dokumen |
| MarkLogic | Dokumentari | Graf, hubungan |
| MongoDB | Dokumentari | Nilai kunci, graf* |
| DataStax | Lajur lebar | Dokumentari, graf |
| Redis | Nilai-kunci | Dokumentari, graf* |
| ArangoDB | - | Graf, dokumen |
| OrientDB | - | Graf, dokumen, hubungan |
| Azure CosmosDB | - | Graf, dokumen, hubungan |
Nota meja
Asterisk dalam penyataan menandakan jadual yang memerlukan tempahan:
- DBMS PostgreSQL tidak menyokong model data graf, tetapi produk ini menyokongnya , seperti AgensGraph.
- Berhubung dengan MongoDB, adalah lebih tepat untuk bercakap tentang kehadiran pengendali graf dalam bahasa pertanyaan (, ) daripada menyokong model graf, walaupun, sudah tentu, pengenalannya memerlukan beberapa pengoptimuman pada tahap storan fizikal ke arah menyokong model graf.
- Berhubung dengan Redis, kami maksudkan sambungan .
Seterusnya, untuk setiap kelas, kami akan menunjukkan bagaimana sokongan untuk beberapa model dilaksanakan dalam DBMS daripada kelas ini. Kami akan menganggap model hubungan, dokumen dan graf sebagai yang paling penting dan menggunakan contoh DBMS khusus untuk menunjukkan cara "yang hilang" dilaksanakan.
DBMS berbilang model berdasarkan model hubungan
DBMS terkemuka pada masa ini adalah hubungan; Ramalan Gartner tidak boleh dianggap benar jika RDBMS tidak menunjukkan pergerakan ke arah pemodelan berbilang. Dan mereka berdemonstrasi. Kini idea bahawa DBMS berbilang model adalah seperti pisau Swiss, yang tidak dapat melakukan apa-apa dengan baik, boleh ditujukan terus kepada Larry Ellison.
Penulis, bagaimanapun, lebih suka pelaksanaan multi-modeling dalam Microsoft SQL Server, sebagai contoh sokongan RDBMS untuk model dokumen dan graf akan diterangkan.
Model dokumen dalam MS SQL Server
Terdapat dua artikel yang sangat baik tentang Habré tentang cara MS SQL Server melaksanakan sokongan untuk model dokumen; Saya akan mengehadkan diri saya kepada penceritaan semula dan ulasan ringkas:
Cara untuk menyokong model dokumen dalam MS SQL Server adalah agak tipikal untuk DBMS hubungan: Dokumen JSON dicadangkan untuk disimpan dalam medan teks biasa. Sokongan untuk model dokumen adalah untuk menyediakan operator khas untuk menghuraikan JSON ini:
- untuk mengekstrak nilai atribut skalar,
- untuk mengekstrak sub-dokumen.
Argumen kedua bagi kedua-dua pengendali ialah ungkapan dalam sintaks seperti JSONPath.
Secara ringkas, kita boleh mengatakan bahawa dokumen yang disimpan dengan cara ini bukanlah "entiti kelas pertama" dalam DBMS hubungan, tidak seperti tupel. Khususnya, dalam MS SQL Server pada masa ini tiada indeks pada medan dokumen JSON, yang menjadikannya sukar untuk menyertai jadual menggunakan nilai medan ini dan juga memilih dokumen menggunakan nilai ini. Walau bagaimanapun, adalah mungkin untuk membuat lajur yang dikira untuk medan sedemikian dan indeks di atasnya.
Selain itu, MS SQL Server menyediakan keupayaan untuk membina dokumen JSON dengan mudah daripada kandungan jadual menggunakan operator. - kemungkinan, dalam erti kata tertentu, bertentangan dengan yang sebelumnya, penyimpanan konvensional. Adalah jelas bahawa tidak kira betapa pantasnya RDBMS, pendekatan ini bercanggah dengan ideologi DBMS dokumen, yang pada asasnya menyimpan jawapan siap sedia untuk pertanyaan popular, dan hanya boleh menyelesaikan masalah kemudahan pembangunan, tetapi bukan kepantasan.
Akhir sekali, MS SQL Server membolehkan anda menyelesaikan masalah bertentangan pembinaan dokumen: anda boleh menguraikan JSON ke dalam jadual menggunakan . Jika dokumen tidak rata sepenuhnya, anda perlu menggunakan CROSS APPLY.
Model graf dalam MS SQL Server
Sokongan untuk model graf (LPG) juga dilaksanakan sepenuhnya dalam Microsoft SQL Server : Adalah dicadangkan untuk menggunakan jadual khas untuk menyimpan nod dan untuk menyimpan tepi graf. Jadual sedemikian dibuat menggunakan ungkapan CREATE TABLE AS NODE и CREATE TABLE AS EDGE masing-masing.
Jadual jenis pertama adalah serupa dengan jadual biasa untuk menyimpan rekod, dengan satu-satunya perbezaan luaran ialah jadual mengandungi medan sistem $node_id — pengecam unik nod graf dalam pangkalan data.
Begitu juga, jadual jenis kedua mempunyai medan sistem $from_id и $to_id, entri dalam jadual sedemikian jelas mentakrifkan sambungan antara nod. Jadual berasingan digunakan untuk menyimpan perhubungan bagi setiap jenis.
Mari kita gambarkan ini dengan contoh. Biarkan data graf mempunyai susun atur seperti yang ditunjukkan dalam rajah. Kemudian untuk mencipta struktur yang sepadan dalam pangkalan data, anda perlu menjalankan pertanyaan 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 jadual sedemikian adalah bahawa dalam pertanyaan terhadapnya adalah mungkin untuk menggunakan corak graf dengan sintaks seperti Cypher (namun, "*"dan lain-lain masih belum disokong). Berdasarkan pengukuran prestasi, ia juga boleh diandaikan bahawa cara data disimpan dalam jadual ini berbeza daripada cara data disimpan dalam jadual biasa dan dioptimumkan untuk melaksanakan pertanyaan graf tersebut.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Lebih-lebih lagi, agak sukar untuk tidak menggunakan corak graf ini apabila bekerja dengan jadual sedemikian, kerana dalam pertanyaan SQL biasa untuk menyelesaikan masalah yang sama adalah perlu untuk membuat usaha tambahan untuk mendapatkan pengecam nod "graf" sistem ($node_id, $from_id, $to_id; Atas sebab yang sama, pertanyaan untuk memasukkan data tidak ditunjukkan di sini kerana ia tidak semestinya menyusahkan).
Untuk meringkaskan huraian pelaksanaan model dokumen dan graf dalam MS SQL Server, saya akan ambil perhatian bahawa pelaksanaan seperti satu model di atas model lain nampaknya tidak berjaya, terutamanya dari sudut pandangan reka bentuk bahasa. Ia adalah perlu untuk melanjutkan satu bahasa dengan yang lain, bahasa itu tidak sepenuhnya "ortogon", peraturan keserasian boleh menjadi agak pelik.
DBMS berbilang model berdasarkan model dokumen
Dalam bahagian ini, saya ingin menggambarkan pelaksanaan pelbagai model dalam DBMS dokumen menggunakan contoh yang tidak paling popular daripada mereka, MongoDB (seperti yang dikatakan, ia hanya mempunyai pengendali graf bersyarat $lookup и $graphLookup, tidak bekerja pada koleksi berpecah), tetapi menggunakan contoh DBMS yang lebih matang dan "perusahaan" .
Jadi, biarkan koleksi mengandungi satu set dokumen XML jenis berikut (MarkLogic juga membenarkan anda menyimpan dokumen JSON):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Model perhubungan dalam MarkLogic
Pandangan hubungan koleksi dokumen boleh dibuat menggunakan (kandungan unsur value dalam contoh di bawah boleh ada XPath sewenang-wenangnya):
<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 boleh menangani paparan yang dibuat dengan pertanyaan SQL (contohnya, melalui ODBC):
SELECT name, surname FROM Person WHERE name="John"Malangnya, paparan hubungan yang dibuat oleh templat paparan adalah baca sahaja. Apabila memproses permintaan untuknya, MarkLogic akan cuba menggunakannya . Sebelum ini, MarkLogic mempunyai pandangan hubungan yang terhad, sepenuhnya dan boleh ditulis, tetapi kini ia dianggap tidak digunakan lagi.
Model graf dalam MarkLogic
Dengan sokongan untuk model graf (RDF), semuanya adalah lebih kurang sama. Sekali lagi dengan bantuan Anda boleh membuat perwakilan RDF bagi koleksi dokumen daripada 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 boleh menangani graf RDF yang terhasil dengan pertanyaan SPARQL:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Tidak seperti hubungan, MarkLogic menyokong model graf dalam dua cara lain:
- DBMS boleh menjadi storan berasingan lengkap data RDF (triplet di dalamnya akan dipanggil berbeza dengan yang diterangkan di atas ).
- RDF dalam siri khas hanya boleh dimasukkan ke dalam dokumen XML atau JSON (dan kembar tiga kemudiannya akan dipanggil ). Ini mungkin alternatif kepada mekanisme
idrefdan lain-lain
Idea yang baik tentang bagaimana perkara "benar-benar" berfungsi dalam MarkLogic diberikan oleh , dalam pengertian ini, ia adalah tahap rendah, walaupun tujuannya agak bertentangan - untuk cuba mengabstrak daripada model data yang digunakan, untuk memastikan kerja yang konsisten dengan data dalam model yang berbeza, transaksi, dsb.
DBMS berbilang model "tanpa model utama"
Terdapat juga DBMS di pasaran yang meletakkan diri mereka sebagai berbilang model pada mulanya, tanpa sebarang model utama yang diwarisi. Ini termasuk , (sejak 2018 syarikat pembangunan milik SAP) dan (perkhidmatan sebagai sebahagian daripada platform awan Microsoft Azure).
Malah, terdapat model "teras" dalam ArangoDB dan OrientDB. Dalam kedua-dua kes, ini adalah model data mereka sendiri, yang merupakan generalisasi dokumen satu. Generalisasi adalah terutamanya untuk memudahkan keupayaan untuk melakukan pertanyaan graf dan sifat perhubungan.
Model ini adalah satu-satunya model yang tersedia untuk digunakan dalam DBMS yang ditentukan; bahasa pertanyaan mereka sendiri direka bentuk untuk berfungsi dengan mereka. Sudah tentu, model dan DBMS sedemikian menjanjikan, tetapi kekurangan keserasian dengan model dan bahasa standard menjadikannya mustahil untuk menggunakan DBMS ini dalam sistem warisan—untuk menggantikan DBMS yang telah digunakan di sana.
Sudah ada artikel menarik tentang ArangoDB dan OrientDB di Habré: .
ArangoDB
ArangoDB menuntut sokongan untuk model data graf.
Nod graf dalam ArangoDB ialah dokumen biasa, dan tepinya ialah dokumen jenis khas yang, bersama dengan medan sistem biasa, mempunyai (_key, _id, _rev) medan sistem _from и _to. Dokumen dalam DBMS dokumen secara tradisinya digabungkan ke dalam koleksi. Koleksi dokumen yang mewakili tepi dipanggil koleksi tepi dalam ArangoDB. Dengan cara ini, dokumen pengumpulan tepi juga merupakan dokumen, jadi tepi dalam ArangoDB juga boleh bertindak sebagai nod.
Data mentah
Jom kita ada koleksi persons, yang dokumennya kelihatan seperti ini:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Biar ada koleksi juga cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Kemudian koleksi likes mungkin kelihatan 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 keputusan
Pertanyaan gaya graf dalam bahasa AQL yang digunakan dalam ArangoDB, mengembalikan dalam bentuk maklumat yang boleh dibaca manusia tentang siapa yang suka kafe mana, kelihatan seperti ini:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }Dalam gaya perhubungan, di mana kita "mengira" perhubungan dan bukannya menyimpannya, pertanyaan ini boleh ditulis semula seperti ini (dengan cara ini, tanpa koleksi likes boleh buat 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 }Keputusan dalam kedua-dua kes adalah sama:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Lebih banyak pertanyaan dan keputusan
Jika format hasil di atas nampaknya lebih tipikal untuk DBMS hubungan berbanding DBMS dokumen, anda boleh mencuba pertanyaan ini (atau anda boleh menggunakan ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Hasilnya akan kelihatan seperti ini:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
Asas untuk melaksanakan model graf di atas model dokumen dalam OrientDB ialah medan dokumen, sebagai tambahan kepada lebih kurang nilai skalar standard, juga mempunyai nilai jenis seperti LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Nilai jenis ini ialah pautan atau koleksi pautan ke dokumen.
Pengecam dokumen yang diberikan oleh sistem mempunyai "makna fizikal", menunjukkan kedudukan rekod dalam pangkalan data, dan kelihatan seperti ini: @rid : #3:16. Oleh itu, nilai sifat rujukan adalah benar-benar penunjuk (seperti dalam model graf) dan bukannya keadaan pemilihan (seperti dalam model hubungan).
Seperti ArangoDB, tepi dalam OrientDB diwakili sebagai dokumen berasingan (walaupun jika tepi tidak mempunyai sifatnya sendiri, ia boleh dibuat , dan ia tidak akan sepadan dengan dokumen yang berasingan).
Data mentah
Dalam format yang hampir dengan Pangkalan data OrientDB, data daripada contoh sebelumnya untuk ArangoDB akan kelihatan 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 kita dapat lihat, bucu juga menyimpan maklumat tentang tepi masuk dan keluar. Pada API Dokumen perlu memantau integriti rujukan itu sendiri, dan API Graf menjalankan kerja ini. Tetapi mari kita lihat bagaimana akses kepada OrientDB kelihatan dalam bahasa pertanyaan "tulen" yang tidak disepadukan ke dalam bahasa pengaturcaraan.
Pertanyaan dan keputusan
Pertanyaan yang serupa dengan tujuan pertanyaan daripada contoh untuk ArangoDB dalam OrientDB kelihatan seperti ini:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameHasilnya akan diperolehi dalam bentuk berikut:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Jika format hasil sekali lagi kelihatan terlalu "berkaitan", anda perlu mengalih keluar baris dengan :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]Bahasa pertanyaan OrientDB boleh digambarkan sebagai SQL dengan sisipan seperti Gremlin. Dalam versi 2.2, borang 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 keputusan akan sama seperti dalam permintaan sebelumnya. Fikirkan tentang perkara yang perlu dialih keluar untuk menjadikannya lebih "berkaitan", seperti dalam pertanyaan pertama.
Azure CosmosDB
Pada tahap yang lebih rendah, perkara yang dinyatakan di atas tentang ArangoDB dan OrientDB terpakai kepada 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. API Gremlin dan API Cassandra - masing-masing untuk mengakses data dalam format graf dan lajur. Data dalam semua model disimpan dalam format model dalaman CosmosDB: (“urutan rekod-atom”), yang juga hampir dengan dokumen satu.
Tetapi model data yang dipilih oleh pengguna dan API yang digunakan ditetapkan pada masa membuat akaun dalam perkhidmatan. Tidak mungkin untuk mengakses data yang dimuatkan dalam satu model dalam format model lain, seperti yang digambarkan oleh sesuatu seperti ini:
Oleh itu, berbilang model dalam Azure CosmosDB hari ini hanyalah keupayaan untuk menggunakan beberapa pangkalan data yang menyokong model berbeza daripada satu pengeluar, yang tidak menyelesaikan semua masalah storan berbilang varian.
DBMS berbilang model berdasarkan model graf?
Perlu diberi perhatian ialah hakikat bahawa belum ada DBMS berbilang model di pasaran yang berdasarkan model graf (kecuali sokongan berbilang model untuk dua model graf serentak: RDF dan LPG; lihat ini dalam ). Kesukaran terbesar adalah disebabkan oleh pelaksanaan model dokumen di atas model graf, dan bukannya model hubungan.
Persoalan bagaimana untuk melaksanakan model hubungan di atas model graf telah dipertimbangkan walaupun semasa pembentukan model yang terakhir. Bagaimana , sebagai contoh, :
Tiada apa-apa yang wujud dalam pendekatan graf yang menghalang penciptaan lapisan (cth, dengan pengindeksan yang sesuai) pada pangkalan data graf yang membolehkan pandangan hubungan dengan (1) pemulihan tupel daripada pasangan nilai kunci biasa dan (2) pengelompokan tupel mengikut jenis hubungan.
Apabila melaksanakan model dokumen di atas model graf, anda perlu mengingati, sebagai contoh, perkara berikut:
- Elemen tatasusunan JSON dianggap tersusun, tetapi elemen yang terpancar daripada bucu tepi graf tidak;
- Data dalam model dokumen biasanya dinyahnormalkan; anda masih tidak mahu menyimpan beberapa salinan dokumen terbenam yang sama dan subdokumen biasanya tidak mempunyai pengecam;
- Sebaliknya, ideologi DBMS dokumen ialah dokumen adalah "agregat" siap pakai yang tidak perlu dibina semula setiap kali. Ia dikehendaki menyediakan model graf dengan keupayaan untuk mendapatkan subgraf yang sepadan dengan dokumen siap dengan cepat.
Sedikit pengiklanan
Penulis artikel berkaitan dengan pembangunan DBMS NitrosBase, model dalaman yang graf, dan model luaran - hubungan dan dokumen - adalah perwakilannya. Semua model adalah sama: hampir mana-mana data tersedia dalam mana-mana daripadanya menggunakan bahasa pertanyaan yang sesuai dengannya. Lebih-lebih lagi, dalam sebarang pandangan, data boleh diubah. Perubahan akan dicerminkan dalam model dalaman dan, oleh itu, dalam pandangan lain.
Mudah-mudahan saya akan menerangkan rupa padanan model dalam NitrosBase dalam salah satu artikel berikut.
Kesimpulan
Saya berharap bahawa kontur umum apa yang dipanggil multi-modeling telah menjadi lebih atau kurang jelas kepada pembaca. DBMS berbilang model agak berbeza, dan "sokongan berbilang model" boleh kelihatan berbeza. Untuk memahami apa yang dipanggil "pelbagai model" dalam setiap kes tertentu, adalah berguna untuk menjawab soalan berikut:
- Adakah kita bercakap tentang menyokong model tradisional atau sejenis model "hibrid"?
- Adakah model "sama", atau adakah salah satu daripadanya menjadi subjek yang lain?
- Adakah model "tidak peduli" antara satu sama lain? Bolehkah data yang ditulis dalam satu model dibaca dalam model lain atau bahkan ditimpa?
Saya berpendapat bahawa persoalan tentang perkaitan DBMS berbilang model sudah boleh dijawab secara positif, tetapi persoalan yang menarik ialah jenis mereka yang akan lebih diminati dalam masa terdekat. Nampaknya DBMS berbilang model yang menyokong model tradisional, terutamanya hubungan, akan mendapat permintaan yang lebih besar; Populariti DBMS berbilang model, menawarkan model baharu yang menggabungkan kelebihan pelbagai model tradisional, adalah soal masa depan yang lebih jauh.
Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. , Sama-sama.
Adakah anda menggunakan DBMS berbilang model?
-
Kami tidak menggunakannya, kami menyimpan segala-galanya dalam satu DBMS dan dalam satu model
-
Kami menggunakan keupayaan berbilang model DBMS tradisional
-
Kami mengamalkan kegigihan polyglot
-
Kami menggunakan DBMS berbilang model baharu (Arango, Orient, CosmosDB)
19 pengguna mengundi. 4 pengguna berpantang.
Sumber: www.habr.com