Қазіргі ақпараттық жүйелер өте күрделі. Ең бастысы, олардың күрделілігі оларда өңделген деректердің күрделілігіне байланысты. Деректердің күрделілігі көбінесе пайдаланылатын деректер үлгілерінің әртүрлілігінде. Мәселен, мысалы, деректер «үлкен» болғанда, проблемалық сипаттамалардың бірі оның көлемі («көлемі») ғана емес, сонымен қатар оның әртүрлілігі («түрлілік»).

Егер сіз дәлелдеуде кемшілік таппасаңыз, оқыңыз.

Мазмұны

Полиглот табандылығы
Көп модельді
Реляциялық модельге негізделген көп модельді ДҚБЖ
     MS SQL серверіндегі құжат моделі
     MS SQL серверіндегі графикалық модель
Құжат үлгісіне негізделген көп модельді ДҚБЖ
     MarkLogic жүйесіндегі реляциялық модель
     MarkLogic жүйесіндегі графикалық модель
Көп модельді ДҚБЖ «негізгі моделі жоқ»
     ArangoDB
     OrientDB
     Azure CosmosDB
Графикалық модельге негізделген көп модельді ДҚБЖ?
қорытынды
сұхбат

Полиглот табандылығы

Жоғарыда айтылғандар кейде тіпті бір жүйенің шеңберінде деректерді сақтау және оларды өңдеудің әртүрлі мәселелерін шешу үшін бірнеше әртүрлі ДҚБЖ пайдалану қажет болатындығына әкеледі, олардың әрқайсысы өзінің деректер үлгісін қолдайды. М.Фаулердің жеңіл қолымен, автор бірқатар әйгілі кітаптар және олардың бірі бірлескен авторлар Agile манифесті, бұл жағдай деп аталады көп нұсқалы сақтау («полиглот табандылығы»).

Фоулерде электрондық коммерция саласындағы толық функционалды және жоғары жүктемелі қолданбада деректерді сақтауды ұйымдастырудың келесі мысалы бар.

Бұл мысал, әрине, біршама асыра айтылған, бірақ сәйкес мақсат үшін сол немесе басқа ДҚБЖ таңдау пайдасына кейбір ойларды табуға болады, мысалы, осында.

Мұндай хайуанаттар бағында қызметші болу оңай емес екені анық.

• Деректерді сақтауды жүзеге асыратын код көлемі пайдаланылатын ДҚБЖ санына пропорционалды өседі; кодты синхрондау деректерінің мөлшері осы санның квадратына пропорционалды болмаса жақсы.
• Пайдаланылатын ДҚБЖ санының еселігі ретінде пайдаланылатын әрбір ДҚБЖ кәсіпорын сипаттамаларын (масштабтылық, ақауларға төзімділік, жоғары қолжетімділік) қамтамасыз ету шығындары артады.
• Тұтастай алғанда сақтаудың ішкі жүйесінің кәсіпорындық сипаттамаларын қамтамасыз ету мүмкін емес - әсіресе транзакциялық.

Хайуанаттар бағы директорының көзқарасы бойынша бәрі былай көрінеді:

• ДҚБЖ өндірушісінен лицензиялар мен техникалық қолдау құнының бірнеше есе артуы.
• Қызметкерлерді шамадан тыс толтыру және мерзімін ұзарту.
• Деректер сәйкес келмеуіне байланысты тікелей қаржылық шығындар немесе айыппұлдар.

Жүйені иеленудің жалпы құнының (ТШО) айтарлықтай өсуі байқалады. «Бірнеше сақтау опциялары» жағдайынан шығудың қандай да бір жолы бар ма?

Көп модельді

«Көп нұсқалы сақтау» термині 2011 жылы қолданыла бастады. Тәсіл мәселелерін білу және шешімді іздеу бірнеше жылға созылды және 2015 жылға қарай Gartner сарапшыларының аузынан жауап тұжырымдалды:

