🥇 ڈیٹا بیس ڈیزائن کے بنیادی اصول - PostgreSQL، Cassandra اور MongoDB کا موازنہ

ہیلو دوستو. مئی کی تعطیلات کے دوسرے حصے کے لیے روانہ ہونے سے پہلے، ہم آپ کے ساتھ اس مواد کا اشتراک کرتے ہیں جس کا ترجمہ ہم نے کورس پر ایک نئے سلسلے کے آغاز کی توقع میں کیا تھا۔ "رشتہ دار DBMS".

ایپلیکیشن ڈویلپرز ایک سے زیادہ آپریشنل ڈیٹا بیس کا موازنہ کرنے میں بہت زیادہ وقت صرف کرتے ہیں تاکہ مطلوبہ کام کے بوجھ کے لیے موزوں ترین ڈیٹا بیس کو منتخب کیا جا سکے۔ ضرورتوں میں آسان ڈیٹا ماڈلنگ، لین دین کی ضمانتیں، پڑھنے/لکھنے کی کارکردگی، افقی اسکیلنگ، اور غلطی کی رواداری شامل ہو سکتی ہے۔ روایتی طور پر، انتخاب ڈیٹابیس کے زمرے، SQL یا NoSQL سے شروع ہوتا ہے، کیونکہ ہر زمرہ تجارتی معاہدوں کا واضح سیٹ پیش کرتا ہے۔ کم تاخیر اور اعلی تھرو پٹ کے لحاظ سے اعلی کارکردگی کو عام طور پر غیر تجارتی ضرورت کے طور پر دیکھا جاتا ہے اور اس لیے یہ کسی بھی نمونے کے ڈیٹا بیس کے لیے ضروری ہے۔

اس مضمون کا مقصد ایپلیکیشن ڈیولپرز کو ایپلیکیشن ڈیٹا ماڈلنگ کے تناظر میں SQL اور NoSQL کے درمیان صحیح انتخاب کرنے میں مدد کرنا ہے۔ ہم ایک SQL ڈیٹا بیس، یعنی PostgreSQL، اور دو NoSQL ڈیٹا بیس، Cassandra اور MongoDB، کو ڈیٹا بیس ڈیزائن کی بنیادی باتوں کا احاطہ کرنے کے لیے دیکھیں گے، جیسے کہ ٹیبل بنانا، ان کو آباد کرنا، ٹیبل سے ڈیٹا پڑھنا، اور اسے حذف کرنا۔ اگلے مضمون میں، ہم اشاریہ جات، لین دین، JOINs، TTL ہدایات، اور JSON پر مبنی ڈیٹا بیس ڈیزائن کو دیکھنا یقینی بنائیں گے۔

SQL اور NoSQL میں کیا فرق ہے؟

ایس کیو ایل ڈیٹا بیس ACID ٹرانزیکشنل گارنٹی کے ذریعے ایپلیکیشن کی لچک کو بڑھاتے ہیں، نیز موجودہ نارملائزڈ ریلیشنل ڈیٹا بیس ماڈلز کے اوپر غیر متوقع طریقوں سے JOIN کا استعمال کرتے ہوئے ڈیٹا کو استفسار کرنے کی ان کی صلاحیت۔

ان کے یک سنگل/سنگل نوڈ فن تعمیر اور فالتو پن کے لیے ماسٹر-سلیو ریپلیکیشن ماڈل کے استعمال کو دیکھتے ہوئے، روایتی ایس کیو ایل ڈیٹا بیس میں دو اہم خصوصیات کی کمی ہے - لکیری تحریری اسکیل ایبلٹی (یعنی متعدد نوڈس میں خودکار تقسیم) اور خودکار/صفر ڈیٹا کا نقصان۔ اس کا مطلب یہ ہے کہ موصول ہونے والے ڈیٹا کی مقدار ایک نوڈ کے زیادہ سے زیادہ رائٹ تھرو پٹ سے زیادہ نہیں ہو سکتی۔ اس کے علاوہ، غلطی کی رواداری میں کچھ عارضی ڈیٹا کے نقصان کو بھی مدنظر رکھا جانا چاہیے (ایک مشترکہ فن تعمیر میں)۔ یہاں آپ کو یہ ذہن میں رکھنے کی ضرورت ہے کہ حالیہ کمٹ ابھی تک غلام کاپی میں ظاہر نہیں ہوئے ہیں۔ ایس کیو ایل ڈیٹا بیس میں غیر ڈاؤن ٹائم اپ ڈیٹس حاصل کرنا بھی مشکل ہے۔

