Βασικές αρχές σχεδίασης βάσεων δεδομένων - Σύγκριση PostgreSQL, Cassandra και MongoDB

Γεια σας φίλοι. Πριν φύγουμε για το δεύτερο μέρος των εορτών του Μαΐου, μοιραζόμαστε μαζί σας το υλικό που έχουμε μεταφράσει εν όψει της έναρξης μιας νέας ροής στις τιμές "Σχεσιακό DBMS".

Οι προγραμματιστές εφαρμογών ξοδεύουν πολύ χρόνο συγκρίνοντας πολλαπλές λειτουργικές βάσεις δεδομένων για να επιλέξουν αυτή που λειτουργεί καλύτερα για τον προβλεπόμενο φόρτο εργασίας τους. Οι ανάγκες μπορεί να περιλαμβάνουν απλοποιημένη μοντελοποίηση δεδομένων, εγγυήσεις συναλλαγών, απόδοση ανάγνωσης/εγγραφής, οριζόντια κλιμάκωση και ανοχή σφαλμάτων. Παραδοσιακά, η επιλογή ξεκινά με την κατηγορία της βάσης δεδομένων, SQL ή NoSQL, αφού κάθε κατηγορία παρέχει ένα σαφές σύνολο αντισταθμίσεων. Η υψηλή απόδοση όσον αφορά τη χαμηλή καθυστέρηση και την υψηλή απόδοση θεωρείται γενικά ως απαίτηση που δεν μπορεί να τεθεί σε κίνδυνο και επομένως είναι απαραίτητη για οποιαδήποτε βάση δεδομένων στο δείγμα.

Ο σκοπός αυτού του άρθρου είναι να βοηθήσει τους προγραμματιστές εφαρμογών να κάνουν τη σωστή επιλογή μεταξύ SQL και NoSQL στο πλαίσιο της μοντελοποίησης δεδομένων εφαρμογών. Θα εξετάσουμε μία βάση δεδομένων SQL, δηλαδή την PostgreSQL, και δύο βάσεις δεδομένων NoSQL, την Cassandra και την MongoDB, για να καλύψουμε τα βασικά στοιχεία του σχεδιασμού της βάσης δεδομένων, όπως η δημιουργία πινάκων, η συμπλήρωσή τους, η ανάγνωση δεδομένων από έναν πίνακα και η διαγραφή τους. Στο επόμενο άρθρο, σίγουρα θα δούμε ευρετήρια, συναλλαγές, JOIN, οδηγίες TTL και σχεδιασμό βάσης δεδομένων με βάση το JSON.

Ποια είναι η διαφορά μεταξύ SQL και NoSQL;

Οι βάσεις δεδομένων SQL αυξάνουν την ευελιξία της εφαρμογής μέσω εγγυήσεων συναλλαγών ACID, καθώς και την ικανότητά τους να αναζητούν δεδομένα χρησιμοποιώντας JOIN με απροσδόκητους τρόπους πέρα ​​από τα υπάρχοντα κανονικοποιημένα μοντέλα σχεσιακών βάσεων δεδομένων.

Δεδομένης της μονολιθικής τους αρχιτεκτονικής/ενός κόμβου και της χρήσης ενός μοντέλου αναπαραγωγής master-slave για πλεονασμό, οι παραδοσιακές βάσεις δεδομένων SQL δεν διαθέτουν δύο σημαντικά χαρακτηριστικά - γραμμική επεκτασιμότητα εγγραφής (δηλαδή αυτόματο διαχωρισμό σε πολλούς κόμβους) και αυτόματη/μηδενική απώλεια δεδομένων. Αυτό σημαίνει ότι η ποσότητα των δεδομένων που λαμβάνονται δεν μπορεί να υπερβαίνει τη μέγιστη απόδοση εγγραφής ενός μεμονωμένου κόμβου. Επιπλέον, πρέπει να ληφθεί υπόψη κάποια προσωρινή απώλεια δεδομένων για την ανοχή σφαλμάτων (σε μια μη κοινόχρηστη αρχιτεκτονική). Εδώ πρέπει να έχετε κατά νου ότι οι πρόσφατες δεσμεύσεις δεν έχουν ακόμη αντικατοπτριστεί στο υποτελές αντίγραφο. Δεν είναι επίσης δύσκολο να επιτευχθούν ενημερώσεις χρόνου διακοπής στις βάσεις δεδομένων SQL.

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

