Müasir informasiya sistemləri kifayət qədər mürəkkəbdir. Ən azı, onların mürəkkəbliyi onlarda işlənmiş məlumatların mürəkkəbliyi ilə bağlıdır. Verilənlərin mürəkkəbliyi çox vaxt istifadə olunan məlumat modellərinin müxtəlifliyindədir. Beləliklə, məsələn, verilənlər "böyük" olduqda problemli xüsusiyyətlərdən biri təkcə onun həcmi ("həcmi") deyil, həm də müxtəlifliyidir ("müxtəliflik").
Əgər əsaslandırmada hələ bir qüsur tapmamısınızsa, oxuyun.
Məzmun
Poliqlot əzmkarlığı
Yuxarıda göstərilənlər ona gətirib çıxarır ki, bəzən hətta bir sistem çərçivəsində məlumatları saxlamaq və onların emalı ilə bağlı müxtəlif problemləri həll etmək üçün bir neçə fərqli DBMS-dən istifadə etmək lazımdır, hər biri öz məlumat modelini dəstəkləyir. M.Fowlerin yüngül əli ilə, bir sıra məşhur kitablar və onlardan biri Bu vəziyyətə Çevik Manifest deyilir çoxvariantlı saxlama (“Poliqlot əzmkarlığı”).
Fowler həmçinin e-ticarət sahəsində tam xüsusiyyətli və yüksək yükləmə tətbiqində məlumatların saxlanmasını təşkil etmək üçün aşağıdakı nümunəyə malikdir.
Bu nümunə, əlbəttə ki, bir qədər şişirdilmişdir, lakin müvafiq məqsəd üçün bu və ya digər DBMS-nin seçilməsi lehinə bəzi mülahizələr tapıla bilər, məsələn, .
Aydındır ki, belə zooparkda qulluqçu olmaq asan deyil.
- Məlumatların saxlanmasını həyata keçirən kodun miqdarı istifadə olunan DBMS-lərin sayına mütənasib olaraq artır; kodu sinxronizasiya edən məlumatların miqdarı bu ədədin kvadratına mütənasib olmasa yaxşıdır.
- İstifadə olunan DBMS-lərin sayının çoxluğu kimi, istifadə olunan DBMS-lərin hər birinin müəssisə xüsusiyyətlərini (miqyaslılıq, səhvlərə dözümlülük, yüksək əlçatanlıq) təmin etmək xərcləri artır.
- Bütövlükdə saxlama alt sisteminin müəssisə xüsusiyyətlərini - xüsusən də əməliyyat qabiliyyətini təmin etmək mümkün deyil.
Zoopark direktorunun nöqteyi-nəzərindən hər şey belə görünür:
- DBMS istehsalçısından lisenziyaların və texniki dəstəyin qiymətində dəfələrlə artım.
- Həddindən artıq işçi heyəti və müddətlərin artırılması.
- Məlumatların uyğunsuzluğu səbəbindən birbaşa maliyyə itkiləri və ya cərimələr.
Sistemin ümumi sahiblik dəyərində (TCO) əhəmiyyətli artım var. "Çoxlu saxlama variantları" vəziyyətindən çıxış yolu varmı?
Çox modelli
“Çoxvariantlı saxlama” termini 2011-ci ildə istifadəyə verilib. Yanaşma problemləri haqqında məlumatlılıq və həll yolu axtarışı bir neçə il çəkdi və 2015-ci ilə qədər Gartner analitiklərinin ağızları ilə cavab formalaşdırıldı:
- From "'
DBMS-lərin gələcəyi, onların arxitekturası və onlardan istifadə üsulları çox modellidir.
- From "'
Aparıcı əməliyyat DBMS-ləri bir platformanın bir hissəsi kimi bir çox modelləri - əlaqəli və qeyri-relational - təklif edəcəkdir.
Görünür, bu dəfə Gartner analitikləri öz proqnozlarında haqlı idilər. ilə səhifəyə keçsəniz DB-Engines-də DBMS, bunu görə bilərsinizоOnun liderlərinin əksəriyyəti özlərini xüsusi olaraq çox modelli DBMS kimi yerləşdirirlər. Eyni şeyi hər hansı şəxsi reytinqi olan səhifədə görmək olar.
Aşağıdakı cədvəl DBMS-ni göstərir - çox modelli olduğunu iddia edən hər bir özəl reytinqdə liderlər. Hər bir DBMS üçün orijinal dəstəklənən model (bir vaxtlar yeganə idi) və onunla birlikdə hazırda dəstəklənən modellər göstərilir. Özlərini “əvvəlcə çox modelli” kimi yerləşdirən və yaradıcıların fikrincə, ilkin irsi modelə malik olmayan DBMS-lər də sadalanır.
| DBMS | İlkin model | Əlavə modellər |
|---|---|---|
| Kahin | əlaqəli | Qrafik, sənəd |
| MS SQL | əlaqəli | Qrafik, sənəd |
| PostgreSQL | əlaqəli | Qrafik*, sənəd |
| MarkLogic | Sənədli | Qrafik, əlaqə |
| MongoDB | Sənədli | Açar-dəyər, qrafik* |
| Data Stax | Geniş sütunlu | Sənədli film, qrafik |
| Redis | Açar-dəyər | Sənədli film, qrafik* |
| ArangoDB | - | Qrafik, sənəd |
| OrientDB | - | Qrafik, sənəd, əlaqə |
| Azure CosmosDB | - | Qrafik, sənəd, əlaqə |
Masanın üzərindəki qeydlər
Cədvəldəki ulduzlar qeyd-şərt tələb edən ifadələri qeyd edir:
- PostgreSQL DBMS qrafik məlumat modelini dəstəkləmir, lakin bu məhsul onu dəstəkləyir , məsələn, AgensGraph.
- MongoDB ilə əlaqədar olaraq, sorğu dilində qrafik operatorlarının olması haqqında danışmaq daha düzgündür (, ) qrafik modelini dəstəkləməkdən daha çox, baxmayaraq ki, əlbəttə ki, onların tətbiqi qrafik modelini dəstəkləmək istiqamətində fiziki yaddaş səviyyəsində bəzi optimallaşdırmaları tələb etdi.
- Redis ilə əlaqədar olaraq biz uzantı nəzərdə tuturuq .
Sonra, siniflərin hər biri üçün bu sinifdən DBMS-də bir neçə model üçün dəstəyin necə həyata keçirildiyini göstərəcəyik. Əlaqəli, sənəd və qrafik modelləri ən vacib hesab edəcəyik və “itkin olanların” necə həyata keçirildiyini göstərmək üçün xüsusi DBMS nümunələrindən istifadə edəcəyik.
Relational model əsasında çox modelli DBMS
Hal-hazırda aparıcı DBMS-lər əlaqəlidir; RDBMS-lər çox modelləşdirmə istiqamətində hərəkət göstərməsələr, Gartnerin proqnozu doğru hesab edilə bilməz. Və nümayiş etdirirlər. İndi çox modelli DBMS-nin heç nə edə bilməyən İsveçrə bıçağına bənzədiyi fikri birbaşa Larri Ellisona yönəldilə bilər.
Bununla belə, müəllif Microsoft SQL Server-də multi-modelləşdirmənin həyata keçirilməsinə üstünlük verir, bunun nümunəsində sənəd və qrafik modelləri üçün RDBMS dəstəyi təsvir ediləcəkdir.
MS SQL Serverdə sənəd modeli
Habré-də artıq MS SQL Serverin sənəd modelinə dəstəyi necə həyata keçirməsi haqqında iki əla məqalə var; Mən özümü qısa izahat və şərhlə məhdudlaşdıracağam:
MS SQL Server-də sənəd modelini dəstəkləməyin yolu relyasiyalı DBMS-lər üçün olduqca xarakterikdir: JSON sənədlərinin adi mətn sahələrində saxlanması təklif olunur. Sənəd modelinə dəstək bu JSON-u təhlil etmək üçün xüsusi operatorları təmin etməkdir:
- skalyar atribut dəyərlərini çıxarmaq üçün,
- alt sənədləri çıxarmaq.
Hər iki operatorun ikinci arqumenti JSONPath kimi sintaksisdəki ifadədir.
Mücərrəd şəkildə deyə bilərik ki, bu şəkildə saxlanılan sənədlər, kortejlərdən fərqli olaraq, əlaqəli DBMS-də "birinci dərəcəli obyektlər" deyildir. Xüsusilə, MS SQL Serverdə hazırda JSON sənədlərinin sahələrində heç bir indeks yoxdur, bu da bu sahələrin dəyərlərindən istifadə edərək cədvəllərə qoşulmağı və hətta bu dəyərlərdən istifadə edərək sənədləri seçməyi çətinləşdirir. Bununla belə, belə bir sahə üçün hesablanmış sütun və onun üzərində indeks yaratmaq mümkündür.
Bundan əlavə, MS SQL Server operatordan istifadə edərək cədvəllərin məzmunundan rahat şəkildə JSON sənədini qurmaq imkanı verir. - müəyyən mənada əvvəlkinin əksinə, şərti saxlama imkanı. Aydındır ki, RDBMS nə qədər sürətli olsa da, bu yanaşma mahiyyətcə populyar sorğulara hazır cavabları saxlayan sənəd DBMS-lərinin ideologiyasına ziddir və sürəti yox, yalnız inkişaf asanlığı problemlərini həll edə bilər.
Nəhayət, MS SQL Server sənədlərin qurulmasının əks problemini həll etməyə imkan verir: JSON-u istifadə edərək cədvəllərə parçalaya bilərsiniz. . Sənəd tamamilə düz deyilsə, istifadə etməlisiniz CROSS APPLY.
MS SQL Serverdə qrafik modeli
Qrafik (LPG) modelinə dəstək də Microsoft SQL Serverində tam şəkildə həyata keçirilir : Düyünləri saxlamaq və qrafik kənarlarını saxlamaq üçün xüsusi cədvəllərdən istifadə etmək təklif olunur. Belə cədvəllər ifadələrdən istifadə etməklə yaradılır CREATE TABLE AS NODE и CREATE TABLE AS EDGE müvafiq.
Birinci növ cədvəllər qeydlərin saxlanması üçün adi cədvəllərə bənzəyir, yeganə xarici fərq cədvəldə sistem sahəsinin olmasıdır. $node_id — verilənlər bazası daxilində qrafik qovşağının unikal identifikatoru.
Eynilə, ikinci tip cədvəllər sistem sahələrinə malikdir $from_id и $to_id, belə cədvəllərdəki qeydlər qovşaqlar arasındakı əlaqələri aydın şəkildə müəyyənləşdirir. Hər bir növ əlaqələri saxlamaq üçün ayrıca cədvəldən istifadə olunur.
Bunu bir misalla izah edək. Qrafik məlumatlarının şəkildə göstərildiyi kimi tərtibata malik olmasına icazə verin. Sonra verilənlər bazasında müvafiq strukturu yaratmaq üçün aşağıdakı DDL sorğularını yerinə yetirməlisiniz:
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);Bu cür cədvəllərin əsas özəlliyi ondan ibarətdir ki, onlara qarşı sorğularda Cypher kimi sintaksisi olan qrafik nümunələrindən istifadə etmək mümkündür (lakin "*"və s. hələ dəstəklənmir). Performans ölçmələrinə əsasən, həmçinin güman etmək olar ki, bu cədvəllərdə məlumatların saxlanma üsulu adi cədvəllərdə verilənlərin saxlanma üsulundan fərqlidir və bu cür qrafik sorğularını yerinə yetirmək üçün optimallaşdırılmışdır.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Üstəlik, bu cür cədvəllərlə işləyərkən bu qrafik nümunələrindən istifadə etməmək olduqca çətindir, çünki oxşar problemləri həll etmək üçün adi SQL sorğularında sistemin "qrafik" node identifikatorlarını əldə etmək üçün əlavə səylər göstərmək lazımdır ($node_id, $from_id, $to_id; Eyni səbəbdən, verilənlərin daxil edilməsi üçün sorğular burada göstərilmir, çünki onlar lazımsız dərəcədə çətin olur).
MS SQL Serverdə sənəd və qrafik modellərinin tətbiqinin təsvirini ümumiləşdirmək üçün qeyd edim ki, bir modelin digər modelin üst-üstə qoyulması ilk növbədə dil dizaynı baxımından uğurlu görünmür. Bir dili digəri ilə genişləndirmək lazımdır, dillər tamamilə "ortoqonal" deyil, uyğunluq qaydaları olduqca qəribə ola bilər.
Sənəd modelinə əsaslanan çoxmodelli DBMS
Bu bölmədə mən onlardan ən populyar olmayanı MongoDB (dediyi kimi, yalnız şərti qrafik operatorları var) nümunəsindən istifadə edərək, sənəd DBMS-lərində çox modelin tətbiqini göstərmək istərdim. $lookup и $graphLookup, parçalanmış kolleksiyalar üzərində işləmir), lakin daha yetkin və "müəssisə" DBMS nümunəsindən istifadə etməklə .
Beləliklə, kolleksiyada aşağıdakı növ XML sənədləri dəsti olsun (MarkLogic həmçinin JSON sənədlərini saxlamağa imkan verir):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>MarkLogic-də əlaqə modeli
Sənədlər toplusunun əlaqəli görünüşü istifadə edərək yaradıla bilər (elementlərin məzmunu value aşağıdakı nümunədə ixtiyari XPath ola bilər):
<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>Yaradılmış görünüşə SQL sorğusu ilə müraciət edə bilərsiniz (məsələn, ODBC vasitəsilə):
SELECT name, surname FROM Person WHERE name="John"Təəssüf ki, displey şablonu tərəfindən yaradılan əlaqəli görünüş yalnız oxunur. Bunun üçün sorğunu emal edərkən MarkLogic istifadə etməyə çalışacaq . Əvvəllər MarkLogic tamamilə məhdud əlaqə baxışlarına malik idi və yazıla bilər, lakin indi onlar köhnəlmiş hesab olunur.
MarkLogic-də qrafik modeli
Qrafik (RDF) modelinin dəstəyi ilə hər şey təxminən eynidir. Yenə köməyi ilə yuxarıdakı nümunədən sənədlər toplusunun RDF təsvirini yarada bilərsiniz:
<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>Yaranan RDF qrafikini SPARQL sorğusu ilə ünvanlaya bilərsiniz:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Əlaqəli modeldən fərqli olaraq, MarkLogic qrafik modelini iki başqa yolla dəstəkləyir:
- DBMS RDF məlumatlarının tam hüquqlu ayrıca saxlanması ola bilər (ondakı üçlülər adlandırılacaq). yuxarıda təsvir edilənlərdən fərqli olaraq ).
- Xüsusi serializasiyadakı RDF sadəcə XML və ya JSON sənədlərinə daxil edilə bilər (və üçlüklər daha sonra çağırılacaq) ). Bu, yəqin ki, mexanizmlərə alternativdir
idrefvə s.
MarkLogic-də işlərin "həqiqətən" necə işlədiyi barədə yaxşı bir fikir verilir , bu mənada o, aşağı səviyyədədir, baxmayaraq ki, onun məqsədi tam əksinədir - istifadə olunan məlumat modelindən mücərrədləşməyə çalışmaq, müxtəlif modellərdə verilənlərlə ardıcıl işin təmin edilməsi, tranzaksiya və s.
Çox modelli DBMS “əsas modelsiz”
Bazarda heç bir irsi əsas modeli olmayan ilkin olaraq çoxmodel kimi yerləşdirən DBMS-lər də var. Bunlara daxildir , (2018-ci ildən inkişaf şirkəti SAP-a məxsusdur) və (Microsoft Azure bulud platformasının bir hissəsi kimi xidmət).
Əslində, ArangoDB və OrientDB-də "əsas" modellər var. Hər iki halda, bunlar bir sənədin ümumiləşdirilməsi olan öz məlumat modelləridir. Ümumiləşdirmələr əsasən qrafik və əlaqəli xarakterli sorğuları yerinə yetirmək bacarığını asanlaşdırmaq üçündür.
Bu modellər müəyyən edilmiş DBMS-də istifadə üçün mövcud olan yeganə modellərdir; öz sorğu dilləri onlarla işləmək üçün nəzərdə tutulmuşdur. Əlbəttə ki, bu cür modellər və DBMS-lər perspektivlidir, lakin standart modellər və dillərlə uyğunluğun olmaması bu DBMS-lərin köhnə sistemlərdə istifadəsini qeyri-mümkün edir - orada artıq istifadə olunan DBMS-ləri əvəz etmək üçün.
Artıq Habré-də ArangoDB və OrientDB haqqında gözəl bir məqalə var idi: .
ArangoDB
ArangoDB qrafik məlumat modelini dəstəklədiyini iddia edir.
ArangoDB-də qrafikin qovşaqları adi sənədlərdir, kənarları isə adi sistem sahələri ilə birlikdə (_key, _id, _rev) sistem sahələri _from и _to. Sənəd DBMS-lərindəki sənədlər ənənəvi olaraq kolleksiyalarda birləşdirilir. Kənarları təmsil edən sənədlər topluları ArangoDB-də kənar kolleksiyalar adlanır. Yeri gəlmişkən, kənar toplama sənədləri də sənədlərdir, ona görə də ArangoDB-də kənarlar qovşaq kimi də çıxış edə bilər.
Xam data
Gəlin kolleksiyamız olsun personssənədləri belə görünür:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Kolleksiya da olsun cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Sonra kolleksiya likes bu kimi görünə bilər:
[
{
"_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
}
]Sorğular və nəticələr
ArangoDB-də istifadə olunan AQL dilində, kimin hansı kafeni bəyəndiyi haqqında insan tərəfindən oxuna bilən formada məlumatı qaytaran qrafik tipli sorğu belə görünür:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }Əlaqələri saxlamaq əvəzinə “hesabladığımız” münasibət üslubunda bu sorğu bu şəkildə yenidən yazıla bilər (yeri gəlmişkən, kolleksiya olmadan likes olmadan edə bilər):
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 }Hər iki halda nəticə eyni olacaq:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Daha çox sorğu və nəticələr
Yuxarıdakı nəticə formatı sənəd DBMS üçün deyil, əlaqəli DBMS üçün daha tipik görünürsə, bu sorğunu sınaya bilərsiniz (və ya istifadə edə bilərsiniz) ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Nəticə belə görünəcək:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
OrientDB-də sənəd modelinin üstündə qrafik modelinin tətbiqi üçün əsasdır sənəd sahələri, az və ya çox standart skalyar qiymətlərə əlavə olaraq, kimi növlərin qiymətlərinə də malikdir LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Bu növlərin dəyərləri bağlantılar və ya keçidlər toplusudur sənədlər.
Sistem tərəfindən təyin edilmiş sənəd identifikatoru verilənlər bazasındakı qeydin yerini göstərən "fiziki məna"ya malikdir və bu kimi görünür: @rid : #3:16. Beləliklə, istinad xassələrinin dəyərləri seçim şərtlərindən (əlaqəli modeldə olduğu kimi) həqiqətən göstəricilərdir (qrafik modeldə olduğu kimi).
ArangoDB kimi, OrientDB-də kənarlar ayrıca sənədlər kimi təqdim olunur (baxmayaraq ki, kənarın öz xüsusiyyətləri yoxdursa, o, edilə bilər. , və o, ayrıca sənədə uyğun gəlməyəcək).
Xam data
Yaxın formatda OrientDB verilənlər bazası, ArangoDB üçün əvvəlki nümunədəki məlumatlar belə görünəcək:
[
{
"@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"
}
]Gördüyümüz kimi təpələr həm də daxil olan və çıxan kənarlar haqqında məlumat saxlayır. At Document API istinad bütövlüyünə nəzarət etməlidir və Graph API bu işi öz üzərinə götürür. Ancaq gəlin OrientDB-yə girişin proqramlaşdırma dillərinə inteqrasiya olunmayan "saf" sorğu dillərində necə göründüyünü görək.
Sorğular və nəticələr
OrientDB-də ArangoDB nümunəsindəki sorğuya məqsəd baxımından oxşar sorğu belə görünür:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameNəticə aşağıdakı formada alınacaq:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Nəticə formatı yenidən çox "əlaqəli" görünürsə, xətti silməlisiniz :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]OrientDB-nin sorğu dili Gremlin kimi əlavələrlə SQL kimi təsvir edilə bilər. 2.2 versiyasında Cyphere bənzər sorğu forması meydana çıxdı, :
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_nameNəticə formatı əvvəlki sorğu ilə eyni olacaq. İlk sorğuda olduğu kimi, onu daha "əlaqəli" etmək üçün nələri çıxarmaq lazım olduğunu düşünün.
Azure CosmosDB
Daha az dərəcədə yuxarıda ArangoDB və OrientDB haqqında deyilənlər Azure CosmosDB-yə aiddir. CosmosDB aşağıdakı verilənlərə çıxış API-lərini təmin edir: SQL, MongoDB, Gremlin və Cassandra.
Sənəd modelindəki məlumatlara daxil olmaq üçün SQL API və MongoDB API istifadə olunur. Gremlin API və Cassandra API - müvafiq olaraq qrafik və sütun formatlarında verilənlərə daxil olmaq üçün. Bütün modellərdəki məlumatlar CosmosDB daxili model formatında saxlanılır: (“atom-rekord-ardıcıllığı”), bu da birinci sənədə yaxındır.
Lakin istifadəçi tərəfindən seçilmiş məlumat modeli və istifadə edilən API xidmətdə hesab yaratarkən müəyyən edilir. Bir modeldə yüklənmiş məlumatlara başqa bir modelin formatında daxil olmaq mümkün deyil, belə bir şəkildə təsvir edilmişdir:
Beləliklə, bu gün Azure CosmosDB-də multi-model yalnız bir istehsalçının müxtəlif modellərini dəstəkləyən bir neçə verilənlər bazasından istifadə etmək imkanıdır ki, bu da çoxvariantlı yaddaşın bütün problemlərini həll etmir.
Qrafik modelə əsaslanan çox modelli DBMS?
Maraqlıdır ki, bazarda qrafik modelə əsaslanan çox modelli DBMS-lər hələ mövcud deyil (eyni zamanda iki qrafik modeli üçün çox modelli dəstək istisna olmaqla: RDF və LPG; buna baxın ). Ən böyük çətinliklər əlaqə modeli deyil, qrafik modelin üstündə sənəd modelinin tətbiqi ilə əlaqədardır.
Qrafik modelin üzərində relational modelin necə həyata keçirilməsi məsələsi hətta sonuncunun formalaşması zamanı da nəzərdən keçirilirdi. Necə məsələn, :
Qrafik yanaşmasına xas olan heç bir şey yoxdur ki, qrafik verilənlər bazasında (1) adi açar dəyər cütlərindən dəstlərin bərpası və (2) qruplaşdırılması ilə əlaqəli görünüş əldə etməyə imkan verən qrafik verilənlər bazasında təbəqə yaratmağa (məsələn, uyğun indeksləşdirmə yolu ilə) mane olur. əlaqə növünə görə dələlər.
Qrafik modelin üstündə bir sənəd modelini tətbiq edərkən, məsələn, aşağıdakıları yadda saxlamaq lazımdır:
- JSON massivinin elementləri sıralı sayılır, lakin qrafikin kənarının təpəsindən çıxan elementlər deyil;
- Sənəd modelindəki məlumatlar adətən qeyri-normallaşdırılır; siz hələ də eyni daxili sənədin bir neçə nüsxəsini saxlamaq istəmirsiniz və alt sənədlərdə adətən identifikator yoxdur;
- Digər tərəfdən, sənəd DBMS-lərinin ideologiyası sənədlərin hər dəfə yenidən qurulmasına ehtiyac olmayan hazır “aqreqatlar” olmasıdır. Qrafik modelini hazır sənədə uyğun olan altqrafı tez əldə etmək imkanı ilə təmin etmək tələb olunur.
Bir az reklam
Məqalənin müəllifi NitrosBase DBMS-nin inkişafı ilə bağlıdır, onun daxili modeli qrafik, xarici modelləri isə - relyasiya və sənəd - onun təmsilləridir. Bütün modellər bərabərdir: demək olar ki, hər hansı bir məlumat onun üçün təbii olan sorğu dilindən istifadə edərək hər hansı birində mövcuddur. Üstəlik, istənilən görünüşdə məlumatlar dəyişdirilə bilər. Dəyişikliklər daxili modeldə və müvafiq olaraq digər baxışlarda əks olunacaq.
Ümid edirəm ki, NitrosBase-də model uyğunluğunun necə göründüyünü aşağıdakı məqalələrdən birində təsvir edəcəyəm.
Nəticə
Ümid edirəm ki, çox modelləşdirmə deyilən şeyin ümumi konturları oxucuya az-çox aydın oldu. Çox modelli DBMS-lər tamamilə fərqlidir və "çox modelli dəstək" fərqli görünə bilər. Hər bir konkret halda nəyin "çox model" adlandırıldığını başa düşmək üçün aşağıdakı suallara cavab vermək faydalıdır:
- Söhbət ənənəvi modelləri və ya bir növ “hibrid” modeli dəstəkləməkdən gedir?
- Modellər “bərabərdir”, yoxsa onlardan biri digərlərinin mövzusudur?
- Modellər bir-birinə “laqeyd”dirlər? Bir modeldə yazılan məlumatlar digərində oxuna və ya hətta üzərinə yazıla bilərmi?
Düşünürəm ki, çoxmodelli DBMS-nin aktuallığı ilə bağlı suala artıq müsbət cavab vermək olar, lakin maraqlı sual onların hansı növlərinə yaxın gələcəkdə daha çox tələbat olacağıdır. Belə görünür ki, ənənəvi modelləri dəstəkləyən çoxmodelli DBMS-lərə, ilk növbədə relyasiyaya görə daha çox tələbat olacaq; Müxtəlif ənənəvi olanların üstünlüklərini birləşdirən yeni modellər təklif edən çoxmodelli DBMS-lərin populyarlığı daha uzaq gələcəyin məsələsidir.
Sorğuda yalnız qeydiyyatdan keçmiş istifadəçilər iştirak edə bilər. xahiş edirəm.
Çox modelli DBMS-dən istifadə edirsiniz?
-
Biz ondan istifadə etmirik, hər şeyi bir DBMS-də və bir modeldə saxlayırıq
-
Biz ənənəvi DBMS-lərin çox modelli imkanlarından istifadə edirik
-
Biz poliqlot əzmkarlığı ilə məşğul oluruq
-
Biz yeni çox modelli DBMS-dən istifadə edirik (Arango, Orient, CosmosDB)
19 istifadəçi səs verib. 4 istifadəçi bitərəf qalıb.
Mənbə: www.habr.com