Τα σύγχρονα πληροφοριακά συστήματα είναι αρκετά περίπλοκα. Πάνω απ 'όλα, η πολυπλοκότητά τους οφείλεται στην πολυπλοκότητα των δεδομένων που υποβάλλονται σε επεξεργασία σε αυτά. Η πολυπλοκότητα των δεδομένων έγκειται συχνά στην ποικιλία των μοντέλων δεδομένων που χρησιμοποιούνται. Έτσι, για παράδειγμα, όταν τα δεδομένα γίνονται «μεγάλα», ένα από τα προβληματικά χαρακτηριστικά δεν είναι μόνο ο όγκος τους («όγκος»), αλλά και η ποικιλία τους («ποικιλία»).

Εάν δεν έχετε βρει ακόμα κάποιο ελάττωμα στο σκεπτικό, τότε διαβάστε.

περιεχόμενο

Πολύγλωσση επιμονή
Πολυμοντέλο
ΣΔΒΔ πολλαπλών μοντέλων με βάση το σχεσιακό μοντέλο
     Μοντέλο εγγράφου στον MS SQL Server
     Μοντέλο γραφήματος στον MS SQL Server
ΣΔΒΔ πολλαπλών μοντέλων με βάση το μοντέλο εγγράφου
     Σχεσιακό μοντέλο στο MarkLogic
     Μοντέλο γραφήματος στο MarkLogic
ΣΔΒΔ πολλαπλών μοντέλων "χωρίς κύριο μοντέλο"
     ArangoDB
     OrientDB
     Azure CosmosDB
ΣΔΒΔ πολλαπλών μοντέλων που βασίζεται σε μοντέλο γραφήματος;
Συμπέρασμα
Опрос

Πολύγλωσση επιμονή

Τα παραπάνω οδηγούν στο γεγονός ότι μερικές φορές ακόμη και στο πλαίσιο ενός συστήματος είναι απαραίτητο να χρησιμοποιηθούν πολλά διαφορετικά DBMS για την αποθήκευση δεδομένων και την επίλυση διαφόρων προβλημάτων επεξεργασίας τους, καθένα από τα οποία υποστηρίζει το δικό του μοντέλο δεδομένων. Με το ελαφρύ χέρι του Μ. Φάουλερ, ο συγγραφέας μια σειρά από διάσημα βιβλία και ένα από συν-συγγραφείς Agile Manifesto, αυτή η κατάσταση λέγεται αποθήκευση πολλαπλών παραλλαγών («επιμονή πολυγλωσσίας»).

Ο Fowler έχει επίσης το ακόλουθο παράδειγμα οργάνωσης αποθήκευσης δεδομένων σε μια εφαρμογή με πλήρη χαρακτηριστικά και μεγάλο φορτίο στον τομέα του ηλεκτρονικού εμπορίου.

Αυτό το παράδειγμα, φυσικά, είναι κάπως υπερβολικό, αλλά υπάρχουν ορισμένες σκέψεις υπέρ της επιλογής ενός ή άλλου ΣΔΒΔ για τον αντίστοιχο σκοπό, για παράδειγμα, εδώ.

Είναι σαφές ότι το να είσαι υπηρέτης σε έναν τέτοιο ζωολογικό κήπο δεν είναι εύκολο.

Η ποσότητα του κώδικα που εκτελεί αποθήκευση δεδομένων αυξάνεται ανάλογα με τον αριθμό των DBMS που χρησιμοποιούνται. η ποσότητα των δεδομένων συγχρονισμού κώδικα είναι καλή αν δεν είναι ανάλογη με το τετράγωνο αυτού του αριθμού.
Ως πολλαπλάσιο του αριθμού των DBMS που χρησιμοποιούνται, το κόστος παροχής επιχειρησιακών χαρακτηριστικών (επεκτασιμότητα, ανοχή σφαλμάτων, υψηλή διαθεσιμότητα) για κάθε ένα από τα χρησιμοποιούμενα DBMS αυξάνεται.
Είναι αδύνατο να διασφαλιστούν τα επιχειρησιακά χαρακτηριστικά του υποσυστήματος αποθήκευσης στο σύνολό του - ιδιαίτερα η συναλλακτικότητα.

