డేటాబేస్ డిజైన్ ఫండమెంటల్స్ - PostgreSQL, Cassandra మరియు MongoDBని పోల్చడం

హలో, మిత్రులారా. మే సెలవుల రెండవ భాగానికి బయలుదేరే ముందు, కోర్సులో కొత్త స్ట్రీమ్ ప్రారంభించబడుతుందని ఊహించి మేము అనువదించిన విషయాలను మీతో పంచుకుంటాము "సంబంధిత DBMS".

అప్లికేషన్ డెవలపర్‌లు ఉద్దేశించిన పనిభారానికి బాగా సరిపోయేదాన్ని ఎంచుకోవడానికి బహుళ కార్యాచరణ డేటాబేస్‌లను సరిపోల్చడానికి చాలా సమయాన్ని వెచ్చిస్తారు. అవసరాలలో సరళీకృత డేటా మోడలింగ్, లావాదేవీల హామీలు, చదవడం/వ్రాయడం పనితీరు, క్షితిజ సమాంతర స్కేలింగ్ మరియు తప్పు సహనం వంటివి ఉండవచ్చు. సాంప్రదాయకంగా, ఎంపిక అనేది డేటాబేస్ వర్గం, SQL లేదా NoSQLతో ప్రారంభమవుతుంది, ఎందుకంటే ప్రతి వర్గం స్పష్టమైన ట్రేడ్-ఆఫ్‌లను అందిస్తుంది. తక్కువ జాప్యం మరియు అధిక నిర్గమాంశ పరంగా అధిక పనితీరు సాధారణంగా నాన్-ట్రేడ్-ఆఫ్ అవసరంగా పరిగణించబడుతుంది మరియు అందువల్ల ఏదైనా నమూనా డేటాబేస్ కోసం ఇది అవసరం.

అప్లికేషన్ డేటా మోడలింగ్ సందర్భంలో SQL మరియు NoSQL మధ్య సరైన ఎంపిక చేయడంలో అప్లికేషన్ డెవలపర్‌లకు సహాయం చేయడం ఈ కథనం యొక్క ఉద్దేశ్యం. మేము ఒక SQL డేటాబేస్, అవి PostgreSQL మరియు రెండు NoSQL డేటాబేస్‌లను పరిశీలిస్తాము, కాసాండ్రా మరియు మొంగోడిబి, డేటాబేస్ డిజైన్ యొక్క ప్రాథమికాలను కవర్ చేయడానికి, పట్టికలను సృష్టించడం, వాటిని నింపడం, టేబుల్ నుండి డేటాను చదవడం మరియు దానిని తొలగించడం వంటివి. తర్వాతి కథనంలో, మేము ఖచ్చితంగా సూచికలు, లావాదేవీలు, JOINలు, TTL ఆదేశాలు మరియు JSON-ఆధారిత డేటాబేస్ రూపకల్పనను చూస్తాము.

SQL మరియు NoSQL మధ్య తేడా ఏమిటి?

SQL డేటాబేస్‌లు ACID లావాదేవీల హామీల ద్వారా అప్లికేషన్ సౌలభ్యాన్ని పెంచుతాయి, అలాగే ఇప్పటికే ఉన్న సాధారణీకరించిన రిలేషనల్ డేటాబేస్ మోడల్‌ల పైన ఊహించని మార్గాల్లో JOINలను ఉపయోగించి డేటాను ప్రశ్నించే సామర్థ్యాన్ని పెంచుతాయి.

