پرو هوسٽر > بلاگ > انتظاميه > ڊيٽابيس ڊيزائن جا بنيادي اصول - PostgreSQL، Cassandra ۽ MongoDB جي مقابلي ۾

ڊيٽابيس ڊيزائن جا بنيادي اصول - PostgreSQL، Cassandra ۽ MongoDB جي مقابلي ۾

هيلو، دوستو. مئي جي موڪلن جي ٻئي حصي لاءِ وڃڻ کان اڳ، اسان توهان سان شيئر ڪريون ٿا مواد جيڪو اسان ترجمو ڪيو آهي ڪورس تي هڪ نئين وهڪرو جي شروعات جي توقع ۾ "لابستگي DBMS".

ڊيٽابيس ڊيزائن جا بنيادي اصول - PostgreSQL، Cassandra ۽ MongoDB جي مقابلي ۾

ايپليڪيشن ڊولپر ڪيترن ئي آپريشنل ڊيٽابيسس جي مقابلي ۾ گهڻو وقت گذاريندا آهن انهي کي چونڊڻ لاءِ جيڪو مطلوب ڪم لوڊ لاءِ مناسب آهي. ضرورتن ۾ شامل ٿي سگھي ٿي آسان ڊيٽا ماڊلنگ، ٽرانزيڪشنل گارنٽي، پڙھڻ/لکڻ جي ڪارڪردگي، افقي اسڪيلنگ، ۽ غلطي رواداري. روايتي طور تي، انتخاب ڊيٽابيس جي درجي، SQL يا NoSQL سان شروع ٿئي ٿو، ڇاڪاڻ ته هر قسم جي واپار جو واضح سيٽ پيش ڪري ٿو. گھٽ ويڪرائي جي لحاظ کان اعلي ڪارڪردگي ۽ اعلي throughput کي عام طور تي ڏٺو ويندو آهي غير واپار جي ضرورت جي طور تي ۽ انهي ڪري ضروري آهي ڪنهن به نموني ڊيٽابيس لاء.

هن آرٽيڪل جو مقصد ايپليڪيشن ڊولپرز جي مدد ڪرڻ آهي SQL ۽ NoSQL جي وچ ۾ ايپليڪيشن ڊيٽا ماڊلنگ جي حوالي سان صحيح چونڊ ڪرڻ. اسان هڪ SQL ڊيٽابيس تي نظر وجهنداسين، يعني PostgreSQL، ۽ ٻه NoSQL ڊيٽابيس، Cassandra ۽ MongoDB، ڊيٽابيس ڊيزائن جي بنيادي ڳالهين کي ڍڪڻ لاءِ، جيئن ٽيبل ٺاهڻ، انهن کي آباد ڪرڻ، ٽيبل مان ڊيٽا پڙهڻ، ۽ ان کي حذف ڪرڻ. ايندڙ آرٽيڪل ۾، اسان انڊيڪس، ٽرانزيڪشن، JOINs، TTL هدايتون، ۽ JSON-based ڊيٽابيس ڊيزائن کي ڏسڻ جي پڪ ڪنداسين.

SQL ۽ NoSQL جي وچ ۾ ڇا فرق آهي؟

SQL ڊيٽابيس ACID ٽرانزيڪشنل گارنٽي ذريعي ايپليڪيشن لچڪ وڌائين ٿا، ۽ گڏوگڏ موجوده نارمل ٿيل لاڳاپي واري ڊيٽابيس ماڊلز جي مٿان غير متوقع طريقن سان JOINs استعمال ڪندي ڊيٽا کي سوال ڪرڻ جي صلاحيت.

انهن جي monolithic/single-node architecture ۽ redundancy لاءِ ماسٽر-غلام ريپليڪشن ماڊل جي استعمال کي ڏنو ويو، روايتي SQL ڊيٽابيس ۾ ٻه اهم خصوصيتون نه آهن - لڪير لکندڙ اسڪاليبلٽي (يعني ڪيترن ئي نوڊس ۾ خودڪار ورهاڱي) ۽ خودڪار / صفر ڊيٽا نقصان. هن جو مطلب آهي ته حاصل ڪيل ڊيٽا جي مقدار هڪ واحد نوڊ جي وڌ ۾ وڌ لکڻ جي ذريعي کان وڌيڪ نه ٿي سگهي. اضافي طور تي، ڪجهه عارضي ڊيٽا جي نقصان کي حساب ۾ ورتو وڃي غلطي رواداري (هڪ شيئر-ڪجهه به فن تعمير ۾). هتي توهان کي ذهن ۾ رکڻ جي ضرورت آهي ته تازو ڪمن اڃا تائين غلام ڪاپي ۾ ظاهر نه ڪيو ويو آهي. SQL ڊيٽابيس ۾ حاصل ڪرڻ لاءِ نان-ڊائون ٽائم اپڊيٽ پڻ مشڪل آھن.

