ڈویلپرز کے لیے NoSQL کے لیے ایک گائیڈ

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

ہمیں اچانک ایک نئے ڈیٹا بیس کی ضرورت کیوں ہے؟

آپ یہ پوچھ کر حیران ہوسکتے ہیں: متعلقہ ڈیٹا بیس میں کیا غلط ہے؟ بات یہ ہے کہ انہوں نے کئی سالوں تک بہت اچھا کام کیا، لیکن اب ایک مسئلہ ہے جسے وہ مزید سنبھال نہیں سکتے۔ کچھ پیشین گوئیوں کے مطابق، 2018 میں انسانیت فی سیکنڈ 50,000 گیگا بائٹس ڈیٹا پیدا کرے گی۔ یہ ڈیٹا کی ایک بڑی مقدار ہے! اس کا ذخیرہ اور ہینڈلنگ ایک سنگین انجینئرنگ چیلنج ہے۔ اس سے بھی بری بات یہ ہے کہ یہ حجم مسلسل بڑھ رہا ہے۔ جیسا کہ یہ پتہ چلتا ہے، متعلقہ ڈیٹا بیس واقعی بڑی مقدار میں ڈیٹا کے ساتھ کام کرنے کے لیے موزوں نہیں ہیں۔ انہیں ایک ہی مشین پر چلانے کے لیے ڈیزائن کیا گیا ہے، اور اگر آپ مزید درخواستوں کو ہینڈل کرنا چاہتے ہیں، تو واحد آپشن یہ ہے کہ زیادہ RAM اور زیادہ طاقتور پروسیسر والا کمپیوٹر خریدیں۔ بدقسمتی سے، سوالات کی تعداد جو ایک مشین سنبھال سکتی ہے محدود ہے، اور متعدد مشینوں میں تقسیم شدہ کام کے لیے ہمیں ایک مختلف ڈیٹا بیس ٹیکنالوجی کی ضرورت ہے۔ یقیناً، کچھ قارئین اس مقام پر ہنسیں گے اور کہیں گے کہ متعلقہ ڈیٹا بیس کی صورت میں متعدد مشینوں کو استعمال کرنے کے لیے دو وسیع پیمانے پر استعمال شدہ طریقے ہیں: نقل اور شارڈنگ۔ یہ سچ ہے، لیکن یہ طریقے ہمارے کاموں سے نمٹنے کے لیے کافی نہیں ہیں۔ پڑھنے کی نقل ایک ایسی تکنیک ہے جس میں ہر ڈیٹابیس اپ ڈیٹ کو دوسری مشینوں تک پھیلایا جاتا ہے جو صرف پڑھنے کی درخواستوں کو ہینڈل کرسکتی ہیں۔ اس صورت میں، تمام تبدیلیاں ایک سرور کے ذریعے کی جاتی ہیں، جسے ماسٹر نوڈ کہتے ہیں، جبکہ دوسرے سرورز، جنہیں ریڈ ریپلیکس کہتے ہیں، صرف ڈیٹا کی کاپیاں برقرار رکھتے ہیں۔ صارف کسی بھی مشین سے پڑھ سکتا ہے، لیکن ڈیٹا کو صرف ماسٹر نوڈ کے ذریعے تبدیل کر سکتا ہے۔ یہ ایک آسان اور بہت مقبول طریقہ ہے، لیکن یہ صرف آپ کو مزید پڑھنے کی درخواستوں پر کارروائی کرنے کی اجازت دیتا ہے اور کسی بھی طرح سے ڈیٹا کی مطلوبہ مقدار پر کارروائی کرنے کا مسئلہ حل نہیں کرتا ہے۔ شارڈنگ ایک اور مقبول طریقہ ہے جو متعلقہ ڈیٹا بیس کی متعدد مثالوں کو استعمال کرتا ہے۔ ان میں سے ہر ایک ڈیٹا کے ایک حصے کے لیے لکھنے اور پڑھنے کے عمل کو سنبھالتا ہے۔ اگر ڈیٹا بیس صارفین کے بارے میں معلومات کو ذخیرہ کرتا ہے، مثال کے طور پر، شارڈنگ کا استعمال کرتے ہوئے، ایک مشین ان صارفین کی تمام درخواستوں کو سنبھال سکتی ہے جن کے نام A سے شروع ہوتے ہیں، دوسری مشین ان صارفین کے تمام ڈیٹا کو ذخیرہ کر سکتی ہے جن کے نام B سے شروع ہوتے ہیں، وغیرہ۔ اگرچہ شارڈنگ آپ کو مزید ڈیٹا ریکارڈ کرنے کی اجازت دیتی ہے، لیکن اس طرح کے ڈیٹا بیس کا انتظام کرنا ایک حقیقی ڈراؤنا خواب ہے: آپ کو مشینوں میں ڈیٹا کو سیدھ میں لانا ہوگا اور ضرورت کے مطابق کلسٹر کو دونوں سمتوں میں پیمانہ کرنا ہوگا۔ اگرچہ نظریہ میں یہ آسان نظر آتا ہے، لیکن اسے درست کرنا کافی مشکل ہے۔

