डेटाबेस डिझाइन मूलभूत गोष्टी - PostgreSQL, Cassandra आणि MongoDB ची तुलना करणे

नमस्कार मित्रांनो. मे महिन्याच्या सुट्ट्यांच्या दुसऱ्या भागासाठी निघण्यापूर्वी, आम्ही अभ्यासक्रमावर नवीन प्रवाह सुरू होण्याच्या अपेक्षेने भाषांतरित केलेली सामग्री तुमच्यासोबत शेअर करतो. "रिलेशनल डीबीएमएस".

अ‍ॅप्लिकेशन डेव्हलपर अनेक ऑपरेशनल डेटाबेसेसची तुलना करण्यासाठी बराच वेळ घालवतात जे इच्छित वर्कलोडसाठी सर्वात योग्य आहे. गरजांमध्ये सरलीकृत डेटा मॉडेलिंग, व्यवहार हमी, वाचन/लेखन कार्यप्रदर्शन, क्षैतिज स्केलिंग आणि दोष सहिष्णुता यांचा समावेश असू शकतो. पारंपारिकपणे, निवड डेटाबेस श्रेणी, SQL किंवा NoSQL ने सुरू होते, कारण प्रत्येक श्रेणी व्यापार-ऑफचा स्पष्ट संच सादर करते. कमी विलंबता आणि उच्च थ्रूपुटच्या बाबतीत उच्च कार्यप्रदर्शन सामान्यतः नॉन-ट्रेड-ऑफ आवश्यकता म्हणून पाहिले जाते आणि म्हणून कोणत्याही नमुना डेटाबेससाठी आवश्यक आहे.

या लेखाचा उद्देश ऍप्लिकेशन डेव्हलपरना ऍप्लिकेशन डेटा मॉडेलिंगच्या संदर्भात SQL आणि NoSQL दरम्यान योग्य निवड करण्यात मदत करणे आहे. आम्ही एक SQL डेटाबेस, पोस्टग्रेएसक्यूएल, आणि दोन NoSQL डेटाबेस, कॅसॅंड्रा आणि मोंगोडीबी, डेटाबेस डिझाइनच्या मूलभूत गोष्टी जसे की टेबल तयार करणे, ते पॉप्युलेट करणे, टेबलमधून डेटा वाचणे आणि तो हटवणे या गोष्टी कव्हर करण्यासाठी पाहू. पुढील लेखात, आम्ही अनुक्रमणिका, व्यवहार, जॉइन, TTL निर्देश आणि JSON-आधारित डेटाबेस डिझाइन पाहण्याची खात्री करू.

SQL आणि NoSQL मध्ये काय फरक आहे?

SQL डेटाबेस ACID ट्रान्झॅक्शनल गॅरंटीद्वारे ऍप्लिकेशन लवचिकता वाढवतात, तसेच विद्यमान सामान्यीकृत रिलेशनल डेटाबेस मॉडेल्सच्या शीर्षस्थानी अनपेक्षित मार्गांनी JOIN चा वापर करून डेटाची क्वेरी करण्याची त्यांची क्षमता वाढवते.

त्यांचे मोनोलिथिक/सिंगल-नोड आर्किटेक्चर आणि रिडंडंसीसाठी मास्टर-स्लेव्ह प्रतिकृती मॉडेलचा वापर पाहता, पारंपारिक SQL डेटाबेसमध्ये दोन महत्त्वाची वैशिष्ट्ये नाहीत - रेखीय लेखन स्केलेबिलिटी (म्हणजे एकाधिक नोड्सवर स्वयंचलित विभाजन) आणि स्वयंचलित/शून्य डेटा नुकसान. याचा अर्थ असा की प्राप्त झालेल्या डेटाचे प्रमाण एका नोडच्या जास्तीत जास्त लेखन थ्रूपुटपेक्षा जास्त असू शकत नाही. याव्यतिरिक्त, काही तात्पुरती डेटा हानी फॉल्ट टॉलरन्समध्ये (सामायिक-काहीही नसलेल्या आर्किटेक्चरमध्ये) विचारात घेणे आवश्यक आहे. येथे तुम्हाला हे लक्षात ठेवणे आवश्यक आहे की अलीकडील कमिट अद्याप स्लेव्ह कॉपीमध्ये प्रतिबिंबित झाले नाहीत. एसक्यूएल डेटाबेसमध्ये नॉन-डाउनटाइम अद्यतने प्राप्त करणे देखील कठीण आहे.