• бастапNoSQL ДҚБЖ үшін нарықтық нұсқаулық - 2015 ж«:
  

  ДҚБЖ болашағы, олардың архитектурасы және оларды пайдалану жолдары көп модельді болып табылады.

• бастапODBMS үшін сиқырлы квадрант - 2016«:
  

  Жетекші операциялық ДҚБЖ бір платформаның бөлігі ретінде реляциялық және реляциялық емес бірнеше үлгілерді ұсынады.

Бұл жолы Gartner сарапшылары өз болжамын дұрыс айтқан сияқты. деген парақшаға өтсеңіз негізгі рейтинг DB-Engines жүйесіндегі ДҚБЖ, сіз мұны көре аласызоОның жетекшілерінің көпшілігі өздерін көп модельді ДҚБЖ ретінде көрсетеді. Мұны кез келген жеке рейтингі бар бетте көруге болады.

Төмендегі кестеде ДҚБЖ көрсетілген - жеке рейтингтердің әрқайсысының көшбасшылары, олар көп үлгілі деп мәлімдейді. Әрбір ДҚБЖ үшін түпнұсқа қолдау көрсетілетін үлгі (бір кезде жалғыз болған) және онымен бірге қазіргі уақытта қолдау көрсетілетін үлгілер көрсетіледі. Сондай-ақ, өздерін «бастапқыда көп үлгілі» ретінде орналастыратын және жасаушылардың пікірінше, бастапқы тұқым қуалайтын үлгісі жоқ ДҚБЖ тізімі берілген.

ДББЖ	Бастапқы үлгі	Қосымша үлгілер
Oracle	Реляциялық	График, құжат
MS SQL	Реляциялық	График, құжат
PostgreSQL	Реляциялық	График*, құжат
MarkLogic	Деректі фильм	График, реляциялық
MongoDB	Деректі фильм	Түйінді мән, график*
DataStax	Кең баған	Деректі фильм, график
Редис	Негізгі мән	Деректі фильм, график*
ArangoDB	-	График, құжат
OrientDB	-	График, құжат, реляциялық
Azure CosmosDB	-	График, құжат, реляциялық

Үстелдегі жазбалар

Кестедегі жұлдызшалар ескертпелерді қажет ететін мәлімдемелерді белгілейді:

• PostgreSQL ДҚБЖ графикалық деректер үлгісін қолдамайды, бірақ бұл өнім оны қолдайды негізінде, мысалы, AgensGraph.
• MongoDB-ге қатысты сұрау тілінде графикалық операторлардың болуы туралы айту дұрысырақ ($lookup, $graphLookup) графикалық модельді қолдауға қарағанда, бірақ, әрине, оларды енгізу графикалық модельді қолдау бағытында физикалық сақтау деңгейінде кейбір оңтайландыруларды талап етті.
• Redis-ке қатысты біз кеңейтімді айтамыз RedisGraph.

Әрі қарай, әрбір сынып үшін осы сыныптағы ДҚБЖ-да бірнеше үлгілерге қолдау қалай жүзеге асырылатынын көрсетеміз. Біз реляциялық, құжаттық және графикалық модельдерді ең маңызды деп қарастырамыз және «жетпегендердің» қалай жүзеге асырылатынын көрсету үшін нақты ДҚБЖ мысалдарын қолданамыз.

Реляциялық модельге негізделген көп модельді ДҚБЖ

Қазіргі уақытта жетекші ДҚБЖ реляциялық болып табылады; RDBMS мультимодельдеу бағытында қозғалысты көрсетпесе, Gartner болжамын шындық деп санауға болмайды. Және олар көрсетеді. Енді көп модельді ДҚБЖ ешнәрсе жақсы істей алмайтын швейцар пышағы сияқты деген идеяны тікелей Ларри Эллисонға бағыттауға болады.

Автор, алайда, Microsoft SQL Server серверінде мультимодельдеуді жүзеге асыруды қалайды, оның мысалында құжат және графикалық модельдерге RDBMS қолдауы сипатталады.

MS SQL серверіндегі құжат моделі