Η NoSQL δίνει έμφαση στην επίτευξη υψηλής απόδοσης σε ένα κατανεμημένο σύμπλεγμα και αυτό είναι το βασικό σκεπτικό για πολλούς συμβιβασμούς σχεδιασμού βάσεων δεδομένων, οι οποίοι περιλαμβάνουν απώλεια συναλλαγών ACID, JOIN και συνεπείς παγκόσμιους δευτερεύοντες δείκτες.

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

Ο παρακάτω πίνακας δείχνει πώς η μοντελοποίηση δεδομένων στο NoSQL διαφέρει από την SQL.

SQL και NoSQL: Γιατί χρειάζονται και τα δύο;

Οι πραγματικές εφαρμογές με μεγάλο αριθμό χρηστών, όπως οι Amazon.com, Netflix, Uber και Airbnb, είναι υπεύθυνες για την εκτέλεση σύνθετων εργασιών διαφόρων ειδών. Για παράδειγμα, μια εφαρμογή ηλεκτρονικού εμπορίου όπως το Amazon.com πρέπει να αποθηκεύει ελαφριά, εξαιρετικά ευαίσθητα δεδομένα, όπως πληροφορίες για χρήστες, προϊόντα, παραγγελίες, τιμολόγια, μαζί με βαριά αλλά λιγότερο ευαίσθητα δεδομένα όπως κριτικές προϊόντων, μηνύματα υποστήριξης. , δραστηριότητα χρήστη , κριτικές χρηστών και προτάσεις. Φυσικά, αυτές οι εφαρμογές βασίζονται σε τουλάχιστον μία βάση δεδομένων SQL μαζί με τουλάχιστον μία βάση δεδομένων NoSQL. Σε διαπεριφερειακά και παγκόσμια συστήματα, η βάση δεδομένων NoSQL λειτουργεί ως γεωγραφικά κατανεμημένη κρυφή μνήμη για δεδομένα που είναι αποθηκευμένα σε μια αξιόπιστη πηγή, βάση δεδομένων SQL, που λειτουργεί σε οποιαδήποτε περιοχή.

Πώς συνδυάζει το YugaByte DB SQL και NoSQL;

Χτισμένο σε μια μηχανή μικτής αποθήκευσης προσανατολισμένη στο αρχείο καταγραφής, στον αυτόματο διαμοιρασμό, σε κατανεμημένη αντιγραφή κοινής συναίνεσης και σε κατανεμημένες συναλλαγές με ACID (εμπνευσμένη από το Google Spanner), η YugaByte DB είναι η πρώτη βάση δεδομένων ανοιχτού κώδικα στον κόσμο που είναι ταυτόχρονα συμβατή με NoSQL (Cassandra & Redis). ) και SQL (PostgreSQL). Όπως φαίνεται στον παρακάτω πίνακα, το YCQL, ένα YugaByte DB API συμβατό με την Cassandra, προσθέτει τις έννοιες των συναλλαγών ACID ενός και πολλαπλών κλειδιών και των καθολικών δευτερευόντων ευρετηρίων στο NoSQL API, εγκαινιάζοντας έτσι την εποχή των βάσεων δεδομένων NoSQL συναλλαγών. Επιπλέον, το YCQL, ένα YugaByte DB API συμβατό με PostgreSQL, προσθέτει τις έννοιες της γραμμικής κλιμάκωσης εγγραφής και της αυτόματης ανακατεύθυνσης στο SQL API, φέρνοντας κατανεμημένες βάσεις δεδομένων SQL στον κόσμο. Δεδομένου ότι η βάση δεδομένων YugaByte DB είναι εγγενώς συναλλακτική, το NoSQL API μπορεί πλέον να χρησιμοποιηθεί στο πλαίσιο κρίσιμων δεδομένων.

Όπως αναφέρθηκε προηγουμένως στο άρθρο "Παρουσίαση του YSQL: A PostgreSQL Compatible Distributed SQL API for YugaByte DB", η επιλογή μεταξύ SQL ή NoSQL στο YugaByte DB εξαρτάται εξ ολοκλήρου από τα χαρακτηριστικά του υποκείμενου φόρτου εργασίας:

• Εάν ο κύριος φόρτος εργασίας σας είναι λειτουργίες JOIN πολλών κλειδιών, τότε όταν επιλέγετε YSQL, λάβετε υπόψη ότι τα κλειδιά σας ενδέχεται να κατανεμηθούν σε πολλούς κόμβους, με αποτέλεσμα υψηλότερο λανθάνοντα χρόνο και/ή χαμηλότερη απόδοση από το NoSQL.
• Διαφορετικά, επιλέξτε ένα από τα δύο NoSQL API, έχοντας κατά νου ότι θα έχετε καλύτερη απόδοση ως αποτέλεσμα των ερωτημάτων που εξυπηρετούνται από έναν κόμβο κάθε φορά. Το YugaByte DB μπορεί να χρησιμεύσει ως μια ενιαία λειτουργική βάση δεδομένων για πραγματικές πολύπλοκες εφαρμογές που πρέπει να διαχειρίζονται πολλαπλούς φόρτους εργασίας ταυτόχρονα.

Το εργαστήριο μοντελοποίησης δεδομένων στην επόμενη ενότητα βασίζεται στα συμβατά με PostgreSQL και Cassandra API βάσης δεδομένων YugaByte DB, σε αντίθεση με τις αρχικές βάσεις δεδομένων. Αυτή η προσέγγιση δίνει έμφαση στην ευκολία αλληλεπίδρασης με δύο διαφορετικά API (σε δύο διαφορετικές θύρες) του ίδιου συμπλέγματος βάσεων δεδομένων, σε αντίθεση με τη χρήση εντελώς ανεξάρτητων συμπλεγμάτων δύο διαφορετικών βάσεων δεδομένων.
Στις επόμενες ενότητες, θα ρίξουμε μια ματιά στο Data Modeling Lab για να δείξουμε τη διαφορά και μερικά από τα κοινά σημεία των εν λόγω βάσεων δεδομένων.

Εργαστήριο Μοντελοποίησης Δεδομένων

Εγκατάσταση βάσεων δεδομένων

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

Συμβατή PostgreSQL & Cassandra, βάση δεδομένων YugaByte DB

mkdir ~/yugabyte && cd ~/yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod +x yb-docker-ctl
docker pull yugabytedb/yugabyte
./yb-docker-ctl create --enable_postgres

MongoDB

docker run --name my-mongo -d mongo:latest

Πρόσβαση στη γραμμή εντολών

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

PostgreSQL

psql είναι ένα κέλυφος γραμμής εντολών για αλληλεπίδραση με την PostgreSQL. Για ευκολία στη χρήση, το YugaByte DB συνοδεύεται από psql απευθείας στον φάκελο bin.

docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgres

Κασσάνδρα

sqlsh είναι ένα κέλυφος γραμμής εντολών για αλληλεπίδραση με την Cassandra και τις συμβατές βάσεις δεδομένων της μέσω CQL (Cassandra Query Language). Για ευκολία στη χρήση, το YugaByte DB συνοδεύεται από cqlsh στον κατάλογο bin.
Σημειώστε ότι η CQL εμπνεύστηκε από την SQL και έχει παρόμοιες έννοιες πινάκων, γραμμών, στηλών και ευρετηρίων. Ωστόσο, ως γλώσσα NoSQL, προσθέτει ένα συγκεκριμένο σύνολο περιορισμών, τους περισσότερους από τους οποίους θα καλύψουμε επίσης σε άλλα άρθρα.

docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlsh

MongoDB

Mongo είναι ένα κέλυφος γραμμής εντολών για αλληλεπίδραση με το MongoDB. Μπορεί να βρεθεί στον κατάλογο bin της εγκατάστασης MongoDB.

docker exec -it my-mongo bash 
cd bin
mongo

Δημιουργήστε έναν πίνακα

Τώρα μπορούμε να αλληλεπιδράσουμε με τη βάση δεδομένων για να εκτελέσουμε διάφορες λειτουργίες χρησιμοποιώντας τη γραμμή εντολών. Ας ξεκινήσουμε δημιουργώντας έναν πίνακα που αποθηκεύει πληροφορίες για τραγούδια που γράφτηκαν από διαφορετικούς καλλιτέχνες. Αυτά τα τραγούδια μπορεί να είναι μέρος ενός άλμπουμ. Επίσης, προαιρετικά χαρακτηριστικά για το τραγούδι είναι το έτος κυκλοφορίας, η τιμή, το είδος και η βαθμολογία. Πρέπει να λάβουμε υπόψη πρόσθετα χαρακτηριστικά που μπορεί να χρειαστούν στο μέλλον μέσω του πεδίου "ετικέτες". Μπορεί να αποθηκεύσει ημι-δομημένα δεδομένα ως ζεύγη κλειδιού-τιμής.

