Zamonaviy axborot tizimlari ancha murakkab. Eng muhimi, ularning murakkabligi ularda qayta ishlangan ma'lumotlarning murakkabligi bilan bog'liq. Ma'lumotlarning murakkabligi ko'pincha ishlatiladigan ma'lumotlar modellarining xilma-xilligi bilan bog'liq. Shunday qilib, masalan, ma'lumotlar "katta" bo'lganda, muammoli xususiyatlardan biri nafaqat uning hajmi ("hajmi"), balki uning xilma-xilligi ("xilma-xilligi").
Agar siz hali ham fikrlashda kamchilik topmagan bo'lsangiz, o'qing.
Mundarija
Poliglot qat'iyligi
Yuqorida aytilganlar shuni ko'rsatadiki, ba'zida bitta tizim doirasida ham ma'lumotlarni saqlash va ularni qayta ishlashning turli muammolarini hal qilish uchun bir nechta turli ma'lumotlar bazasidan foydalanish kerak bo'ladi, ularning har biri o'z ma'lumotlar modelini qo'llab-quvvatlaydi. M.Fowlerning engil qo'li bilan, bir qator mashhur kitoblar va ulardan biri Agile Manifest, bu holat deyiladi ko'p variantli saqlash (“Poliglot qat’iyligi”).
Fowler shuningdek, elektron tijorat sohasida to'liq xususiyatli va yuqori yuklangan ilovada ma'lumotlarni saqlashni tashkil qilishning quyidagi misoliga ega.
Bu misol, albatta, biroz bo'rttirilgan, ammo tegishli maqsad uchun u yoki bu DBMSni tanlash foydasiga ba'zi fikrlarni topish mumkin, masalan, .
Bunday hayvonot bog'ida xizmatkor bo'lish oson emasligi aniq.
- Ma'lumotni saqlashni amalga oshiradigan kod miqdori ishlatiladigan ma'lumotlar bazasining soniga mutanosib ravishda oshadi; kodni sinxronlash ma'lumotlarining miqdori, agar bu raqamning kvadratiga proportsional bo'lmasa, yaxshi.
- Amaldagi ma'lumotlar bazalari sonining ko'paytmasi sifatida, har bir foydalaniladigan ma'lumotlar bazasining korporativ xususiyatlarini (ko'lamlilik, nosozliklarga chidamlilik, yuqori mavjudligi) ta'minlash xarajatlari oshadi.
- Saqlash quyi tizimining korporativ xususiyatlarini umuman ta'minlash mumkin emas - ayniqsa tranzaksiya.
Hayvonot bog'i direktori nuqtai nazaridan, hamma narsa shunday ko'rinadi:
- DBMS ishlab chiqaruvchisidan litsenziyalar va texnik yordam narxining bir necha bor oshishi.
- Xodimlarni haddan tashqari oshirib yuborish va muddatlarni oshirish.
- Ma'lumotlarning nomuvofiqligi sababli to'g'ridan-to'g'ri moliyaviy yo'qotishlar yoki jarimalar.
Tizimning umumiy egalik qiymatida (TCO) sezilarli o'sish kuzatilmoqda. "Ko'p saqlash imkoniyatlari" holatidan chiqish yo'li bormi?
Ko'p modelli
"Ko'p o'lchovli saqlash" atamasi 2011 yilda ishlatilgan. Yondashuv muammolaridan xabardorlik va yechim izlash bir necha yil davom etdi va 2015 yilga kelib Gartner tahlilchilarining og'zi bilan javob quyidagicha shakllantirildi:
- dan ""
DBMS kelajagi, ularning arxitekturasi va ulardan foydalanish usullari ko'p modelli.
- dan ""
Etakchi operatsion DBMSlar bitta platformaning bir qismi sifatida bir nechta modellarni - aloqador va aloqador bo'lmagan modellarni taklif qiladi.
Aftidan, bu safar Gartner tahlilchilari o‘z prognozlari bilan to‘g‘ri chiqishdi. bilan sahifaga kirsangiz DB-Engines-dagi DBMS, buni ko'rishingiz mumkinоUning ko'pgina rahbarlari o'zlarini ko'p modelli DBMS sifatida ko'rsatishadi. Xuddi shu narsani har qanday shaxsiy reytingga ega sahifada ko'rish mumkin.
Quyidagi jadvalda ko'p modelli deb da'vo qilingan har bir xususiy reytingda yetakchilar - DBMS ko'rsatilgan. Har bir DBMS uchun asl qo'llab-quvvatlanadigan model (bir paytlar yagona bo'lgan) va u bilan birga hozirda qo'llab-quvvatlanadigan modellar ko'rsatilgan. Shuningdek, o'zlarini "dastlab ko'p modelli" deb ko'rsatadigan va yaratuvchilarga ko'ra, hech qanday boshlang'ich meros modeliga ega bo'lmagan DBMSlar ham ro'yxatga olingan.
| Ma'lumotlar bazasi | Dastlabki model | Qo'shimcha modellar |
|---|---|---|
| Oracle | Aloqaviy | Grafik, hujjat |
| MS SQL | Aloqaviy | Grafik, hujjat |
| PostgreSQL | Aloqaviy | Grafik*, hujjat |
| MarkLogic | Hujjatli film | Grafik, aloqador |
| MongoDB | Hujjatli film | Kalit-qiymat, grafik* |
| DataStax | Keng ustunli | Hujjatli film, grafik |
| Redis | Kalit-qiymat | Hujjatli film, grafik* |
| ArangoDB | - | Grafik, hujjat |
| OrientDB | - | Grafik, hujjat, relyatsion |
| Azure CosmosDB | - | Grafik, hujjat, relyatsion |
Stol ustidagi eslatmalar
Jadvaldagi yulduzchalar band qilishni talab qiladigan bayonotlarni belgilaydi:
- PostgreSQL DBMS grafik ma'lumotlar modelini qo'llab-quvvatlamaydi, lekin bu mahsulot uni qo'llab-quvvatlaydi , masalan, AgensGraph.
- MongoDB bilan bog'liq holda, so'rovlar tilida grafik operatorlarining mavjudligi haqida gapirish to'g'riroq (, ) grafik modelini qo'llab-quvvatlashdan ko'ra, garchi, albatta, ularni joriy etish grafik modelni qo'llab-quvvatlash yo'nalishi bo'yicha jismoniy saqlash darajasida ba'zi optimallashtirishlarni talab qildi.
- Redisga nisbatan biz kengaytmani nazarda tutamiz .
Keyinchalik, har bir sinf uchun biz ushbu sinfdagi DBMSda bir nechta modellarni qo'llab-quvvatlash qanday amalga oshirilishini ko'rsatamiz. Biz aloqadorlik, hujjat va grafik modellarni eng muhim deb hisoblaymiz va "yo'qolganlar" qanday amalga oshirilishini ko'rsatish uchun aniq ma'lumotlar bazalarining misollaridan foydalanamiz.
Relyatsion modelga asoslangan ko'p modelli DBMS
Hozirgi vaqtda etakchi DBMSlar relyatsiondir; Agar RDBMS ko'p modellashtirish yo'nalishi bo'yicha harakatni ko'rsatmasa, Gartnerning prognozini to'g'ri deb hisoblash mumkin emas. Va ular namoyish etadilar. Endi ko'p modelli DBMS shveytsariyalik pichog'iga o'xshaydi, u hech narsa qila olmaydi, to'g'ridan-to'g'ri Larri Ellisonga yo'naltirilishi mumkin.
Biroq, muallif Microsoft SQL Serverda ko'p modellashni amalga oshirishni afzal ko'radi, uning misolida hujjat va grafik modellarni RDBMS qo'llab-quvvatlashi tasvirlanadi.
MS SQL Serverda hujjat modeli
Habré-da MS SQL Server hujjat modelini qo'llab-quvvatlashni qanday amalga oshirishi haqida ikkita ajoyib maqola bor edi; Men o'zimni qisqacha takrorlash va sharhlash bilan cheklayman:
MS SQL Serverda hujjat modelini qo'llab-quvvatlash usuli relyatsion DBMSlar uchun odatiy holdir: JSON hujjatlarini oddiy matn maydonlarida saqlash tavsiya etiladi. Hujjat modelini qo'llab-quvvatlash ushbu JSON-ni tahlil qilish uchun maxsus operatorlarni taqdim etishdan iborat:
- skaler atribut qiymatlarini chiqarish uchun,
- pastki hujjatlarni chiqarish uchun.
Ikkala operatorning ikkinchi argumenti JSONPath-ga o'xshash sintaksisdagi ifodadir.
Xulosa qilib aytishimiz mumkinki, shu tarzda saqlangan hujjatlar kortejlardan farqli o'laroq, relyatsion DBMSda "birinchi darajali ob'ektlar" emas. Xususan, MS SQL Serverda hozirda JSON hujjatlari maydonlarida indekslar mavjud emas, bu esa ushbu maydonlar qiymatlari yordamida jadvallarni birlashtirishni va hatto ushbu qiymatlardan foydalangan holda hujjatlarni tanlashni qiyinlashtiradi. Biroq, bunday maydon uchun hisoblangan ustunni va undagi indeksni yaratish mumkin.
Bundan tashqari, MS SQL Server operator yordamida jadvallar tarkibidan JSON hujjatini qulay tarzda yaratish imkoniyatini beradi. - ma'lum ma'noda oldingisiga qarama-qarshi bo'lgan odatiy saqlash imkoniyati. Ko'rinib turibdiki, RDBMS qanchalik tez bo'lmasin, bu yondashuv asosan ommabop so'rovlarga tayyor javoblarni saqlaydigan hujjatlar ma'lumotlar bazasi ma'lumotlar bazasi mafkurasiga zid keladi va tezlikni emas, balki faqat ishlab chiqish qulayligi muammolarini hal qila oladi.
Va nihoyat, MS SQL Server sizga hujjatlarni tuzishning qarama-qarshi muammosini hal qilishga imkon beradi: JSON-ni jadvallarga ajratishingiz mumkin. . Agar hujjat butunlay tekis bo'lmasa, siz foydalanishingiz kerak bo'ladi CROSS APPLY.
MS SQL Serverda grafik modeli
Grafik (LPG) modelini qo'llab-quvvatlash Microsoft SQL Serverda ham to'liq amalga oshirilgan : Tugunlarni saqlash va grafik qirralarini saqlash uchun maxsus jadvallardan foydalanish taklif etiladi. Bunday jadvallar ifodalar yordamida tuziladi CREATE TABLE AS NODE и CREATE TABLE AS EDGE mos ravishda.
Birinchi turdagi jadvallar yozuvlarni saqlash uchun oddiy jadvallarga o'xshaydi, faqat tashqi farqi shundaki, jadvalda tizim maydoni mavjud. $node_id — maʼlumotlar bazasidagi grafik tugunning yagona identifikatori.
Xuddi shunday, ikkinchi turdagi jadvallar tizim maydonlariga ega $from_id и $to_id, bunday jadvallardagi yozuvlar tugunlar orasidagi aloqalarni aniq belgilaydi. Har bir turdagi munosabatlarni saqlash uchun alohida jadvaldan foydalaniladi.
Keling, buni bir misol bilan tushuntirib beraylik. Grafik ma'lumotlari rasmda ko'rsatilgandek tartibga ega bo'lsin. Keyin ma'lumotlar bazasida mos keladigan tuzilmani yaratish uchun siz quyidagi DDL so'rovlarini bajarishingiz kerak:
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);Bunday jadvallarning asosiy o'ziga xosligi shundaki, ularga qarshi so'rovlarda Cypher-ga o'xshash sintaksis bilan grafik naqshlardan foydalanish mumkin (ammo, "*"va boshqalar hali qo'llab-quvvatlanmaydi). Ishlash o'lchovlariga asoslanib, shuningdek, ushbu jadvallarda ma'lumotlarni saqlash usuli ma'lumotlarni oddiy jadvallarda saqlash usulidan farq qiladi va bunday grafik so'rovlarni bajarish uchun optimallashtirilgan deb taxmin qilish mumkin.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Bundan tashqari, bunday jadvallar bilan ishlashda ushbu grafik naqshlaridan foydalanmaslik juda qiyin, chunki shunga o'xshash muammolarni hal qilish uchun oddiy SQL so'rovlarida tizim "grafik" tugun identifikatorlarini olish uchun qo'shimcha harakatlar qilish kerak bo'ladi ($node_id, $from_id, $to_id; Xuddi shu sababga ko'ra, ma'lumotlarni kiritish uchun so'rovlar bu erda ko'rsatilmaydi, chunki ular keraksiz darajada noqulaydir).
MS SQL Serverda hujjat va grafik modellarni amalga oshirish tavsifini umumlashtirish uchun shuni ta'kidlab o'tishim kerakki, bir modelni ikkinchisining ustiga qo'yish, birinchi navbatda, til dizayni nuqtai nazaridan muvaffaqiyatli ko'rinmaydi. Bir tilni boshqa til bilan kengaytirish kerak, tillar to'liq "ortogonal" emas, muvofiqlik qoidalari juda g'alati bo'lishi mumkin.
Hujjat modeliga asoslangan ko'p modelli DBMS
Ushbu bo'limda men eng ommabop bo'lmagan MongoDB misolidan foydalanib, hujjatlarning ma'lumotlar bazasi tizimlarida ko'p modelni amalga oshirishni ko'rsatmoqchiman (aytilganidek, unda faqat shartli grafik operatorlari mavjud) $lookup и $graphLookup, parchalangan to'plamlarda ishlamaydi), lekin yanada etuk va "korxona" DBMS misolidan foydalanish .
Shunday qilib, to'plamda quyidagi turdagi XML hujjatlari to'plami bo'lsin (MarkLogic sizga JSON hujjatlarini saqlashga ham imkon beradi):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>MarkLogic-dagi relyatsion model
Hujjatlar to'plamining relyatsion ko'rinishi yordamida yaratilishi mumkin (elementlar tarkibi value quyidagi misolda ixtiyoriy XPath bo'lishi mumkin):
<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>Yaratilgan ko'rinishga SQL so'rovi bilan murojaat qilishingiz mumkin (masalan, ODBC orqali):
SELECT name, surname FROM Person WHERE name="John"Afsuski, displey shabloni tomonidan yaratilgan relyatsion ko'rinish faqat o'qish uchun mo'ljallangan. Buning uchun so'rovni qayta ishlashda MarkLogic foydalanishga harakat qiladi . Ilgari MarkLogic butunlay cheklangan munosabatlarga ega edi va yozilishi mumkin, ammo endi ular eskirgan deb hisoblanadi.
MarkLogic-da grafik modeli
Grafik (RDF) modelini qo'llab-quvvatlash bilan hamma narsa taxminan bir xil. Yana yordam bilan Yuqoridagi misoldan hujjatlar to'plamining RDF tasvirini yaratishingiz mumkin:
<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>Olingan RDF grafigiga SPARQL so'rovi bilan murojaat qilishingiz mumkin:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Aloqaviy modeldan farqli o'laroq, MarkLogic grafik modelini ikkita boshqa usulda qo'llab-quvvatlaydi:
- DBMS RDF ma'lumotlarining to'liq huquqli alohida saqlashi bo'lishi mumkin (undagi uchlik deb ataladi yuqorida tavsiflanganlardan farqli o'laroq ).
- Maxsus ketma-ketlikdagi RDF shunchaki XML yoki JSON hujjatlariga kiritilishi mumkin (va keyin tripletlar chaqiriladi) ). Bu, ehtimol, mexanizmlarga muqobildir
idrefva boshqalar.
MarkLogic-da narsalar "haqiqatan ham" qanday ishlashi haqida yaxshi fikr berilgan , bu ma'noda u past darajali, garchi uning maqsadi aksincha bo'lsa-da - foydalanilgan ma'lumotlar modelidan abstraktlashtirishga harakat qilish, turli modellardagi ma'lumotlar bilan izchil ishlashni ta'minlash, tranzaksiya va boshqalar.
Ko'p modelli DBMS "asosiy modelsiz"
Bozorda, shuningdek, hech qanday meros bo'lib qolgan asosiy modelsiz, o'zlarini dastlab ko'p modelli sifatida joylashtiradigan DBMSlar mavjud. Bularga kiradi , (2018 yildan boshlab ishlab chiqish kompaniyasi SAPga tegishli) va (Microsoft Azure bulutli platformasining bir qismi sifatida xizmat).
Aslida, ArangoDB va OrientDB da "yadro" modellari mavjud. Ikkala holatda ham bu o'zlarining ma'lumotlar modellari bo'lib, ular birinchi hujjatning umumlashtirilishi hisoblanadi. Umumlashtirishlar, asosan, grafik va relyatsion xarakterdagi so'rovlarni bajarish qobiliyatini osonlashtirish uchundir.
Ushbu modellar ko'rsatilgan DBMSda foydalanish uchun mavjud bo'lgan yagona modeldir, ularning so'rov tillari ular bilan ishlash uchun mo'ljallangan. Albatta, bunday modellar va ma'lumotlar bazasi tizimlari istiqbolli, ammo standart modellar va tillar bilan mos kelmasligi ushbu ma'lumotlar bazasidan eski tizimlarda foydalanishni imkonsiz qiladi - u erda allaqachon qo'llanilgan ma'lumotlar bazalarini almashtirish uchun.
Habré-da ArangoDB va OrientDB haqida ajoyib maqola allaqachon mavjud edi: .
ArangoDB
ArangoDB grafik ma'lumotlar modelini qo'llab-quvvatlaydi.
ArangoDB-dagi grafik tugunlari oddiy hujjatlardir, qirralari esa oddiy tizim maydonlari bilan bir qatorda maxsus turdagi hujjatlardir (_key, _id, _rev) tizim maydonlari _from и _to. Hujjat ma'lumotlar bazasidagi hujjatlar an'anaviy ravishda to'plamlarga birlashtiriladi. Qirralarni ifodalovchi hujjatlar to'plami ArangoDBda chekka to'plamlar deb ataladi. Aytgancha, chekka yig'ish hujjatlari ham hujjatlardir, shuning uchun ArangoDB-dagi qirralar ham tugun vazifasini bajarishi mumkin.
Xom ma'lumotlar
Keling, to'plamga ega bo'lamiz persons, uning hujjatlari quyidagicha ko'rinadi:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]To'plam ham bo'lsin cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Keyin to'plam likes quyidagicha ko'rinishi mumkin:
[
{
"_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
}
]So'rovlar va natijalar
ArangoDB da qoʻllaniladigan AQL tilidagi grafik uslubidagi soʻrov, kimga qaysi kafeni yoqtirishi haqidagi maʼlumotni odam oʻqishi mumkin boʻlgan shaklda qaytaruvchi soʻrov quyidagicha koʻrinadi:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }Biz munosabatlarni saqlash o'rniga ularni "hisoblash" uslubida, bu so'rovni shunday qayta yozish mumkin (aytmoqchi, to'plamsiz) likes holda mumkin):
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 }Ikkala holatda ham natija bir xil bo'ladi:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Ko'proq so'rovlar va natijalar
Agar yuqoridagi natija formati ma'lumotlar bazasi hujjatiga qaraganda relyatsion ma'lumotlar bazasi uchun odatiyroq bo'lsa, siz ushbu so'rovni sinab ko'rishingiz mumkin (yoki foydalanishingiz mumkin). ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Natija quyidagicha ko'rinadi:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
OrientDB da hujjat modeli ustiga grafik modelni amalga oshirish uchun asos hisoblanadi Hujjat maydonlari, ko'p yoki kamroq standart skalyar qiymatlardan tashqari, kabi turlarning qiymatlariga ham ega LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Ushbu turdagi qiymatlar havolalar yoki havolalar to'plamidir hujjatlar.
Tizim tomonidan tayinlangan hujjat identifikatori ma'lumotlar bazasidagi yozuvning o'rnini ko'rsatadigan "jismoniy ma'no" ga ega va shunday ko'rinadi: @rid : #3:16. Shunday qilib, mos yozuvlar xususiyatlarining qiymatlari tanlov shartlari (relyatsion modeldagi kabi) emas, balki haqiqatan ham ko'rsatkichlardir (grafik modelidagi kabi).
ArangoDB singari, OrientDB-dagi qirralar alohida hujjatlar sifatida taqdim etiladi (garchi chekka o'z xususiyatlariga ega bo'lmasa, uni amalga oshirish mumkin. , va u alohida hujjatga mos kelmaydi).
Xom ma'lumotlar
ga yaqin formatda OrientDB ma'lumotlar bazasi, ArangoDB uchun oldingi misoldagi ma'lumotlar quyidagicha ko'rinadi:
[
{
"@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"
}
]Ko'rib turganimizdek, tepaliklar kiruvchi va chiquvchi qirralar haqidagi ma'lumotlarni ham saqlaydi. Da Document API ma'lumotnoma yaxlitligini o'zi kuzatishi kerak va Graph API bu ishni o'z zimmasiga oladi. Ammo dasturlash tillariga integratsiya qilinmagan "sof" so'rov tillarida OrientDB-ga kirish qanday ko'rinishini ko'rib chiqaylik.
So'rovlar va natijalar
OrientDB'dagi ArangoDB misolidagi so'rovga o'xshash so'rov shunday ko'rinadi:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameNatija quyidagi shaklda olinadi:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Agar natija formati yana juda "aloqador" bo'lib ko'rinsa, qatorni olib tashlashingiz kerak :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]OrientDB so'rovlar tilini Gremlinga o'xshash qo'shimchalar bilan SQL sifatida ta'riflash mumkin. 2.2 versiyasida Cyph-ga o'xshash so'rov shakli paydo bo'ldi, :
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_nameNatija formati avvalgi so'rovdagi kabi bo'ladi. Birinchi so'rovda bo'lgani kabi, uni yanada "aloqador" qilish uchun nimani olib tashlash kerakligini o'ylab ko'ring.
Azure CosmosDB
ArangoDB va OrientDB haqida yuqorida aytilganlar ozroq darajada Azure CosmosDB uchun amal qiladi. CosmosDB quyidagi ma'lumotlarga kirish API-larini taqdim etadi: SQL, MongoDB, Gremlin va Cassandra.
SQL API va MongoDB API hujjat modelidagi ma'lumotlarga kirish uchun ishlatiladi. Gremlin API va Cassandra API - mos ravishda grafik va ustun formatidagi ma'lumotlarga kirish uchun. Barcha modellardagi ma'lumotlar CosmosDB ichki model formatida saqlanadi: (“atom-rekord-ketma-ket”), bu ham birinchi hujjatga yaqin.
Ammo foydalanuvchi tomonidan tanlangan ma'lumotlar modeli va ishlatiladigan API xizmatda hisob yaratish vaqtida belgilanadi. Bir modelga boshqa model formatida yuklangan maʼlumotlarga kirish imkoni yoʻq, buni quyidagicha koʻrish mumkin:
Shunday qilib, bugungi kunda Azure CosmosDB-dagi ko'p model faqat bitta ishlab chiqaruvchining turli modellarini qo'llab-quvvatlaydigan bir nechta ma'lumotlar bazalaridan foydalanish imkoniyatidir, bu ko'p variantli saqlashning barcha muammolarini hal qilmaydi.
Grafik modeliga asoslangan ko'p modelli DBMS?
Shunisi e'tiborga loyiqki, bozorda hali grafik modelga asoslangan ko'p modelli DBMS mavjud emas (bir vaqtning o'zida ikkita grafik modelni ko'p modelli qo'llab-quvvatlashdan tashqari: RDF va LPG; buni qarang. ). Eng katta qiyinchiliklar hujjat modelini relyatsion emas, balki grafik model ustida amalga oshirish bilan bog'liq.
Grafik modelning tepasida relyatsion modelni qanday amalga oshirish masalasi hatto ikkinchisini shakllantirish paytida ham ko'rib chiqildi. Qanaqasiga , masalan, :
Grafik ma'lumotlar bazasida qatlam yaratishga (masalan, mos indekslash orqali) to'sqinlik qiladigan grafik yondashuvga xos narsa yo'q, bu (1) odatiy kalit qiymat juftliklaridan kortejlarni tiklash va (2) guruhlash bilan bog'liq ko'rinishga imkon beradi. aloqa turi bo'yicha kortejlar.
Hujjat modelini grafik model ustiga qo'llashda siz, masalan, quyidagilarni yodda tutishingiz kerak:
- JSON massivining elementlari tartibli hisoblanadi, lekin grafik chetining tepasidan chiquvchi elementlar tartibli emas;
- Hujjat modelidagi ma'lumotlar odatda denormalizatsiya qilinadi, siz hali ham bir xil o'rnatilgan hujjatning bir nechta nusxalarini saqlashni xohlamaysiz va pastki hujjatlarda odatda identifikatorlar bo'lmaydi;
- Boshqa tomondan, hujjatlar ma'lumotlar bazasi mafkurasi shundan iboratki, hujjatlar har safar yangidan qurishni talab qilmaydigan tayyor "agregatlar". Grafik modelni tayyor hujjatga mos keladigan pastki grafikni tezda olish qobiliyati bilan ta'minlash talab qilinadi.
Bir oz reklama
Maqola muallifi NitrosBase DBMSni ishlab chiqish bilan bog'liq bo'lib, uning ichki modeli grafik, tashqi modellari - relyatsion va hujjat - uning tasvirlari. Barcha modellar tengdir: deyarli har qanday ma'lumotlar ularning har birida o'ziga xos bo'lgan so'rovlar tilidan foydalangan holda mavjud. Bundan tashqari, har qanday ko'rinishda ma'lumotlarni o'zgartirish mumkin. O'zgarishlar ichki modelda va shunga mos ravishda boshqa ko'rinishlarda aks etadi.
Umid qilamanki, NitrosBase-da modelga mos kelish qanday ko'rinishini keyingi maqolalardan birida tasvirlab beraman.
xulosa
Umid qilamanki, ko'p modellashtirish deb ataladigan narsaning umumiy konturlari o'quvchiga ko'proq yoki kamroq tushunarli bo'ldi. Ko'p modelli DBMSlar butunlay boshqacha va "ko'p modelli qo'llab-quvvatlash" boshqacha ko'rinishi mumkin. Har bir alohida holatda "ko'p model" deb ataladigan narsani tushunish uchun quyidagi savollarga javob berish foydali bo'ladi:
- Biz an'anaviy modellarni yoki qandaydir "gibrid" modelni qo'llab-quvvatlash haqida gapiramizmi?
- Modellar "teng"mi yoki ulardan biri boshqalarning mavzusimi?
- Modellar bir-biriga "befarq"mi? Bir modelda yozilgan ma'lumotlarni boshqasida o'qish yoki hatto ustiga yozish mumkinmi?
O'ylaymanki, ko'p modelli DBMSning dolzarbligi haqidagi savolga allaqachon ijobiy javob berish mumkin, ammo qiziqarli savol shundaki, yaqin kelajakda ularning qaysi turlariga talab ko'proq bo'ladi. Ko'rinishidan, an'anaviy modellarni qo'llab-quvvatlaydigan ko'p modelli DBMSlar, birinchi navbatda, relyatsion, ko'proq talabga ega bo'ladi; Turli xil an'anaviylarning afzalliklarini birlashtirgan yangi modellarni taklif qiluvchi ko'p modelli DBMSlarning mashhurligi uzoq kelajak masalasidir.
So'rovda faqat ro'yxatdan o'tgan foydalanuvchilar ishtirok etishlari mumkin. iltimos.
Ko'p modelli DBMS dan foydalanasizmi?
-
Biz undan foydalanmaymiz, biz hamma narsani bitta DBMSda va bitta modelda saqlaymiz
-
Biz an'anaviy DBMSlarning ko'p modelli imkoniyatlaridan foydalanamiz
-
Biz poliglot qat'iyligini mashq qilamiz
-
Biz yangi ko'p modelli DBMS dan foydalanamiz (Arango, Orient, CosmosDB)
19 nafar foydalanuvchi ovoz berdi. 4 nafar foydalanuvchi betaraf qolgan.
Manba: www.habr.com