NoSQL डेटाबेस सहसा निसर्गाद्वारे वितरीत केले जातात, उदा. त्यामध्ये, डेटा विभागांमध्ये विभागला जातो आणि अनेक नोड्समध्ये वितरित केला जातो. त्यांना विकृतीकरण आवश्यक आहे. याचा अर्थ असा की तुम्ही पाठवलेल्या विशिष्ट विनंत्यांना प्रतिसाद देण्यासाठी प्रविष्ट केलेला डेटा देखील अनेक वेळा कॉपी करणे आवश्यक आहे. वाचन दरम्यान उपलब्ध शार्ड्सची संख्या कमी करून उच्च कार्यप्रदर्शन प्राप्त करणे हे एकूण ध्येय आहे. याचा अर्थ असा होतो की NoSQL ला तुम्हाला तुमच्या क्वेरीचे मॉडेल करणे आवश्यक आहे, तर SQL ला तुम्ही तुमचा डेटा मॉडेल करणे आवश्यक आहे.

NoSQL वितरित क्लस्टरमध्ये उच्च कार्यप्रदर्शन साध्य करण्यावर लक्ष केंद्रित करते आणि हे अनेक डेटाबेस डिझाइन ट्रेडऑफसाठी मूलभूत तर्क आहे ज्यात ACID व्यवहार नुकसान, जॉइन आणि सातत्यपूर्ण जागतिक दुय्यम निर्देशांक समाविष्ट आहेत.

असा युक्तिवाद आहे की NoSQL डेटाबेस रेखीय लेखन स्केलेबिलिटी आणि उच्च दोष सहिष्णुता प्रदान करतात, व्यवहार हमी गमावल्यामुळे ते मिशन-क्रिटिकल डेटासाठी अयोग्य बनतात.

NoSQL मधील डेटा मॉडेलिंग SQL पेक्षा कसे वेगळे आहे हे खालील सारणी दाखवते.

SQL आणि NoSQL: दोन्हीची गरज का आहे?

Amazon.com, Netflix, Uber आणि Airbnb सारख्या मोठ्या संख्येने वापरकर्त्यांसह वास्तविक-जागतिक अनुप्रयोगांना जटिल, बहुआयामी कार्ये करण्याचे काम दिले जाते. उदाहरणार्थ, Amazon.com सारख्या ई-कॉमर्स ऍप्लिकेशनला वापरकर्ता माहिती, उत्पादने, ऑर्डर, इनव्हॉइस यांसारखा हलका, उच्च-गंभीर डेटा संग्रहित करणे आवश्यक आहे, तसेच जड, कमी संवेदनशील डेटा जसे की उत्पादन पुनरावलोकने, समर्थन संदेश, वापरकर्ता क्रियाकलाप, वापरकर्ता पुनरावलोकने आणि शिफारसी. साहजिकच, हे अॅप्लिकेशन्स किमान एका NoSQL डेटाबेससह किमान एका SQL डेटाबेसवर अवलंबून असतात. क्रॉस-प्रादेशिक आणि जागतिक प्रणालींमध्ये, NoSQL डेटाबेस एका विशिष्ट प्रदेशात चालणाऱ्या विश्वसनीय स्त्रोत SQL डेटाबेसमध्ये संग्रहित डेटासाठी भौगोलिक-वितरित कॅशे म्हणून कार्य करतो.

युगाबाइट डीबी SQL आणि NoSQL कसे एकत्र करते?