Από τη σκοπιά του διευθυντή του ζωολογικού κήπου, όλα μοιάζουν κάπως έτσι:

Πολλαπλή αύξηση του κόστους αδειών και τεχνικής υποστήριξης από τον κατασκευαστή DBMS.
Υπερπροσωπικό και αυξημένες προθεσμίες.
Άμεσες οικονομικές απώλειες ή κυρώσεις λόγω ασυνέπειας δεδομένων.

Υπάρχει σημαντική αύξηση στο συνολικό κόστος ιδιοκτησίας του συστήματος (TCO). Υπάρχει κάποια διέξοδος από την κατάσταση των «πολλαπλών επιλογών αποθήκευσης»;

Πολυμοντέλο

Ο όρος "πολυμεταβλητή αποθήκευση" άρχισε να χρησιμοποιείται το 2011. Η συνειδητοποίηση των προβλημάτων της προσέγγισης και η αναζήτηση λύσης χρειάστηκαν αρκετά χρόνια και μέχρι το 2015, δια στόματος αναλυτών της Gartner, διατυπώθηκε η απάντηση:

Από "Οδηγός αγοράς για NoSQL DBMS - 2015»
Το μέλλον των DBMS, των αρχιτεκτονικών τους και των τρόπων χρήσης τους είναι πολλαπλών μοντέλων.
Από "Magic Quadrant για ODBMS - 2016»
Τα κορυφαία λειτουργικά DBMS θα προσφέρουν πολλαπλά μοντέλα —σχεσιακά και μη— ως μέρος μιας ενιαίας πλατφόρμας.

Φαίνεται ότι αυτή τη φορά οι αναλυτές της Gartner είχαν δίκιο με την πρόβλεψή τους. Εάν μεταβείτε στη σελίδα με κύρια βαθμολογία DBMS σε DB-Engines, μπορείτε να το δείτε αυτόоΟι περισσότεροι από τους ηγέτες της τοποθετούνται συγκεκριμένα ως DBMS πολλαπλών μοντέλων. Το ίδιο μπορεί να δει κανείς στη σελίδα με οποιαδήποτε ιδιωτική βαθμολογία.

Ο παρακάτω πίνακας δείχνει το DBMS - τους ηγέτες σε καθεμία από τις ιδιωτικές αξιολογήσεις, οι οποίες ισχυρίζονται ότι είναι πολλαπλών μοντέλων. Για κάθε DBMS, υποδεικνύεται το αρχικό υποστηριζόμενο μοντέλο (που κάποτε ήταν το μοναδικό) και μαζί με αυτό τα μοντέλα που υποστηρίζονται αυτήν τη στιγμή. Αναφέρονται επίσης τα DBMS που τοποθετούνται ως «αρχικά πολλαπλά μοντέλα» και, σύμφωνα με τους δημιουργούς, δεν έχουν κάποιο αρχικό κληρονομικό μοντέλο.

DBMS	Αρχικό μοντέλο	Πρόσθετα μοντέλα
μαντείο	σχετικός	Γράφημα, έγγραφο
MS SQL	σχετικός	Γράφημα, έγγραφο
PostgreSQL	σχετικός	Γράφημα*, έγγραφο
MarkLogic	Ντοκυμαντέρ	Γράφημα, σχεσιακό
MongoDB	Ντοκυμαντέρ	Κλειδί-τιμή, γράφημα*
DataStax	Φαρδιά κολόνα	Ντοκιμαντέρ, γράφημα
Ρέντη	Κλειδί-τιμή	Ντοκιμαντέρ, γράφημα*
ArangoDB	-	Γράφημα, έγγραφο
OrientDB	-	Γράφημα, έγγραφο, σχεσιακό
Azure CosmosDB	-	Γράφημα, έγγραφο, σχεσιακό

Σημειώσεις στο τραπέζι

Οι αστερίσκοι στον πίνακα επισημαίνουν δηλώσεις που απαιτούν κράτηση:

Το PostgreSQL DBMS δεν υποστηρίζει το μοντέλο δεδομένων γραφήματος, αλλά αυτό το προϊόν το υποστηρίζει με βάση αυτό, όπως το AgensGraph.
Σε σχέση με το MongoDB, είναι πιο σωστό να μιλάμε για την παρουσία τελεστών γραφήματος στη γλώσσα ερωτήματος ($lookup, $graphLookup) παρά για την υποστήριξη του μοντέλου γραφήματος, αν και, φυσικά, η εισαγωγή τους απαιτούσε ορισμένες βελτιστοποιήσεις σε επίπεδο φυσικής αποθήκευσης προς την κατεύθυνση της υποστήριξης του μοντέλου γραφήματος.
Σε σχέση με το Redis, εννοούμε την επέκταση RedisGraph.

Στη συνέχεια, για κάθε μία από τις κλάσεις, θα δείξουμε πώς η υποστήριξη για πολλά μοντέλα υλοποιείται στο DBMS από αυτήν την κλάση. Θα θεωρήσουμε τα σχεσιακά μοντέλα, τα μοντέλα εγγράφων και γραφημάτων ως τα πιο σημαντικά και θα χρησιμοποιήσουμε παραδείγματα συγκεκριμένων ΣΔΒΔ για να δείξουμε πώς υλοποιούνται τα «ελλείποντα».

ΣΔΒΔ πολλαπλών μοντέλων με βάση το σχεσιακό μοντέλο

Τα κορυφαία DBMS επί του παρόντος είναι σχεσιακά. Και διαδηλώνουν. Τώρα η ιδέα ότι ένα DBMS πολλαπλών μοντέλων είναι σαν ένα ελβετικό μαχαίρι, που δεν μπορεί να κάνει τίποτα καλά, μπορεί να κατευθυνθεί απευθείας στον Larry Ellison.

Ο συγγραφέας, ωστόσο, προτιμά την υλοποίηση της πολυμοντελοποίησης στον 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 Server

Η υποστήριξη για το μοντέλο γραφήματος (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 εγγράφων χρησιμοποιώντας το παράδειγμα του όχι πιο δημοφιλούς από αυτά, του 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 στην αγορά που τοποθετούνται ως αρχικά πολλαπλά μοντέλα, χωρίς κανένα κληρονομικό κύριο μοντέλο. Αυτά περιλαμβάνουν ArangoDB, OrientDB (από το 2018 η εταιρεία ανάπτυξης ανήκει στη SAP) και CosmosDB (υπηρεσία ως μέρος της πλατφόρμας cloud Microsoft Azure).

Στην πραγματικότητα, υπάρχουν μοντέλα "πυρήνας" στο ArangoDB και στο OrientDB. Και στις δύο περιπτώσεις, αυτά είναι τα δικά τους μοντέλα δεδομένων, τα οποία είναι γενικεύσεις του εγγράφου. Οι γενικεύσεις είναι κυρίως για να διευκολύνουν την ικανότητα εκτέλεσης ερωτημάτων γραφικής και σχεσιακής φύσης.

Αυτά τα μοντέλα είναι τα μόνα διαθέσιμα για χρήση στο καθορισμένο DBMS, οι δικές τους γλώσσες ερωτημάτων έχουν σχεδιαστεί για να λειτουργούν με αυτά. Φυσικά, τέτοια μοντέλα και DBMS είναι πολλά υποσχόμενα, αλλά η έλλειψη συμβατότητας με τυπικά μοντέλα και γλώσσες καθιστά αδύνατη τη χρήση αυτών των DBMS σε παλαιού τύπου συστήματα — για την αντικατάσταση των DBMS που χρησιμοποιούνται ήδη εκεί.

Υπήρχε ήδη ένα υπέροχο άρθρο σχετικά με το ArangoDB και το OrientDB στο Habré: ΕΓΓΡΑΦΕΙΤΕ σε βάσεις δεδομένων NoSQL.

ArangoDB

Το ArangoDB αξιώνει υποστήριξη για ένα μοντέλο δεδομένων γραφήματος.

Οι κόμβοι ενός γραφήματος στο ArangoDB είναι συνηθισμένα έγγραφα και οι ακμές είναι έγγραφα ειδικού τύπου που, μαζί με τα κανονικά πεδία συστήματος, έχουν (_key, _id, _rev) πεδία συστήματος _from и _to. Τα έγγραφα στα DBMS εγγράφων συνδυάζονται παραδοσιακά σε συλλογές. Οι συλλογές εγγράφων που αντιπροσωπεύουν ακμές ονομάζονται συλλογές ακμών στο 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 
  }
]