NoSQL ڈیٹا بیس عام طور پر فطرت کے لحاظ سے تقسیم کیے جاتے ہیں، یعنی ان میں، ڈیٹا کو حصوں میں تقسیم کیا جاتا ہے اور کئی نوڈس میں تقسیم کیا جاتا ہے۔ انہیں ڈی نارملائزیشن کی ضرورت ہے۔ اس کا مطلب یہ ہے کہ درج کردہ ڈیٹا کو بھی آپ کی بھیجی گئی مخصوص درخواستوں کا جواب دینے کے لیے کئی بار کاپی کرنا ضروری ہے۔ مجموعی مقصد پڑھنے کے دوران دستیاب شارڈز کی تعداد کو کم کرکے اعلی کارکردگی حاصل کرنا ہے۔ اس کا مطلب یہ ہے کہ NoSQL آپ سے اپنے سوالات کو ماڈل کرنے کا تقاضا کرتا ہے، جبکہ SQL آپ سے اپنے ڈیٹا کو ماڈل کرنے کا تقاضا کرتا ہے۔

NoSQL تقسیم شدہ کلسٹر میں اعلیٰ کارکردگی کے حصول پر توجہ مرکوز کرتا ہے اور یہ بہت سے ڈیٹا بیس ڈیزائن ٹریڈ آف کے لیے بنیادی دلیل ہے جس میں ACID ٹرانزیکشن نقصان، JOINs، اور مسلسل عالمی ثانوی اشاریہ جات شامل ہیں۔

ایک دلیل یہ ہے کہ جب کہ NoSQL ڈیٹا بیس لکیری تحریری اسکیل ایبلٹی اور ہائی فالٹ ٹولرنس فراہم کرتے ہیں، ٹرانزیکشنل گارنٹی کا نقصان انہیں مشن کے اہم ڈیٹا کے لیے نا مناسب بنا دیتا ہے۔

درج ذیل جدول دکھاتا ہے کہ NoSQL میں ڈیٹا ماڈلنگ SQL سے کس طرح مختلف ہے۔

SQL اور NoSQL: دونوں کی ضرورت کیوں ہے؟

بڑی تعداد میں صارفین کے ساتھ حقیقی دنیا کی ایپلی کیشنز، جیسے Amazon.com، Netflix، Uber، اور Airbnb، کو پیچیدہ، کثیر جہتی کام انجام دینے کی ذمہ داری سونپی گئی ہے۔ مثال کے طور پر، Amazon.com جیسی ای کامرس ایپلیکیشن کو ہلکا پھلکا، اعلیٰ اہم ڈیٹا جیسے کہ صارف کی معلومات، پروڈکٹس، آرڈرز، انوائسز، بھاری، کم حساس ڈیٹا جیسے پروڈکٹ کے جائزے، سپورٹ پیغامات، صارف کی سرگرمی، ذخیرہ کرنے کی ضرورت ہوتی ہے۔ صارف کے جائزے اور سفارشات۔ قدرتی طور پر، یہ ایپلیکیشنز کم از کم ایک ایس کیو ایل ڈیٹا بیس کے ساتھ کم از کم ایک NoSQL ڈیٹا بیس پر انحصار کرتی ہیں۔ کراس ریجنل اور عالمی نظاموں میں، ایک NoSQL ڈیٹابیس کسی خاص علاقے میں چلنے والے قابل اعتماد ماخذ SQL ڈیٹا بیس میں ذخیرہ شدہ ڈیٹا کے لیے جیو ڈسٹری بیوٹڈ کیشے کے طور پر کام کرتا ہے۔