लॉग-ओरिएंटेड मिक्स्ड स्टोरेज इंजिन, ऑटो-शार्डिंग, शार्डेड डिस्ट्रिब्युटेड कॉन्सेन्सस रिप्लिकेशन आणि ACID वितरित व्यवहार (Google स्पॅनरद्वारे प्रेरित) वर तयार केलेले, युगाबाइट डीबी हा जगातील पहिला मुक्त स्रोत डेटाबेस आहे जो एकाच वेळी NoSQL (Cassandra & Redis) शी सुसंगत आहे. SQL (PostgreSQL). खालील तक्त्यामध्ये दर्शविल्याप्रमाणे, YCQL, युगाबाइट DB API Cassandra सह सुसंगत, NoSQL API मध्ये सिंगल आणि मल्टी-की ACID व्यवहार आणि जागतिक दुय्यम निर्देशांकाच्या संकल्पना जोडते, ज्यामुळे व्यवहारिक NoSQL डेटाबेसच्या युगाची सुरुवात होते. याव्यतिरिक्त, YCQL, PostgreSQL सह सुसंगत युगाबाइट DB API, SQL API मध्ये रेखीय लेखन स्केलिंग आणि स्वयंचलित फॉल्ट टॉलरन्सच्या संकल्पना जोडते, वितरित SQL डेटाबेस जगासमोर आणते. कारण युगाबाइट डीबी व्यवहारात आहे, NoSQL API आता मिशन-क्रिटिकल डेटाच्या संदर्भात वापरले जाऊ शकते.

आधी लेखात म्हटल्याप्रमाणे "YSQL सादर करत आहे: युगाबाइट DB साठी एक PostgreSQL सुसंगत वितरित SQL API", YugaByte DB मधील SQL किंवा NoSQL मधील निवड पूर्णपणे अंतर्निहित वर्कलोडच्या वैशिष्ट्यांवर अवलंबून असते:

• जर तुमचा प्राथमिक वर्कलोड मल्टी-की जॉइन ऑपरेशन्स असेल, तर YSQL निवडताना, समजून घ्या की तुमच्या की बहुविध नोड्समध्ये वितरीत केल्या जाऊ शकतात, परिणामी उच्च विलंबता आणि/किंवा NoSQL पेक्षा कमी थ्रूपुट.
• अन्यथा, दोन NoSQL API पैकी एक निवडा, हे लक्षात ठेवून की तुम्हाला एका वेळी एकाच नोडमधून दिलेल्या क्वेरीचा परिणाम म्हणून चांगली कामगिरी मिळेल. युगाबाइट डीबी वास्तविक-जगातील, जटिल अनुप्रयोगांसाठी एकल ऑपरेशनल डेटाबेस म्हणून काम करू शकते ज्यांना एकाच वेळी अनेक वर्कलोड्स व्यवस्थापित करण्याची आवश्यकता आहे.

पुढील विभागातील डेटा मॉडेलिंग लॅब मूळ डेटाबेसच्या विरूद्ध, PostgreSQL आणि Cassandra API सुसंगत युगाबाइट DB डेटाबेसेसवर आधारित आहे. हा दृष्टिकोन दोन भिन्न डेटाबेसचे पूर्णपणे स्वतंत्र क्लस्टर वापरण्याऐवजी, एकाच डेटाबेस क्लस्टरच्या दोन भिन्न API (दोन भिन्न पोर्टवर) सह संवाद साधण्याच्या सुलभतेवर जोर देतो.
खालील विभागांमध्ये, आम्ही कव्हर केलेल्या डेटाबेसमधील फरक आणि काही समानता स्पष्ट करण्यासाठी डेटा मॉडेलिंग लॅबवर एक नजर टाकू.

डेटा मॉडेलिंग प्रयोगशाळा

डेटाबेस स्थापना

डेटा मॉडेल डिझाइनवर (जटिल डिप्लॉयमेंट आर्किटेक्चर्सऐवजी) भर दिल्याने, आम्ही स्थानिक मशीनवर डॉकर कंटेनरमध्ये डेटाबेस स्थापित करू आणि नंतर त्यांच्या संबंधित कमांड लाइन शेल वापरून त्यांच्याशी संवाद साधू.

PostgreSQL आणि Cassandra सुसंगत युगाबाइट 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 साठी कमांड लाइन शेल वापरून डेटाबेसशी कनेक्ट करू.

