🥇 مزید ڈویلپرز کو ڈیٹا بیس کے بارے میں یہ جاننا چاہیے

نوٹ. ترجمہ: جانا ڈوگن گوگل میں ایک تجربہ کار انجینئر ہے جو اس وقت گو میں لکھی گئی کمپنی کی پروڈکشن سروسز کے مشاہدے پر کام کر رہی ہے۔ اس مضمون میں، جس نے انگریزی بولنے والے سامعین میں زبردست مقبولیت حاصل کی، اس نے DBMSs (اور بعض اوقات عام طور پر تقسیم شدہ نظام) کے حوالے سے 17 نکات کی اہم تکنیکی تفصیلات جمع کیں جو بڑی/مطلوب ایپلی کیشنز کے ڈویلپرز کے لیے غور کرنے کے لیے مفید ہیں۔

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

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

میں Emmanuel Odeke، Rein Henrichs اور دوسروں کا شکریہ ادا کرنا چاہوں گا کہ اس مضمون کے پہلے ورژن پر ان کے تاثرات۔

آپ خوش قسمت ہیں اگر 99,999% وقت نیٹ ورک مسائل کا باعث نہیں بن رہا ہے۔

سوال یہ ہے کہ جدید نیٹ ورک ٹیکنالوجیز کتنی قابل اعتماد ہیں اور نیٹ ورک کی ناکامی کی وجہ سے سسٹم کتنی بار بند رہتے ہیں۔ اس مسئلے پر معلومات بہت کم ہیں اور تحقیق پر اکثر خصوصی نیٹ ورکس، آلات اور عملے والی بڑی تنظیموں کا غلبہ ہوتا ہے۔

سپنر (گوگل کا عالمی سطح پر تقسیم شدہ ڈیٹا بیس) کے لیے 99,999% کی دستیابی کی شرح کے ساتھ، گوگل کا دعویٰ ہے کہ صرف 7,6٪ مسائل نیٹ ورک سے متعلق ہیں۔ اسی وقت، کمپنی اپنے خصوصی نیٹ ورک کو اعلیٰ دستیابی کا "اہم ستون" کہتی ہے۔ مطالعہ بیلس اور کنگزبری2014 میں منعقد کیا گیا، ایک چیلنج کرتا ہے "تقسیم شدہ کمپیوٹنگ کے بارے میں غلط فہمیاں"، جسے پیٹر ڈوئچ نے 1994 میں تیار کیا تھا۔ کیا نیٹ ورک واقعی قابل اعتماد ہے؟

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

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

ACID کا مطلب بہت سی مختلف چیزیں ہیں۔

ACID کا مخفف Atomicity، Consistency، Isolation، Reliability کا ہے۔ لین دین کی ان خصوصیات کا مقصد ناکامیوں، غلطیوں، ہارڈ ویئر کی ناکامی وغیرہ کی صورت میں ان کی درستگی کو یقینی بنانا ہے۔ ACID یا اسی طرح کی اسکیموں کے بغیر، ایپلیکیشن ڈویلپرز کے لیے یہ فرق کرنا مشکل ہوگا کہ وہ کس چیز کے لیے ذمہ دار ہیں اور ڈیٹا بیس کس چیز کے لیے ذمہ دار ہے۔ زیادہ تر متعلقہ لین دین کے ڈیٹا بیس ACID کے مطابق ہونے کی کوشش کرتے ہیں، لیکن NoSQL جیسے نئے طریقوں نے ACID لین دین کے بغیر بہت سے ڈیٹا بیس کو جنم دیا ہے کیونکہ ان پر عمل درآمد مہنگا ہے۔

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

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

اس بارے میں بحث جاری ہے کہ آیا MongoDB ACID کی ضروریات کو پورا کرتا ہے ورژن 4 کے اجراء کے بعد بھی۔ MongoDB ایک طویل عرصے سے تعاون یافتہ نہیں ہے۔ لاگنگ، اگرچہ پہلے سے طے شدہ ڈیٹا ہر 60 سیکنڈ میں ایک بار سے زیادہ ڈسک پر پابند نہیں تھا۔ مندرجہ ذیل منظر نامے کا تصور کریں: ایک درخواست دو تحریریں پوسٹ کرتی ہے (w1 اور w2)۔ MongoDB کامیابی کے ساتھ w1 کو اسٹور کرتا ہے، لیکن ہارڈ ویئر کی ناکامی کی وجہ سے w2 کھو جاتا ہے۔

منظر نامے کی وضاحت کرنے والا خاکہ۔ MongoDB ڈسک پر ڈیٹا لکھنے سے پہلے کریش ہو جاتا ہے۔

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

ہر ڈیٹا بیس کی اپنی مستقل مزاجی اور تنہائی کا طریقہ کار ہوتا ہے۔

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

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