یوگا بائٹ ڈی بی SQL اور NoSQL کو کیسے جوڑتا ہے؟

لاگ پر مبنی مکسڈ اسٹوریج انجن، آٹو شارڈنگ، شارڈ ڈسٹری بیوٹڈ کننسس ریپلیکشن اور ACID ڈسٹری بیوٹڈ ٹرانزیکشنز (گوگل اسپنر سے متاثر) پر بنایا گیا یوگا بائٹ ڈی بی دنیا کا پہلا اوپن سورس ڈیٹا بیس ہے جو بیک وقت NoSQL (Cassandra & Redis) کے ساتھ مطابقت رکھتا ہے۔ ایس کیو ایل (پوسٹگری ایس کیو ایل)۔ جیسا کہ نیچے دیے گئے جدول میں دکھایا گیا ہے، YCQL، کیسینڈرا کے ساتھ مطابقت رکھنے والا YugaByte DB API، NoSQL API میں سنگل اور ملٹی کلی ACID ٹرانزیکشنز اور عالمی ثانوی اشاریہ جات کے تصورات کو شامل کرتا ہے، اس طرح ٹرانزیکشنل NoSQL ڈیٹا بیس کے دور کا آغاز ہوتا ہے۔ مزید برآں، YCQL، PostgreSQL کے ساتھ مطابقت رکھنے والا YugaByte DB API، SQL API میں لکیری رائٹ اسکیلنگ اور خودکار فالٹ ٹولرنس کے تصورات کو شامل کرتا ہے، جس سے دنیا میں تقسیم شدہ SQL ڈیٹا بیس لایا جاتا ہے۔ چونکہ YugaByte DB فطرت میں ٹرانزیکشنل ہے، NoSQL API کو اب مشن کے اہم ڈیٹا کے تناظر میں استعمال کیا جا سکتا ہے۔

جیسا کہ پہلے مضمون میں کہا گیا ہے۔ "وائی ایس کیو ایل کا تعارف: یوگا بائٹ ڈی بی کے لیے ایک پوسٹگری ایس کیو ایل ہم آہنگ تقسیم شدہ ایس کیو ایل API", YugaByte DB میں SQL یا NoSQL کے درمیان انتخاب مکمل طور پر بنیادی کام کے بوجھ کی خصوصیات پر منحصر ہے:

اگر آپ کا بنیادی کام کا بوجھ ملٹی کلیدی جوائن آپریشنز ہے، تو YSQL کا انتخاب کرتے وقت، سمجھ لیں کہ آپ کی کیز کو متعدد نوڈس میں تقسیم کیا جا سکتا ہے، جس کے نتیجے میں NoSQL سے زیادہ تاخیر اور/یا کم تھرو پٹ ہو سکتا ہے۔
دوسری صورت میں، دو NoSQL APIs میں سے کسی ایک کا انتخاب کریں، اس بات کو ذہن میں رکھتے ہوئے کہ آپ کو ایک وقت میں ایک نوڈ سے پیش کردہ سوالات کے نتیجے میں بہتر کارکردگی ملے گی۔ YugaByte DB حقیقی دنیا، پیچیدہ ایپلی کیشنز کے لیے ایک واحد آپریشنل ڈیٹا بیس کے طور پر کام کر سکتا ہے جنہیں بیک وقت متعدد کام کے بوجھ کو منظم کرنے کی ضرورت ہے۔

اگلے حصے میں ڈیٹا ماڈلنگ لیب پوسٹگری ایس کیو ایل اور کیسینڈرا API مطابقت پذیر یوگا بائٹ ڈی بی ڈیٹا بیس پر مبنی ہے، جیسا کہ مقامی ڈیٹا بیس کے برخلاف ہے۔ یہ نقطہ نظر ایک ہی ڈیٹا بیس کلسٹر کے دو مختلف APIs (دو مختلف بندرگاہوں پر) کے ساتھ بات چیت کی آسانی پر زور دیتا ہے، جیسا کہ دو مختلف ڈیٹا بیس کے مکمل طور پر آزاد کلسٹرز کو استعمال کرنے کے برخلاف ہے۔
مندرجہ ذیل حصوں میں، ہم ڈیٹا ماڈلنگ لیب پر ایک نظر ڈالیں گے تاکہ احاطہ کیے گئے ڈیٹا بیس کے فرق اور کچھ مشترکات کو واضح کیا جا سکے۔