पोस्टग्रे एसक्यूएल

psql PostgreSQL शी संवाद साधण्यासाठी कमांड लाइन शेल आहे. वापराच्या सुलभतेसाठी, युगाबाइट डीबी बिन फोल्डरमध्ये psql सह येतो.

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

शरिरासाठी चांगलं असतं,

cqlsh CQL (Cassandra Query Language) द्वारे Cassandra आणि त्याच्या सुसंगत डेटाबेसशी संवाद साधण्यासाठी कमांड लाइन शेल आहे. वापर सुलभतेसाठी, युगाबाइट डीबी सोबत येतो 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

एक टेबल तयार करणे

आता आपण कमांड लाइन वापरून विविध ऑपरेशन्स करण्यासाठी डेटाबेसशी संवाद साधू शकतो. वेगवेगळ्या कलाकारांनी लिहिलेल्या गाण्यांबद्दल माहिती संग्रहित करणारा तक्ता तयार करून सुरुवात करूया. ही गाणी अल्बमचा भाग असू शकतात. तसेच गाण्यासाठी पर्यायी विशेषता म्हणजे रिलीजचे वर्ष, किंमत, शैली आणि रेटिंग. आम्हाला "टॅग" फील्डद्वारे भविष्यात आवश्यक असलेल्या अतिरिक्त विशेषतांचा विचार करणे आवश्यक आहे. हे की-व्हॅल्यू जोड्यांच्या स्वरूपात अर्ध-संरचित डेटा संचयित करू शकते.

पोस्टग्रे एसक्यूएल

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 सारखेच आहे. मुख्य फरकांपैकी एक म्हणजे अखंडतेच्या मर्यादांचा अभाव (उदा. NULL नाही), परंतु ही NoSQL डेटाबेस नव्हे तर अनुप्रयोगाची जबाबदारी आहे. प्राथमिक कीमध्ये विभाजन की (खालील उदाहरणातील कलाकार स्तंभ) आणि क्लस्टरिंग स्तंभांचा संच (खालील उदाहरणातील सॉन्गटाइटल स्तंभ) असतो. विभाजन की पंक्ती कोणत्या विभाजन/शार्डमध्ये ठेवायची हे निर्धारित करते आणि क्लस्टरिंग स्तंभ वर्तमान शार्डमध्ये डेटा कसा व्यवस्थित केला जावा हे सूचित करतात.

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 डेटाबेसेस (डेटाबेस) (कॅसॅन्ड्रा मधील कीस्पेस प्रमाणे) डेटा आयोजित करते, जेथे संग्रह (टेबल प्रमाणे) असतात ज्यात दस्तऐवज असतात (टेबलमधील पंक्तींप्रमाणे). मोंगोडीबीमध्ये, मुळात प्रारंभिक स्कीमा परिभाषित करण्याची आवश्यकता नाही. संघ "डेटाबेस वापरा", खाली दर्शविलेले, पहिल्या कॉलवर डेटाबेस इन्स्टंट करते आणि नव्याने तयार केलेल्या डेटाबेससाठी संदर्भ बदलते. संग्रह देखील स्पष्टपणे तयार करणे आवश्यक नाही; ते स्वयंचलितपणे तयार केले जातात, फक्त जेव्हा तुम्ही नवीन संग्रहात पहिला दस्तऐवज जोडता. लक्षात घ्या की मोंगोडीबी डीफॉल्टनुसार चाचणी डेटाबेस वापरते, त्यामुळे विशिष्ट डेटाबेस निर्दिष्ट न करता कोणतेही संकलन-स्तरीय ऑपरेशन डीफॉल्टनुसार त्यावर चालेल.

use myNewDatabase;

टेबलबद्दल माहिती मिळवणे
पोस्टग्रे एसक्यूएल

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;

