پیارے DELETE۔ نیکولے سموخوالوف (Postgres.ai)

مستقبل بعید میں کسی وقت، غیر ضروری ڈیٹا کو خودکار طور پر ہٹانا DBMS کے اہم کاموں میں سے ایک ہوگا [1]۔ اس دوران، ہمیں خود کو غیر ضروری ڈیٹا کو حذف کرنے یا کم مہنگے اسٹوریج سسٹمز میں منتقل کرنے کا خیال رکھنے کی ضرورت ہے۔ فرض کریں کہ آپ چند ملین قطاروں کو حذف کرنے کا فیصلہ کرتے ہیں۔ کافی آسان کام، خاص طور پر اگر حالت معلوم ہو اور مناسب انڈیکس ہو۔ "ٹیبل 1 سے حذف کریں جہاں col1 = :value" - کیا آسان ہو سکتا ہے، ٹھیک ہے؟

ویڈیو:

• میں ہائی لوڈ پروگرام کمیٹی میں پہلے سال سے ہوں، یعنی 2007 سے۔

• اور میں 2005 سے پوسٹگریس کے ساتھ رہا ہوں۔ اسے بہت سے منصوبوں میں استعمال کیا۔

• RuPostges کے ساتھ گروپ بھی 2007 سے۔

• ہم میٹ اپ میں 2100+ شرکاء تک پہنچ گئے ہیں۔ یہ نیویارک کے بعد دنیا میں دوسرے نمبر پر ہے، جس نے طویل عرصے تک سان فرانسسکو کو پیچھے چھوڑ دیا۔

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

https://postgres.ai/ میری کمپنی ہے. ہم خودکار کاموں کے کاروبار میں ہیں جو ترقی کی سست روی کو ختم کرتے ہیں۔

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

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

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

زیٹا بائٹس کی دنیا میں زیادہ سے زیادہ ڈیٹا موجود ہے - یعنی 1 پیٹا بائٹس۔ اور اب یہ پہلے ہی اندازہ لگایا گیا ہے کہ ہمارے پاس دنیا میں 000 زیٹا بائٹس سے زیادہ ڈیٹا محفوظ ہے۔ اور ان میں سے زیادہ ہیں۔

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

اور اس کے ساتھ کیا کرنا ہے؟ ظاہر ہے اسے ہٹانے کی ضرورت ہے۔ اس دلچسپ رپورٹ کا لنک یہ ہے۔ لیکن ابھی تک اس کو ڈی بی ایم ایس میں نافذ نہیں کیا گیا ہے۔

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

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

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

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

اور ہماری ایک ایسی درخواست ہے، جس پر ہم آج بات کریں گے، یعنی کچرا ہٹانے کے بارے میں۔

ہم نے ایک تجربہ کار ڈویلپر کو ایسا کرنے کو کہا۔ اس نے یہ درخواست لی، اسے خود چیک کیا - سب کچھ کام کرتا ہے۔ سٹیجنگ پر تجربہ کیا - سب کچھ ٹھیک ہے. رول آؤٹ - سب کچھ کام کرتا ہے۔ دن میں ایک بار ہم اسے چلاتے ہیں - سب کچھ ٹھیک ہے۔

ڈیٹا بیس بڑھتا اور بڑھتا ہے۔ روزانہ DELETE کچھ زیادہ آہستہ سے کام کرنا شروع کرتا ہے۔

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

چند ماہ بعد انہیں یاد آیا۔ اور اس ڈویلپر نے چھوڑ دیا یا کسی اور چیز میں مصروف ہے، دوسرے کو اسے واپس کرنے کی ہدایت کی۔

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

اگے کیا ہوتا ہے؟ پھر ہمارے لیے سب کچھ ٹوٹ جاتا ہے۔ یہ اس طرح گرتا ہے کہ کسی وقت سب کچھ نیچے گر جاتا ہے۔ ہر کوئی صدمے میں ہے، کوئی نہیں سمجھ رہا کہ کیا ہو رہا ہے۔ اور پھر پتہ چلا کہ معاملہ اس DELETE میں تھا۔

کچھ غلط ہو گیا؟ یہاں ایک فہرست ہے کہ کیا غلط ہوسکتا ہے۔ ان میں سے سب سے اہم کون سا ہے؟

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

• شاید انہوں نے کچھ غلط چیک کیا۔

