डाटाबेस डिजाइन आधारभूत कुराहरू - PostgreSQL, Cassandra, र MongoDB तुलना गर्दै

नमस्ते साथीहरू। मेको बिदाको दोस्रो भागको लागि प्रस्थान गर्नु अघि, हामी तपाइँसँग सामग्री साझा गर्दछौं जुन हामीले पाठ्यक्रममा नयाँ स्ट्रिमको प्रक्षेपणको प्रत्याशामा अनुवाद गरेका थियौं। "रिलेशनल DBMS".

एप्लिकेसन विकासकर्ताहरूले धेरै अपरेशनल डाटाबेसहरू तुलना गर्न धेरै समय खर्च गर्छन् जुन उद्देश्यको कामको भारसँग राम्रोसँग उपयुक्त छ। आवश्यकताहरूमा सरलीकृत डेटा मोडेलिङ, लेनदेन ग्यारेन्टीहरू, पढ्न/लेखन कार्यसम्पादन, तेर्सो स्केलिंग, र दोष सहिष्णुता समावेश हुन सक्छ। परम्परागत रूपमा, छनौट डाटाबेस कोटी, SQL वा NoSQL बाट सुरु हुन्छ, किनकि प्रत्येक कोटीले ट्रेड-अफहरूको स्पष्ट सेट प्रस्तुत गर्दछ। कम विलम्बता र उच्च थ्रुपुटको सन्दर्भमा उच्च प्रदर्शनलाई सामान्यतया गैर-ट्रेड-अफ आवश्यकताको रूपमा हेरिन्छ र त्यसैले कुनै पनि नमूना डाटाबेसको लागि आवश्यक छ।

यस लेखको उद्देश्य अनुप्रयोग विकासकर्ताहरूलाई अनुप्रयोग डेटा मोडलिङको सन्दर्भमा SQL र NoSQL बीचको सही छनौट गर्न मद्दत गर्नु हो। हामी एउटा SQL डाटाबेस, जस्तै PostgreSQL, र दुई NoSQL डाटाबेसहरू, क्यासान्ड्रा र MongoDB, डाटाबेस डिजाइनको आधारभूत कुराहरू समावेश गर्न, जस्तै तालिकाहरू सिर्जना गर्ने, तिनीहरूलाई भर्ने, तालिकाबाट डाटा पढ्ने, र यसलाई मेटाउने हेर्नेछौं। अर्को लेखमा, हामी अनुक्रमणिकाहरू, लेनदेनहरू, JOINs, TTL निर्देशनहरू, र JSON-आधारित डाटाबेस डिजाइन हेर्न निश्चित हुनेछौं।

SQL र NoSQL बीच के भिन्नता छ?

SQL डाटाबेसहरूले ACID लेनदेन ग्यारेन्टीहरू मार्फत आवेदन लचिलोपन बढाउँछन्, साथसाथै अवस्थित सामान्यीकृत रिलेसनल डाटाबेस मोडेलहरूको शीर्षमा अप्रत्याशित तरिकाहरूमा JOINs प्रयोग गरेर डाटा क्वेरी गर्ने क्षमता।

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

NoSQL डाटाबेस सामान्यतया प्रकृति द्वारा वितरित गरिन्छ, अर्थात्। तिनीहरूमा, डेटा खण्डहरूमा विभाजित र धेरै नोडहरूमा वितरित गरिन्छ। उनीहरूलाई विकृतिकरण चाहिन्छ। यसको मतलब यो हो कि तपाईंले पठाउनुभएको विशेष अनुरोधहरूको जवाफ दिन प्रविष्ट गरिएको डाटा पनि धेरै पटक प्रतिलिपि गरिएको हुनुपर्छ। समग्र लक्ष्य पढ्ने क्रममा उपलब्ध शार्डहरूको संख्या घटाएर उच्च प्रदर्शन प्राप्त गर्नु हो। यसले संकेत गर्दछ कि NoSQL ले तपाइँलाई तपाइँको प्रश्नहरू मोडेल गर्न आवश्यक छ, जबकि SQL ले तपाइँलाई तपाइँको डेटा मोडेल गर्न आवश्यक छ।

NoSQL ले वितरित क्लस्टरमा उच्च कार्यसम्पादन हासिल गर्नमा केन्द्रित छ र ACID लेनदेन हानि, JOINs, र लगातार विश्वव्यापी माध्यमिक अनुक्रमणिकाहरू समावेश गर्ने धेरै डाटाबेस डिजाइन ट्रेडअफहरूको लागि यो अन्तर्निहित तर्क हो।

त्यहाँ एउटा तर्क छ कि जब NoSQL डाटाबेसले रैखिक लेखन स्केलेबिलिटी र उच्च त्रुटि सहिष्णुता प्रदान गर्दछ, लेनदेन ग्यारेन्टीहरू गुमाउँदा उनीहरूलाई मिशन-क्रिटिकल डाटाको लागि अनुपयुक्त बनाउँदछ।

