თანამედროვე საინფორმაციო სისტემები საკმაოდ რთულია. რაც მთავარია, მათი სირთულე განპირობებულია მათში დამუშავებული მონაცემების სირთულით. მონაცემთა სირთულე ხშირად მდგომარეობს გამოყენებული მონაცემთა მოდელების მრავალფეროვნებაში. მაგალითად, როდესაც მონაცემები ხდება "დიდი", ერთ-ერთი პრობლემური მახასიათებელია არა მხოლოდ მისი მოცულობა ("მოცულობა"), არამედ მისი მრავალფეროვნება ("ჯიში").

თუ ჯერ ვერ იპოვნეთ ხარვეზი მსჯელობაში, შემდეგ წაიკითხეთ.

ინფორმაციის

პოლიგლოტური გამძლეობა
მრავალმოდელი
მრავალმოდელური DBMS, რომელიც დაფუძნებულია რელაციურ მოდელზე
     დოკუმენტის მოდელი MS SQL Server-ში
     გრაფიკის მოდელი MS SQL სერვერში
მრავალ მოდელის DBMS დოკუმენტის მოდელზე დაფუძნებული
     რელაციური მოდელი MarkLogic-ში
     გრაფიკის მოდელი MarkLogic-ში
მრავალ მოდელის DBMS "მთავარი მოდელის გარეშე"
     ArangoDB
     OrientDB
     Azure CosmosDB
მრავალ მოდელის DBMS გრაფიკის მოდელზე დაფუძნებული?
დასკვნა
ინტერვიუ

პოლიგლოტური გამძლეობა

ზემოაღნიშნული მივყავართ იმ ფაქტს, რომ ზოგჯერ ერთი სისტემის ფარგლებშიც კი აუცილებელია რამდენიმე განსხვავებული DBMS-ის გამოყენება მონაცემთა შესანახად და მათი დამუშავების სხვადასხვა პრობლემის გადასაჭრელად, რომელთაგან თითოეული მხარს უჭერს მონაცემთა საკუთარ მოდელს. მ.ფაულერის მსუბუქი ხელით, ავტორი არაერთი ცნობილი წიგნი და ერთ-ერთი თანაავტორები Agile Manifesto, ამ სიტუაციას ე.წ მრავალვარიანტი შენახვა ("პოლიგლოტური გამძლეობა").

ფაულერს ასევე აქვს მონაცემთა შენახვის ორგანიზების შემდეგი მაგალითი ელექტრონული კომერციის სფეროში სრულფასოვანი და მაღალი დატვირთვის აპლიკაციაში.

ეს მაგალითი, რა თქმა უნდა, გარკვეულწილად გადაჭარბებულია, მაგრამ გარკვეული მოსაზრებები შესაბამისი მიზნისთვის ამა თუ იმ DBMS-ის არჩევის სასარგებლოდ შეიძლება მოიძებნოს, მაგალითად, აქ.

გასაგებია, რომ ასეთ ზოოპარკში მსახური ადვილი არ არის.

კოდის რაოდენობა, რომელიც ახორციელებს მონაცემთა შენახვას, იზრდება გამოყენებული DBMS-ების რაოდენობის პროპორციულად; კოდის სინქრონიზაციის მონაცემების რაოდენობა კარგია, თუ არა პროპორციული ამ რიცხვის კვადრატისა.
როგორც გამოყენებული DBMS-ების რაოდენობის მრავალჯერადი, იზრდება თითოეული გამოყენებული DBMS-ის საწარმოს მახასიათებლების (მაშტაბურობა, ხარვეზების ტოლერანტობა, მაღალი ხელმისაწვდომობა) უზრუნველყოფის ხარჯები.
შეუძლებელია მთლიანობაში შენახვის ქვესისტემის საწარმოს მახასიათებლების უზრუნველყოფა - განსაკუთრებით ტრანზაქციულობა.

ზოოპარკის დირექტორის გადმოსახედიდან ყველაფერი ასე გამოიყურება:

ლიცენზიებისა და ტექნიკური მხარდაჭერის ღირებულების მრავალჯერადი ზრდა DBMS მწარმოებლისგან.
პერსონალის გადაჭარბება და გაზრდილი ვადები.
პირდაპირი ფინანსური ზარალი ან ჯარიმები მონაცემთა შეუსაბამობის გამო.

მნიშვნელოვნად იზრდება სისტემის მთლიანი საკუთრების ღირებულება (TCO). არსებობს რაიმე გამოსავალი "მრავალჯერადი შენახვის პარამეტრების" სიტუაციიდან?

მრავალმოდელი

ტერმინი „მრავალვარიატიული საცავი“ 2011 წელს გამოიყენეს. მიდგომის პრობლემების გაცნობიერებას და გამოსავლის ძიებას რამდენიმე წელი დასჭირდა და 2015 წლისთვის, Gartner-ის ანალიტიკოსების პირით, პასუხი ჩამოყალიბდა:

საწყისი "ბაზრის სახელმძღვანელო NoSQL DBMS-ებისთვის - 2015 წ"
DBMS-ების მომავალი, მათი არქიტექტურა და მათი გამოყენების გზები მრავალმოდელიანია.
საწყისი "Magic Quadrant for ODBMS - 2016 წ"
წამყვანი ოპერაციული DBMS-ები შესთავაზებენ მრავალ მოდელს - რელაციურ და არარელატიურ - როგორც ერთი პლატფორმის ნაწილს.

როგორც ჩანს, ამჯერად Gartner-ის ანალიტიკოსები მართალი იყვნენ თავიანთი პროგნოზით. თუ გადადიხარ გვერდზე მთავარი რეიტინგი DBMS DB- ძრავებზე, თქვენ ხედავთ ამასоმისი ლიდერების უმეტესობა პოზიციონირებს კონკრეტულად, როგორც მრავალ მოდელის DBMS. იგივე შეიძლება ნახოთ გვერდზე ნებისმიერი კერძო რეიტინგით.

ქვემოთ მოყვანილი ცხრილი გვიჩვენებს DBMS - ლიდერებს თითოეულ კერძო რეიტინგში, რომლებიც აცხადებენ მრავალმოდელად. თითოეული DBMS-ისთვის მითითებულია ორიგინალური მხარდაჭერილი მოდელი (რომელიც ოდესღაც ერთადერთი იყო) და მასთან ერთად ამჟამად მხარდაჭერილი მოდელები. ასევე ჩამოთვლილია DBMS-ები, რომლებიც პოზიციონირებენ როგორც „თავდაპირველად მრავალმოდელად“ და, შემქმნელების თქმით, არ აქვთ რაიმე საწყისი მემკვიდრეობითი მოდელი.

DBMS	საწყისი მოდელი	დამატებითი მოდელები
Oracle	რელატიური	გრაფიკი, დოკუმენტი
MS SQL	რელატიური	გრაფიკი, დოკუმენტი
PostgreSQL	რელატიური	გრაფიკი*, დოკუმენტი
MarkLogic	დოკუმენტური	გრაფიკი, მიმართებითი
MongoDB	დოკუმენტური	გასაღები-მნიშვნელობა, გრაფიკი*
DataStax	ფართო სვეტი	დოკუმენტური, გრაფიკი
Redis	გასაღები-მნიშვნელობა	დოკუმენტური, გრაფიკა*
ArangoDB	-	გრაფიკი, დოკუმენტი
OrientDB	-	გრაფიკი, დოკუმენტი, მიმართებითი
Azure CosmosDB	-	გრაფიკი, დოკუმენტი, მიმართებითი

შენიშვნები მაგიდაზე

ცხრილის ვარსკვლავი აღნიშნავს განცხადებებს, რომლებიც საჭიროებენ დათქმას:

PostgreSQL DBMS არ უჭერს მხარს გრაფიკის მონაცემთა მოდელს, მაგრამ ეს პროდუქტი მხარს უჭერს მას მასზე დაყრდნობით, როგორიცაა AgensGraph.
MongoDB-სთან დაკავშირებით უფრო სწორია საუბარი შეკითხვის ენაში გრაფიკული ოპერატორების არსებობაზე ($lookup, $graphLookup) ვიდრე გრაფიკის მოდელის მხარდაჭერის შესახებ, თუმცა, რა თქმა უნდა, მათი დანერგვა მოითხოვდა გარკვეულ ოპტიმიზაციას ფიზიკური შენახვის დონეზე გრაფიკის მოდელის მხარდაჭერის მიმართულებით.
Redis-თან მიმართებაში ვგულისხმობთ გაფართოებას RedisGraph.

შემდეგი, თითოეული კლასისთვის, ჩვენ ვაჩვენებთ, თუ როგორ არის დანერგილი რამდენიმე მოდელის მხარდაჭერა ამ კლასის DBMS-ში. ჩვენ განვიხილავთ რელაციურ, დოკუმენტურ და გრაფიკულ მოდელებს, როგორც ყველაზე მნიშვნელოვანს და გამოვიყენებთ კონკრეტული DBMS-ების მაგალითებს იმის საჩვენებლად, თუ როგორ ხორციელდება „დაკარგულები“.

მრავალმოდელური DBMS, რომელიც დაფუძნებულია რელაციურ მოდელზე

წამყვანი DBMS ამჟამად რელაციურია; Gartner-ის პროგნოზი არ შეიძლება ჩაითვალოს ჭეშმარიტად, თუ RDBMS არ აჩვენებს მოძრაობას მრავალ მოდელირების მიმართულებით. და დემონსტრირებას ახდენენ. ახლა ის აზრი, რომ მრავალ მოდელის DBMS შვეიცარიულ დანას ჰგავს, რომელიც კარგად ვერაფერს აკეთებს, შეიძლება პირდაპირ ლარი ელისონზე იყოს მიმართული.

თუმცა, ავტორი უპირატესობას ანიჭებს მრავალ მოდელირების განხორციელებას Microsoft SQL Server-ში, რომლის მაგალითზე იქნება აღწერილი RDBMS მხარდაჭერა დოკუმენტისა და გრაფიკის მოდელებისთვის.

დოკუმენტის მოდელი MS SQL Server-ში

Habré-ზე უკვე იყო ორი შესანიშნავი სტატია იმის შესახებ, თუ როგორ ახორციელებს MS SQL Server მხარდაჭერა დოკუმენტის მოდელისთვის; მე შემოვიფარგლები მოკლედ გადმოცემით და კომენტარით:

MS SQL Server-ში დოკუმენტის მოდელის მხარდაჭერის გზა საკმაოდ ტიპიურია რელაციური DBMS-ებისთვის: JSON დოკუმენტები შემოთავაზებულია შესანახად ჩვეულებრივ ტექსტურ ველებში. დოკუმენტის მოდელის მხარდაჭერა არის სპეციალური ოპერატორების უზრუნველყოფა ამ JSON-ის გასაანალიზებლად:

JSON_VALUE სკალარული ატრიბუტების მნიშვნელობების ამოღება,
JSON_QUERY ქვედოკუმენტების ამოსაღებად.

ორივე ოპერატორის მეორე არგუმენტი არის JSONPath-ის მსგავსი სინტაქსის გამოხატულება.

აბსტრაქტულად, შეგვიძლია ვთქვათ, რომ ამ გზით შენახული დოკუმენტები არ არის „პირველი კლასის ერთეულები“ რელაციურ DBMS-ში, ტუპლებისგან განსხვავებით. კონკრეტულად, MS SQL Server-ში ამჟამად არ არის ინდექსები JSON დოკუმენტების ველებზე, რაც ართულებს ცხრილების შეერთებას ამ ველების მნიშვნელობების გამოყენებით და დოკუმენტების შერჩევასაც კი ამ მნიშვნელობების გამოყენებით. თუმცა, შესაძლებელია ასეთი ველისთვის გამოთვლილი სვეტის შექმნა და მასზე ინდექსი.

