მონაცემთა ბაზის დიზაინის საფუძვლები - PostgreSQL, Cassandra და MongoDB-ის შედარება

გამარჯობა მეგობრებო. მაისის არდადეგების მეორე ნაწილში გამგზავრებამდე გაგიზიარებთ მასალას, რომელიც ვთარგმნეთ კურსზე ახალი ნაკადის დაწყების მოლოდინში. "რელატიური DBMS".

აპლიკაციის დეველოპერები დიდ დროს ხარჯავენ მრავალი ოპერატიული მონაცემთა ბაზის შედარებაში, რათა აირჩიონ ის, რომელიც საუკეთესოდ შეეფერება სამუშაო დატვირთვას. საჭიროებები შეიძლება მოიცავდეს მონაცემთა გამარტივებულ მოდელირებას, ტრანზაქციის გარანტიებს, წაკითხვის/ჩაწერის შესრულებას, ჰორიზონტალურ მასშტაბირებას და შეცდომის ტოლერანტობას. ტრადიციულად, არჩევანი იწყება მონაცემთა ბაზის კატეგორიით, SQL ან NoSQL, რადგან თითოეული კატეგორია წარმოადგენს კომპეტენციების მკაფიო კომპლექტს. მაღალი წარმადობა დაბალი შეყოვნებისა და მაღალი გამტარუნარიანობის თვალსაზრისით ზოგადად განიხილება, როგორც შეუცვლელი მოთხოვნა და, შესაბამისად, აუცილებელია ნებისმიერი ნიმუშის მონაცემთა ბაზისთვის.

ამ სტატიის მიზანია დაეხმაროს აპლიკაციის შემქმნელებს გააკეთონ სწორი არჩევანი SQL-სა და NoSQL-ს შორის აპლიკაციის მონაცემთა მოდელირების კონტექსტში. ჩვენ გადავხედავთ ერთ SQL მონაცემთა ბაზას, კერძოდ PostgreSQL და ორ NoSQL მონაცემთა ბაზას, Cassandra და MongoDB, რათა დაფაროს მონაცემთა ბაზის დიზაინის საფუძვლები, როგორიცაა ცხრილების შექმნა, მათი შევსება, მონაცემების წაკითხვა ცხრილიდან და წაშლა. შემდეგ სტატიაში ჩვენ აუცილებლად გადავხედავთ ინდექსებს, ტრანზაქციებს, JOIN-ებს, TTL დირექტივებს და JSON-ზე დაფუძნებულ მონაცემთა ბაზის დიზაინს.

რა განსხვავებაა SQL-სა და NoSQL-ს შორის?

SQL მონაცემთა ბაზები ზრდის აპლიკაციის მოქნილობას ACID ტრანზაქციის გარანტიების მეშვეობით, ასევე მათ უნარს, მოიძიონ მონაცემები JOIN-ების გამოყენებით მოულოდნელი გზებით, არსებული ნორმალიზებული რელაციური მონაცემთა ბაზის მოდელების თავზე.

მათი მონოლითური/ერთი კვანძის არქიტექტურისა და ჭარბი რეპლიკაციისთვის სამაგისტრო-სლავის რეპლიკაციის მოდელის გამოყენების გათვალისწინებით, ტრადიციულ 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-სთან, ამატებს NoSQL API-ს ერთი და მრავალ გასაღებიანი ACID ტრანზაქციების და გლობალური მეორადი ინდექსების ცნებებს, რითაც იწყებს ტრანზაქციების NoSQL მონაცემთა ბაზების ეპოქას. გარდა ამისა, YCQL, YugaByte DB API, რომელიც თავსებადია PostgreSQL-თან, ამატებს SQL API-ს ხაზოვანი ჩაწერის სკალირებისა და შეცდომების ავტომატური ტოლერანტობის ცნებებს, რაც ავრცელებს SQL მონაცემთა ბაზებს მსოფლიოში. იმის გამო, რომ YugaByte DB ტრანზაქციული ხასიათისაა, NoSQL API ახლა შეიძლება გამოყენებულ იქნას მისიის კრიტიკული მონაცემების კონტექსტში.

როგორც ადრე იყო ნათქვამი სტატიაში "წარმოგიდგენთ YSQL: PostgreSQL თავსებადი განაწილებული SQL API YugaByte DB-სთვის"YugaByte DB-ში SQL ან NoSQL-ს შორის არჩევანი მთლიანად დამოკიდებულია ძირითადი დატვირთვის მახასიათებლებზე:

• თუ თქვენი ძირითადი დატვირთვა არის მრავალ გასაღებიანი JOIN ოპერაციები, მაშინ YSQL-ის არჩევისას გაითვალისწინეთ, რომ თქვენი გასაღებები შეიძლება განაწილდეს მრავალ კვანძზე, რაც გამოიწვევს უფრო მაღალ შეყოვნებას და/ან დაბალ გამტარუნარიანობას, ვიდრე NoSQL.
• წინააღმდეგ შემთხვევაში, აირჩიეთ ორი NoSQL API-დან რომელიმე, იმის გათვალისწინებით, რომ თქვენ მიიღებთ უკეთეს შესრულებას ერთი კვანძიდან მოწოდებული მოთხოვნების შედეგად. YugaByte DB შეიძლება იყოს ერთი ოპერაციული მონაცემთა ბაზა რეალურ სამყაროში, რთული აპლიკაციებისთვის, რომლებიც საჭიროებენ მრავალ დატვირთვის ერთდროულად მართვას.

მონაცემთა მოდელირების ლაბორატორია მომდევნო განყოფილებაში დაფუძნებულია PostgreSQL და Cassandra API თავსებადი YugaByte DB მონაცემთა ბაზებზე, განსხვავებით ადგილობრივი მონაცემთა ბაზებისგან. ეს მიდგომა ხაზს უსვამს იმავე მონაცემთა ბაზის კლასტერის ორ განსხვავებულ API-სთან (ორ განსხვავებულ პორტზე) ურთიერთქმედების მარტივობას, განსხვავებით ორი განსხვავებული მონაცემთა ბაზის სრულიად დამოუკიდებელი კლასტერის გამოყენებისა.
შემდეგ სექციებში ჩვენ გადავხედავთ მონაცემთა მოდელირების ლაბორატორიას განსხვავებებისა და დაფარული მონაცემთა ბაზების ზოგიერთი საერთო ილუსტრირებისთვის.

მონაცემთა მოდელირების ლაბორატორია

მონაცემთა ბაზის ინსტალაცია

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

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

Cassandra

cqlsh არის ბრძანების ხაზის ჭურვი კასანდრასთან და მის თავსებადი მონაცემთა ბაზებთან CQL (Cassandra Query Language) საშუალებით ურთიერთობისთვის. მოხერხებულობისთვის, YugaByte DB მოყვება cqlsh კატალოგში bin.
გაითვალისწინეთ, რომ CQL იყო შთაგონებული SQL-ით და აქვს ცხრილების, სტრიქონების, სვეტების და ინდექსების მსგავსი ცნებები. თუმცა, როგორც NoSQL ენა, ის ამატებს გარკვეულ შეზღუდვებს, რომელთა უმეტესობას ასევე განვიხილავთ სხვა სტატიებში.

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

MongoDB

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

Cassandra

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

Cassandra

საერთო გამოხატულება INSERT კასანდრაში ძალიან ჰგავს PostgreSQL-ს. თუმცა, არის ერთი დიდი განსხვავება სემანტიკაში. კასანდრაში INSERT ფაქტიურად ოპერაციაა UPSERT, სადაც ბოლო მნიშვნელობები ემატება მწკრივს, თუ მწკრივი უკვე არსებობს.

მონაცემთა შეყვანა PostgreSQL-ის მსგავსია INSERT ზემოთ

.

MongoDB

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

Cassandra

ზემოთ ჩამოთვლილი 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;

Cassandra

ზემოთ PostgreSQL მაგალითის მსგავსი.

MongoDB

db.music.find( {} );

მონაცემების რედაქტირება ცხრილში

PostgreSQL

PostgreSQL გთავაზობთ ინსტრუქციებს UPDATE მონაცემების შესაცვლელად. მას არ აქვს შესაძლებლობები UPSERT, ასე რომ, ეს განცხადება ვერ იქნება, თუ მწკრივი აღარ არის მონაცემთა ბაზაში.

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

Cassandra

კასანდრას აქვს 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';

Cassandra

ზემოთ PostgreSQL მაგალითის მსგავსი.

MongoDB

MongoDB-ს აქვს ორი ტიპის ოპერაცია დოკუმენტების წასაშლელად - deleteOne() /deleteMany() и ამოღება (). ორივე ტიპი შლის დოკუმენტებს, მაგრამ აბრუნებს განსხვავებულ შედეგებს.

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

ცხრილის წაშლა

PostgreSQL

DROP TABLE Music;

Cassandra

ზემოთ 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