NoSQL ڊيٽابيس عام طور تي فطرت طرفان ورهايل آهن، يعني. انهن ۾، ڊيٽا حصن ۾ ورهايل آهي ۽ ڪيترن ئي نوڊس ۾ ورهايل آهي. انهن کي غير معمولي ڪرڻ جي ضرورت آهي. ان جو مطلب اهو آهي ته داخل ڪيل ڊيٽا کي پڻ نقل ڪيو وڃي ڪيترائي ڀيرا توهان جي موڪليل مخصوص درخواستن جو جواب ڏيڻ لاءِ. مجموعي مقصد پڙهڻ دوران موجود شارڊز جي تعداد کي گهٽائڻ سان اعلي ڪارڪردگي حاصل ڪرڻ آهي. انهي جو مطلب اهو آهي ته NoSQL توهان کي توهان جي سوالن کي ماڊل ڪرڻ جي ضرورت آهي، جڏهن ته SQL توهان کي توهان جي ڊيٽا کي ماڊل ڪرڻ جي ضرورت آهي.

NoSQL هڪ ورهايل ڪلسٽر ۾ اعليٰ ڪارڪردگي حاصل ڪرڻ تي ڌيان ڏئي ٿو ۽ اهو ڪيترن ئي ڊيٽابيس ڊيزائن ٽريڊ آف لاءِ بنيادي دليل آهي جنهن ۾ ACID ٽرانزيڪشن نقصان، JOINs، ۽ مسلسل عالمي ثانوي انڊيڪس شامل آهن.

اتي هڪ دليل آهي ته جڏهن NoSQL ڊيٽابيس مهيا ڪن ٿا لڪير لکڻ جي اسڪاليبلٽي ۽ اعلي غلطي رواداري، ٽرانزيڪشن جي ضمانت جي نقصان انهن کي مشن-نازڪ ڊيٽا لاء غير مناسب بڻائي ٿو.

هيٺ ڏنل جدول ڏيکاري ٿو ته ڪيئن NoSQL ۾ ڊيٽا ماڊلنگ SQL کان مختلف آهي.

ڊيٽابيس ڊيزائن جا بنيادي اصول - PostgreSQL، Cassandra ۽ MongoDB جي مقابلي ۾

SQL ۽ NoSQL: ٻنهي جي ضرورت ڇو آهي؟

حقيقي دنيا جون ايپليڪيشنون وڏي تعداد ۾ استعمال ڪندڙن سان گڏ، جهڙوڪ Amazon.com، Netflix، Uber، ۽ Airbnb، کي پيچيده، گھڻ طرفي ڪمن کي انجام ڏيڻ جي ذميواري ڏني وئي آهي. مثال طور، هڪ اي ڪامرس ايپليڪيشن جهڙوڪ Amazon.com کي ٿلهي وزن، اعليٰ نازڪ ڊيٽا کي ذخيرو ڪرڻ جي ضرورت آهي جهڙوڪ صارف جي معلومات، پراڊڪٽس، آرڊر، انوائسز، ان سان گڏ ڳري، گهٽ حساس ڊيٽا جهڙوڪ پراڊڪٽ جا جائزو، سپورٽ پيغام، صارف جي سرگرمي، استعمال ڪندڙ تبصرا ۽ سفارشون. قدرتي طور تي، اهي ايپليڪيشنون گهٽ ۾ گهٽ هڪ SQL ڊيٽابيس سان گڏ گهٽ ۾ گهٽ هڪ NoSQL ڊيٽابيس تي ڀاڙين ٿيون. علائقائي ۽ عالمي نظامن ۾، هڪ NoSQL ڊيٽابيس هڪ خاص علائقي ۾ هلندڙ هڪ قابل اعتماد ماخذ SQL ڊيٽابيس ۾ محفوظ ڪيل ڊيٽا لاءِ جيو ورهايل ڪيش طور ڪم ڪري ٿو.

يوگا بائيٽ ڊي بي SQL ۽ NoSQL کي ڪيئن گڏ ڪري ٿو؟