• ہوسکتا ہے کہ ہارڈ ویئر پرانا ہو اور آپ کو اس بیس کو اپ گریڈ کرنے کی ضرورت ہو۔

• یا خود ڈیٹا بیس میں کچھ غلط ہے، اور ہمیں Postgres سے MySQL میں جانے کی ضرورت ہے۔

• یا شاید آپریشن میں کچھ گڑبڑ ہے۔

• ہوسکتا ہے کہ کام کی تنظیم میں کچھ غلطیاں ہوں اور آپ کو کسی کو برطرف کرنے اور بہترین لوگوں کی خدمات حاصل کرنے کی ضرورت ہے؟

کوئی DBA چیک نہیں تھا۔ اگر کوئی ڈی بی اے ہوتا تو وہ یہ کئی ملین لائنیں دیکھتا اور بغیر کسی تجربات کے کہتا: "وہ ایسا نہیں کرتے۔" فرض کریں کہ اگر یہ کوڈ GitLab، GitHub میں ہوتا اور وہاں کوڈ پر نظرثانی کا عمل ہوتا اور یہ ایسا نہیں تھا کہ DBA کی منظوری کے بغیر یہ آپریشن prod پر ہوتا، تو ظاہر ہے DBA کہے گا: "یہ نہیں ہو سکتا۔ "

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

http://bit.ly/nancy-hl2018-2

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

ہم سمجھتے ہیں کہ ہمارے ٹیسٹ کمزور ہیں، یعنی جو عمل بنایا گیا ہے وہ مسائل کو نہیں پکڑتا۔ ایک مناسب DB تجربہ نہیں کیا گیا تھا۔

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

شاید ہمارا سامان خراب ہے؟ دیکھو تو لیٹنسی اچھل پڑی۔ ہم نے دیکھا ہے کہ استعمال 100% ہے۔ بلاشبہ، اگر یہ جدید NVMe ڈرائیوز ہوتیں، تو شاید یہ ہمارے لیے بہت آسان ہوتا۔ اور شاید ہم اس سے لیٹ نہ ہوں۔

اگر آپ کے پاس بادل ہیں، تو وہاں اپ گریڈ آسانی سے ہو جاتا ہے۔ نئے ہارڈ ویئر پر نئی نقلیں تیار کیں۔ سوئچ اوور اور سب ٹھیک ہے۔ بہت آسان.

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

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

پوسٹگریس میں سیٹنگز پیچھے ہیں۔ وہ 10-15 سال پرانے ڈیٹا اور لین دین کے لیے ڈیزائن کیے گئے ہیں۔ اور چیک پوائنٹ اس سے مستثنیٰ نہیں ہے۔

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

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

اور بطور ڈیفالٹ max_wal_saze 1 گیگا بائٹ پر سیٹ ہے۔ حقیقت میں، یہ واقعی پوسٹگریس میں 300-400 میگا بائٹس کے بعد ہوتا ہے۔ آپ نے بہت زیادہ ڈیٹا بدل دیا ہے اور آپ کی چوکی ہوتی ہے۔

اور اگر کسی نے اسے ٹیون نہیں کیا، اور سروس میں اضافہ ہوا، اور کمپنی بہت پیسہ کماتی ہے، اس کے پاس بہت زیادہ لین دین ہے، تو چیک پوائنٹ ایک منٹ میں ایک بار آتا ہے، کبھی کبھی ہر 30 سیکنڈ میں، اور کبھی کبھی اوورلیپ بھی ہوتا ہے۔ یہ کافی برا ہے۔

اور ہمیں یہ یقینی بنانا ہوگا کہ یہ کم کثرت سے آتا ہے۔ یعنی ہم max_wal_size کو بڑھا سکتے ہیں۔ اور یہ کم کثرت سے آئے گا۔

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

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

پہلی سیریز - ہم max_wal_size کو تبدیل کرتے ہیں۔ اور ہم بڑے پیمانے پر آپریشن کر رہے ہیں۔ سب سے پہلے، ہم اسے 1 گیگا بائٹ کی ڈیفالٹ سیٹنگ پر کرتے ہیں۔ اور ہم لاکھوں لائنوں کو بڑے پیمانے پر ڈیلیٹ کرتے ہیں۔