ڈیٹا ماڈلنگ لیبارٹری

ڈیٹا بیس کی تنصیب

ڈیٹا ماڈل ڈیزائن (پیچیدہ تعیناتی آرکیٹیکچرز کے بجائے) پر زور دیتے ہوئے، ہم مقامی مشین پر ڈوکر کنٹینرز میں ڈیٹا بیس انسٹال کریں گے اور پھر ان کے متعلقہ کمانڈ لائن شیلز کا استعمال کرتے ہوئے ان کے ساتھ بات چیت کریں گے۔

پوسٹگری ایس کیو ایل اور کیسینڈرا ہم آہنگ یوگا بائٹ ڈی بی ڈیٹا بیس

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 CQL (Cassandra Query Language) کے ذریعے Cassandra اور اس کے ہم آہنگ ڈیٹا بیس کے ساتھ بات چیت کرنے کے لیے ایک کمانڈ لائن شیل ہے۔ استعمال میں آسانی کے لیے، یوگا بائٹ ڈی بی کے ساتھ آتا ہے۔ cqlsh کیٹلاگ میں bin.
نوٹ کریں کہ سی کیو ایل ایس کیو ایل سے متاثر تھا اور اس میں ٹیبلز، قطاروں، کالموں اور اشاریہ جات کے ایک جیسے تصورات ہیں۔ تاہم، ایک NoSQL زبان کے طور پر، یہ حدود کے ایک مخصوص سیٹ کا اضافہ کرتی ہے، جن میں سے بیشتر کو ہم دوسرے مضامین میں بھی شامل کریں گے۔

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

منگو ڈی بی

کے mongo 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 ٹیسٹ ڈیٹا بیس کو بطور ڈیفالٹ استعمال کرتا ہے، اس لیے کسی مخصوص ڈیٹا بیس کی وضاحت کیے بغیر کوئی بھی کلیکشن لیول آپریشن اس پر بطور ڈیفالٹ چلے گا۔

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 کیسینڈرا میں پوسٹگری ایس کیو ایل سے بہت ملتا جلتا نظر آتا ہے۔ تاہم، سیمنٹکس میں ایک بڑا فرق ہے۔ کیسینڈرا میں INSERT اصل میں ایک آپریشن ہے UPSERT، جہاں قطار میں آخری قدریں شامل کی جاتی ہیں اگر قطار پہلے سے موجود ہے۔

ڈیٹا انٹری پوسٹگری ایس کیو ایل کی طرح ہے۔ INSERT اوپر

منگو ڈی بی

اگرچہ MongoDB Cassandra کی طرح NoSQL ڈیٹا بیس ہے، لیکن اس کے داخل کرنے کا عمل Cassandra کے معنوی رویے کے ساتھ کچھ بھی مشترک نہیں ہے۔ مونگو ڈی بی میں داخل کریں () مواقع نہیں ہیں 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, <, >, =>, <=) پارٹیشن کیز پر، سوائے اس کے کہ جب سیکنڈری انڈیکس کی درخواست کی جائے (یہاں صرف = آپریٹر کی اجازت ہے)۔

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;

منگو ڈی بی

جیسا کہ پچھلی مثالوں میں دکھایا گیا ہے، 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 مثال کی طرح۔

منگو ڈی بی

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 میں موجودہ دستاویز کو مکمل طور پر اپ ڈیٹ کر سکتا ہے یا صرف کچھ فیلڈز کو اپ ڈیٹ کر سکتا ہے۔ پہلے سے طے شدہ طور پر، یہ صرف ایک دستاویز کو اپ ڈیٹ کرتا ہے جس میں سیمنٹکس غیر فعال ہے۔ 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 سال سے زیادہ عرصے سے جاری ہے۔ اس بحث کے دو اہم پہلو ہیں: ڈیٹابیس انجن کا فن تعمیر (یک سنگی، ٹرانزیکشنل ایس کیو ایل بمقابلہ ڈسٹری بیوٹڈ، غیر ٹرانزیکشنل NoSQL) اور ڈیٹا بیس ڈیزائن اپروچ (SQL میں آپ کے ڈیٹا کی ماڈلنگ بمقابلہ NoSQL میں آپ کے سوالات کی ماڈلنگ)۔