لاگ-اورينٽيڊ مخلوط اسٽوريج انجڻ تي ٺهيل، آٽو-شارڊنگ، شارڊ ٿيل ورهايل اتفاق راءِ ۽ ACID ورهايل ٽرانزيڪشن (گوگل اسپنر کان متاثر ٿيل)، YugaByte DB دنيا جو پهريون اوپن سورس ڊيٽابيس آهي جيڪو هڪ ئي وقت NoSQL (Cassandra & Redis) سان مطابقت رکي ٿو. SQL (PostgreSQL). جيئن هيٺ ڏنل جدول ۾ ڏيکاريل آهي، YCQL، YugaByte DB API Cassandra سان مطابقت رکي ٿو، NoSQL API ۾ سنگل ۽ ملٽي-ڪي ACID ٽرانزيڪشنز ۽ عالمي ثانوي انڊيڪسز جي تصورن کي شامل ڪري ٿو، ان ڪري ٽرانزيڪشنل NoSQL ڊيٽابيس جي دور کي شروع ڪري ٿو. اضافي طور تي، YCQL، PostgreSQL سان مطابقت رکندڙ YugaByte DB API، SQL API ۾ لڪير لکڻ جي اسڪيلنگ ۽ خودڪار غلطي رواداري جا تصور شامل ڪري ٿو، دنيا ۾ ورهايل SQL ڊيٽابيس آڻيندي. ڇاڪاڻ ته YugaByte DB فطرت ۾ ٽرانزيڪشنل آهي، NoSQL API هاڻي استعمال ڪري سگهجي ٿو مشن-نازڪ ڊيٽا جي حوالي سان.

ڊيٽابيس ڊيزائن جا بنيادي اصول - PostgreSQL، Cassandra ۽ MongoDB جي مقابلي ۾

جيئن اڳ ۾ مضمون ۾ چيو ويو آهي "YSQL متعارف ڪرايو: يوگا بائيٽ ڊي بي لاءِ هڪ PostgreSQL مطابقت رکندڙ ورهايل SQL API", YugaByte DB ۾ SQL يا NoSQL جي وچ ۾ چونڊ مڪمل طور تي بنيادي ڪم لوڊ جي خاصيتن تي منحصر آهي:

  • جيڪڏهن توهان جو بنيادي ڪم لوڊ آهي ملٽي ڪيئي جوائن آپريشنز، پوءِ جڏهن YSQL چونڊيو، سمجھو ته توهان جون ڪنجيون ڪيترن ئي نوڊس ۾ ورهائي سگهجن ٿيون، جنهن جي نتيجي ۾ NoSQL کان وڌيڪ ويڪرائي ۽/يا گهٽ ٿرو پُٽ.
  • ٻي صورت ۾، ٻن NoSQL APIs مان ڪنهن هڪ کي چونڊيو، ذهن ۾ رکو ته توهان هڪ وقت ۾ هڪ نوڊ مان پيش ڪيل سوالن جي نتيجي ۾ بهتر ڪارڪردگي حاصل ڪندا. YugaByte DB حقيقي دنيا لاءِ هڪ واحد آپريشنل ڊيٽابيس جي طور تي ڪم ڪري سگهي ٿو، پيچيده ايپليڪيشنون جيڪي هڪ ئي وقت ڪيترن ئي ڪم لوڊ کي منظم ڪرڻ جي ضرورت آهي.

ايندڙ حصي ۾ ڊيٽا ماڊلنگ ليب PostgreSQL ۽ Cassandra API مطابقت رکندڙ YugaByte DB ڊيٽابيس تي ٻڌل آهي، جيئن ته اصلي ڊيٽابيس جي مخالفت. اهو طريقو ساڳيو ڊيٽابيس ڪلستر جي ٻن مختلف APIs (ٻن مختلف بندرگاهن تي) سان رابطو ڪرڻ جي آسانيءَ تي زور ڏئي ٿو، جيئن ته ٻن مختلف ڊيٽابيسن جي مڪمل طور تي آزاد ڪلسٽر استعمال ڪرڻ جي مخالفت ڪئي وڃي.
هيٺ ڏنل حصن ۾، اسان ڊيٽا ماڊلنگ ليب تي نظر وجهنداسين فرقن کي بيان ڪرڻ لاءِ ۽ شامل ڪيل ڊيٽابيس جي ڪجهه مشترڪات کي.

ڊيٽا ماڊلنگ ليبارٽري

ڊيٽابيس جي انسٽاليشن

ڊيٽا ماڊل ڊيزائن تي زور ڏنو ويو (بلڪه پيچيده ڊيپلائيمينٽ آرڪيٽيڪچرز)، اسان مقامي مشين تي ڊاکر ڪنٽينرز ۾ ڊيٽابيس انسٽال ڪنداسين ۽ پوءِ انهن سان لاڳاپيل ڪمانڊ لائن شيل استعمال ڪندي انهن سان لهه وچڙ ۾ آڻينداسين.

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