გარდა ამისა, MS SQL Server უზრუნველყოფს JSON დოკუმენტის მოხერხებულად აგების შესაძლებლობას ცხრილების შიგთავსიდან ოპერატორის გამოყენებით. FOR JSON PATH - შესაძლებლობა, გარკვეული გაგებით, წინა საპირისპიროდ, ჩვეულებრივი შენახვა. ნათელია, რომ რაც არ უნდა სწრაფი იყოს RDBMS, ეს მიდგომა ეწინააღმდეგება დოკუმენტის DBMS-ების იდეოლოგიას, რომელიც არსებითად ინახავს მზა პასუხებს პოპულარულ შეკითხვებზე და შეუძლია გადაჭრას მხოლოდ განვითარების სიმარტივის პრობლემები, მაგრამ არა სიჩქარე.

და ბოლოს, 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-ში დოკუმენტისა და გრაფიკის მოდელების განხორციელების აღწერილობის შესაჯამებლად, აღვნიშნავ, რომ ერთი მოდელის მეორეზე ზემოდან ასეთი დანერგვა წარმატებულად არ გამოიყურება, პირველ რიგში, ენის დიზაინის თვალსაზრისით. აუცილებელია ერთი ენის გაფართოება მეორეზე, ენები არ არის სრულიად „ორთოგონალური“, თავსებადობის წესები შეიძლება საკმაოდ უცნაური იყოს.

მრავალ მოდელის DBMS დოკუმენტის მოდელზე დაფუძნებული

ამ განყოფილებაში მსურს წარმოვაჩინო მულტი მოდელის დანერგვა დოკუმენტურ DBMS-ებში, მათგან ყველაზე პოპულარული MongoDB-ის მაგალითის გამოყენებით (როგორც ითქვა, მას აქვს მხოლოდ პირობითი გრაფიკის ოპერატორები. $lookup и $graphLookup, არ მუშაობს გახეხილ კოლექციებზე), მაგრამ უფრო მომწიფებული და „საწარმოს“ DBMS-ის მაგალითის გამოყენებით 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 მხარს უჭერს გრაფიკის მოდელს ორი სხვა გზით:

DBMS შეიძლება იყოს RDF მონაცემების სრულფასოვანი ცალკე საცავი (მასში შემავალი სამეული ე.წ. მართვა ზემოთ აღწერილისგან განსხვავებით მოპოვებული).
RDF სპეციალურ სერიალიზაციაში შეიძლება უბრალოდ ჩასვათ XML ან JSON დოკუმენტებში (და ტრიპლეტი გამოიძახება უმართავი). ეს ალბათ მექანიზმების ალტერნატივაა idref და ა.შ.

კარგი იდეა იმის შესახებ, თუ როგორ მუშაობს ყველაფერი "ნამდვილად" MarkLogic-ში მოცემულია ოპტიკური API, ამ თვალსაზრისით, ის დაბალი დონისაა, თუმცა მისი დანიშნულება საკმაოდ საპირისპიროა - ცდილობდეს აბსტრაქციას გამოყენებული მონაცემთა მოდელიდან, უზრუნველყოს მონაცემთა თანმიმდევრული მუშაობა სხვადასხვა მოდელებში, ტრანზაქცია და ა.შ.

მრავალ მოდელის DBMS "მთავარი მოდელის გარეშე"

ასევე არსებობს DBMS ბაზარზე, რომლებიც პოზიციონირებენ როგორც თავდაპირველად მრავალმოდელად, ყოველგვარი მემკვიდრეობითი ძირითადი მოდელის გარეშე. Ესენი მოიცავს ArangoDB, OrientDB (2018 წლიდან დეველოპერული კომპანია SAP-ს ეკუთვნის) და CosmosDB (მომსახურება, როგორც Microsoft Azure ღრუბლოვანი პლატფორმის ნაწილი).

სინამდვილეში, არსებობს "ძირითადი" მოდელები ArangoDB-სა და OrientDB-ში. ორივე შემთხვევაში, ეს არის მათი საკუთარი მონაცემთა მოდელები, რომლებიც წარმოადგენს დოკუმენტის პირველის განზოგადებებს. განზოგადებები ძირითადად მიზნად ისახავს გრაფიკული და რელაციური ხასიათის მოთხოვნების შესრულების უნარს.