کیا رشتہ دار ڈیٹا بیس کو بہتر بنایا جا سکتا ہے؟

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

1. اپنا مقامی ڈیٹا واپس حاصل کریں، چاہے وہ تازہ ترین نہ ہو۔ اس معاملے میں، دستیابی کو ترجیح دی جاتی ہے (کم از کم کچھ ڈیٹا واپس کرنے کے لیے، یہاں تک کہ پرانے والے بھی)۔
2. واپسی کی غلطی۔ اس صورت میں، مستقل مزاجی کو ترجیح دی جاتی ہے: کلائنٹ کو پرانا ڈیٹا نہیں ملے گا، لیکن اسے کوئی بھی ڈیٹا موصول نہیں ہوگا۔

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

NoSQL ڈیٹا بیس مستقل مزاجی اور دستیابی کو کیسے متوازن کرتے ہیں؟

یہ آپ کو لگتا ہے کہ اگر آپ NoSQL ڈیٹا بیس کا انتخاب کرتے ہیں، تو آپ کو ہمیشہ یا تو کچھ پرانا ڈیٹا ملے گا یا کسی ناکامی کی صورت میں کوئی غلطی ہوگی۔ عملی طور پر، دستیابی اور مستقل مزاجی کسی بھی طرح سے دستیاب اختیارات نہیں ہیں۔ آپ کے لیے انتخاب کرنے کے لیے اختیارات کی ایک وسیع رینج موجود ہے۔ متعلقہ ڈیٹا بیس میں یہ اختیارات نہیں ہیں، لیکن NoSQL آپ کو اسی طرح سے استفسار پر عمل درآمد کو کنٹرول کرنے کی اجازت دیتا ہے۔ کسی نہ کسی طرح، وہ آپ کو NoSQL ڈیٹا بیس میں لکھنے یا پڑھنے کی کارروائیوں کو انجام دیتے وقت دو پیرامیٹرز سیٹ کرنے کی اجازت دیتے ہیں: W - کلسٹر میں کتنی مشینیں لکھنے کے آپریشن کو انجام دیتے وقت ڈیٹا کی بچت کی تصدیق کرتی ہیں ۔ مشینوں کی تعداد جتنی زیادہ ہوگی جہاں آپ اپنا ڈیٹا لکھیں گے، اگلے پڑھنے کے آپریشن پر تازہ ترین ڈیٹا کو پڑھنا اتنا ہی آسان ہوگا، بلکہ اس میں زیادہ وقت بھی لگے گا۔ R - آپ کتنی مشینوں سے ڈیٹا پڑھنا چاہیں گے ۔ تقسیم شدہ نظام میں، کلسٹر میں تمام مشینوں میں ڈیٹا تقسیم کرنے میں کچھ وقت لگ سکتا ہے، اس لیے کچھ سرورز کے پاس تازہ ترین ڈیٹا ہوگا جبکہ دیگر پیچھے رہ جائیں گے۔ مشینوں کی جتنی زیادہ تعداد سے ڈیٹا پڑھا جاتا ہے، موجودہ ڈیٹا کو پڑھنے کے امکانات اتنے ہی زیادہ ہوتے ہیں۔ آئیے ایک عملی مثال دیکھتے ہیں۔ اگر آپ کے کلسٹر میں پانچ کمپیوٹر ہیں اور آپ صرف ایک پر ڈیٹا لکھنے کا فیصلہ کرتے ہیں اور پھر تصادفی طور پر منتخب کردہ ایک کمپیوٹر سے ڈیٹا پڑھتے ہیں، تو اس بات کا 80% امکان ہے کہ آپ باسی ڈیٹا پڑھیں گے۔ دوسری طرف، یہ کم از کم وسائل کا استعمال کرے گا. لہذا اگر میراثی ڈیٹا آپ کے ساتھ ٹھیک ہے، تو یہ اتنا برا آپشن نہیں ہے۔ اس صورت میں، پیرامیٹرز W اور R 1 کے برابر ہیں۔ دوسری طرف، اگر آپ NoSQL ڈیٹا بیس میں پانچوں مشینوں پر ڈیٹا لکھتے ہیں، تو آپ کسی بھی مشین سے ڈیٹا پڑھ سکتے ہیں اور ہر بار اپ ٹو ڈیٹ ڈیٹا حاصل کرنے کی ضمانت دی جاتی ہے۔ بڑی تعداد میں مشینوں پر ایک ہی آپریشن کو انجام دینے میں زیادہ وقت لگے گا، لیکن اگر اپ ٹو ڈیٹ ڈیٹا آپ کے لیے اہم ہے، تو آپ اس اختیار کا انتخاب کر سکتے ہیں۔ اس صورت میں، W = R = 5۔ ڈیٹا بیس کی مستقل مزاجی کے لیے پڑھنے اور لکھنے کی کم از کم کتنی تعداد درکار ہے؟ یہاں ایک سادہ فارمولا ہے: R + W ≥ N + 1 ، جہاں N کلسٹر میں مشینوں کی تعداد ہے۔ اس کا مطلب ہے کہ پانچ سرورز کے ساتھ، آپ R = 2 اور W = 4، یا R = 3 اور W = 3، یا R = 4 اور W = 2 کا انتخاب کر سکتے ہیں۔ اس صورت میں، اس سے کوئی فرق نہیں پڑتا ہے کہ کونسی مشینیں ڈیٹا لکھا ہوا ہے، پڑھنا ہمیشہ کم از کم ایک مشین سے تازہ ترین ڈیٹا کے ساتھ کیا جائے گا۔ دیگر ڈیٹا بیس، جیسے DynamoDB پر مختلف پابندیاں ہیں اور وہ صرف مستقل تحریروں کی اجازت دیتے ہیں۔ ڈیٹا کا ہر ٹکڑا تین سرورز پر محفوظ ہوتا ہے، اور جب کوئی ڈیٹا لکھا جاتا ہے، تو اسے تین میں سے دو مشینوں پر لکھا جاتا ہے۔ لیکن ڈیٹا پڑھتے وقت، آپ دو اختیارات میں سے ایک کا انتخاب کر سکتے ہیں:

1. سختی سے مسلسل پڑھنا، جس میں ڈیٹا کو تین میں سے دو مشینوں سے پڑھا جاتا ہے اور ہمیشہ حال ہی میں لکھا ہوا ڈیٹا واپس کرتا ہے۔
2. ایک حتمی مسلسل پڑھنا، جس میں ایک مشین کو تصادفی طور پر منتخب کیا جاتا ہے جس سے ڈیٹا کو پڑھنا ہے۔ تاہم، یہ عارضی طور پر پرانا ڈیٹا واپس کر سکتا ہے۔

اتنے NoSQL ڈیٹا بیس کیوں ہیں؟

اگر آپ سافٹ ویئر ڈویلپمنٹ کے میدان میں تازہ ترین خبروں کی پیروی کرتے ہیں، تو آپ نے شاید بہت سے مختلف NoSQL ڈیٹا بیس کے بارے میں سنا ہوگا، جیسے MongoDB، DynamoDB، Cassandra، Redis اور بہت سے دوسرے۔ آپ سوچ رہے ہوں گے: ہمیں اتنے مختلف NoSQL ڈیٹا بیس کی ضرورت کیوں ہے؟ وجہ سادہ ہے: کہ مختلف NoSQL ڈیٹا بیس مختلف مسائل کو حل کرنے کے لیے بنائے گئے ہیں۔ یہی وجہ ہے کہ مسابقتی ڈیٹا بیس کی تعداد اتنی زیادہ ہے۔ NoSQL ڈیٹا بیس چار اہم زمروں میں آتے ہیں:

دستاویز پر مبنی ڈیٹا بیس

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

کلیدی/ویلیو ڈیٹا بیس

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

گراف ڈیٹا بیس

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

کالم ڈیٹا بیس

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

آپ کو کون سا ڈیٹا بیس منتخب کرنا چاہئے؟

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

آپ کو یہ سب کیسے سیکھنا ہے؟

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

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


2. DynamoDB _ اگر آپ Amazon Web Services (AWS) استعمال کرتے ہیں، تو آپ DynamoDB کے بارے میں مزید جانیں گے۔ یہ ایک انتہائی قابل اعتماد، قابل توسیع، کم لیٹنسی ڈیٹا بیس ہے جس میں بھرپور فیچر سیٹ اور بہت سی دوسری AWS سروسز کے ساتھ انضمام ہے۔ سب سے اچھی بات یہ ہے کہ آپ کو اسے خود تعینات کرنے کی ضرورت نہیں ہے۔ ایک قابل توسیع DynamoDB کلسٹر ترتیب دینا جو ہزاروں سوالات کو سنبھال سکتا ہے صرف چند کلکس کی دوری پر ہے۔ اگر اس میں آپ کی دلچسپی ہے تو آپ اس کورس پر ایک نظر ڈال سکتے ہیں۔


3. Neo4j _ سب سے عام گراف ڈیٹا بیس۔ یہ ایک قابل توسیع اور مستحکم حل ہے جو ان لوگوں کے لیے موزوں ہے جو گراف ڈیٹا ماڈل استعمال کرنا چاہتے ہیں۔ اگر آپ مزید جاننا چاہتے ہیں تو اس کورس کے ساتھ شروع کریں ۔


4. ریڈیس _ جب کہ یہاں بیان کردہ دیگر ڈیٹا بیس بنیادی ایپلیکیشن ڈیٹا کو ذخیرہ کرنے کے لیے استعمال کیے جاتے ہیں، Redis بنیادی طور پر کیچز کو لاگو کرنے اور معاون ڈیٹا کو ذخیرہ کرنے کے لیے استعمال کیا جاتا ہے۔ بہت سے معاملات میں، مذکورہ بالا ڈیٹا بیس میں سے ایک کو Redis کے ساتھ مل کر استعمال کیا جاتا ہے۔ مزید جاننے کے لیے، اس کورس کو دیکھیں

NoSQL کے ساتھ 2018 میں

NoSQL ڈیٹا بیس ایک وسیع اور تیزی سے بڑھتا ہوا فیلڈ ہے۔ وہ آپ کو ڈیٹا کی پہلے ناقابل تصور مقدار کو ذخیرہ کرنے اور اس پر کارروائی کرنے کی اجازت دیتے ہیں، لیکن یہ قیمت پر آتا ہے۔ ان ڈیٹا بیس میں ایسی بہت سی خصوصیات نہیں ہیں جن سے آپ رشتہ دار ڈیٹا بیس میں واقف ہیں، اور ان کو استعمال کرنے کے لیے خود کو ترتیب دینا مشکل ہو سکتا ہے۔ لیکن ایک بار جب آپ ان کو پکڑ لیتے ہیں، تو آپ قابل توسیع، تقسیم شدہ ڈیٹا بیس بنا سکتے ہیں جو پڑھنے اور لکھنے کی درخواستوں کی حیران کن مقداروں کو سنبھال سکتے ہیں، جو کہ انتہائی اہم ہو سکتا ہے کیونکہ ڈیٹا کے بڑے اور بڑے حجم پیدا ہوتے ہیں۔ اصل: https://simpleprogrammer.com/guide-nosql-software-developers/