منڊو ڊي

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

ڪمانڊ لائن رسائي

اچو ته لاڳاپيل APIs لاءِ ڪمانڊ لائن شيل استعمال ڪندي ڊيٽابيس سان ڳنڍيون.

PostgreSQL

psql PostgreSQL سان رابطو ڪرڻ لاءِ ڪمانڊ لائن شيل آھي. استعمال جي آسانيءَ لاءِ، YugaByte DB اچي ٿو psql سان ساڄي بن فولڊر ۾.

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

Cassandra

cqlsh Cassandra ۽ ان جي مطابقت رکندڙ ڊيٽابيس سان CQL (Cassandra Query Language) ذريعي رابطي لاءِ ڪمانڊ لائن شيل آھي. استعمال جي آسانيءَ لاءِ، يوگا بائيٽ ڊي بي سان گڏ اچي ٿو cqlsh فهرست ۾ bin.
نوٽ ڪريو ته CQL SQL کان متاثر ٿيو ۽ ان ۾ جدولن، قطارن، ڪالمن ۽ انڊيڪس جا ساڳيا تصور آھن. جڏهن ته، هڪ NoSQL ٻولي جي طور تي، اها حدن جو هڪ خاص سيٽ شامل ڪري ٿي، جن مان اڪثر اسان ٻين مضمونن ۾ پڻ شامل ڪنداسين.

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

منڊو ڊي

mongo 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

Cassandra ۾ ٽيبل ٺاهڻ تمام گهڻو آهي PostgreSQL. مکيه اختلافن مان هڪ آهي سالميت جي رڪاوٽن جو فقدان (مثال طور NUT 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)

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

منڊو ڊي

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 Cassandra ۾ تمام گهڻو ساڳيو ڏسڻ ۾ اچي ٿو پوسٽ گري ايس ايس ايل ۾. بهرحال، اتي هڪ وڏو فرق آهي semantics ۾. Cassandra ۾ INSERT اصل ۾ هڪ آپريشن آهي UPSERT، جتي آخري قدر شامل ڪيا ويندا قطار ۾ جيڪڏھن قطار اڳ ۾ ئي موجود آھي.

ڊيٽا داخلا PostgreSQL سان ملندڙ جلندڙ آهي INSERT اعلي

.

منڊو ڊي

جيتوڻيڪ MongoDB Cassandra وانگر هڪ 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 ڪارڪردگي پش سان آهي جنهن بابت اسان اڳ ۾ ڳالهايو آهي. اها خواهش ڪنهن به ڪراس-ٽيبلر ۽ ڪراس-ڪي رابطي ۾ هر ممڪن گهٽتائي جي ڪري ٿي. اهو بين-نوڊ رابطي ۾ وڏي دير متعارف ڪرائي سگهي ٿو جڏهن هڪ درخواست جو جواب ڏنو وڃي ۽ ان ڪري عام طور تي بهترين کان بچي وڃي. مثال طور، 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

مٿي ڏنل پوسٽ گري ايس ايس ايل جي سوالن مان، صرف پهريون ئي ڪم ڪندو ڪاسندرا ۾ بغير ڪنهن تبديلي جي، جيئن آپريٽر 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;

منڊو ڊي

جيئن پوئين مثالن ۾ ڏيکاريل آهي، مونگو ڊي بي ۾ سوالن ٺاهڻ جو بنيادي طريقو آهي 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 مثال وانگر.

منڊو ڊي

db.music.find( {} );

ٽيبل ۾ ڊيٽا کي تبديل ڪرڻ

PostgreSQL

PostgreSQL هدايتون مهيا ڪري ٿي UPDATE ڊيٽا کي تبديل ڪرڻ لاء. هن وٽ ڪو به موقعو ناهي UPSERT، تنهنڪري هي بيان ناڪام ٿيندو جيڪڏهن قطار هاڻي ڊيٽابيس ۾ نه آهي.

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

Cassandra

Cassandra آهي UPDATE PostgreSQL وانگر. UPDATE ساڳي معنيٰ رکي ٿي UPSERT، ساڳيو INSERT.

مٿي ڏنل PostgreSQL مثال وانگر.

