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

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

مجھے اس کی ضرورت کیوں ہے؟

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

سمجھوتے سے ملیں۔

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

ٹریڈ آف 1: کارکردگی

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

ٹریڈ آف 2: مستقل مزاجی۔

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

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

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

ٹریڈ آف 3: کریش

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

فی لین دین ایک کنکشن؟

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

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

عملی طور پر کنٹرول کو یقینی بنانا

پہلے سے طے شدہ طور پر، PostgreSQL مستقل مزاجی فراہم کرتا ہے۔ یہ سرور پیرامیٹر کے ذریعے کنٹرول کیا جاتا ہے۔ synchronous_commit. پہلے سے طے شدہ طور پر یہ پوزیشن میں ہے۔ on، لیکن اس کے پاس تین دوسرے اختیارات ہیں: local, remote_write یا off.

پیرامیٹر کو ترتیب دیتے وقت off تمام ہم وقت سازی کو روک دیا گیا ہے، یہاں تک کہ مقامی نظام پر بھی۔ مقامی پیرامیٹر مقامی نظام کے لیے ہم وقت ساز موڈ کی وضاحت کرتا ہے، لیکن نقل کے لیے لکھنا متضاد طور پر انجام دیا جاتا ہے۔ Remote_write اس سے بھی آگے جاتا ہے: ریپلیکا کو لکھنا متضاد طور پر بنایا جاتا ہے، لیکن جب ریپلیکا نے تحریر کو قبول کیا ہے لیکن اسے ڈسک پر نہیں لکھا ہے تو اسے واپس کیا جاتا ہے۔

اختیارات کی دستیاب رینج پر غور کرتے ہوئے، ہم ایک طرز عمل کا انتخاب کرتے ہیں اور، اس کو ذہن میں رکھتے ہوئے on - یہ ہم وقت ساز ریکارڈنگ ہیں، ہم منتخب کریں گے۔ local نیٹ ورک پر غیر مطابقت پذیر کمٹ کے لیے، جبکہ مقامی کمٹ کو ہم وقت ساز چھوڑنا۔

اب، ہم آپ کو بتائیں گے کہ اسے ایک لمحے میں کیسے ترتیب دیا جائے، لیکن تصور کریں کہ ہم نے سیٹ اپ کیا۔ synchronous_commit в local سرور کے لیے ہم نے سوچا کہ کیا پیرامیٹر کو تبدیل کرنا ممکن ہے۔ synchronous_commit مکھی پر، اور یہ پتہ چلا کہ یہ نہ صرف ممکن ہے، ایسا کرنے کے دو طریقے بھی ہیں۔ سب سے پہلے اپنے کنکشن کا سیشن اس طرح ترتیب دینا ہے:

SET SESSION synchronous_commit TO ON;  
// Your writes go here

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

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

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

ڈیٹا بیس کی جانب سے منسلک کلائنٹ کو مثبت جواب دینے سے پہلے تمام لین دین کے وعدوں کی اب تصدیق ہو جائے گی جیسا کہ نقل میں لکھا گیا ہے۔

PostgreSQL ترتیب دینا

اس سے پہلے، ہم نے پوسٹگری ایس کیو ایل سسٹم کے ساتھ تصور کیا تھا۔ synchronous_commitمیں نصب local. سرور کی طرف اس کو حقیقت پسندانہ بنانے کے لیے، آپ کو سرور کی ترتیب کے دو اختیارات مرتب کرنے ہوں گے۔ ایک اور پیرامیٹر synchronous_standby_names اپنے آپ میں آئے گا جب synchronous_commit میں ہو جائے گا on. یہ اس بات کا تعین کرتا ہے کہ کون سی نقلیں مطابقت پذیر کمٹ کے لیے اہل ہیں، اور ہم اسے مقرر کریں گے۔ *، جس کا مطلب یہ ہوگا کہ تمام نقلیں شامل ہیں۔ یہ اقدار عام طور پر ترتیب دی جاتی ہیں۔ ترتیب فائل شامل کرکے:

synchronous_commit = local  
synchronous_standby_names='*'

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

اگر آپ ترقی کی پیروی کر رہے ہیں۔ گورنر پروجیکٹآپ نے کچھ حالیہ تبدیلیاں دیکھی ہوں گی (1, 2)، جس نے گورنر کے صارفین کو ان پیرامیٹرز کی جانچ کرنے اور ان کی مستقل مزاجی کی نگرانی کرنے کی اجازت دی۔

کچھ اور الفاظ...

صرف ایک ہفتہ پہلے، میں نے آپ کو بتایا تھا کہ PostgreSQL کو اتنی باریک ٹیون کرنا ناممکن ہے۔ تب ہی جب کمپوز پلیٹ فارم ٹیم کے ایک رکن کرٹ نے اصرار کیا کہ ایسا موقع موجود ہے۔ اس نے میرے اعتراضات کو پرسکون کیا اور PostgreSQL دستاویزات میں پایا مندرجہ ذیل:

اس ترتیب کو کسی بھی وقت تبدیل کیا جا سکتا ہے۔ کسی بھی لین دین کے لیے رویے کا تعین اس ترتیب سے کیا جاتا ہے جو کمٹ کے وقت لاگو ہوتی ہے۔ اس لیے، کچھ لین دین کے لیے ہم وقت سازی اور دوسروں کے لیے متضاد طور پر کرنا ممکن اور مفید ہے۔ مثال کے طور پر کسی کو مجبور کرنا multistatement جب پیرامیٹر کی ڈیفالٹ ویلیو مخالف ہو تو متضاد طور پر کمٹ کرنے کے لیے لین دین، سیٹ SET LOCAL synchronous_commit TO OFF ایک لین دین میں.

کنفیگریشن فائل میں اس چھوٹی سی ترمیم کے ساتھ، ہم نے صارفین کو ان کی مستقل مزاجی اور کارکردگی پر کنٹرول دیا۔

ماخذ: www.habr.com