PostgreSQL

CREATE TABLE Music (
    Artist VARCHAR(20) NOT NULL, 
    SongTitle VARCHAR(30) NOT NULL,
    AlbumTitle VARCHAR(25),
    Year INT,
    Price FLOAT,
    Genre VARCHAR(10),
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);	

Κασσάνδρα

Η δημιουργία ενός πίνακα στην Cassandra μοιάζει πολύ με την PostgreSQL. Μία από τις κύριες διαφορές είναι η απουσία περιορισμών ακεραιότητας (όπως το NOT NULL), αλλά αυτό είναι ευθύνη της εφαρμογής και όχι της βάσης δεδομένων NoSQL.. Το πρωτεύον κλειδί αποτελείται από ένα κλειδί διαμερίσματος (στήλη καλλιτέχνη στο παρακάτω παράδειγμα) και ένα σύνολο στηλών ομαδοποίησης (στήλη SongTitle στο παρακάτω παράδειγμα). Το κλειδί διαμερίσματος καθορίζει σε ποιο διαμέρισμα/θραύσμα θα τοποθετηθεί η σειρά και οι στήλες ομαδοποίησης υποδεικνύουν πώς πρέπει να οργανωθούν τα δεδομένα μέσα στο τρέχον θραύσμα.

CREATE KEYSPACE myapp;
USE myapp;
CREATE TABLE Music (
    Artist TEXT, 
    SongTitle TEXT,
    AlbumTitle TEXT,
    Year INT,
    Price FLOAT,
    Genre TEXT,
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);

MongoDB

Το MongoDB οργανώνει δεδομένα σε βάσεις δεδομένων (Βάση δεδομένων) (παρόμοια με το Keyspace στην Κασσάνδρα), όπου υπάρχουν συλλογές (Συλλογές) (παρόμοια με πίνακες) που περιέχουν έγγραφα (Έγγραφα) (παρόμοια με σειρές σε έναν πίνακα). Στο MongoDB, καταρχήν, δεν απαιτείται αρχικός ορισμός σχήματος. Ομάδα "χρήση βάσης δεδομένων", που φαίνεται παρακάτω, δημιουργεί τη βάση δεδομένων στην πρώτη κλήση και αλλάζει το περιβάλλον για τη βάση δεδομένων που δημιουργήθηκε πρόσφατα. Ακόμη και οι συλλογές δεν χρειάζεται να δημιουργηθούν ρητά, δημιουργούνται αυτόματα, ακριβώς όταν προστίθεται το πρώτο έγγραφο σε μια νέα συλλογή. Σημειώστε ότι το MongoDB χρησιμοποιεί μια δοκιμαστική βάση δεδομένων από προεπιλογή, επομένως οποιαδήποτε λειτουργία σε επίπεδο συλλογής χωρίς να καθορίσετε μια συγκεκριμένη βάση δεδομένων θα εκτελείται σε αυτήν από προεπιλογή.

use myNewDatabase;

Λήψη πληροφοριών για έναν πίνακα
PostgreSQL

d Music
Table "public.music"
    Column    |         Type          | Collation | Nullable | Default 
--------------+-----------------------+-----------+----------+--------
 artist       | character varying(20) |           | not null | 
 songtitle    | character varying(30) |           | not null | 
 albumtitle   | character varying(25) |           |          | 
 year         | integer               |           |          | 
 price        | double precision      |           |          | 
 genre        | character varying(10) |           |          | 
 criticrating | double precision      |           |          | 
 tags         | text                  |           |          | 
Indexes:
    "music_pkey" PRIMARY KEY, btree (artist, songtitle)

Κασσάνδρα

DESCRIBE TABLE MUSIC;
CREATE TABLE myapp.music (
    artist text,
    songtitle text,
    albumtitle text,
    year int,
    price float,
    genre text,
    tags text,
    PRIMARY KEY (artist, songtitle)
) WITH CLUSTERING ORDER BY (songtitle ASC)
    AND default_time_to_live = 0
    AND transactions = {'enabled': 'false'};

MongoDB

use myNewDatabase;
show collections;

Εισαγωγή δεδομένων σε πίνακα
PostgreSQL

INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Year, Price, Genre, CriticRating, 
    Tags)
VALUES(
    'No One You Know', 'Call Me Today', 'Somewhat Famous',
    2015, 2.14, 'Country', 7.8,
    '{"Composers": ["Smith", "Jones", "Davis"],"LengthInSeconds": 214}'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, CriticRating)
VALUES(
    'No One You Know', 'My Dog Spot', 'Hey Now',
    1.98, 'Country', 8.4
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre)
VALUES(
    'The Acme Band', 'Look Out, World', 'The Buck Starts Here',
    0.99, 'Rock'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, 
    Tags)
VALUES(
    'The Acme Band', 'Still In Love', 'The Buck Starts Here',
    2.47, 'Rock', 
    '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": { "Seattle": "20150625", "Cleveland": "20150630"}, "rotation": Heavy}'
);

Κασσάνδρα

Γενικά η έκφραση INSERT στο Cassandra μοιάζει πολύ με αυτό στο PostgreSQL. Ωστόσο, υπάρχει μια μεγάλη διαφορά στη σημασιολογία. Στην Κασσάνδρα INSERT είναι στην πραγματικότητα μια επέμβαση UPSERT, όπου οι τελευταίες τιμές προστίθενται στη συμβολοσειρά, σε περίπτωση που η συμβολοσειρά υπάρχει ήδη.

Η εισαγωγή δεδομένων είναι παρόμοια με την PostgreSQL INSERT πάνω από

.

MongoDB

Παρόλο που το MongoDB είναι μια βάση δεδομένων NoSQL όπως η Cassandra, η λειτουργία εισαγωγής δεδομένων του δεν έχει καμία σχέση με τη σημασιολογική συμπεριφορά της Cassandra. Στο MongoDB εισάγετε() δεν έχει ευκαιρία UPSERT, κάτι που το κάνει παρόμοιο με το PostgreSQL. Προσθήκη προεπιλεγμένων δεδομένων χωρίς _idspecified θα έχει ως αποτέλεσμα την προσθήκη ενός νέου εγγράφου στη συλλογή.

