تعارف
ہیلو. میں ningenMe ہوں، ویب ڈویلپر۔
جیسا کہ عنوان کہتا ہے، میری کہانی MySQL میں 300 ملین ریکارڈز کو جسمانی طور پر حذف کرنے کی کہانی ہے۔
مجھے اس میں دلچسپی پیدا ہوئی، اس لیے میں نے ایک یاد دہانی (ہدایات) بنانے کا فیصلہ کیا۔
ہوم - الرٹ
میں جس بیچ سرور کا استعمال اور دیکھ بھال کرتا ہوں اس کا باقاعدہ عمل ہوتا ہے جو MySQL سے دن میں ایک بار پچھلے مہینے کا ڈیٹا اکٹھا کرتا ہے۔
عام طور پر یہ عمل تقریباً 1 گھنٹے میں مکمل ہو جاتا ہے، لیکن اس بار یہ 7 یا 8 گھنٹے تک مکمل نہیں ہوا، اور الرٹ پاپ اپ ہونا بند نہیں ہوا...
وجہ تلاش کرنا
میں نے عمل کو دوبارہ شروع کرنے اور لاگز کو دیکھنے کی کوشش کی، لیکن مجھے کچھ غلط نظر نہیں آیا۔
استفسار درست طریقے سے ترتیب دیا گیا تھا۔ لیکن جب میں نے سوچا کہ کیا غلط ہو رہا ہے تو مجھے احساس ہوا کہ ڈیٹا بیس کا سائز کافی بڑا ہے۔
hoge_table | 350'000'000 |350 ملین ریکارڈ۔ ایسا لگتا ہے کہ انڈیکسنگ صحیح طریقے سے کام کر رہی ہے، بس بہت سست۔
ہر ماہ مطلوبہ ڈیٹا اکٹھا کرنا تقریباً 12 ریکارڈز تھا۔ ایسا لگتا ہے کہ سلیکٹ کمانڈ میں کافی وقت لگا اور لین دین کافی عرصے سے مکمل نہیں ہوا۔
DB
یہ بنیادی طور پر ایک میز ہے جو ہر روز تقریباً 400 اندراجات سے بڑھتا ہے۔ ڈیٹا بیس کو صرف پچھلے مہینے کا ڈیٹا اکٹھا کرنا تھا، اس لیے توقع کی جا رہی تھی کہ یہ ڈیٹا کی اس مقدار کو برداشت کرے گا، لیکن بدقسمتی سے، روٹیٹ آپریشن شامل نہیں تھا۔
یہ ڈیٹا بیس میرے ذریعہ تیار نہیں کیا گیا تھا۔ میں نے اسے ایک اور ڈویلپر سے لیا، لہذا یہ اب بھی تکنیکی قرض کی طرح محسوس ہوا۔
ایک وقت ایسا آیا جب روزانہ داخل کیے جانے والے ڈیٹا کا حجم بڑا ہو گیا اور آخر کار اپنی حد کو پہنچ گیا۔ یہ فرض کیا جاتا ہے کہ ڈیٹا کی اتنی بڑی مقدار کے ساتھ کام کرتے وقت، انہیں الگ کرنا ضروری ہوگا، لیکن بدقسمتی سے ایسا نہیں کیا گیا۔
اور پھر میں حرکت میں آگیا۔
تصحیح
خود ڈیٹا بیس کا سائز کم کرنا اور اس پر کارروائی کے لیے وقت کو کم کرنا بجائے خود منطق کو تبدیل کرنا زیادہ عقلی تھا۔
اگر آپ 300 ملین ریکارڈز کو مٹا دیتے ہیں تو صورتحال میں نمایاں تبدیلی آنی چاہیے، اس لیے میں نے ایسا کرنے کا فیصلہ کیا... ہاں، میں نے سوچا کہ یہ ضرور کام کرے گا۔
ایکشن 1
ایک قابل اعتماد بیک اپ تیار کرنے کے بعد، میں نے بالآخر درخواستیں بھیجنا شروع کر دیں۔
''درخواست بھیجنا''
DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';"…"
"…"
"ہمم... کوئی جواب نہیں۔ شاید اس عمل میں کافی وقت لگے؟ — میں نے سوچا، لیکن صرف اس صورت میں، میں نے گرافانا کو دیکھا اور دیکھا کہ ڈسک کا بوجھ بہت تیزی سے بڑھ رہا ہے۔
"خطرناک،" میں نے دوبارہ سوچا اور فوراً درخواست روک دی۔
ایکشن 2
ہر چیز کا تجزیہ کرنے کے بعد، میں نے محسوس کیا کہ ڈیٹا کا حجم اتنا بڑا ہے کہ ہر چیز کو ایک ساتھ حذف نہیں کیا جا سکتا۔
میں نے ایک اسکرپٹ لکھنے کا فیصلہ کیا جو تقریباً 1 ریکارڈز کو حذف کر سکے اور اسے لانچ کیا۔
''میں اسکرپٹ کو نافذ کرتا ہوں''
’’اب یہ ضرور کام کرے گا،‘‘ میں نے سوچا۔
ایکشن 3
دوسرا طریقہ کارگر ثابت ہوا، لیکن یہ بہت محنت طلب نکلا۔
ہر چیز کو احتیاط سے کرنے میں، غیر ضروری اعصاب کے بغیر، تقریباً دو ہفتے لگیں گے۔ لیکن پھر بھی، یہ منظر نامہ سروس کی ضروریات کو پورا نہیں کرتا تھا، لہذا ہمیں اس سے دور ہونا پڑا۔
تو یہ ہے جو میں نے کرنے کا فیصلہ کیا ہے:
ٹیبل کو کاپی کریں اور اس کا نام تبدیل کریں۔
پچھلے مرحلے سے، میں نے محسوس کیا کہ ڈیٹا کی اتنی بڑی مقدار کو حذف کرنے سے اتنا ہی بڑا بوجھ پیدا ہوتا ہے۔ لہذا میں نے داخل کرنے کا استعمال کرتے ہوئے شروع سے ایک نیا ٹیبل بنانے کا فیصلہ کیا اور اس ڈیٹا کو منتقل کرنے کا فیصلہ کیا جسے میں اس میں حذف کرنے جا رہا ہوں۔
| hoge_table | 350'000'000|
| tmp_hoge_table | 50'000'000|اگر آپ نئے ٹیبل کو اوپر کے سائز کے برابر بناتے ہیں، تو ڈیٹا پروسیسنگ کی رفتار بھی 1/7 تیز ہوجائے گی۔
ٹیبل بنانے اور اس کا نام تبدیل کرنے کے بعد، میں نے اسے ماسٹر ٹیبل کے طور پر استعمال کرنا شروع کیا۔ اب اگر میں 300 ملین ریکارڈ کے ساتھ ٹیبل چھوڑ دوں تو سب کچھ ٹھیک ہو جائے گا۔
مجھے پتہ چلا کہ ٹرنکیٹ یا ڈراپ ڈیلیٹ کے مقابلے میں کم اوور ہیڈ بناتا ہے اور اس طریقہ کو استعمال کرنے کا فیصلہ کیا۔
تکمیل
''درخواست بھیجنا''
INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';
"…"
"…"
"ایم...؟"
ایکشن 4
میں نے سوچا کہ پچھلا خیال کام کرے گا، لیکن داخل کی درخواست بھیجنے کے بعد، متعدد غلطیاں ظاہر ہوئیں۔ MySQL معاف کرنے والا نہیں ہے۔
میں پہلے ہی اتنا تھکا ہوا تھا کہ میں نے سوچنا شروع کر دیا کہ میں اب یہ کام نہیں کرنا چاہتا۔
میں نے بیٹھ کر سوچا اور محسوس کیا کہ شاید ایک وقت کے لیے بہت زیادہ داخل سوالات تھے...
میں نے ڈیٹا کی مقدار کے لیے داخل کی درخواست بھیجنے کی کوشش کی جس پر ڈیٹا بیس کو 1 دن میں کارروائی کرنی چاہیے۔ ہوا!
ٹھیک ہے، اس کے بعد ہم ڈیٹا کی اسی مقدار کے لیے درخواستیں بھیجتے رہتے ہیں۔ چونکہ ہمیں ایک ماہ کا ڈیٹا ہٹانے کی ضرورت ہے، اس لیے ہم اس آپریشن کو تقریباً 35 بار دہراتے ہیں۔
ٹیبل کا نام تبدیل کرنا
یہاں قسمت میری طرف تھی: سب کچھ آسانی سے چلا گیا.
الرٹ غائب ہو گیا۔
بیچ پروسیسنگ کی رفتار میں اضافہ ہوا ہے۔
پہلے اس عمل میں تقریباً ایک گھنٹہ لگتا تھا، اب تقریباً 2 منٹ لگتے ہیں۔
جب مجھے یقین ہو گیا کہ تمام مسائل حل ہو گئے ہیں، میں نے 300 ملین ریکارڈز کو گرا دیا۔ میں نے میز کو حذف کر دیا اور دوبارہ پیدا ہونے کا احساس کیا۔
خلاصہ
میں نے محسوس کیا کہ بیچ پروسیسنگ میں روٹیشن پروسیسنگ غائب تھی، اور یہی بنیادی مسئلہ تھا۔ اس قسم کی تعمیراتی غلطی وقت کے ضیاع کا باعث بنتی ہے۔
کیا آپ ڈیٹا بیس سے ریکارڈ کو حذف کرتے وقت ڈیٹا کی نقل کے دوران بوجھ کے بارے میں سوچتے ہیں؟ آئیے MySQL کو اوورلوڈ نہ کریں۔
جو لوگ ڈیٹا بیس میں مہارت رکھتے ہیں وہ یقینی طور پر ایسی پریشانی کا سامنا نہیں کریں گے۔ آپ کے باقی لوگوں کے لیے، مجھے امید ہے کہ یہ مضمون مفید تھا۔
پڑھنے کا شکریہ!
ہمیں بہت خوشی ہوگی اگر آپ ہمیں بتائیں کہ کیا آپ کو یہ مضمون پسند آیا، کیا ترجمہ واضح ہے، کیا یہ آپ کے لیے مفید تھا؟
ماخذ: www.habr.com