Ερωτήματα και αποτελέσματα

Ένα ερώτημα τύπου γραφήματος στη γλώσσα 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 αντιπροσωπεύονται ως ξεχωριστά έγγραφα (αν και αν μια άκρη δεν έχει τις δικές της ιδιότητες, μπορεί να γίνει πυγμάχος ελαφρού βάρους, και δεν θα αντιστοιχεί σε ξεχωριστό έγγραφο).

Ακατέργαστα δεδομένα

Σε μορφή κοντά στο μορφή απόρριψης 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 με ένθετα τύπου Gremlin. Στην έκδοση 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 ("atom-record-sequence"), το οποίο είναι επίσης κοντά στο έγγραφο.

Ωστόσο, το μοντέλο δεδομένων που επιλέγει ο χρήστης και το API που χρησιμοποιείται διορθώνονται τη στιγμή της δημιουργίας ενός λογαριασμού στην υπηρεσία. Δεν είναι δυνατή η πρόσβαση σε δεδομένα που έχουν φορτωθεί σε ένα μοντέλο σε μορφή άλλου μοντέλου, όπως φαίνεται από κάτι σαν αυτό:

Έτσι, το multi-model στο Azure CosmosDB σήμερα είναι μόνο η δυνατότητα χρήσης πολλών βάσεων δεδομένων που υποστηρίζουν διαφορετικά μοντέλα από έναν κατασκευαστή, κάτι που δεν επιλύει όλα τα προβλήματα αποθήκευσης πολλαπλών παραλλαγών.

ΣΔΒΔ πολλαπλών μοντέλων που βασίζεται σε μοντέλο γραφήματος;

Αξιοσημείωτο είναι το γεγονός ότι δεν υπάρχουν ακόμη στην αγορά DBMS πολλαπλών μοντέλων που να βασίζονται σε μοντέλο γραφήματος (εκτός από την υποστήριξη πολλαπλών μοντέλων για ταυτόχρονα δύο μοντέλα γραφημάτων: RDF και LPG, βλ. προηγούμενη δημοσίευση). Οι μεγαλύτερες δυσκολίες προκαλούνται από την εφαρμογή ενός μοντέλου εγγράφου πάνω από ένα μοντέλο γραφήματος, παρά από ένα σχεσιακό.

Το ερώτημα του πώς να εφαρμοστεί ένα σχεσιακό μοντέλο πάνω από το μοντέλο γραφήματος εξετάστηκε ακόμη και κατά τη διαμόρφωση του τελευταίου. Πως ακτίναΓια παράδειγμα, Ντέιβιντ ΜακΓκόβερν:

Δεν υπάρχει τίποτα εγγενές στην προσέγγιση γραφήματος που να εμποδίζει τη δημιουργία ενός επιπέδου (π.χ. με κατάλληλη ευρετηρίαση) σε μια βάση δεδομένων γραφήματος που επιτρέπει μια σχεσιακή προβολή με (1) ανάκτηση πλειάδων από τα συνηθισμένα ζεύγη τιμών κλειδιών και (2) ομαδοποίηση πλειάδες ανά τύπο σχέσης.

Όταν εφαρμόζετε ένα μοντέλο εγγράφου πάνω από ένα μοντέλο γραφήματος, πρέπει να έχετε υπόψη, για παράδειγμα, τα εξής:

Τα στοιχεία ενός πίνακα JSON θεωρούνται διατεταγμένα, αλλά αυτά που προέρχονται από την κορυφή μιας άκρης του γραφήματος δεν είναι.
Τα δεδομένα στο μοντέλο εγγράφου είναι συνήθως αποκανονικά, δεν θέλετε να αποθηκεύσετε πολλά αντίγραφα του ίδιου ενσωματωμένου εγγράφου και τα δευτερεύοντα έγγραφα συνήθως δεν έχουν αναγνωριστικά.
Από την άλλη πλευρά, η ιδεολογία των DBMS εγγράφων είναι ότι τα έγγραφα είναι έτοιμα "συγκεντρωτικά" που δεν χρειάζεται να χτίζονται εκ νέου κάθε φορά. Απαιτείται να παρέχεται στο μοντέλο γραφήματος η δυνατότητα γρήγορης λήψης υπογράφου που αντιστοιχεί στο έτοιμο έγγραφο.

Κάποια διαφήμιση

Ο συγγραφέας του άρθρου σχετίζεται με την ανάπτυξη του NitrosBase DBMS, το εσωτερικό μοντέλο του οποίου είναι το γράφημα και τα εξωτερικά μοντέλα - σχεσιακά και έγγραφα - είναι οι αναπαραστάσεις του. Όλα τα μοντέλα είναι ίσα: σχεδόν όλα τα δεδομένα είναι διαθέσιμα σε οποιοδήποτε από αυτά χρησιμοποιώντας μια γλώσσα ερωτημάτων που είναι φυσική σε αυτό. Επιπλέον, σε οποιαδήποτε προβολή, τα δεδομένα μπορούν να αλλάξουν. Οι αλλαγές θα αντικατοπτρίζονται στο εσωτερικό μοντέλο και, κατά συνέπεια, σε άλλες απόψεις.

Ελπίζω να περιγράψω πώς φαίνεται η αντιστοίχιση μοντέλων στο NitrosBase σε ένα από τα ακόλουθα άρθρα.

Συμπέρασμα

Ελπίζω ότι τα γενικά περιγράμματα αυτού που ονομάζεται πολυμοντελοποίηση έχουν γίνει λίγο-πολύ σαφή στον αναγνώστη. Τα ΣΔΒΔ πολλαπλών μοντέλων είναι αρκετά διαφορετικά και η "υποστήριξη πολλαπλών μοντέλων" μπορεί να φαίνεται διαφορετική. Για να κατανοήσετε τι ονομάζεται "πολυμοντέλο" σε κάθε συγκεκριμένη περίπτωση, είναι χρήσιμο να απαντήσετε στις ακόλουθες ερωτήσεις:

Μιλάμε για υποστήριξη παραδοσιακών μοντέλων ή κάποιου είδους «υβριδικού» μοντέλου;
Είναι τα μοντέλα «ίσα» ή ένα από αυτά είναι αντικείμενο των άλλων;
Είναι τα μοντέλα «αδιάφορα» μεταξύ τους; Μπορούν τα δεδομένα που είναι γραμμένα σε ένα μοντέλο να διαβαστούν σε άλλο ή ακόμα και να αντικατασταθούν;

Νομίζω ότι η ερώτηση σχετικά με τη συνάφεια των DBMS πολλαπλών μοντέλων μπορεί ήδη να απαντηθεί θετικά, αλλά το ενδιαφέρον ερώτημα είναι ποιοι τύποι από αυτούς θα είναι πιο περιζήτητοι στο εγγύς μέλλον. Φαίνεται ότι τα DBMS πολλαπλών μοντέλων που υποστηρίζουν παραδοσιακά μοντέλα, κυρίως σχεσιακά, θα έχουν μεγαλύτερη ζήτηση. Η δημοτικότητα των DBMS πολλαπλών μοντέλων, που προσφέρουν νέα μοντέλα που συνδυάζουν τα πλεονεκτήματα διαφόρων παραδοσιακών, είναι θέμα του πιο απώτερου μέλλοντος.

Μόνο εγγεγραμμένοι χρήστες μπορούν να συμμετάσχουν στην έρευνα. Συνδεθείτε, Σας παρακαλούμε.