موجودہ کنکرنسی ماڈلز اور ان کے درمیان تعلقات کا جائزہ

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

ایس کیو ایل کا معیار درج ذیل تنہائی کی سطحوں کا ذکر کرتا ہے:

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

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

دیے گئے DBMS میں تنہائی کی سطح کے لیے معاونت کی تشہیر اکثر کی جاتی ہے، لیکن صرف اس کے رویے کا بغور مطالعہ ہی یہ ظاہر کر سکتا ہے کہ اصل میں کیا ہو رہا ہے۔

مختلف DBMSs کے لیے مختلف تنہائی کی سطحوں پر ہم آہنگی کی بے ضابطگیوں کا جائزہ

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

جب معمول کو برقرار رکھنا مشکل ہو تو پرامید بلاکنگ بچاؤ کے لیے آتی ہے۔

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

پرامید تالا ایک ایسا طریقہ ہے جس میں سٹرنگ کو پڑھتے وقت، یہ اس کے ورژن، چیکسم، یا آخری ترمیم کے وقت کو مدنظر رکھتا ہے۔ یہ آپ کو اس بات کا یقین کرنے کی اجازت دیتا ہے کہ اندراج کو تبدیل کرنے سے پہلے جوہری ورژن میں کوئی تبدیلی نہیں ہے:

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

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

گندے پڑھنے اور ڈیٹا کے ضائع ہونے کے علاوہ اور بھی بے ضابطگیاں ہیں۔

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

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

مثال کے طور پر، آئیے ایک مانیٹرنگ ایپلی کیشن پر غور کریں جس کے لیے ایک آپریٹر کو ہر وقت آن کال کرنے کی ضرورت ہوتی ہے:

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

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

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

ڈیٹا بیس اور صارف ہمیشہ اس بات پر متفق نہیں ہوتے ہیں کہ کیا کرنا ہے۔

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

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

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

نتیجہ1 = T1() // حقیقی نتائج وعدے ہیں۔
نتیجہ2 = T2()

اگر ایٹمیسیٹی کی ضرورت ہے (یعنی یا تو تمام آپریشنز کو مکمل کیا جانا چاہیے یا اسے ختم کرنا چاہیے) اور ترتیب کے معاملات ہیں، تو آپریشنز T1 اور T2 کو ایک ہی لین دین کے اندر انجام دیا جانا چاہیے۔

ایپلیکیشن لیول شارڈنگ کو ایپلیکیشن سے باہر منتقل کیا جا سکتا ہے۔

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

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

فن تعمیر کی ایک مثال جس میں ایپلیکیشن سرورز کو شارڈنگ سروس سے الگ کیا جاتا ہے۔

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

خود بخود اضافہ خطرناک ہو سکتا ہے۔

AUTOINCREMENT بنیادی کلیدیں بنانے کا ایک عام طریقہ ہے۔ اکثر ایسے معاملات ہوتے ہیں جب ڈیٹا بیس کو ID جنریٹر کے طور پر استعمال کیا جاتا ہے، اور ڈیٹا بیس میں ٹیبلز ہوتے ہیں جو شناخت کنندگان کو تیار کرنے کے لیے بنائے گئے ہیں۔ آٹو انکریمنٹنگ کا استعمال کرتے ہوئے پرائمری کیز بنانے کی بہت سی وجوہات ہیں:

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

کسی نقطہ نظر کے بارے میں فیصلہ کرنے سے پہلے، انڈیکسنگ، پارٹیشننگ، اور شارڈنگ پر آٹو انکریمنٹ IDs اور UUIDs کے اثرات پر غور کریں۔

باسی ڈیٹا مفید ہو سکتا ہے اور اسے لاک کرنے کی ضرورت نہیں ہے۔

ملٹی ورشن کنکرنسی کنٹرول (MVCC) مستقل مزاجی کے بہت سے تقاضوں کو نافذ کرتا ہے جن پر مختصراً اوپر بحث کی گئی ہے۔ کچھ ڈیٹا بیس (مثال کے طور پر، Postgres، Spanner) MVCC کا استعمال اسنیپ شاٹس کے ساتھ لین دین کو "فیڈ" کرنے کے لیے کرتے ہیں— ڈیٹا بیس کے پرانے ورژن۔ مطابقت کو یقینی بنانے کے لیے سنیپ شاٹ کے لین دین کو بھی سیریلائز کیا جا سکتا ہے۔ پرانے سنیپ شاٹ سے پڑھتے وقت، پرانا ڈیٹا پڑھا جاتا ہے۔

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

میراثی ڈیٹا کے ساتھ کام کرنے کا پہلا فائدہ کم تاخیر ہے (خاص طور پر اگر ڈیٹا بیس کو مختلف جغرافیوں میں تقسیم کیا گیا ہو)۔ دوسرا یہ کہ صرف پڑھنے والے لین دین لاک فری ہیں۔ یہ ان ایپلی کیشنز کے لیے ایک اہم فائدہ ہے جو بہت زیادہ پڑھتی ہیں، جب تک کہ وہ باسی ڈیٹا کو سنبھال سکیں۔