వాటి మోనోలిథిక్/సింగిల్-నోడ్ ఆర్కిటెక్చర్ మరియు రిడెండెన్సీ కోసం మాస్టర్-స్లేవ్ రెప్లికేషన్ మోడల్‌ను ఉపయోగించడం వల్ల, సాంప్రదాయ SQL డేటాబేస్‌లకు రెండు ముఖ్యమైన లక్షణాలు లేవు - లీనియర్ రైట్ స్కేలబిలిటీ (అనగా బహుళ నోడ్‌లలో ఆటోమేటిక్ విభజన) మరియు ఆటోమేటిక్/జీరో డేటా నష్టం. దీనర్థం అందుకున్న డేటా మొత్తం ఒకే నోడ్ యొక్క గరిష్ట వ్రాత నిర్గమాంశను మించకూడదు. అదనంగా, కొంత తాత్కాలిక డేటా నష్టాన్ని తప్పు సహనం (షేర్డ్-నథింగ్ ఆర్కిటెక్చర్‌లో) పరిగణనలోకి తీసుకోవాలి. బానిస కాపీలో ఇటీవలి కమిట్‌లు ఇంకా ప్రతిబింబించలేదని ఇక్కడ మీరు గుర్తుంచుకోవాలి. SQL డేటాబేస్‌లలో నాన్-డౌన్‌టైమ్ అప్‌డేట్‌లు సాధించడం కూడా కష్టం.

NoSQL డేటాబేస్‌లు సాధారణంగా ప్రకృతి ద్వారా పంపిణీ చేయబడతాయి, అనగా. వాటిలో, డేటా విభాగాలుగా విభజించబడింది మరియు అనేక నోడ్‌లలో పంపిణీ చేయబడుతుంది. వారికి డీనార్మలైజేషన్ అవసరం. అంటే మీరు పంపే నిర్దిష్ట అభ్యర్థనలకు ప్రతిస్పందించడానికి నమోదు చేసిన డేటా కూడా చాలాసార్లు కాపీ చేయబడాలి. చదివేటప్పుడు అందుబాటులో ఉండే ముక్కల సంఖ్యను తగ్గించడం ద్వారా అధిక పనితీరును పొందడం మొత్తం లక్ష్యం. NoSQLకి మీరు మీ ప్రశ్నలను మోడల్ చేయవలసి ఉంటుందని ఇది సూచిస్తుంది, అయితే SQLకి మీరు మీ డేటాను మోడల్ చేయవలసి ఉంటుంది.

పంపిణీ చేయబడిన క్లస్టర్‌లో అధిక పనితీరును సాధించడంపై NoSQL దృష్టి పెడుతుంది మరియు ఇది ACID లావాదేవీ నష్టం, JOINలు మరియు స్థిరమైన గ్లోబల్ సెకండరీ ఇండెక్స్‌లను కలిగి ఉన్న అనేక డేటాబేస్ డిజైన్ ట్రేడ్‌ఆఫ్‌లకు అంతర్లీన కారణం.

NoSQL డేటాబేస్‌లు లీనియర్ రైట్ స్కేలబిలిటీ మరియు హై ఫాల్ట్ టాలరెన్స్‌ని అందజేస్తుండగా, లావాదేవీల హామీల నష్టం వాటిని మిషన్-క్రిటికల్ డేటాకు తగదని ఒక వాదన ఉంది.

SQL నుండి NoSQLలో డేటా మోడలింగ్ ఎలా విభిన్నంగా ఉందో క్రింది పట్టిక చూపిస్తుంది.

SQL మరియు NoSQL: రెండూ ఎందుకు అవసరం?