آپ دیکھ سکتے ہیں کہ یہ ہمارے لیے کتنا مشکل ہے۔ ہم دیکھتے ہیں کہ ڈسک IO بہت خراب ہے۔ ہم دیکھتے ہیں کہ ہم نے کتنی WALs بنائی ہیں، کیونکہ یہ بہت اہم ہے۔ دیکھتے ہیں کتنی بار چوکی ہوئی۔ اور ہم دیکھتے ہیں کہ یہ اچھا نہیں ہے۔

اگلا ہم max_wal_size میں اضافہ کرتے ہیں۔ ہم دہراتے ہیں۔ ہم بڑھاتے ہیں، ہم دہراتے ہیں۔ اور کئی بار۔ اصولی طور پر، 10 پوائنٹس اچھے ہیں، جہاں 1، 2، 4، 8 گیگا بائٹس۔ اور ہم ایک خاص نظام کے رویے کو دیکھتے ہیں۔ یہ واضح ہے کہ یہاں سامان آن پروڈ کی طرح ہونا چاہئے۔ آپ کے پاس ایک جیسی ڈسکیں، اتنی ہی میموری اور ایک جیسی پوسٹگریس سیٹنگز ہونی چاہئیں۔

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

روسی میں چیک پوائنٹ چیک پوائنٹ ہیں۔

مثال: اشاریہ کے لحاظ سے کئی ملین قطاریں حذف کریں، صفحوں میں صفیں "بکھری ہوئی" ہیں۔

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

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

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

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

کیوں؟

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

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

اور ہم اسے کئی بار بچانے کے لیے چوکی پر مجبور کریں گے۔ اس کے لیے بے کار آپریشن کیسے ہوں گے۔

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

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

اس کے بعد کی تبدیلیوں میں، صرف ایک مخصوص ٹوپل ہوگا، لیکن پہلی بار ہم سب کچھ لکھتے ہیں۔

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

اور، اس کے مطابق، ہمارے پاس دو فالتو چیزیں ہیں۔

اگر ہم max_wal_size کو بڑھاتے ہیں تو پتہ چلتا ہے کہ ہم اسے چیک پوائنٹ اور وال رائٹر دونوں کے لیے آسان بناتے ہیں۔ اور یہ بہت اچھا ہے۔

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

ہم ایک آپریشن کرتے ہیں اور دیکھتے ہیں کہ چیک پوائنٹ کب مکمل ہونے والا ہے، ہم جان بوجھ کر -9 پوسٹگریس کو مار ڈالتے ہیں۔

اور اس کے بعد ہم اسے دوبارہ شروع کرتے ہیں، اور دیکھتے ہیں کہ یہ اس آلات پر کتنی دیر تک چڑھے گا، یعنی اس خراب صورتحال میں یہ کتنا دوبارہ کام کرے گا۔

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

ہم اس طرح کی صورتحال کو مختلف max_wal_size کے سائز کے لیے ناپتے ہیں اور سمجھتے ہیں کہ اگر max_wal_size 64 گیگا بائٹس ہے، تو ایک دوہری بدترین صورت میں ہم 10 منٹ تک چڑھ جائیں گے۔ اور ہم سوچتے ہیں کہ یہ ہمارے لیے مناسب ہے یا نہیں۔ یہ ایک کاروباری سوال ہے۔ ہمیں یہ تصویر کاروباری فیصلوں کے ذمہ داروں کو دکھانے اور پوچھنے کی ضرورت ہے، "کسی مسئلے کی صورت میں ہم زیادہ سے زیادہ کتنی دیر تک لیٹ سکتے ہیں؟ کیا ہم بدترین صورتحال میں 3-5 منٹ تک لیٹ سکتے ہیں؟ اور آپ فیصلہ کریں۔

اور یہاں ایک دلچسپ نکتہ ہے۔ ہمارے پاس کانفرنس میں پیٹرونی کے بارے میں کچھ رپورٹس ہیں۔ اور شاید آپ اسے استعمال کر رہے ہیں۔ یہ پوسٹگریس کے لیے آٹو فیل اوور ہے۔ GitLab اور Data Egret نے اس بارے میں بات کی۔

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

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

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

تکرار کرنے کے لیے، مثال کے طور پر، max_wal_size =1, 8، آپ کو بڑے پیمانے پر آپریشن کو کئی بار دہرانے کی ضرورت ہے۔ تم نے کر دکھایا. اور اسی بنیاد پر آپ اسے دوبارہ کرنا چاہتے ہیں، لیکن آپ نے پہلے ہی سب کچھ حذف کر دیا ہے۔ کیا کرنا ہے؟