ایپلیکیشن سرور مقامی نقل سے ڈیٹا پڑھتا ہے جو کہ 5 سیکنڈ پرانا ہے، چاہے تازہ ترین ورژن بحر الکاہل کے دوسری طرف دستیاب ہو۔

DBMSs خود بخود پرانے ورژنز کو صاف کرتے ہیں اور بعض صورتوں میں، آپ کو درخواست پر ایسا کرنے کی اجازت دیتے ہیں۔ مثال کے طور پر، Postgres صارفین کو کرنے کی اجازت دیتا ہے۔ VACUUM درخواست پر، اور وقتاً فوقتاً یہ آپریشن خود بخود انجام دیتا ہے۔ اسپنر ایک گھنٹہ سے زیادہ پرانے سنیپ شاٹس سے چھٹکارا پانے کے لیے کوڑا اٹھانے والا چلاتا ہے۔

کسی بھی وقت ذرائع تحریف کے تابع ہوتے ہیں۔

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

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

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

صورتحال اس حقیقت سے مزید گھمبیر ہوتی ہے کہ ایپلی کیشنز اور ڈیٹا بیس اکثر مختلف مشینوں پر موجود ہوتے ہیں (اگر مختلف ڈیٹا سینٹرز میں نہیں ہیں)۔ اس طرح، وقت نہ صرف مختلف مشینوں میں تقسیم کردہ ڈی بی نوڈس پر مختلف ہوگا۔ یہ ایپلیکیشن سرور پر بھی مختلف ہوگا۔

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

TrueTime دو مختلف ذرائع استعمال کرتا ہے: GPS اور ایٹمی گھڑیاں۔ ان گھڑیوں میں غیر متعلقہ ناکامی کے طریقے ہیں۔ تفصیل کے لیے صفحہ 5 دیکھیں یہاں - تقریبا. ترجمہ)، لہذا ان کے مشترکہ استعمال سے وشوسنییتا میں اضافہ ہوتا ہے۔
TrueTime میں ایک غیر معمولی API ہے۔ یہ پیمائش کی غلطی اور اس میں شامل غیر یقینی صورتحال کے ساتھ وقفہ کے طور پر وقت لوٹاتا ہے۔ وقت کا اصل لمحہ وقفہ کی اوپری اور نچلی حدود کے درمیان کہیں ہوتا ہے۔ اسپنر، گوگل کا تقسیم شدہ ڈیٹا بیس، صرف اس وقت تک انتظار کرتا ہے جب تک کہ یہ کہنا محفوظ نہ ہو کہ موجودہ وقت حد سے باہر ہے۔ یہ طریقہ سسٹم میں کچھ تاخیر کو متعارف کراتا ہے، خاص طور پر اگر ماسٹرز پر غیر یقینی صورتحال زیادہ ہے، لیکن عالمی سطح پر تقسیم شدہ صورتحال میں بھی درستگی کو یقینی بناتا ہے۔

اسپنر کے اجزاء TrueTime کا استعمال کرتے ہیں، جہاں TT.now() وقفہ لوٹاتا ہے، اس لیے اسپنر صرف اس مقام تک سوتا ہے جہاں اسے یقین ہو کہ موجودہ وقت ایک خاص نقطہ سے گزر چکا ہے۔

موجودہ وقت کے تعین میں درستگی میں کمی کا مطلب سپنر آپریشنز کی مدت میں اضافہ اور کارکردگی میں کمی ہے۔ یہی وجہ ہے کہ سب سے زیادہ ممکنہ درستگی کو برقرار رکھنا ضروری ہے حالانکہ مکمل طور پر درست گھڑی حاصل کرنا ناممکن ہے۔

تاخیر کے کئی معنی ہیں۔

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

کسی مخصوص لین دین کے لیے کارکردگی کی ضروریات کا جائزہ لیا جانا چاہیے۔

کبھی کبھی DBMS کی کارکردگی کی خصوصیات اور اس کی حدود لکھنے/پڑھنے کے تھرو پٹ اور تاخیر کے لحاظ سے بیان کی جاتی ہیں۔ یہ کلیدی نظام کے پیرامیٹرز کا عمومی جائزہ فراہم کرتا ہے، لیکن نئے DBMS کی کارکردگی کا جائزہ لیتے وقت، ایک بہت زیادہ جامع نقطہ نظر یہ ہے کہ الگ الگ طور پر اہم کارروائیوں کا جائزہ لیا جائے (ہر سوال اور/یا لین دین کے لیے)۔ مثالیں:

متعلقہ جدولوں میں مخصوص رکاوٹوں اور قطار کی پیڈنگ کے ساتھ ٹیبل X (50 ملین قطاروں کے ساتھ) میں نئی قطار داخل کرتے وقت تھرو پٹ اور لیٹنسی لکھیں۔
دوستوں کی اوسط تعداد 500 ہونے پر کسی مخصوص صارف کے دوستوں کے دوستوں کو ظاہر کرنے میں تاخیر۔
صارف کی تاریخ سے سرفہرست 100 اندراجات کو بازیافت کرنے میں تاخیر جب صارف فی گھنٹہ X اندراجات کے ساتھ 500 دوسرے صارفین کی پیروی کرتا ہے۔

تشخیص اور تجربات میں ایسے نازک معاملات شامل ہو سکتے ہیں جب تک کہ آپ کو یقین نہ ہو کہ ڈیٹا بیس کارکردگی کی ضروریات کو پورا کرتا ہے۔ لیٹنسی میٹرکس جمع کرتے وقت اور SLOs کا تعین کرتے وقت انگوٹھے کا ایک ہی اصول اس خرابی کو بھی مدنظر رکھتا ہے۔

ہر آپریشن کے لیے میٹرکس جمع کرتے وقت اعلیٰ قلبی سے آگاہ رہیں۔ ہائی پاور ڈیبگنگ ڈیٹا حاصل کرنے کے لیے لاگز، ایونٹ کلیکشن، یا تقسیم شدہ ٹریسنگ کا استعمال کریں۔ مضمون میں "تاخیر کو ڈیبگ کرنا چاہتے ہیں؟» آپ تاخیر سے ڈیبگنگ کے طریقہ کار سے خود کو واقف کر سکتے ہیں۔

نیسٹڈ لین دین خطرناک ہو سکتا ہے۔

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

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

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

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

مندرجہ بالا کوڈ کا آؤٹ پٹ کیا ہوگا؟ کیا یہ دونوں لین دین کو واپس لے جائے گا، یا صرف اندرونی ایک؟ کیا ہوتا ہے اگر ہم لائبریریوں کی متعدد پرتوں پر انحصار کریں جو ہمارے لیے لین دین کی تخلیق کو سمیٹتی ہیں؟ کیا ہم ایسے کیسز کی نشاندہی اور ان میں بہتری لا سکیں گے؟

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

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

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

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

لین دین کو درخواست کی حالت سے منسلک نہیں کیا جانا چاہئے۔

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

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

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

سوال کے منصوبہ ساز آپ کو ڈیٹا بیس کے بارے میں بہت کچھ بتا سکتے ہیں۔

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

SELECT * FROM articles where author = "rakyll" order by title;

نتائج دو طریقوں سے حاصل کیے جا سکتے ہیں:

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

استفسار کے منصوبہ ساز کا کام یہ طے کرنا ہے کہ کون سی حکمت عملی بہترین ہے۔ یہ بات قابل غور ہے کہ استفسار کرنے والوں کے پاس صرف پیشین گوئی کی محدود صلاحیتیں ہوتی ہیں۔ اس سے غلط فیصلے ہو سکتے ہیں۔ DBAs یا ڈویلپرز ان کا استعمال کم کارکردگی والے سوالات کی تشخیص اور ٹھیک ٹیون کرنے کے لیے کر سکتے ہیں۔ DBMS کے نئے ورژن استفسار کے منصوبہ سازوں کو ترتیب دے سکتے ہیں، اور اگر نیا ورژن کارکردگی کے مسائل کا باعث بنتا ہے تو ڈیٹا بیس کو اپ ڈیٹ کرتے وقت خود تشخیص میں مدد مل سکتی ہے۔ سست استفسار کے نوشتہ جات، لیٹنسی ایشو رپورٹس، یا ایگزیکیوشن ٹائم کے اعدادوشمار ان سوالات کی نشاندہی کرنے میں مدد کر سکتے ہیں جن کو اصلاح کی ضرورت ہے۔

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

آن لائن ہجرت مشکل ہے لیکن ممکن ہے۔

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

آن لائن منتقلی کے مختلف ماڈلز ہیں۔ یہاں ان میں سے ایک ہے:

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

اضافی معلومات کے لیے، میں رابطہ کرنے کی تجویز کرتا ہوں۔ آرٹیکل، جو اس ماڈل کی بنیاد پر اسٹرائپ کی نقل مکانی کی حکمت عملی کی تفصیلات فراہم کرتا ہے۔

ڈیٹا بیس میں ایک نمایاں اضافہ غیر متوقع میں اضافہ پر مشتمل ہے۔

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

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

...

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

PS

ہمارے بلاگ پر بھی پڑھیں:

ماخذ: www.habr.com

مزید ڈویلپرز کو ڈیٹا بیس کے بارے میں یہ جاننا چاہیے۔