Amazon.com, Netflix, Uber మరియు Airbnb వంటి పెద్ద సంఖ్యలో వినియోగదారులతో ఉన్న వాస్తవ-ప్రపంచ అప్లికేషన్‌లు సంక్లిష్టమైన, బహుముఖ విధులను నిర్వర్తించే పనిలో ఉన్నాయి. ఉదాహరణకు, Amazon.com వంటి ఇ-కామర్స్ అప్లికేషన్ వినియోగదారు సమాచారం, ఉత్పత్తులు, ఆర్డర్‌లు, ఇన్‌వాయిస్‌లు వంటి తేలికైన, అత్యంత కీలకమైన డేటాతో పాటు ఉత్పత్తి సమీక్షలు, మద్దతు సందేశాలు, వినియోగదారు కార్యాచరణ వంటి భారీ, తక్కువ సున్నితమైన డేటాను నిల్వ చేయాలి. వినియోగదారు సమీక్షలు మరియు సిఫార్సులు. సహజంగానే, ఈ అప్లికేషన్‌లు కనీసం ఒక SQL డేటాబేస్‌తో పాటు కనీసం ఒక NoSQL డేటాబేస్‌పై ఆధారపడతాయి. క్రాస్-రీజనల్ మరియు గ్లోబల్ సిస్టమ్స్‌లో, ఒక NoSQL డేటాబేస్ ఒకే ప్రాంతంలో నడుస్తున్న విశ్వసనీయ మూలం SQL డేటాబేస్‌లో నిల్వ చేయబడిన డేటా కోసం జియో-డిస్ట్రిబ్యూటెడ్ కాష్‌గా పనిచేస్తుంది.

YugaByte DB SQL మరియు NoSQLలను ఎలా మిళితం చేస్తుంది?

లాగ్-ఓరియెంటెడ్ మిక్స్‌డ్ స్టోరేజ్ ఇంజన్, ఆటో-షార్డింగ్, షార్డ్ డిస్ట్రిబ్యూటెడ్ ఏకాభిప్రాయ ప్రతిరూపణ మరియు ACID పంపిణీ లావాదేవీలు (గూగుల్ స్పానర్ ద్వారా ప్రేరణ పొందింది), యుగాబైట్ DB అనేది ప్రపంచంలోని మొట్టమొదటి ఓపెన్ సోర్స్ డేటాబేస్, ఇది NoSQL (కాసాండ్రా & రెడిస్)తో ఏకకాలంలో అనుకూలంగా ఉంటుంది. SQL (PostgreSQL). దిగువ పట్టికలో చూపినట్లుగా, YCQL, YugaByte DB API, Cassandraతో అనుకూలమైనది, NoSQL APIకి సింగిల్ మరియు బహుళ-కీ ACID లావాదేవీలు మరియు గ్లోబల్ సెకండరీ ఇండెక్స్‌ల భావనలను జోడిస్తుంది, తద్వారా లావాదేవీ NoSQL డేటాబేస్‌ల యుగానికి నాంది పలికింది. అదనంగా, YCQL, PostgreSQLకి అనుకూలంగా ఉండే YugaByte DB API, SQL APIకి లీనియర్ రైట్ స్కేలింగ్ మరియు ఆటోమేటిక్ ఫాల్ట్ టాలరెన్స్ భావనలను జోడిస్తుంది, పంపిణీ చేయబడిన SQL డేటాబేస్‌లను ప్రపంచానికి తీసుకువస్తుంది. YugaByte DB అనేది లావాదేవీల స్వభావాన్ని కలిగి ఉన్నందున, NoSQL API ఇప్పుడు మిషన్-క్రిటికల్ డేటా సందర్భంలో ఉపయోగించబడుతుంది.

గతంలో వ్యాసంలో చెప్పినట్లుగా "YSQLని పరిచయం చేస్తోంది: YugaByte DB కోసం పోస్ట్‌గ్రెస్‌ఎస్‌క్యూఎల్ అనుకూల పంపిణీ చేయబడిన SQL API", YugaByte DBలో SQL లేదా NoSQL మధ్య ఎంపిక పూర్తిగా అంతర్లీన పనిభారం యొక్క లక్షణాలపై ఆధారపడి ఉంటుంది:

• మీ ప్రాథమిక పనిభారం బహుళ-కీ JOIN కార్యకలాపాలు అయితే, YSQLని ఎంచుకున్నప్పుడు, మీ కీలు బహుళ నోడ్‌లలో పంపిణీ చేయబడవచ్చని అర్థం చేసుకోండి, దీని ఫలితంగా NoSQL కంటే ఎక్కువ జాప్యం మరియు/లేదా తక్కువ నిర్గమాంశ వస్తుంది.
• లేకపోతే, ఒకేసారి ఒక నోడ్ నుండి అందించిన ప్రశ్నల ఫలితంగా మీరు మెరుగైన పనితీరును పొందుతారని గుర్తుంచుకోండి, రెండు NoSQL APIలలో దేనినైనా ఎంచుకోండి. యుగాబైట్ 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తో పరస్పర చర్య చేయడానికి కమాండ్ లైన్ షెల్. వాడుకలో సౌలభ్యం కోసం, YugaByte DB బిన్ ఫోల్డర్‌లోనే psqlతో వస్తుంది.

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

కాసాండ్రా

cqlsh CQL (కాసాండ్రా క్వెరీ లాంగ్వేజ్) ద్వారా కాసాండ్రా మరియు దాని అనుకూల డేటాబేస్‌లతో పరస్పర చర్య చేయడానికి కమాండ్ లైన్ షెల్. వాడుకలో సౌలభ్యం కోసం, 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)
);	

కాసాండ్రా

కాసాండ్రాలో పట్టికను సృష్టించడం 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 డిఫాల్ట్‌గా పరీక్ష డేటాబేస్‌ను ఉపయోగిస్తుందని గమనించండి, కాబట్టి నిర్దిష్ట డేటాబేస్‌ను పేర్కొనకుండా ఏదైనా సేకరణ-స్థాయి ఆపరేషన్ డిఫాల్ట్‌గా దానిపై రన్ అవుతుంది.

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 కాసాండ్రాలో పోస్ట్‌గ్రెస్‌ఎస్‌క్యూఎల్‌లో చాలా పోలి ఉంటుంది. అయితే, అర్థశాస్త్రంలో ఒక పెద్ద తేడా ఉంది. కాసాండ్రాలో INSERT నిజానికి ఒక ఆపరేషన్ UPSERT, అడ్డు వరుస ఇప్పటికే ఉన్నట్లయితే చివరి విలువలు అడ్డు వరుసకు జోడించబడతాయి.

డేటా ఎంట్రీ PostgreSQL మాదిరిగానే ఉంటుంది 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. వ్యక్తీకరణ తర్వాత SQL అనుమతిస్తుంది FROM బహుళ పట్టికలను ఎంచుకోండి మరియు దీనితో వ్యక్తీకరణ WHERE ఏదైనా సంక్లిష్టత కలిగి ఉండవచ్చు (ఆపరేషన్‌లతో సహా JOIN పట్టికల మధ్య). అయినప్పటికీ, NoSQL తీవ్ర పరిమితిని విధించేలా చేస్తుంది FROM, మరియు ఒక పేర్కొన్న పట్టికతో మాత్రమే పని చేయండి మరియు ఇన్ 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;

కాసాండ్రా

పైన జాబితా చేయబడిన 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

మునుపటి ఉదాహరణలలో చూపినట్లుగా, 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() /తొలగించు అనేక() и తొలగించు (). రెండు రకాలు పత్రాలను తొలగిస్తాయి కానీ వేర్వేరు ఫలితాలను అందిస్తాయి.

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

పట్టికను తొలగిస్తోంది

PostgreSQL

DROP TABLE Music;

కాసాండ్రా

పైన ఉన్న PostgreSQL ఉదాహరణ లాగానే.

MongoDB

db.music.drop();

తీర్మానం

SQL మరియు NoSQL మధ్య ఎంచుకోవడం గురించి చర్చ 10 సంవత్సరాలకు పైగా కొనసాగుతోంది. ఈ చర్చకు రెండు ప్రధాన అంశాలు ఉన్నాయి: డేటాబేస్ ఇంజిన్ ఆర్కిటెక్చర్ (ఏకశిలా, లావాదేవీల SQL vs పంపిణీ, నాన్-ట్రాన్సాక్షనల్ NoSQL) మరియు డేటాబేస్ డిజైన్ విధానం (SQLలో మీ డేటాను మోడలింగ్ చేయడం vs NoSQLలో మీ ప్రశ్నలను మోడలింగ్ చేయడం).