ეს მოდელები ერთადერთია, რომლებიც ხელმისაწვდომია მითითებულ DBMS-ში გამოსაყენებლად; მათი შეკითხვის ენები შექმნილია მათთან მუშაობისთვის. რა თქმა უნდა, ასეთი მოდელები და DBMS პერსპექტიულია, მაგრამ სტანდარტულ მოდელებთან და ენებთან თავსებადობის ნაკლებობა შეუძლებელს ხდის ამ DBMS-ების გამოყენებას მემკვიდრეობით სისტემებში - იქ უკვე გამოყენებული DBMS-ების ჩანაცვლება.

უკვე იყო მშვენიერი სტატია ArangoDB-ისა და OrientDB-ის შესახებ Habré-ზე: შეუერთდით NoSQL მონაცემთა ბაზებს.

ArangoDB

ArangoDB აცხადებს მხარდაჭერას გრაფიკული მონაცემების მოდელზე.

გრაფის კვანძები ArangoDB-ში არის ჩვეულებრივი დოკუმენტები, ხოლო კიდეები არის სპეციალური ტიპის დოკუმენტები, რომლებსაც რეგულარულ სისტემის ველებთან ერთად აქვთ (_key, _id, _rev) სისტემის ველები _from и _to. დოკუმენტების DBMS-ებში არსებული დოკუმენტები ტრადიციულად გაერთიანებულია კოლექციებში. დოკუმენტების კოლექციებს, რომლებიც წარმოადგენენ კიდეებს, ArangoDB-ში კიდეების კოლექციებს უწოდებენ. სხვათა შორის, კიდეების შეგროვების დოკუმენტები ასევე დოკუმენტებია, ამიტომ ArangoDB-ში კიდეებს შეუძლიათ აგრეთვე იმოქმედონ როგორც კვანძები.

Raw მონაცემები

მოდით გვქონდეს კოლექცია 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 
  }
]

კითხვები და შედეგები

გრაფიკის სტილის მოთხოვნა AQL ენაზე, რომელიც გამოიყენება ArangoDB-ში, რომელიც აბრუნებს ადამიანის მიერ წასაკითხად ინფორმაციას იმის შესახებ, თუ ვის რომელი კაფე მოსწონს, ასე გამოიყურება:

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 : "Джон Донн" }
]

მეტი შეკითხვა და შედეგი