میں اپنے حل کے بارے میں بعد میں بات کروں گا، ایسے حالات میں اعادہ کرنے کے لیے ہم کیا کرتے ہیں۔ اور یہ سب سے صحیح طریقہ ہے۔

لیکن اس معاملے میں ہم خوش قسمت تھے۔ اگر، جیسا کہ یہاں لکھا ہے "BEGIN، DELETE، ROLLBACK"، تو ہم DELETE کو دہرا سکتے ہیں۔ یعنی اگر ہم نے اسے خود منسوخ کر دیا ہے تو ہم اسے دوبارہ کر سکتے ہیں۔ اور جسمانی طور پر آپ پر ڈیٹا اسی جگہ پڑے گا۔ آپ کو کوئی پھولا بھی نہیں آتا۔ آپ اس طرح کے DELETEs پر اعادہ کر سکتے ہیں۔

ROLLBACK کے ساتھ یہ DELETE چیک پوائنٹ ٹیوننگ کے لیے مثالی ہے، یہاں تک کہ اگر آپ کے پاس مناسب طریقے سے تعینات کردہ ڈیٹا بیس لیبز نہ ہوں۔

ہم نے ایک کالم "i" کے ساتھ ایک پلیٹ بنائی۔ پوسٹگریس میں یوٹیلیٹی کالم ہیں۔ وہ پوشیدہ ہیں جب تک کہ خاص طور پر طلب نہ کیا جائے۔ یہ ہیں: ctid، xmid، xmax۔

Ctid ایک جسمانی پتہ ہے۔ صفر صفحہ، صفحہ میں پہلا ٹوپل۔

یہ دیکھا جا سکتا ہے کہ ROOLBACK کے بعد ٹیپل اسی جگہ پر رہا۔ یعنی ہم دوبارہ کوشش کر سکتے ہیں، یہ اسی طرح برتاؤ کرے گا۔ یہ بنیادی چیز ہے۔

Xmax tuple کی موت کا وقت ہے. اس پر مہر لگائی گئی تھی، لیکن پوسٹگریس جانتا ہے کہ لین دین واپس کر دیا گیا تھا، اس لیے اس سے کوئی فرق نہیں پڑتا کہ یہ 0 ہے یا یہ ایک رول بیک ٹرانزیکشن ہے۔ اس سے پتہ چلتا ہے کہ DELETE پر اعادہ کرنا اور سسٹم کے رویے کے بلک آپریشنز کو چیک کرنا ممکن ہے۔ آپ غریبوں کے لیے ڈیٹا بیس لیب بنا سکتے ہیں۔

یہ پروگرامرز کے بارے میں ہے۔ DBA کے بارے میں بھی، وہ ہمیشہ اس کے لیے پروگرامرز کو ڈانٹتے ہیں: "آپ اتنے طویل اور مشکل آپریشن کیوں کر رہے ہیں؟"۔ یہ ایک بالکل مختلف کھڑا موضوع ہے۔ پہلے بھی انتظامیہ تھی، اب ترقی ہوگی۔

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

توڑنا کیوں ضروری ہے؟

• اگر ہم دیکھتے ہیں کہ ڈسک مشکل ہے، تو آئیے اسے سست کر دیں۔ اور اگر ہم ٹوٹے ہوئے ہیں، تو ہم وقفے شامل کر سکتے ہیں، ہم تھروٹلنگ کو کم کر سکتے ہیں۔

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

https://postgres.ai/products/joe/

یہ دلچسپ ہے. میں اکثر دیکھتا ہوں کہ ڈویلپر پوچھتے ہیں: "مجھے کس پیک سائز کا انتخاب کرنا چاہئے؟"۔

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

میرے پاس ایک بہت ہی آسان اصول ہے: جتنا ہو سکے لے لو، لیکن فی سیکنڈ پر عمل درآمد نہ کرو۔

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

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

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

ویسے، میں جس چیز کے بارے میں بات کر رہا ہوں وہ صرف DELETE کے بارے میں نہیں ہے۔ جیسا کہ آپ نے اندازہ لگایا ہے، یہ اعداد و شمار پر کسی بھی بڑی تعداد میں کارروائیاں ہیں۔