db.music.insert( {
artist: "No One You Know",
songTitle: "Call Me Today",
albumTitle: "Somewhat Famous",
year: 2015,
price: 2.14,
genre: "Country",
tags: {
Composers: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
}
);
db.music.insert( {
artist: "No One You Know",
songTitle: "My Dog Spot",
albumTitle: "Hey Now",
price: 1.98,
genre: "Country",
criticRating: 8.4
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Look Out, World",
albumTitle:"The Buck Starts Here",
price: 0.99,
genre: "Rock"
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Still In Love",
albumTitle:"The Buck Starts Here",
price: 2.47,
genre: "Rock",
tags: {
radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"],
tourDates: {
Seattle: "20150625",
Cleveland: "20150630"
},
rotation: "Heavy"
}
}
);

Ερώτηση πίνακα

Ίσως η πιο σημαντική διαφορά μεταξύ SQL και NoSQL όσον αφορά το ερώτημα είναι η χρήση του FROM и WHERE. Η SQL επιτρέπει μετά την έκφραση FROM επιλέξτε πολλούς πίνακες και μια έκφραση με WHERE μπορεί να είναι οποιασδήποτε πολυπλοκότητας (συμπεριλαμβανομένων των λειτουργιών JOIN μεταξύ των τραπεζιών). Ωστόσο, το NoSQL τείνει να επιβάλλει ένα σκληρό όριο FROM, και εργαστείτε με έναν μόνο καθορισμένο πίνακα και μέσα WHERE, το πρωτεύον κλειδί πρέπει πάντα να προσδιορίζεται. Αυτό οφείλεται στην επιθυμία βελτίωσης της απόδοσης του NoSQL, για την οποία μιλήσαμε νωρίτερα. Αυτή η επιθυμία οδηγεί σε κάθε πιθανή μείωση οποιασδήποτε αλληλεπίδρασης cross-tab και cross-key. Μπορεί να προκαλέσει μεγάλη καθυστέρηση στην επικοινωνία μεταξύ των κόμβων κατά την ανταπόκριση σε ένα αίτημα και επομένως είναι καλύτερα να αποφεύγεται κατ' αρχήν. Για παράδειγμα, η Cassandra απαιτεί να περιορίζονται τα αιτήματα σε συγκεκριμένους χειριστές (επιτρέπονται μόνο =, IN, <, >, =>, <=) στα κλειδιά διαμερισμάτων, εκτός από την περίπτωση υποβολής ερωτημάτων σε δευτερεύον ευρετήριο (μόνο ο τελεστής = επιτρέπεται εδώ).

PostgreSQL

Ακολουθούν τρία παραδείγματα ερωτημάτων που μπορούν εύκολα να εκτελεστούν από μια βάση δεδομένων SQL.

• Εμφάνιση όλων των τραγουδιών του καλλιτέχνη.
• Εμφάνιση όλων των τραγουδιών του καλλιτέχνη που ταιριάζουν με το πρώτο μέρος του τίτλου.
• Εμφανίστε όλα τα τραγούδια του καλλιτέχνη που έχουν μια συγκεκριμένη λέξη στον τίτλο και έχουν τιμή μικρότερη από 1.00.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE 'Call%';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE '%Today%'
AND Price > 1.00;

Κασσάνδρα

Από τα ερωτήματα PostgreSQL που αναφέρονται παραπάνω, μόνο το πρώτο θα λειτουργεί αμετάβλητο στην Κασσάνδρα, επειδή η δήλωση LIKE δεν μπορεί να εφαρμοστεί σε στήλες ομαδοποίησης όπως π.χ SongTitle. Στην περίπτωση αυτή, επιτρέπονται μόνο χειριστές = и IN.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle IN ('Call Me Today', 'My Dog Spot')
AND Price > 1.00;

MongoDB

Όπως φαίνεται στα προηγούμενα παραδείγματα, η κύρια μέθοδος για τη δημιουργία ερωτημάτων στο MongoDB είναι db.collection.find(). Αυτή η μέθοδος περιέχει ρητά το όνομα της συλλογής (music στο παρακάτω παράδειγμα), επομένως δεν επιτρέπεται η υποβολή ερωτημάτων σε πολλές συλλογές.

db.music.find( {
  artist: "No One You Know"
 } 
);
db.music.find( {
  artist: "No One You Know",
  songTitle: /Call/
 } 
);

Ανάγνωση όλων των σειρών ενός πίνακα

Η ανάγνωση όλων των σειρών είναι απλώς μια ειδική περίπτωση του μοτίβου ερωτήματος που συζητήσαμε νωρίτερα.

PostgreSQL

SELECT * 
FROM Music;

Κασσάνδρα

Παρόμοιο με το παραπάνω παράδειγμα PostgreSQL.

MongoDB

db.music.find( {} );

Επεξεργασία δεδομένων σε πίνακα

PostgreSQL

Η PostgreSQL παρέχει μια δήλωση UPDATE για αλλαγή δεδομένων. Δεν έχει καμία ευκαιρία UPSERT, επομένως αυτή η δήλωση θα αποτύχει εάν η σειρά δεν βρίσκεται πλέον στη βάση δεδομένων.

UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';

Κασσάνδρα

Η Κασσάνδρα έχει UPDATE παρόμοια με την PostgreSQL. UPDATE έχει την ίδια σημασιολογία UPSERT, αρέσει INSERT.

Παρόμοιο με το παραπάνω παράδειγμα PostgreSQL.

MongoDB
Λειτουργία εκσυγχρονίζω() στο MongoDB μπορεί να ενημερώσει πλήρως ένα υπάρχον έγγραφο ή να ενημερώσει μόνο ορισμένα πεδία. Από προεπιλογή ενημερώνει μόνο ένα έγγραφο με απενεργοποιημένη τη σημασιολογία UPSERT. Ανανέωση πολλών εγγράφων και παρόμοια συμπεριφορά UPSERT μπορεί να εφαρμοστεί ορίζοντας πρόσθετες σημαίες για τη λειτουργία. Όπως για παράδειγμα στο παρακάτω παράδειγμα, το είδος ενός συγκεκριμένου καλλιτέχνη ενημερώνεται από το τραγούδι του.

db.music.update(
  {"artist": "The Acme Band"},
  { 
    $set: {
      "genre": "Disco"
    }
  },
  {"multi": true, "upsert": true}
);

Αφαίρεση δεδομένων από πίνακα

PostgreSQL

DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';

Κασσάνδρα

Παρόμοιο με το παραπάνω παράδειγμα PostgreSQL.

MongoDB

Το MongoDB έχει δύο τύπους λειτουργιών για τη διαγραφή εγγράφων − deleteOne() /deleteMany() и αφαιρώ(). Και οι δύο τύποι διαγράφουν έγγραφα αλλά επιστρέφουν διαφορετικά αποτελέσματα.

db.music.deleteMany( {
        artist: "The Acme Band"
    }
);

Διαγραφή πίνακα

PostgreSQL

DROP TABLE Music;

Κασσάνδρα

Παρόμοιο με το παραπάνω παράδειγμα PostgreSQL.

MongoDB

db.music.drop();

Συμπέρασμα

Η συζήτηση για την επιλογή μεταξύ SQL και NoSQL μαίνεται για πάνω από 10 χρόνια. Υπάρχουν δύο κύριες πτυχές σε αυτήν τη συζήτηση: η αρχιτεκτονική της μηχανής βάσης δεδομένων (μονολιθική, συναλλακτική SQL έναντι κατανεμημένης, μη συναλλακτική NoSQL) και η προσέγγιση του σχεδιασμού της βάσης δεδομένων (μοντελοποίηση δεδομένων σε SQL έναντι μοντελοποίησης των ερωτήσεών σας σε NoSQL).

Με μια κατανεμημένη βάση δεδομένων συναλλαγών όπως το YugaByte DB, η συζήτηση για την αρχιτεκτονική της βάσης δεδομένων μπορεί εύκολα να διαλυθεί. Καθώς οι όγκοι δεδομένων γίνονται μεγαλύτεροι από αυτόν που μπορεί να εγγραφεί σε έναν μόνο κόμβο, καθίσταται απαραίτητη μια πλήρως κατανεμημένη αρχιτεκτονική που υποστηρίζει επεκτασιμότητα γραμμικής εγγραφής με αυτόματη κοινή χρήση/εξισορρόπηση.

Εκτός από όσα ειπώθηκαν σε ένα από τα άρθρα Google Cloud, οι συναλλακτικές, έντονα συνεπείς αρχιτεκτονικές υιοθετούνται πλέον ευρέως για να παρέχουν καλύτερη ευελιξία ανάπτυξης από τις μη συναλλακτικές, τελικά συνεπείς αρχιτεκτονικές.

Επιστρέφοντας στη συζήτηση του σχεδιασμού της βάσης δεδομένων, είναι δίκαιο να πούμε ότι και οι δύο προσεγγίσεις σχεδιασμού (SQL και NoSQL) είναι απαραίτητες για οποιαδήποτε πολύπλοκη εφαρμογή του πραγματικού κόσμου. Η προσέγγιση "μοντελοποίησης δεδομένων" της SQL επιτρέπει στους προγραμματιστές να ανταποκρίνονται πιο εύκολα στις μεταβαλλόμενες επιχειρηματικές απαιτήσεις, ενώ η προσέγγιση "μοντελοποίησης ερωτημάτων" της NoSQL επιτρέπει στους ίδιους τους προγραμματιστές να χειρίζονται μεγάλες ποσότητες δεδομένων με χαμηλή καθυστέρηση και υψηλή απόδοση. Αυτός είναι ο λόγος που το YugaByte DB παρέχει SQL και NoSQL API σε έναν κοινό πυρήνα και δεν υποστηρίζει καμία από τις προσεγγίσεις. Επιπλέον, παρέχοντας συμβατότητα με δημοφιλείς γλώσσες βάσεων δεδομένων, συμπεριλαμβανομένων των PostgreSQL και Cassandra, το YugaByte DB διασφαλίζει ότι οι προγραμματιστές δεν χρειάζεται να μάθουν άλλη γλώσσα για να εργαστούν με έναν κατανεμημένο εξαιρετικά συνεπή κινητήρα βάσης δεδομένων.

Σε αυτό το άρθρο, εξετάσαμε πώς διαφέρουν τα βασικά στοιχεία του σχεδιασμού της βάσης δεδομένων μεταξύ PostgreSQL, Cassandra και MongoDB. Στα επόμενα άρθρα, θα εμβαθύνουμε σε προηγμένες έννοιες σχεδιασμού, όπως ευρετήρια, συναλλαγές, JOIN, οδηγίες TTL και έγγραφα JSON.

Σας ευχόμαστε καλό Σαββατοκύριακο και σας προσκαλούμε δωρεάν διαδικτυακό σεμινάριοπου θα πραγματοποιηθεί στις 14 Μαΐου.

Πηγή: www.habr.com