टेबलमध्ये डेटा प्रविष्ट करणे
पोस्टग्रे एसक्यूएल

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 सारखेच दिसते. तथापि, सिमेंटिक्समध्ये एक मोठा फरक आहे. Cassandra मध्ये INSERT प्रत्यक्षात एक ऑपरेशन आहे UPSERT, जेथे पंक्ती आधीपासून अस्तित्वात असल्यास शेवटची मूल्ये पंक्तीमध्ये जोडली जातात.

डेटा एंट्री पोस्टग्रेएसक्यूएल सारखीच आहे INSERT उच्च

.

MongoDB

जरी मोंगोडीबी हा कॅसॅंड्रासारखा NoSQL डेटाबेस असला तरी, त्याच्या इन्सर्टेशन ऑपरेशनमध्ये कॅसॅन्ड्राच्या सिमेंटिक वर्तनाशी काहीही साम्य नाही. मोंगोडीबी मध्ये घाला () संधी नाहीत 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. एसक्यूएल अभिव्यक्ती नंतर परवानगी देते FROM एकाधिक सारण्या निवडा आणि यासह अभिव्यक्ती WHERE कोणत्याही जटिलतेचे असू शकते (ऑपरेशन्ससह JOIN टेबल दरम्यान). तथापि, NoSQL वर गंभीर मर्यादा लादते FROM, आणि फक्त एका निर्दिष्ट टेबलसह कार्य करा आणि मध्ये WHERE, प्राथमिक की नेहमी निर्दिष्ट करणे आवश्यक आहे. हे NoSQL कार्यप्रदर्शन पुशशी संबंधित आहे ज्याबद्दल आम्ही आधी बोललो होतो. या इच्छेमुळे कोणत्याही क्रॉस-टेब्युलर आणि क्रॉस-की परस्परसंवादामध्ये प्रत्येक संभाव्य घट होऊ शकते. विनंतीला प्रतिसाद देताना आंतर-नोड संप्रेषणामध्ये मोठा विलंब होऊ शकतो आणि त्यामुळे सर्वसाधारणपणे टाळले जाते. उदाहरणार्थ, कॅसॅन्ड्राला विशिष्ट ऑपरेटर्सपुरते मर्यादित (केवळ =, IN, <, >, =>, <=) विभाजन की वर, दुय्यम निर्देशांकाची विनंती केल्याशिवाय (येथे फक्त = ऑपरेटरला परवानगी आहे).

पोस्टग्रे एसक्यूएल

खाली क्वेरीची तीन उदाहरणे दिली आहेत जी 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 क्वेरींपैकी, फक्त पहिलीच Cassandra मध्ये अपरिवर्तित कार्य करेल, कारण ऑपरेटर 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

मागील उदाहरणांमध्ये दर्शविल्याप्रमाणे, मोंगोडीबीमध्ये क्वेरी तयार करण्याची मुख्य पद्धत आहे db.collection.find(). या पद्धतीमध्ये संग्रहाचे नाव स्पष्टपणे समाविष्ट आहे (music खालील उदाहरणामध्ये), त्यामुळे एकाधिक संग्रहांची चौकशी करणे प्रतिबंधित आहे.

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

टेबलच्या सर्व पंक्ती वाचणे

सर्व पंक्ती वाचणे हे आम्ही आधी पाहिलेल्या क्वेरी पॅटर्नचे फक्त एक विशेष प्रकरण आहे.

पोस्टग्रे एसक्यूएल

SELECT * 
FROM Music;

शरिरासाठी चांगलं असतं,

वरील PostgreSQL उदाहरणाप्रमाणेच.

MongoDB

db.music.find( {} );

टेबलमधील डेटा संपादित करणे

पोस्टग्रे एसक्यूएल

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

टेबलमधून डेटा काढून टाकत आहे

पोस्टग्रे एसक्यूएल

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

शरिरासाठी चांगलं असतं,

वरील PostgreSQL उदाहरणाप्रमाणेच.

MongoDB

मोंगोडीबीकडे कागदपत्रे हटवण्यासाठी दोन प्रकारचे ऑपरेशन्स आहेत - हटवा() /deleteMany() и () काढा. दोन्ही प्रकार दस्तऐवज हटवतात परंतु भिन्न परिणाम देतात.

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