निम्न तालिकाले NoSQL मा डेटा मोडलिङ SQL बाट कसरी फरक छ भनेर देखाउँछ।

SQL र NoSQL: किन दुबै आवश्यक छ?

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

YugaByte DB ले SQL र NoSQL लाई कसरी जोड्छ?

लग-उन्मुख मिश्रित भण्डारण इन्जिनमा निर्मित, स्वत:-शेर्डिङ, साझा वितरित सहमति प्रतिकृति र ACID वितरित लेनदेनहरू (गुगल स्प्यानरबाट प्रेरित), युगाबाइट DB संसारको पहिलो खुला स्रोत डाटाबेस हो जुन NoSQL (Cassandra & Redis) सँग एकैसाथ उपयुक्त छ। SQL (PostgreSQL)। तलको तालिकामा देखाइए अनुसार, YCQL, क्यासान्ड्रासँग मिल्दो युगाबाइट DB API, NoSQL API मा एकल र बहु-कुञ्जी ACID लेनदेनहरू र विश्वव्यापी माध्यमिक अनुक्रमणिकाहरूको अवधारणाहरू थप्छ, जसले गर्दा लेनदेन NoSQL डाटाबेसहरूको युगमा प्रवेश गर्छ। थप रूपमा, YCQL, PostgreSQL सँग मिल्दो युगाबाइट DB API, SQL API मा रैखिक लेखन स्केलिंग र स्वचालित त्रुटि सहिष्णुताको अवधारणाहरू थप्छ, विश्वमा वितरित SQL डाटाबेसहरू ल्याउँछ। YugaByte DB लेनदेन प्रकृतिको हुनाले, NoSQL API अब मिशन-क्रिटिकल डाटाको सन्दर्भमा प्रयोग गर्न सकिन्छ।

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

• यदि तपाईंको प्राथमिक कार्यभार बहु-कुञ्जी JOIN अपरेसनहरू हो भने, तब YSQL छनौट गर्दा, बुझ्नुहोस् कि तपाईंको कुञ्जीहरू धेरै नोडहरूमा वितरित हुन सक्छन्, परिणामस्वरूप उच्च विलम्बता र/वा NoSQL भन्दा कम थ्रुपुट।
• अन्यथा, दुई NoSQL API हरू मध्ये कुनै एक छान्नुहोस्, तपाईंले एक पटकमा एउटै नोडबाट प्रस्तुत गरिएका प्रश्नहरूको परिणाम स्वरूप राम्रो प्रदर्शन प्राप्त गर्नुहुनेछ भन्ने कुरालाई ध्यानमा राख्दै। YugaByte DB ले वास्तविक-विश्व, जटिल अनुप्रयोगहरूको लागि एकल परिचालन डाटाबेसको रूपमा सेवा गर्न सक्छ जुन एकै साथ धेरै कार्यभारहरू व्यवस्थापन गर्न आवश्यक छ।

अर्को खण्डमा डाटा मोडलिङ प्रयोगशाला 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 हरूका लागि कमाण्ड लाइन शेल प्रयोग गरेर डेटाबेसहरूमा जडान गरौं।

PostgreSQL

psql PostgreSQL सँग अन्तरक्रियाको लागि कमाण्ड लाइन शेल हो। प्रयोगको सजिलोको लागि, युगाबाइट DB psql सँग बिन फोल्डरमा आउँछ।

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

Cassandra