اور ہم دیکھتے ہیں کہ منصوبہ بہترین ہے۔ آپ انڈیکس اسکین دیکھ سکتے ہیں، صرف انڈیکس اسکین اس سے بھی بہتر ہے۔ اور ہمارے پاس تھوڑا سا ڈیٹا شامل ہے۔ اور ایک سیکنڈ سے بھی کم پورا ہوتا ہے۔ سپر

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

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

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

https://docs.gitlab.com/ee/development/background_migrations.html

تقسیم کی حکمت عملی کیا ہیں؟ میں 3 مختلف تقسیم کرنے کی حکمت عملی دیکھ رہا ہوں جو پیک پر ڈویلپر استعمال کر رہے ہیں۔

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

دوسری حکمت عملی ایک متوازن نقطہ نظر ہے۔ یہ Gitlab میں استعمال ہوتا ہے۔ انہوں نے لے کر میز کو سکین کیا۔ ہم نے شناختی پیک کی حدود تلاش کیں تاکہ ہر پیک میں بالکل 10 ریکارڈ ہوں۔ اور انہیں ایک قطار میں کھڑا کریں۔ اور پھر ہم عمل کرتے ہیں۔ آپ اسے متعدد دھاگوں میں کر سکتے ہیں۔

پہلی حکمت عملی میں بھی، ویسے، آپ اسے کئی تھریڈز میں کر سکتے ہیں۔ یہ مشکل نہیں ہے۔

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

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

عام طور پر صرف انڈیکس اسکین انڈیکس اسکین سے تیز ہوتا ہے۔

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

ہمیں اس کی ضرورت کیوں ہے؟ یہ وہی ہے جس کی ہمیں واپس رپورٹ کرنے کی ضرورت ہے۔ اب ہم نے حقیقت میں بہت سی لائنوں کو حذف کر دیا ہے۔ اور ہمارے پاس ID کی طرف سے یا اس طرح create_at کے ذریعے سرحدیں ہیں۔ آپ کم سے کم، زیادہ سے زیادہ کر سکتے ہیں۔ کچھ اور بھی کیا جا سکتا ہے۔ آپ یہاں بہت کچھ کر سکتے ہیں۔ اور یہ نگرانی کے لیے بہت آسان ہے۔

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

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

لیکن یہ سب سے بہترین حکمت عملی ہے، کس طرح بیچوں میں تقسیم کیا جائے اور ایک درخواست کے ساتھ بیچوں کو گولی مار دی جائے، تھوڑا سا حذف کیا جائے، وغیرہ۔

طویل لین دین https://gitlab.com/snippets/1890447

بلاک شدہ آٹو ویکیوم - https://gitlab.com/snippets/1889668

مسدود کرنے کا مسئلہ - https://gitlab.com/snippets/1890428

غلطی #5 ایک بڑی غلطی ہے۔ Okmeter سے نکولائی نے Postgres کی نگرانی کے بارے میں بات کی۔ مثالی پوسٹگریس مانیٹرنگ، بدقسمتی سے، موجود نہیں ہے۔ کچھ قریب ہیں، کچھ دور ہیں۔ Okmeter کامل ہونے کے کافی قریب ہے، لیکن بہت کچھ غائب ہے اور اسے شامل کرنے کی ضرورت ہے۔ آپ کو اس کے لیے تیار رہنے کی ضرورت ہے۔

مثال کے طور پر، مردہ ٹیپلز کی بہترین نگرانی کی جاتی ہے۔ اگر آپ کے پاس میز میں بہت ساری مردہ چیزیں ہیں، تو کچھ غلط ہے. بہتر ہے کہ اب رد عمل کا اظہار کریں، ورنہ تنزلی ہو سکتی ہے، اور ہم لیٹ سکتے ہیں۔ یہ ہوتا ہے.

اگر ایک بڑا IO ہے، تو یہ واضح ہے کہ یہ اچھا نہیں ہے.

طویل لین دین بھی۔ OLTP پر طویل لین دین کی اجازت نہیں ہونی چاہیے۔ اور یہاں ایک ٹکڑا کا لنک ہے جو آپ کو یہ ٹکڑا لینے اور طویل لین دین کی کچھ ٹریکنگ کرنے کی اجازت دیتا ہے۔

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

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