टेबल हटवत आहे

पोस्टग्रे एसक्यूएल

DROP TABLE Music;

शरिरासाठी चांगलं असतं,

वरील PostgreSQL उदाहरणाप्रमाणेच.

MongoDB

db.music.drop();

निष्कर्ष

एसक्यूएल आणि NoSQL मधील निवडीबद्दलची चर्चा 10 वर्षांहून अधिक काळ सुरू आहे. या वादाचे दोन मुख्य पैलू आहेत: डेटाबेस इंजिन आर्किटेक्चर (मोनोलिथिक, ट्रान्झॅक्शनल एसक्यूएल विरुद्ध डिस्ट्रिब्युटेड, नॉन-ट्रान्झॅक्शनल NoSQL) आणि डेटाबेस डिझाइन दृष्टिकोन (SQL मध्ये तुमच्या डेटाचे मॉडेलिंग vs NoSQL मध्ये तुमच्या क्वेरीचे मॉडेलिंग).

युगाबाइट डीबी सारख्या वितरीत व्यवहार डेटाबेससह, डेटाबेस आर्किटेक्चरबद्दलच्या वादविवादाला सहजपणे विश्रांती दिली जाऊ शकते. डेटा व्हॉल्यूम एका नोडवर लिहिल्या जाऊ शकतात त्यापेक्षा मोठा होत असल्याने, स्वयंचलित शार्डिंग/रिबॅलेंसिंगसह रेखीय लेखन स्केलेबिलिटीला समर्थन देणारे पूर्ण वितरित आर्किटेक्चर आवश्यक होते.

याशिवाय, एका लेखात म्हटल्याप्रमाणे Google मेघ,व्यवहारी, जोरदार सुसंगत आर्किटेक्चर्स आता अधिक आहेत, गैर-व्यवहारापेक्षा चांगली विकास चपळता प्रदान करण्यासाठी वापरली जातात, अखेरीस सुसंगत आर्किटेक्चर.

डेटाबेस डिझाइन चर्चेकडे परत येत असताना, कोणत्याही जटिल वास्तविक-जागतिक अनुप्रयोगासाठी दोन्ही डिझाइन दृष्टिकोन (SQL आणि NoSQL) आवश्यक आहेत असे म्हणणे योग्य आहे. SQL "डेटा मॉडेलिंग" दृष्टीकोन विकासकांना बदलत्या व्यवसाय आवश्यकता अधिक सहजपणे पूर्ण करण्यास अनुमती देतो, तर NoSQL "क्वेरी मॉडेलिंग" दृष्टीकोन समान विकासकांना कमी विलंबता आणि उच्च थ्रूपुटसह मोठ्या प्रमाणात डेटावर कार्य करण्यास अनुमती देतो. या कारणास्तव युगाबाइट डीबी एका पध्दतीचा प्रचार करण्याऐवजी, समान कोरमध्ये SQL आणि NoSQL API प्रदान करते. याव्यतिरिक्त, PostgreSQL आणि Cassandra यासह लोकप्रिय डेटाबेस भाषांसह सुसंगतता प्रदान करून, युगाबाइट DB हे सुनिश्चित करते की विकसकांना वितरित, अत्यंत सुसंगत डेटाबेस इंजिनसह कार्य करण्यासाठी दुसरी भाषा शिकण्याची गरज नाही.

या लेखात, आम्ही PostgreSQL, Cassandra आणि MongoDB मधील डेटाबेस डिझाइन मूलभूत गोष्टी कशा वेगळ्या आहेत हे पाहिले. भविष्यातील लेखांमध्ये, आम्ही अनुक्रमणिका, व्यवहार, जॉइन, TTL निर्देश आणि JSON दस्तऐवज यासारख्या प्रगत डिझाइन संकल्पनांचा अभ्यास करू.

आम्ही तुम्हाला आठवड्याच्या शेवटी विश्रांतीची शुभेच्छा देतो आणि तुम्हाला आमंत्रित करतो विनामूल्य वेबिनार, जे 14 मे रोजी होणार आहे.

स्त्रोत: www.habr.com