یوگا بائٹ ڈی بی جیسے تقسیم شدہ لین دین کے ڈیٹا بیس کے ساتھ، ڈیٹا بیس کے فن تعمیر کے بارے میں بحث کو آسانی سے ختم کیا جا سکتا ہے۔ چونکہ ڈیٹا والیوم اس سے بڑا ہو جاتا ہے جو کسی ایک نوڈ پر لکھا جا سکتا ہے، ایک مکمل طور پر تقسیم شدہ فن تعمیر جو خودکار شارڈنگ/ری بیلنسنگ کے ساتھ لکیری تحریری اسکیل ایبلٹی کو سپورٹ کرتا ہے۔

اس کے علاوہ، جیسا کہ ایک مضمون میں کہا گیا ہے۔ گوگل کلاؤڈ,ٹرانزیکشنل، مضبوطی سے مسلسل آرکیٹیکچرز اب زیادہ ہیں، غیر لین دین کے مقابلے میں بہتر ترقی کی چستی فراہم کرنے کے لیے استعمال کیے جاتے ہیں، آخر کار مستقل فن تعمیرات۔

ڈیٹا بیس ڈیزائن کی بحث پر واپس آتے ہوئے، یہ کہنا مناسب ہے کہ ڈیزائن کے دونوں طریقے (SQL اور NoSQL) کسی بھی پیچیدہ حقیقی دنیا کی ایپلی کیشن کے لیے ضروری ہیں۔ ایس کیو ایل "ڈیٹا ماڈلنگ" اپروچ ڈویلپرز کو بدلتے ہوئے کاروباری تقاضوں کو زیادہ آسانی سے پورا کرنے کی اجازت دیتا ہے، جبکہ NoSQL "کوئیری ماڈلنگ" اپروچ اسی ڈویلپرز کو کم تاخیر اور زیادہ تھرو پٹ کے ساتھ ڈیٹا کی بڑی مقدار پر کام کرنے کی اجازت دیتا ہے۔ یہی وجہ ہے کہ YugaByte DB کسی ایک نقطہ نظر کو فروغ دینے کے بجائے، ایک مشترکہ کور میں SQL اور NoSQL APIs فراہم کرتا ہے۔ مزید برآں، PostgreSQL اور Cassandra سمیت مقبول ڈیٹا بیس زبانوں کے ساتھ مطابقت فراہم کرکے، YugaByte DB اس بات کو یقینی بناتا ہے کہ ڈیولپرز کو تقسیم شدہ، انتہائی مستقل ڈیٹا بیس انجن کے ساتھ کام کرنے کے لیے دوسری زبان سیکھنے کی ضرورت نہیں ہے۔

اس مضمون میں، ہم نے دیکھا کہ کس طرح ڈیٹا بیس ڈیزائن کے بنیادی اصول PostgreSQL، Cassandra، اور MongoDB کے درمیان مختلف ہیں۔ مستقبل کے مضامین میں، ہم جدید ترین ڈیزائن کے تصورات جیسے کہ اشاریہ جات، لین دین، JOINs، TTL ہدایات، اور JSON دستاویزات پر غور کریں گے۔

ہم آپ کو ہفتے کے آخر میں بہترین آرام کی خواہش کرتے ہیں اور آپ کو دعوت دیتے ہیں۔ مفت ویبینارجو کہ 14 مئی کو ہو گا۔

ماخذ: www.habr.com

ڈیٹا بیس ڈیزائن کے بنیادی اصول - PostgreSQL، Cassandra، اور MongoDB کا موازنہ

نیا تبصرہ شامل کریں جواب منسوخ کریں