اور بلاکس کا مسئلہ۔ بلاک درختوں کا جنگل۔ میں کسی سے کچھ لینا اور اسے بہتر کرنا پسند کرتا ہوں۔ یہاں میں نے ڈیٹا ایگریٹ سے ایک ٹھنڈا تکرار کرنے والا CTE لیا جو لاک درختوں کا جنگل دکھاتا ہے۔ یہ ایک اچھا تشخیصی ٹول ہے۔ اور اس کی بنیاد پر آپ مانیٹرنگ بھی بنا سکتے ہیں۔ لیکن یہ احتیاط سے کیا جانا چاہئے. آپ کو اپنے لیے ایک چھوٹا سا بیان_ٹائم آؤٹ کرنے کی ضرورت ہے۔ اور لاک_ٹائم آؤٹ مطلوبہ ہے۔

بعض اوقات یہ تمام غلطیاں جمع میں ہوتی ہیں۔

میری رائے میں یہاں بنیادی غلطی تنظیمی ہے۔ یہ تنظیمی ہے، کیونکہ تکنیک نہیں کھینچتی ہے۔ یہ نمبر 2 ہے - انہوں نے غلط جگہ پر چیک کیا۔

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

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

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

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

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

فرض کریں کہ آپ کے پاس 10 ٹیرا بائٹس ہیں، ہم ڈیٹا بیس لیب کو بھی 10 ٹیرا بائٹس بناتے ہیں۔ اور بیک وقت 10 ٹیرا بائٹ ڈیٹا بیس کے ساتھ، 10 ڈویلپر بیک وقت کام کر سکتے ہیں۔ ہر کوئی جو چاہے کر سکتا ہے۔ حذف کر سکتے ہیں، چھوڑ سکتے ہیں، وغیرہ۔ ہم کل اس پر بات کریں گے۔

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

مثال: 5 ٹیرا بائٹ ڈیٹا بیس، 30 سیکنڈ سے بھی کم وقت میں ایک کاپی حاصل کرنا۔ اور یہ سائز پر بھی منحصر نہیں ہے، یعنی اس سے کوئی فرق نہیں پڑتا کہ کتنے ٹیرا بائٹس ہیں۔

آج آپ جا سکتے ہیں۔ postgres.ai اور ہمارے ٹولز میں کھودیں۔ آپ یہ دیکھنے کے لیے رجسٹر کر سکتے ہیں کہ وہاں کیا ہے۔ آپ اس بوٹ کو انسٹال کر سکتے ہیں۔ یہ مفت ہے. لکھیں۔

آپ کے سوالات

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

یہ بہت اچھا طریقہ ہے اور بہت اچھا کام ہے۔ یہ pg_repack کے کام سے بہت ملتا جلتا ہے، یہ اس سے بہت ملتا جلتا ہے جب آپ IDs 4 بائٹس بناتے ہیں۔ بہت سے فریم ورک نے کچھ سال پہلے یہ کیا تھا، اور صرف پلیٹیں بڑی ہو گئی ہیں، اور انہیں 8 بائٹس میں تبدیل کرنے کی ضرورت ہے۔

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

اگر آپ GitHub پر pg_repack کو دیکھیں، تو وہاں، جب ایک ID کو int 4 سے int 8 میں تبدیل کرنے کا کام تھا، تو خود pg_repack کو استعمال کرنے کا خیال آیا۔ یہ بھی ممکن ہے، لیکن یہ تھوڑا سا ہیک ہے، لیکن یہ اس کے لیے بھی کام کرے گا۔ آپ pg_repack استعمال کرنے والے محرک میں مداخلت کر سکتے ہیں اور وہاں کہہ سکتے ہیں: "ہمیں اس ڈیٹا کی ضرورت نہیں ہے"، یعنی ہم صرف وہی منتقل کرتے ہیں جس کی ہمیں ضرورت ہے۔ اور پھر وہ صرف سوئچ کرتا ہے اور بس۔

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

بلوٹ موجود نہیں ہے، یہ ایک اچھا نقطہ نظر ہے. لیکن میں جانتا ہوں کہ اس کے لیے ایک آٹومیشن تیار کرنے کی کوششیں ہو رہی ہیں، یعنی ایک آفاقی حل تیار کرنا۔ میں آپ کو اس آٹومیشن کے ساتھ رابطے میں رکھ سکتا ہوں۔ یہ Python میں لکھا ہوا ہے، جو اچھی بات ہے۔

میں MySQL کی دنیا سے تھوڑا سا ہوں، اس لیے سننے آیا ہوں۔ اور ہم یہ طریقہ استعمال کرتے ہیں۔