Habré-де MS SQL Server құжат үлгісіне қолдауды қалай жүзеге асыратыны туралы екі тамаша мақала болды; Мен өзімді қысқаша қайталау және түсініктеме берумен шектелемін:

• SQL Server 2016 жүйесінде JSON бағдарламасымен жұмыс істеу
• SQL Server 2017 JSON

MS SQL серверінде құжат үлгісін қолдау тәсілі реляциялық ДҚБЖ үшін өте тән: JSON құжаттарын кәдімгі мәтіндік өрістерде сақтау ұсынылады. Құжат үлгісін қолдау осы JSON талдауы үшін арнайы операторларды қамтамасыз ету болып табылады:

• JSON_VALUE скаляр атрибут мәндерін шығару үшін,
• JSON_QUERY қосалқы құжаттарды алу үшін.

Екі оператордың екінші аргументі JSONPath тәрізді синтаксистегі өрнек болып табылады.

Абстрактілі түрде, осылайша сақталған құжаттар кортеждерден айырмашылығы, реляциялық ДҚБЖ-да «бірінші класты нысандар» емес деп айта аламыз. Атап айтқанда, MS SQL серверінде қазіргі уақытта JSON құжаттарының өрістерінде индекстер жоқ, бұл осы өрістердің мәндерін пайдаланып кестелерді біріктіруді және тіпті осы мәндерді пайдаланып құжаттарды таңдауды қиындатады. Дегенмен, мұндай өріс үшін есептелген бағанды ​​және оған индексті құруға болады.

Сонымен қатар, MS SQL Server оператордың көмегімен кестелердің мазмұнынан JSON құжатын ыңғайлы құру мүмкіндігін береді. FOR JSON PATH - белгілі бір мағынада, бұрынғыға қарама-қарсы, әдеттегі сақтау мүмкіндігі. RDBMS қаншалықты жылдам болса да, бұл тәсіл негізінен танымал сұраныстарға дайын жауаптарды сақтайтын құжаттық ДҚБЖ идеологиясына қайшы келетіні және жылдамдықты емес, әзірлеудің қарапайымдылығы мәселелерін ғана шеше алатыны анық.

Соңында, MS SQL Server құжатты құрудың қарама-қарсы мәселесін шешуге мүмкіндік береді: JSON-ды пайдаланып кестелерге бөлуге болады. OPENJSON. Құжат толығымен тегіс болмаса, пайдалану қажет болады CROSS APPLY.

MS SQL серверіндегі графикалық модель

График (LPG) үлгісіне қолдау Microsoft SQL Server-де де толығымен жүзеге асырылады болжауға болатын: Түйіндерді сақтау және график жиектерін сақтау үшін арнайы кестелерді пайдалану ұсынылады. Мұндай кестелер өрнектер арқылы жасалады CREATE TABLE AS NODE и CREATE TABLE AS EDGE тиісінше.

Бірінші типтегі кестелер жазбаларды сақтауға арналған қарапайым кестелерге ұқсас, тек сыртқы айырмашылығы кестеде жүйелік өріс бар. $node_id — дерекқордағы графикалық түйіннің бірегей идентификаторы.

Сол сияқты екінші типтегі кестелерде жүйелік өрістер болады $from_id и $to_id, мұндай кестелердегі жазбалар түйіндер арасындағы байланыстарды нақты анықтайды. Әр түрдегі қатынастарды сақтау үшін жеке кесте пайдаланылады.

Мұны мысалмен түсіндірейік. График деректерінің суретте көрсетілгендей орналасуы болсын. Содан кейін дерекқорда сәйкес құрылымды жасау үшін келесі DDL сұрауларын орындау керек:

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

Мұндай кестелердің негізгі ерекшелігі - оларға қарсы сұрауларда Cypher тәрізді синтаксисі бар графикалық үлгілерді қолдануға болады (бірақ «*«және т.б. әлі қолдау көрсетілмейді). Өнімділік өлшемдеріне сүйене отырып, бұл кестелерде деректерді сақтау тәсілі деректерді кәдімгі кестелерде сақтау тәсілінен өзгеше және осындай графикалық сұрауларды орындау үшін оңтайландырылған деп болжауға болады.

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