منڊو ڊي
آپريشن اپڊيٽ () 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 دستاويزن کي ختم ڪرڻ لاء ٻن قسمن جا عمل آهن - حذف ڪريو () /deleteMany() и ختم ڪريو (). ٻئي قسم جا دستاويز حذف ڪن ٿا پر مختلف نتيجا واپس ڪن ٿا. 

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

ٽيبل کي ختم ڪريو

PostgreSQL

DROP TABLE Music;

Cassandra

مٿي ڏنل PostgreSQL مثال وانگر.

منڊو ڊي

db.music.drop();

ٿڪل

SQL ۽ NoSQL جي وچ ۾ چونڊڻ بابت بحث 10 سالن کان وڌيڪ عرصي کان جاري آهي. هن بحث جا ٻه مکيه پهلو آهن: ڊيٽابيس انجڻ آرڪيٽيڪچر (مونوليٿڪ، ٽرانزيڪشنل SQL بمقابله ورهايل، غير ٽرانزيڪشنل NoSQL) ۽ ڊيٽابيس ڊيزائن جو طريقو (SQL ۾ توهان جي ڊيٽا کي ماڊل ڪرڻ ۽ NoSQL ۾ توهان جي سوالن کي ماڊل ڪرڻ).

يوگا بائيٽ ڊي بي وانگر ورهايل ٽرانزيڪشنل ڊيٽابيس سان، ڊيٽابيس آرڪيٽيڪچر بابت بحث کي آساني سان آرام ڪري سگهجي ٿو. جيئن ته ڊيٽا جو مقدار ان کان وڏو ٿي وڃي ٿو جيڪو هڪ واحد نوڊ تي لکيو وڃي ٿو، هڪ مڪمل طور تي ورهايل فن تعمير جيڪو خودڪار شارڊنگ / ريبلانسنگ سان لڪير لکڻ جي اسڪيبلٽي کي سپورٽ ڪري ٿو.

ان کان سواء، جيئن آرٽيڪل مان هڪ ۾ بيان ڪيو ويو آهي Google Cloud,Transactional, strongly consistent architectures are now more ,استعمال ٿيل آهن بهتر ترقي جي چستيءَ کي مهيا ڪرڻ لاءِ غير ٽرانزيڪشن جي ڀيٽ ۾، ,آخرڪار هڪجهڙائي واري اڏاوت.

ڊيٽابيس ڊيزائن جي بحث ڏانهن واپس اچي رهيو آهي، اهو چوڻ مناسب آهي ته ٻنهي ڊيزائن جي طريقن (SQL ۽ NoSQL) ڪنهن به پيچيده حقيقي دنيا جي ايپليڪيشن لاء ضروري آهن. SQL ”ڊيٽا ماڊلنگ“ جو طريقو ڊولپرز کي وڌيڪ آسانيءَ سان بدلجندڙ ڪاروباري ضرورتن کي پورو ڪرڻ جي اجازت ڏئي ٿو، جڏهن ته NoSQL ”ڪوري ماڊلنگ“ جو طريقو ساڳيو ڊولپرز کي اجازت ڏئي ٿو ته ڊيٽا جي وڏي مقدار تي ڪم ڪري سگھي گهٽ دير سان ۽ اعليٰ ذريعي. اهو ئي سبب آهي ته YugaByte DB هڪ عام ڪور ۾ SQL ۽ NoSQL APIs مهيا ڪري ٿي، بجاءِ ڪنهن هڪ طريقي کي فروغ ڏيڻ جي. اضافي طور تي، PostgreSQL ۽ Cassandra سميت مشهور ڊيٽابيس ٻولين سان مطابقت مهيا ڪندي، YugaByte DB يقيني بڻائي ٿو ته ڊولپرز کي ورهايل، انتهائي مسلسل ڊيٽابيس انجڻ سان ڪم ڪرڻ لاءِ ٻي ٻولي سکڻ جي ضرورت ناهي.

هن آرٽيڪل ۾، اسان ڏٺو ته ڪيئن ڊيٽابيس ڊيزائن بنياديات ۾ فرق آهي PostgreSQL، Cassandra، ۽ MongoDB. مستقبل جي مضمونن ۾، اسان ترقي يافته ڊيزائن جي تصورن جهڙوڪ انڊيڪسس، ٽرانزيڪشن، JOINs، TTL هدايتون، ۽ JSON دستاويزن ۾ شامل ڪنداسين.

اسان توهان کي هفتي جي آخر ۾ هڪ عظيم آرام جي خواهشمند آهيون ۽ توهان کي دعوت ڏيو ٿا مفت ويبينار، جيڪو 14 مئي تي ٿيندو.

جو ذريعو: www.habr.com

تبصرو شامل ڪريو