YugaByte DB వంటి పంపిణీ చేయబడిన లావాదేవీల డేటాబేస్‌తో, డేటాబేస్ ఆర్కిటెక్చర్ గురించి చర్చను సులభంగా నిలిపివేయవచ్చు. డేటా వాల్యూమ్‌లు ఒకే నోడ్‌కు వ్రాయగలిగే దానికంటే పెద్దవిగా మారడంతో, ఆటోమేటిక్ షార్డింగ్/రీబ్యాలెన్సింగ్‌తో లీనియర్ రైట్ స్కేలబిలిటీకి మద్దతు ఇచ్చే పూర్తిగా పంపిణీ చేయబడిన ఆర్కిటెక్చర్ అవసరం అవుతుంది.

అంతేకాకుండా, కథనాలలో ఒకదానిలో పేర్కొన్నట్లు Google మేఘం,లావాదేవీలు కాని, చివరికి స్థిరమైన నిర్మాణాల కంటే మెరుగైన అభివృద్ధి చురుకుదనాన్ని అందించడానికి లావాదేవి, బలమైన స్థిరమైన నిర్మాణాలు ఇప్పుడు ఎక్కువగా ఉపయోగించబడుతున్నాయి.

డేటాబేస్ డిజైన్ చర్చకు తిరిగి వస్తున్నప్పుడు, ఏదైనా సంక్లిష్టమైన వాస్తవ-ప్రపంచ అనువర్తనానికి డిజైన్ విధానాలు (SQL మరియు NoSQL) రెండూ అవసరమని చెప్పడం సరైంది. SQL "డేటా మోడలింగ్" విధానం డెవలపర్‌లు మారుతున్న వ్యాపార అవసరాలను మరింత సులభంగా తీర్చడానికి అనుమతిస్తుంది, అయితే NoSQL "క్వెరీ మోడలింగ్" విధానం అదే డెవలపర్‌లు తక్కువ జాప్యం మరియు అధిక నిర్గమాంశతో పెద్ద వాల్యూమ్‌ల డేటాపై పనిచేయడానికి అనుమతిస్తుంది. ఈ కారణంగానే YugaByte DB విధానాల్లో ఒకదానిని ప్రోత్సహించకుండా, సాధారణ కోర్‌లో SQL మరియు NoSQL APIలను అందిస్తుంది. అదనంగా, PostgreSQL మరియు Cassandraతో సహా ప్రసిద్ధ డేటాబేస్ భాషలతో అనుకూలతను అందించడం ద్వారా, YugaByte DB డెవలపర్లు పంపిణీ చేయబడిన, అత్యంత స్థిరమైన డేటాబేస్ ఇంజిన్‌తో పనిచేయడానికి మరొక భాష నేర్చుకోవాల్సిన అవసరం లేదని నిర్ధారిస్తుంది.

ఈ కథనంలో, PostgreSQL, Cassandra మరియు MongoDB మధ్య డేటాబేస్ డిజైన్ ఫండమెంటల్స్ ఎలా విభిన్నంగా ఉన్నాయో మేము చూశాము. భవిష్యత్ కథనాలలో, మేము ఇండెక్స్‌లు, లావాదేవీలు, JOINలు, TTL ఆదేశాలు మరియు JSON డాక్యుమెంట్‌ల వంటి అధునాతన డిజైన్ కాన్సెప్ట్‌లలోకి ప్రవేశిస్తాము.

మేము మీకు వారాంతంలో గొప్ప విశ్రాంతిని కోరుకుంటున్నాము మరియు మిమ్మల్ని ఆహ్వానిస్తున్నాము ఉచిత webinar, ఇది మే 14న జరుగుతుంది.

మూలం: www.habr.com