cqlsh CQL (Cassandra Query Language) मार्फत Cassandra र यसको मिल्दो डाटाबेसहरूसँग अन्तरक्रिया गर्नको लागि कमाण्ड लाइन शेल हो। प्रयोगको सजिलोको लागि, युगाबाइट 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 सँग मिल्दोजुल्दो छ। मुख्य भिन्नताहरू मध्ये एक अखण्डता अवरोधहरूको अभाव हो (जस्तै 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 ले डाटाबेस (डेटाबेस) (क्यासान्ड्रामा कीस्पेस जस्तै) मा डाटा व्यवस्थित गर्दछ, जहाँ त्यहाँ संग्रहहरू छन् (टेबलहरू जस्तै) जसमा कागजातहरू छन् (तालिकामा पङ्क्तिहरू जस्तै)। 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 मा धेरै मिल्दोजुल्दो देखिन्छ। तर, सिमान्टिक्समा एउटा ठूलो भिन्नता छ। Cassandra मा INSERT वास्तवमा एक अपरेशन हो UPSERT, जहाँ पङ्क्ति पहिले नै अवस्थित छ भने पङ्क्तिमा अन्तिम मानहरू थपिन्छन्।

डाटा प्रविष्टि PostgreSQL जस्तै छ INSERT उच्च

.

MongoDB

यद्यपि MongoDB क्यासान्ड्रा जस्तै NoSQL डाटाबेस हो, यसको सम्मिलन अपरेसन क्यासान्ड्राको सिमेन्टिक व्यवहारसँग मिल्दोजुल्दो छैन। 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 कार्यसम्पादन पुशमा जोडिएको छ जुन हामीले पहिले कुरा गरेका थियौं। यो इच्छाले कुनै पनि क्रस-टेबुलर र क्रस-कुञ्जी अन्तरक्रियामा हरेक सम्भावित कमीलाई निम्त्याउँछ। अनुरोधको जवाफ दिँदा यसले अन्तर-नोड सञ्चारमा ठूलो ढिलाइ परिचय गराउन सक्छ र त्यसैले सामान्य रूपमा बेवास्ता गरिन्छ। उदाहरणका लागि, क्यासान्ड्रालाई केही अपरेटरहरूमा मात्र सीमित हुन प्रश्नहरू आवश्यक छ (केवल =, IN, <, >, =>, <=) विभाजन कुञ्जीहरूमा, माध्यमिक अनुक्रमणिका अनुरोध गर्दा बाहेक (यहाँ = अपरेटरलाई मात्र अनुमति छ)।

PostgreSQL

तल प्रश्नहरूको तीन उदाहरणहरू छन् जुन SQL डाटाबेसद्वारा सजिलै कार्यान्वयन गर्न सकिन्छ।

• कलाकार द्वारा सबै गीतहरू प्रदर्शन गर्नुहोस्;
• शीर्षकको पहिलो भागसँग मेल खाने कलाकारद्वारा सबै गीतहरू प्रदर्शन गर्नुहोस्;
• शीर्षकमा निश्चित शब्द भएको र १.०० भन्दा कम मूल्य भएका कलाकारका सबै गीतहरू प्रदर्शन गर्नुहोस्।

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 सँग कागजातहरू मेटाउन दुई प्रकारका अपरेशनहरू छन् - मेट्नुहोस् एक() /deleteMany() и हटाउनुहोस् ()। दुवै प्रकारका कागजातहरू मेटाउँछन् तर फरक परिणामहरू फर्काउँछन्।

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

तालिका मेटाउँदै

PostgreSQL

DROP TABLE Music;

Cassandra

माथिको PostgreSQL उदाहरण जस्तै।

MongoDB

db.music.drop();

निष्कर्षमा

SQL र NoSQL को बीचमा छनोट गर्ने बारे बहस १० बर्ष भन्दा बढि भैरहेको छ। यस बहसका दुई मुख्य पक्षहरू छन्: डाटाबेस इन्जिन आर्किटेक्चर (मोनोलिथिक, लेनदेन SQL बनाम वितरित, गैर-लेनदेन NoSQL) र डाटाबेस डिजाइन दृष्टिकोण (SQL मा तपाईंको डाटा मोडेलिङ बनाम NoSQL मा तपाईंको प्रश्नहरूको मोडेलिङ)।

युगाबाइट डीबी जस्ता वितरित लेनदेन डाटाबेसको साथ, डाटाबेस वास्तुकलाको बारेमा बहस सजिलैसँग आराम गर्न सकिन्छ। डेटा भोल्युमहरू एकल नोडमा लेख्न सकिने भन्दा ठूला हुँदै जाँदा, स्वचालित शार्डिङ/रिब्यालेन्सिङको साथ रैखिक लेखन स्केलेबिलिटीलाई समर्थन गर्ने पूर्ण रूपमा वितरित वास्तुकला आवश्यक हुन्छ।

यसबाहेक, लेख मध्ये एक मा भनिएको छ गुगल क्लाउड,लेनदेनात्मक, बलियो संगत आर्किटेक्चरहरू अब अधिक छन्, गैर-लेनदेन भन्दा राम्रो विकास चपलता प्रदान गर्न प्रयोग गरिन्छ, ,अन्ततः सुसंगत आर्किटेक्चरहरू।

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

यस लेखमा, हामीले कसरी डाटाबेस डिजाइन आधारभूतहरू PostgreSQL, Cassandra, र MongoDB बीच भिन्नता देख्यौं। भविष्यका लेखहरूमा, हामी अनुक्रमणिकाहरू, लेनदेनहरू, JOINs, TTL निर्देशनहरू, र JSON कागजातहरू जस्ता उन्नत डिजाइन अवधारणाहरूमा डुब्नेछौं।

हामी तपाईंलाई सप्ताहन्तको उत्कृष्ट विश्रामको कामना गर्दछौं र तपाईंलाई निमन्त्रणा गर्दछौं नि: शुल्क वेबिनार, जुन मे 14 मा हुनेछ।

स्रोत: www.habr.com