Сонымен қатар, мұндай кестелермен жұмыс істеу кезінде бұл графикалық үлгілерді қолданбау өте қиын, өйткені ұқсас мәселелерді шешу үшін қарапайым SQL сұрауларында жүйенің «график» түйінінің идентификаторларын алу үшін қосымша күш салу қажет болады ($node_id, $from_id, $to_id; Дәл сол себепті деректерді енгізуге арналған сұраулар бұл жерде көрсетілмейді, себебі олар қажетсіз қиын).

MS SQL Server-де құжат және графикалық модельдердің іске асырылуының сипаттамасын қорытындылау үшін, бір үлгінің екіншісінің үстіне мұндай іске асыру, ең алдымен, тілдік дизайн тұрғысынан сәтті көрінбейтінін атап өткім келеді. Бір тілді екіншісімен кеңейту керек, тілдер толығымен «ортогональды» емес, үйлесімділік ережелері өте оғаш болуы мүмкін.

Құжат үлгісіне негізделген көп модельді ДҚБЖ

Бұл бөлімде мен олардың ең танымал емес MongoDB мысалын қолдана отырып, құжаттардың ДҚБЖ-ға көп модельді енгізуді суреттегім келеді (айтқандай, оның тек шартты графикалық операторлары бар) $lookup и $graphLookup, бөлшектелген жинақтарда жұмыс істемейді), бірақ неғұрлым жетілген және «кәсіпорын» ДҚБЖ мысалын пайдалану MarkLogic.

Сонымен, коллекцияда келесі түрдегі XML құжаттарының жиынтығы болуы керек (MarkLogic сонымен қатар JSON құжаттарын сақтауға мүмкіндік береді):

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

MarkLogic жүйесіндегі реляциялық модель

Құжаттар жинағының реляциялық көрінісін пайдалану арқылы жасауға болады көрсету үлгісі (элементтердің мазмұны value төмендегі мысалда ерікті XPath болуы мүмкін):

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

Құрылған көріністі SQL сұрауымен (мысалы, ODBC арқылы) шешуге болады:

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

Өкінішке орай, дисплей үлгісі арқылы жасалған реляциялық көрініс тек оқуға арналған. Оған сұранысты өңдеу кезінде MarkLogic пайдалануға тырысады құжат индекстері. Бұрын MarkLogic толығымен шектеулі реляциялық көріністерге ие болды индексіне негізделген және жазылуы мүмкін, бірақ қазір олар ескірген болып саналады.

MarkLogic жүйесіндегі графикалық модель

Графикалық (RDF) моделін қолдау арқылы барлығы бірдей. Қайтадан көмекпен көрсету үлгісі жоғарыдағы мысалдан құжаттар жинағының RDF көрінісін жасауға болады:

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

Алынған RDF графигін SPARQL сұрауымен шешуге болады:

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

Реляциялық модельден айырмашылығы, MarkLogic графикалық модельді екі басқа жолмен қолдайды:

1. ДҚБЖ RDF деректерінің толыққанды бөлек қоймасы болуы мүмкін (ондағы үштік деп аталады). басқарылатын жоғарыда сипатталғандардан айырмашылығы шығарылды).
2. Арнайы сериялаудағы RDF жай ғана XML немесе JSON құжаттарына кірістірілуі мүмкін (және содан кейін үштіктер деп аталады). басқарылмайтын). Бұл механизмдерге балама шығар idref және басқалар.

MarkLogic-те заттардың «шынымен» қалай жұмыс істейтіні туралы жақсы идея береді Оптикалық API, бұл мағынада ол төмен деңгейлі, оның мақсаты керісінше болса да – пайдаланылған деректер үлгісінен абстракциялауға тырысу, әртүрлі модельдердегі деректермен дәйекті жұмысты қамтамасыз ету, транзакциялық және т.б.

Көп модельді ДҚБЖ «негізгі моделі жоқ»

