ڈیٹا بیس کسی ایپ کا وہ حصہ ہے جو ڈیٹا کو محفوظ کرتا ہے تاکہ ایپ کے دوبارہ شروع ہونے، سرور کے کریش ہونے، یا بجلی چلے جانے کے بعد بھی وہ ڈیٹا موجود رہے۔ ایپ بعد میں اس ڈیٹا کو مخصوص صورتوں میں طلب کر سکتی ہے، مثلاً ID کے ذریعے کوئی ایک ریکارڈ یا کسی صارف (user) کے لحاظ سے فلٹر کی گئی فہرست۔
“ڈیٹا” کے تصور کو عملی مثال سے سمجھنے کے لیے، ٹاسک لسٹ (کاموں کی فہرست) کی ایک چھوٹی سی ایپ پر غور کریں۔ ہر ٹاسک ایک ریکارڈ ہوتا ہے جس میں task_id، user_id، title، completed اور created_at جیسی فیلڈز شامل ہوتی ہیں، اور ایپ کو دو بنیادی کام (actions) کرنے کی ضرورت ہوتی ہے۔ ایک عمل ٹاسک تخلیق کرتا ہے، اور دوسرا صارف کے ٹاسکس کی فہرست دکھاتا ہے۔
سنگل سرور (ایک ہی سرور) والے بنیادی ڈھانچے میں، کلائنٹ ایپ سرور کو HTTP درخواستیں بھیجتا ہے، اور ایپ سرور ایک ہی ڈیٹا بیس میں قطاریں (rows) پڑھتا اور لکھتا ہے۔ ڈیٹا بیس “ہر درخواست پر ٹاسک کی قطار صرف ایک بار لکھی جائے” جیسے اصولوں کو نافذ کر کے درستگی کو یقینی بناتا ہے، اور اس عمل میں تاخیر (latency) بھی پیدا ہوتی ہے کیونکہ ڈسک اور میموری پر ڈیٹا پڑھنے اور لکھنے میں وقت لگتا ہے۔ آئیے ایک باکس ڈایاگرام پر درخواستوں کے ان دونوں راستوں کا جائزہ لیتے ہیں۔
ٹاسک بنانے (create-task) کی درخواست پر، ایپ سرور ان پٹ کی تصدیق کرتا ہے، پھر ڈیٹا بیس سے ایک نئی ٹاسک رو (row) شامل کرنے کو کہتا ہے، اور آخر میں کلائنٹ کو نیا task_id واپس بھیجتا ہے۔ کلائنٹ ڈیٹا کے محفوظ (durable) اندراج کو تبھی تسلیم کرتا ہے جب ڈیٹا بیس اس کی تصدیق کر دے؛ یہی وجہ ہے کہ درستگی کے عمل میں ڈیٹا بیس ایک کلیدی حیثیت (critical path) رکھتا ہے۔
ٹاسکس کی فہرست (list-tasks) طلب کرنے کی درخواست پر، ایپ سرور ڈیٹا بیس سے ان تمام ٹاسکس کا مطالبہ کرتا ہے جن کا user_id میچ کرتا ہو (اکثر created_at کے لحاظ سے ترتیب دیے گئے)؛ پھر ایپ سرور جواب (response) کو مناسب فارمیٹ میں تیار کرتا ہے۔ جب کوئی کوئری ضرورت سے زیادہ روز (rows) کو اسکین کرتی ہے تو ڈیٹا بیس کو زیادہ کام کرنا پڑتا ہے اور کلائنٹ کو طویل انتظار کرنا پڑتا ہے، لہٰذا کارکردگی کا انحصار اس بات پر ہوتا ہے کہ ڈیٹا بیس میچنگ روز کو کس طرح تلاش کرتا ہے۔
جیسے جیسے مزید صارفین ٹاسکس شامل کرتے ہیں، سب سے پہلے نظر آنے والی خرابی عام طور پر یہ ہوتی ہے کہ ٹاسکس کی فہرست دکھانے کا عمل (list-tasks) سست ہو جاتا ہے کیونکہ ڈیٹا بیس کو ایک ہی کوئری کا جواب دینے کے لیے بہت زیادہ ڈیٹا پڑھنا پڑتا ہے۔ اس کے بعد، کوئی بہت زیادہ فعال صارف (hot user) یا مشترکہ فہرست ‘لاک ویٹس’ (lock waits) کا سبب بن سکتی ہے، جہاں متعدد ‘رائٹ’ (write) آپریشنز ایک ہی رو یا روز کے سیٹ کو اپ ڈیٹ کرنے کی کوشش کرتے ہیں؛ نتیجتاً، درخواستیں متوازی (parallel) طور پر مکمل ہونے کے بجائے ایک دوسرے کے پیچھے قطار میں لگ جاتی ہیں۔ آخر میں، اگر واحد ڈیٹا بیس پروسیس یا مشین ناکارہ ہو جائے تو پوری ایپ سروس دینا بند کر دیتی ہے کیونکہ ہر درخواست کا انحصار اسی پر ہوتا ہے۔ اگلا خاکہ (ڈایاگرام) انہی تین دباؤ والے مقامات (pressure points) کی نشاندہی کرتا ہے۔