თუ ზემოთ მოყვანილი შედეგის ფორმატი უფრო ტიპიურია რელაციური DBMS-ისთვის, ვიდრე დოკუმენტის DBMS-ისთვის, შეგიძლიათ სცადოთ ეს შეკითხვა (ან შეგიძლიათ გამოიყენოთ 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-ში კიდეები წარმოდგენილია ცალკე დოკუმენტებად (თუმცა თუ კიდეს არ აქვს საკუთარი თვისებები, მისი დამზადება შესაძლებელია მსუბუქი, და ის არ შეესაბამება ცალკე დოკუმენტს).

Raw მონაცემები

ახლოს ფორმატში ნაგავსაყრელის ფორმატი 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-ზე წვდომა „სუფთა“ შეკითხვის ენებში, რომლებიც არ არის ინტეგრირებული პროგრამირების ენებში.

კითხვები და შედეგები

ArangoDB-ის მაგალითიდან მიღებული შეკითხვა, მიზნობრივად, მსგავსია OrientDB-ში ასე გამოიყურება:

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-ის შეკითხვის ენა შეიძლება აღწერილი იყოს როგორც 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-ში მულტიმოდელია მხოლოდ ერთი მწარმოებლისგან განსხვავებული მოდელების მხარდაჭერის რამდენიმე მონაცემთა ბაზის გამოყენების შესაძლებლობა, რაც არ წყვეტს მრავალვარიანტი შენახვის ყველა პრობლემას.

მრავალ მოდელის DBMS გრაფიკის მოდელზე დაფუძნებული?

საყურადღებოა ის ფაქტი, რომ ბაზარზე ჯერ არ არსებობს მრავალმოდელიანი DBMS, რომლებიც დაფუძნებულია გრაფიკულ მოდელზე (გარდა მრავალმოდელის მხარდაჭერისა ერთდროულად ორი გრაფიკული მოდელისთვის: RDF და LPG; იხილეთ ეს წინა პუბლიკაცია). ყველაზე დიდი სირთულეები გამოწვეულია დოკუმენტის მოდელის დანერგვით გრაფიკის მოდელის თავზე და არა რელაციური.

კითხვა, თუ როგორ უნდა განხორციელდეს რელაციური მოდელი გრაფიკის მოდელის თავზე, განიხილებოდა ამ უკანასკნელის ფორმირების დროსაც. Როგორ ისაუბრამაგალითად, დევიდ მაკგოვერნი:

არაფერია თანდაყოლილი გრაფის მიდგომაში, რომელიც ხელს უშლის ფენის შექმნას (მაგ., შესაბამისი ინდექსირებით) გრაფიკის მონაცემთა ბაზაზე, რომელიც იძლევა ურთიერთდამოკიდებულების ხედვას (1) წყვილების აღდგენით საკვანძო მნიშვნელობის ჩვეულებრივი წყვილებიდან და (2) დაჯგუფება. ტუპლები მიმართების ტიპის მიხედვით.

გრაფიკის მოდელის თავზე დოკუმენტის მოდელის განხორციელებისას, უნდა გაითვალისწინოთ, მაგალითად, შემდეგი:

JSON მასივის ელემენტები განიხილება დალაგებული, მაგრამ ისინი, რომლებიც წარმოიქმნება გრაფის კიდის წვეროდან, არა;
დოკუმენტის მოდელის მონაცემები ჩვეულებრივ დენორმალიზებულია; თქვენ მაინც არ გსურთ შეინახოთ ერთი და იგივე ჩაშენებული დოკუმენტის რამდენიმე ასლი, ხოლო ქვედოკუმენტებს ჩვეულებრივ არ აქვთ იდენტიფიკატორები;
მეორეს მხრივ, დოკუმენტების DBMS-ების იდეოლოგია არის ის, რომ დოკუმენტები არის მზა „აგრეგატები“, რომლებიც არ საჭიროებენ ყოველ ჯერზე ხელახლა აშენებას. საჭიროა გრაფიკის მოდელის მიწოდება მზა დოკუმენტის შესაბამისი ქვეგრაფის სწრაფად მიღების შესაძლებლობით.

ცოტა რეკლამა

სტატიის ავტორი დაკავშირებულია NitrosBase DBMS-ის შემუშავებასთან, რომლის შიდა მოდელი არის გრაფი, ხოლო გარე მოდელები - რელაციური და დოკუმენტური - მისი წარმოდგენები. ყველა მოდელი თანაბარია: თითქმის ნებისმიერი მონაცემი ხელმისაწვდომია ნებისმიერ მათგანში შეკითხვისთვის ბუნებრივი ენის გამოყენებით. უფრო მეტიც, ნებისმიერი თვალსაზრისით, მონაცემები შეიძლება შეიცვალოს. ცვლილებები აისახება შიდა მოდელში და, შესაბამისად, სხვა შეხედულებებზეც.

იმედია აღვწერ, თუ როგორ გამოიყურება მოდელის დამთხვევა NitrosBase-ში ერთ-ერთ შემდეგ სტატიაში.

დასკვნა

ვიმედოვნებ, რომ ზოგადი მონახაზები, რასაც მულტიმოდელირება ჰქვია, მეტ-ნაკლებად ნათელი გახდა მკითხველისთვის. მრავალ მოდელის DBMS საკმაოდ განსხვავებულია და „მრავალმოდელური მხარდაჭერა“ შეიძლება განსხვავებულად გამოიყურებოდეს. იმის გასაგებად, თუ რას ჰქვია "მრავალმოდელს" თითოეულ კონკრეტულ შემთხვევაში, სასარგებლოა პასუხის გაცემა შემდეგ კითხვებზე:

ვსაუბრობთ ტრადიციული მოდელების მხარდაჭერაზე თუ რაიმე სახის „ჰიბრიდულ“ მოდელზე?
არის თუ არა მოდელები „თანაბარი“, თუ ერთ-ერთი მათგანი სხვების საგანია?
არიან თუ არა მოდელები ერთმანეთის მიმართ „გულგრილი“? შეიძლება თუ არა ერთ მოდელში ჩაწერილი მონაცემების წაკითხვა მეორეში ან თუნდაც გადაწერა?

ვფიქრობ, მულტიმოდელური DBMS-ის აქტუალურობის შესახებ კითხვაზე უკვე შეიძლება დადებითი პასუხის გაცემა, მაგრამ საინტერესო კითხვაა, რომელ ტიპებზე იქნება უფრო მოთხოვნადი უახლოეს მომავალში. როგორც ჩანს, მრავალმოდელური DBMS-ები, რომლებიც მხარს უჭერენ ტრადიციულ მოდელებს, უპირველეს ყოვლისა, ურთიერთობებს, უფრო დიდი მოთხოვნა იქნება; მრავალ მოდელის DBMS-ების პოპულარობა, რომლებიც გვთავაზობენ ახალ მოდელებს, რომლებიც აერთიანებს სხვადასხვა ტრადიციულის უპირატესობას, უფრო შორეული მომავლის საკითხია.

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

იყენებთ მრავალ მოდელის DBMS-ს?

ჩვენ არ ვიყენებთ მას, ვინახავთ ყველაფერს ერთ DBMS-ში და ერთ მოდელში
ჩვენ ვიყენებთ ტრადიციული DBMS-ების მრავალ მოდელის შესაძლებლობებს
ჩვენ ვვარჯიშობთ პოლიგლოტურ გამძლეობას
ჩვენ ვიყენებთ ახალ მრავალ მოდელის DBMS-ს (Arango, Orient, CosmosDB)

მისცა ხმა 19 მომხმარებელმა. 4 მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com

არის თუ არა მრავალმოდელიანი DBMS თანამედროვე საინფორმაციო სისტემების საფუძველი?

პოლიგლოტური გამძლეობა

მრავალმოდელი

მრავალმოდელური DBMS, რომელიც დაფუძნებულია რელაციურ მოდელზე

დოკუმენტის მოდელი MS SQL Server-ში

გრაფიკის მოდელი MS SQL სერვერში

მრავალ მოდელის DBMS დოკუმენტის მოდელზე დაფუძნებული

რელაციური მოდელი MarkLogic-ში

გრაფიკის მოდელი MarkLogic-ში

მრავალ მოდელის DBMS "მთავარი მოდელის გარეშე"

ArangoDB

OrientDB

Azure CosmosDB

მრავალ მოდელის DBMS გრაფიკის მოდელზე დაფუძნებული?

დასკვნა

იყენებთ მრავალ მოდელის DBMS-ს?

ახალი კომენტარის დამატება

არის თუ არა მრავალმოდელიანი DBMS თანამედროვე საინფორმაციო სისტემების საფუძველი?

პოლიგლოტური გამძლეობა

მრავალმოდელი

მრავალმოდელური DBMS, რომელიც დაფუძნებულია რელაციურ მოდელზე

დოკუმენტის მოდელი MS SQL Server-ში

გრაფიკის მოდელი MS SQL სერვერში

მრავალ მოდელის DBMS დოკუმენტის მოდელზე დაფუძნებული

რელაციური მოდელი MarkLogic-ში

გრაფიკის მოდელი MarkLogic-ში

მრავალ მოდელის DBMS "მთავარი მოდელის გარეშე"

ArangoDB

OrientDB

Azure CosmosDB

მრავალ მოდელის DBMS გრაფიკის მოდელზე დაფუძნებული?

დასკვნა

იყენებთ მრავალ მოდელის DBMS-ს?

ახალი კომენტარის დამატება პასუხის გასაუქმებლად

ახალი კომენტარის დამატება