Сондай-ақ нарықта мұрагерлік негізгі үлгісі жоқ, өздерін бастапқыда көп үлгілі ретінде орналастыратын ДҚБЖ бар. Оларға жатады ArangoDB, OrientDB (2018 жылдан бастап әзірлеуші ​​компания SAP-қа тиесілі) және CosmosDB (Microsoft Azure бұлттық платформасының бөлігі ретіндегі қызмет).

Шын мәнінде, ArangoDB және OrientDB-де «негізгі» модельдер бар. Екі жағдайда да бұл бірінші құжатты жалпылау болып табылатын өздерінің деректер үлгілері. Жалпылаулар негізінен графиктік және реляциялық сипаттағы сұрауларды орындау мүмкіндігін жеңілдету үшін болып табылады.

Бұл модельдер көрсетілген ДҚБЖ-да қолдануға болатын жалғыз үлгілер болып табылады; олардың жеке сұрау тілдері олармен жұмыс істеуге арналған. Әрине, мұндай модельдер мен ДҚБЖ перспективалы, бірақ стандартты үлгілермен және тілдермен үйлесімділіктің болмауы бұл ДҚБЖ-ны бұрынғы жүйелерде пайдалануды мүмкін емес етеді - онда бұрыннан қолданылған ДҚБЖ ауыстыру үшін.

Habré сайтында ArangoDB және OrientDB туралы тамаша мақала болды: NoSQL дерекқорларына ҚОСЫЛУ.

ArangoDB

ArangoDB графикалық деректер үлгісіне қолдау көрсетеді.

ArangoDB-дегі графиктің түйіндері қарапайым құжаттар, ал жиектері кәдімгі жүйелік өрістермен бірге (_key, _id, _rev) жүйелік өрістер _from и _to. ДҚБЖ құжаттарындағы құжаттар дәстүрлі түрде жинақтарға біріктіріледі. Жиектерді білдіретін құжаттар топтамасы ArangoDB ішінде жиектер жинақтары деп аталады. Айтпақшы, жиектерді жинау құжаттары да құжаттар болып табылады, сондықтан ArangoDB жиектері түйін ретінде де әрекет ете алады.

Бастапқы деректер

Бізге жинақ болсын persons, құжаттары келесідей:

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

Жинақ болсын cafes:

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

Содан кейін жинақ likes келесідей көрінуі мүмкін:

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

Сұраулар мен нәтижелер

ArangoDB жүйесінде пайдаланылатын AQL тіліндегі графикалық стильдегі сұрау, кімге қай кафені ұнататыны туралы адам оқи алатын пішінде ақпаратты қайтарады, келесідей:

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

Біз қарым-қатынастарды сақтаудың орнына «есептеп» жатқан реляциялық стильде бұл сұрауды осылай қайта жазуға болады (айтпақшы, жинақсыз likes онсыз жасай алады):

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 }

Екі жағдайда да нәтиже бірдей болады:

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

Қосымша сұраулар мен нәтижелер

Егер жоғарыдағы нәтиже пішімі дерекқор құжатына қарағанда реляциялық ДҚБЖ үшін әдеттегідей болып көрінсе, осы сұрауды қолданып көруге болады (немесе пайдалана аласыз). COLLECT):

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

Нәтиже келесідей болады:

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

OrientDB

OrientDB-де құжат үлгісінің үстіне графикалық модельді енгізудің негізі болып табылады мүмкіндік құжат өрістерінде азды-көпті стандартты скаляр мәндерден басқа, сияқты түрлердің мәндері де болады LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Бұл түрлердің мәндері сілтемелер немесе сілтемелер жинағы болып табылады жүйелік идентификаторлар құжаттар.

Жүйе тағайындаған құжат идентификаторы дерекқордағы жазбаның орнын көрсететін «физикалық мағынаға» ие және келесідей көрінеді: @rid : #3:16. Осылайша, анықтамалық сипаттардың мәндері таңдау шарттарына (реляциялық модельдегідей) емес, шын мәнінде көрсеткіш болып табылады (графикалық модельдегідей).