لیکن یہ صرف اس صورت میں ہے جب ہمارے پاس 90٪ ہے۔ اگر ہمارے پاس 5% ہے، تو اسے استعمال کرنا بہت اچھا نہیں ہے۔

رپورٹ کے لیے شکریہ! اگر پروڈ کی مکمل کاپی بنانے کے لیے کوئی وسائل نہیں ہیں، تو کیا بوجھ یا سائز کا حساب لگانے کے لیے کوئی الگورتھم یا فارمولا ہے؟

اچھا سوال. اب تک، ہم ملٹی ٹیرا بائٹ ڈیٹا بیس تلاش کرنے کے قابل ہیں۔ یہاں تک کہ اگر وہاں کا ہارڈ ویئر ایک جیسا نہیں ہے، مثال کے طور پر، کم میموری، کم پروسیسر اور ڈسک بالکل ایک جیسی نہیں ہیں، لیکن پھر بھی ہم ایسا کرتے ہیں۔ اگر بالکل کہیں نہیں ہے، تو آپ کو سوچنے کی ضرورت ہے. مجھے کل تک سوچنے دو، تم آگئے، ہم بات کریں گے، یہ اچھا سوال ہے۔

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

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

اشاریہ جات کے ساتھ ہو گیا۔

میں فرض کر سکتا ہوں کہ وہی چیک پوائنٹ ٹیوننگ خودکار ہو سکتی ہے۔ کسی دن ایسا ہو سکتا ہے۔ لیکن پھر میں واقعی میں سوال نہیں سمجھتا ہوں۔

سوال یہ ہے کہ کیا ترقی کا کوئی ایسا ویکٹر ہے جو ادھر ادھر جاتا ہے اور یہاں آپ کا متوازی چلتا ہے؟ وہ. کیا انہوں نے ابھی تک اس کے بارے میں نہیں سوچا؟

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

اور چیک پوائنٹ ٹیوننگ کے لیے، آپ یہ کر سکتے ہیں: اگر آپ کے پاس ایک ہزار کلسٹرز اور مختلف ہارڈ ویئر، کلاؤڈ میں مختلف ورچوئل مشینیں ہیں، تو آپ ہماری بوٹ استعمال کر سکتے ہیں۔ نینسی آٹومیشن کرو. اور max_wal_size خود بخود آپ کی ٹارگٹ سیٹنگ کے مطابق منتخب ہو جائے گا۔ لیکن بدقسمتی سے اب تک یہ بنیادی طور پر قریب نہیں ہے۔

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

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

رپورٹ کے لیے شکریہ! آپ نے اپنی رپورٹ یہ کہہ کر شروع کی کہ آپ نے غلط ٹیسٹ کیا ہے۔ ہم نے اپنا خیال جاری رکھا کہ ہمیں ایک ہی سامان لینے کی ضرورت ہے، اسی طرح بیس کے ساتھ۔ ہم کہتے ہیں کہ ہم نے ڈویلپر کو ایک بنیاد دی۔ اور اس نے درخواست کی تعمیل کی۔ اور لگتا ہے وہ ٹھیک ہے۔ لیکن وہ لائیو کی جانچ نہیں کرتا، بلکہ لائیو کے لیے، مثال کے طور پر، ہمارے پاس 60-70% کا بوجھ ہے۔ اور یہاں تک کہ اگر ہم اس ٹیوننگ کا استعمال کرتے ہیں، تو یہ بہت اچھا کام نہیں کرتا.

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

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

پوسٹگریس میں آٹو ویکیوم خود بخود یہی کرتا ہے۔

اوہ، کیا وہ کرتا ہے؟

آٹو ویکیوم کچرا جمع کرنے والا ہے۔

آپ کا شکریہ!

رپورٹ کے لیے شکریہ! کیا کوئی آپشن ہے کہ فوری طور پر تقسیم کے ساتھ ڈیٹا بیس کو اس طرح ڈیزائن کیا جائے کہ تمام کوڑا کرکٹ مین ٹیبل سے لے کر سائیڈ تک گندا ہو جائے؟

یقینا have ہے۔

کیا یہ ممکن ہے کہ اپنے آپ کو بچایا جائے اگر ہم نے ایسی میز کو بند کر دیا ہے جسے استعمال نہیں کرنا چاہئے؟

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

ماخذ: www.habr.com