ArangoDB сияқты, OrientDB жиектері бөлек құжаттар ретінде ұсынылған (бірақ жиектің өз қасиеттері болмаса, оны жасауға болады. жеңіл, және ол бөлек құжатқа сәйкес келмейді).

Бастапқы деректер

жақын форматта демп форматы OrientDB дерекқорында ArangoDB үшін алдыңғы мысалдағы деректер келесідей болады:

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

Көріп отырғанымыздай, шыңдар кіріс және шығыс жиектер туралы ақпаратты сақтайды. Сағат қолдану Document API анықтамалық тұтастығын өзі бақылауы керек және Graph API бұл жұмысты атқарады. Бірақ бағдарламалау тілдеріне біріктірілмеген «таза» сұрау тілдерінде OrientDB қол жеткізудің қандай болатынын көрейік.

Сұраулар мен нәтижелер

OrientDB ішіндегі ArangoDB мысалындағы сұрауға мақсаты бойынша ұқсас сұрау келесідей көрінеді:

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

Нәтиже келесі формада алынады:

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

Егер нәтиже пішімі қайтадан тым «қатысты» болып көрінсе, жолды алып тастау керек UNWIND():

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

OrientDB сұрау тілін Gremlin тәрізді кірістірулері бар SQL ретінде сипаттауға болады. 2.2 нұсқасында Cypher тәрізді сұрау пішіні пайда болды, MATCH :

MATCH {CLASS: Person, AS: person}-likes->{CLASS: Cafe, AS: cafe}
RETURN person.name AS person_name, LIST(cafe.name) AS cafe_name
GROUP BY person_name

Нәтиже пішімі алдыңғы сұраудағыдай болады. Бірінші сұраудағы сияқты оны «қатысты» ету үшін нені жою керектігі туралы ойланыңыз.

Azure CosmosDB

Аз дәрежеде ArangoDB және OrientDB туралы жоғарыда айтылғандар Azure CosmosDB үшін қолданылады. CosmosDB келесі деректерге қол жеткізу API интерфейстерін қамтамасыз етеді: SQL, MongoDB, Gremlin және Cassandra.

SQL API және MongoDB API құжат үлгісіндегі деректерге қол жеткізу үшін пайдаланылады. Gremlin API және Cassandra API - сәйкесінше диаграмма және баған пішіміндегі деректерге қол жеткізу үшін. Барлық үлгілердегі деректер CosmosDB ішкі үлгі пішімінде сақталады: ARS («атом-жазба-тізбегі»), ол да бірінші құжатқа жақын.

Бірақ пайдаланушы таңдаған деректер үлгісі және пайдаланылатын API қызметте тіркелгі жасау кезінде бекітіледі. Бір үлгіде жүктелген деректерге басқа үлгі пішімінде қол жеткізу мүмкін емес, мысалы:

Осылайша, Azure CosmosDB-дегі мульти-модель бүгінде бір өндірушінің әртүрлі үлгілерін қолдайтын бірнеше дерекқорды пайдалану мүмкіндігі ғана болып табылады, бұл көп нұсқалы сақтаудың барлық мәселелерін шешпейді.

Графикалық модельге негізделген көп модельді ДҚБЖ?

Бір қызығы, нарықта графикалық модельге негізделген көп модельді ДҚБЖ әлі жоқ (бір уақытта екі графикалық модель үшін көп модельді қолдауды қоспағанда: RDF және LPG; мынаны қараңыз). алдыңғы жарияланым). Ең үлкен қиындықтар реляциялық емес, графикалық модельдің үстіне құжат үлгісін енгізуден туындайды.

Графикалық модельдің үстіне реляциялық модельді қалай жүзеге асыру керек деген мәселе соңғысының қалыптасуы кезінде де қарастырылды. Қалай сөйледі, мысалы, Дэвид Макговерн:

(1) кәдімгі кілт мәндер жұптарынан кортеждерді қалпына келтіру және (2) топтастыру арқылы реляциялық көріністі қамтамасыз ететін графикалық дерекқорда қабат құруға (мысалы, сәйкес индекстеу арқылы) кедергі келтіретін графикалық тәсілге тән ештеңе жоқ. қатынас типі бойынша кортеждер.

Графикалық модельдің үстіне құжат үлгісін енгізу кезінде, мысалы, мыналарды есте сақтау қажет:

• JSON массивінің элементтері реттелген болып саналады, бірақ графиктің жиегінің шыңынан шығатын элементтер емес;
• Құжат үлгісіндегі деректер әдетте нормадан ажыратылады; сіз әлі де бірдей ендірілген құжаттың бірнеше көшірмелерін сақтағыңыз келмейді және ішкі құжаттарда әдетте идентификаторлар болмайды;
• Екінші жағынан, құжаттық ДҚБЖ-ның идеологиясы - бұл құжаттар әр уақытта жаңадан құрастыруды қажет етпейтін дайын «агрегаттар» болып табылады. Графикалық модельді дайын құжатқа сәйкес келетін субграфты тез алу мүмкіндігімен қамтамасыз ету қажет.

Кішкене жарнама

Мақала авторы NitrosBase ДҚБЖ әзірлеумен байланысты, оның ішкі моделі график, ал сыртқы модельдер – реляциялық және құжат – оның бейнелері. Барлық модельдер бірдей: кез келген дерлік деректер олардың кез келгенінде өзіне табиғи сұраныс тілін пайдалана отырып қол жетімді. Сонымен қатар, кез келген көріністе деректерді өзгертуге болады. Өзгерістер ішкі үлгіде және сәйкесінше басқа да көріністерде көрініс табады.

Мен келесі мақалалардың бірінде NitrosBase жүйесінде үлгі сәйкестігінің қандай болатынын сипаттаймын деп үміттенемін.

қорытынды

Көп модельдеу деп аталатын нәрсенің жалпы сызбалары оқырманға азды-көпті түсінікті болды деп үміттенемін. Көп модельді ДҚБЖ мүлдем басқаша және «көп модельді қолдау» басқаша көрінуі мүмкін. Әрбір нақты жағдайда «мульти-модель» деп аталатын нәрсені түсіну үшін келесі сұрақтарға жауап беру пайдалы:

1. Біз дәстүрлі үлгілерді немесе қандай да бір «гибридті» модельдерді қолдау туралы айтып отырмыз ба?
2. Модельдер «тең» ме, әлде олардың біреуі басқаларының тақырыбы ма?
3. Модельдер бір-біріне «немқұрайды» ма? Бір үлгіде жазылған деректерді екіншісінде оқуға немесе тіпті қайта жазуға болады ма?

Менің ойымша, мультимодельді ДҚБЖ өзектілігі туралы сұраққа қазірдің өзінде оң жауап беруге болады, бірақ қызықты сұрақ - олардың қай түрлері жақын арада сұранысқа ие болады. Дәстүрлі үлгілерді қолдайтын, ең алдымен реляциялық көп модельді ДҚБЖ көбірек сұранысқа ие болатын сияқты; Әртүрлі дәстүрлі артықшылықтарды біріктіретін жаңа үлгілерді ұсынатын көпмодельді ДҚБЖ-ның танымалдығы алыс болашақтың мәселесі болып табылады.

Сауалнамаға тек тіркелген пайдаланушылар қатыса алады. Кіру, өтінемін.

Сіз көп модельді ДҚБЖ пайдаланасыз ба?

• Біз оны қолданбаймыз, біз барлығын бір ДҚБЖ және бір үлгіде сақтаймыз

• Біз дәстүрлі ДҚБЖ мультимоделі мүмкіндіктерін қолданамыз

• Біз полиглот табандылығымен айналысамыз

• Біз жаңа мультимодельді ДҚБЖ қолданамыз (Arango, Orient, CosmosDB)

19 пайдаланушы дауыс берді. 4 пайдаланушы қалыс қалды.

Ақпарат көзі: www.habr.com