حال ہی میں میں نے آپ کو بتایا کہ کس طرح، معیاری ترکیبیں استعمال کرتے ہوئے PostgreSQL ڈیٹا بیس سے۔ آج ہم بات کریں گے کہ کیسے ریکارڈنگ زیادہ مؤثر طریقے سے کیا جا سکتا ہے ڈیٹا بیس میں کنفیگریشن میں کوئی "ٹوئسٹ" استعمال کیے بغیر - صرف ڈیٹا کے بہاؤ کو صحیح طریقے سے ترتیب دے کر۔
#1 سیکشننگ
یہ کیسے اور کیوں ترتیب دینے کے قابل ہے کے بارے میں ایک مضمون پہلے ہی ہو چکا ہے، یہاں ہم اپنے اندر کچھ طریقوں کو لاگو کرنے کی مشق کے بارے میں بات کریں گے۔ .
"گئے دنوں کی باتیں..."
ابتدائی طور پر، کسی بھی MVP کی طرح، ہمارا پروجیکٹ کافی ہلکے بوجھ کے تحت شروع ہوا تھا - نگرانی صرف ایک درجن انتہائی اہم سرورز کے لیے کی گئی تھی، تمام میزیں نسبتا compact تھیں... لیکن جیسے جیسے وقت گزرتا گیا، نگرانی کیے گئے میزبانوں کی تعداد بڑھتی گئی۔ اور مزید، اور ایک بار پھر ہم نے ایک کے ساتھ کچھ کرنے کی کوشش کی۔ میزیں 1.5TB سائز میں، ہم نے محسوس کیا کہ اگرچہ اس طرح زندگی گزارنا ممکن تھا، لیکن یہ بہت تکلیف دہ تھا۔
اوقات تقریباً مہاکاوی اوقات کی طرح تھے، PostgreSQL 9.x کے مختلف ورژن متعلقہ تھے، اس لیے تمام تقسیم کاری کو "دستی طور پر" کرنا پڑتا تھا۔ ٹیبل وراثت اور محرکات متحرک کے ساتھ روٹنگ EXECUTE.
نتیجہ حل اتنا عالمگیر نکلا کہ اس کا ترجمہ تمام جدولوں میں کیا جا سکتا ہے:
- ایک خالی "ہیڈر" پیرنٹ ٹیبل کا اعلان کیا گیا تھا، جس نے سب کو بیان کیا تھا۔ ضروری اشاریہ جات اور محرکات.
- کلائنٹ کے نقطہ نظر سے ریکارڈ "روٹ" ٹیبل میں بنایا گیا تھا، اور اندرونی طور پر استعمال کیا گیا تھا۔ روٹنگ ٹرگر
BEFORE INSERTریکارڈ کو "جسمانی طور پر" مطلوبہ حصے میں داخل کیا گیا تھا۔ اگر ابھی تک ایسی کوئی چیز نہیں تھی، تو ہم نے ایک استثناء پکڑا اور... - … کا استعمال کرتے ہوئے پیرنٹ ٹیبل کے سانچے کی بنیاد پر بنایا گیا تھا۔ مطلوبہ تاریخ پر پابندی کے ساتھ سیکشنتاکہ جب ڈیٹا کو بازیافت کیا جائے تو صرف اس میں پڑھائی کی جاتی ہے۔
PG10: پہلی کوشش
لیکن وراثت کے ذریعے تقسیم کرنا تاریخی طور پر ایک فعال تحریری سلسلے یا چائلڈ پارٹیشنز کی ایک بڑی تعداد سے نمٹنے کے لیے موزوں نہیں ہے۔ مثال کے طور پر، آپ یاد کر سکتے ہیں کہ مطلوبہ حصے کو منتخب کرنے کا الگورتھم تھا۔ چوکور پیچیدگیکہ یہ 100+ سیکشنز کے ساتھ کام کرتا ہے، آپ خود سمجھتے ہیں کہ کیسے...
PG10 میں اس صورتحال کو سپورٹ کو لاگو کرکے بہت بہتر بنایا گیا۔ . لہذا، ہم نے اسٹوریج کو منتقل کرنے کے بعد فوری طور پر اسے لاگو کرنے کی کوشش کی، لیکن ...
جیسا کہ دستی کو کھودنے کے بعد یہ نکلا، اس ورژن میں مقامی طور پر تقسیم شدہ جدول ہے:
- انڈیکس کی تفصیل کی حمایت نہیں کرتا ہے۔
- اس پر محرکات کی حمایت نہیں کرتا ہے۔
- کسی کی "اولاد" نہیں ہو سکتی
- حمایت نہیں کرتے
INSERT ... ON CONFLICT - خود بخود سیکشن نہیں بنا سکتا
ریک کے ساتھ پیشانی پر تکلیف دہ ضرب لگنے کے بعد، ہم نے محسوس کیا کہ درخواست میں ترمیم کیے بغیر ایسا کرنا ناممکن ہو گا، اور مزید تحقیق کو چھ ماہ کے لیے ملتوی کر دیا۔
PG10: دوسرا موقع
لہذا، ہم نے ایک ایک کرکے پیدا ہونے والے مسائل کو حل کرنا شروع کیا:
- کیونکہ محرکات اور
ON CONFLICTہم نے محسوس کیا کہ ہمیں اب بھی ان کی یہاں اور وہاں ضرورت ہے، لہذا ہم نے ان پر کام کرنے کے لیے ایک درمیانی مرحلہ بنایا پراکسی ٹیبل. - "روٹنگ" سے نجات ملی محرکات میں - یعنی سے
EXECUTE. - انہوں نے اسے الگ سے نکالا۔ تمام اشاریہ جات کے ساتھ ٹیمپلیٹ ٹیبلتاکہ وہ پراکسی ٹیبل میں بھی موجود نہ ہوں۔
آخر کار، اس سب کے بعد، ہم نے مرکزی میز کو مقامی طور پر تقسیم کیا۔ ایک نئے حصے کی تخلیق ابھی بھی درخواست کے ضمیر پر چھوڑی گئی ہے۔
"ساونگ" لغات
جیسا کہ کسی بھی تجزیاتی نظام میں، ہمارے پاس بھی تھا۔ "حقائق" اور "کٹ" (لغات)۔ ہمارے معاملے میں، اس صلاحیت میں انہوں نے کام کیا، مثال کے طور پر، اسی طرح کے سست سوالات یا خود سوال کا متن۔
"حقائق" کو پہلے ہی ایک طویل عرصے سے دن کے حساب سے سیکشن کیا گیا تھا، لہذا ہم نے پرسکون طریقے سے فرسودہ حصوں کو حذف کر دیا، اور انہوں نے ہمیں پریشان نہیں کیا (لاگز!) لیکن لغات کے ساتھ ایک مسئلہ تھا...
یہ کہنا نہیں ہے کہ ان میں سے بہت سارے تھے، لیکن تقریبا 100TB "حقائق" کے نتیجے میں 2.5TB لغت بنی۔. آپ اس طرح کے ٹیبل سے کسی بھی چیز کو آسانی سے حذف نہیں کرسکتے ہیں، آپ اسے مناسب وقت میں کمپریس نہیں کرسکتے ہیں، اور اس پر لکھنا آہستہ آہستہ آہستہ ہوتا چلا گیا۔
ایک لغت کی طرح... اس میں، ہر اندراج کو ایک بار پیش کیا جانا چاہیے... اور یہ درست ہے، لیکن!... کوئی ہمیں رکھنے سے نہیں روک رہا ہے۔ ہر دن کے لیے ایک الگ لغت! جی ہاں، یہ ایک خاص فالتو پن لاتا ہے، لیکن یہ اجازت دیتا ہے:
- تیزی سے لکھیں/پڑھیں۔ چھوٹے حصے کے سائز کی وجہ سے
- کم میموری استعمال کریں مزید کمپیکٹ انڈیکس کے ساتھ کام کرکے
- کم ڈیٹا ذخیرہ کریں فوری طور پر پرانے کو ہٹانے کی صلاحیت کی وجہ سے
اقدامات کے پورے کمپلیکس کے نتیجے میں CPU لوڈ ~30%، ڈسک لوڈ ~50% کم ہوا:
اسی وقت، ہم نے ڈیٹا بیس میں بالکل وہی چیز لکھنا جاری رکھا، بس کم بوجھ کے ساتھ۔
#2 ڈیٹا بیس کا ارتقاء اور ری فیکٹرنگ
لہذا ہم نے جو کچھ ہمارے پاس ہے اس پر طے کیا۔ ہر دن کا اپنا حصہ ہوتا ہے۔ ڈیٹا کے ساتھ. دراصل، CHECK (dt = '2018-10-12'::date) — اور ایک تقسیم کرنے والی کلید ہے اور ریکارڈ کے لیے مخصوص حصے میں آنے کی شرط ہے۔
چونکہ ہماری سروس میں تمام رپورٹس ایک مخصوص تاریخ کے تناظر میں بنائی گئی ہیں، اس لیے ان کے لیے "غیر تقسیم شدہ اوقات" سے لے کر اب تک کے اشاریہ جات ہر قسم کے ہیں۔ (سرور، تاریخپلان ٹیمپلیٹ), (سرور، تاریخ، پلان نوڈ), (تاریخ, ایرر کلاس، سرور)، ...
لیکن اب وہ ہر طبقے پر رہتے ہیں۔ آپ کی کاپیاں ہر اس طرح کا اشاریہ... اور ہر ایک حصے کے اندر تاریخ ایک مستقل ہے... یہ پتہ چلتا ہے کہ اب ہم ہر اس طرح کے انڈیکس میں ہیں۔ صرف ایک مستقل درج کریں۔ فیلڈز میں سے ایک کے طور پر، جو اس کا حجم اور اس کے لیے تلاش کا وقت دونوں بڑھاتا ہے، لیکن کوئی نتیجہ نہیں لاتا۔ انہوں نے ریک کو اپنے پاس چھوڑ دیا، افوہ...
اصلاح کی سمت واضح ہے - سادہ تمام اشاریہ جات سے ڈیٹ فیلڈ کو ہٹا دیں۔ تقسیم شدہ میزوں پر۔ ہماری جلدوں کو دیکھتے ہوئے، فائدہ کے بارے میں ہے 1TB/ہفتہ!
اب نوٹ کرتے ہیں کہ اس ٹیرا بائٹ کو اب بھی کسی نہ کسی طرح ریکارڈ کرنا تھا۔ یعنی ہم بھی ڈسک اب کم لوڈ ہونا چاہئے! یہ تصویر صفائی سے حاصل ہونے والے اثر کو واضح طور پر ظاہر کرتی ہے، جس کے لیے ہم نے ایک ہفتہ وقف کیا تھا:
#3 چوٹی کا بوجھ "پھیلنا"
بھاری بھرکم سسٹمز کی بڑی پریشانیوں میں سے ایک ہے۔ بے کار مطابقت پذیری کچھ آپریشن جن کی ضرورت نہیں ہے۔ کبھی کبھی "کیونکہ انہوں نے نوٹس نہیں لیا"، کبھی کبھی "یہ اس طرح آسان تھا"، لیکن جلد یا بدیر آپ کو اس سے چھٹکارا حاصل کرنا ہوگا۔
آئیے پچھلی تصویر کو زوم کریں اور دیکھیں کہ ہمارے پاس ایک ڈسک ہے۔ ڈبل طول و عرض کے ساتھ بوجھ کے نیچے "پمپ" ملحقہ نمونوں کے درمیان، جو واضح طور پر "اعداد و شمار کے لحاظ سے" ایسی متعدد کارروائیوں کے ساتھ نہیں ہونا چاہئے:
یہ حاصل کرنا کافی آسان ہے۔ ہم نے پہلے ہی نگرانی شروع کر دی ہے۔ تقریباً 1000 سرورز، ہر ایک کو الگ الگ منطقی دھاگے کے ذریعے پروسیس کیا جاتا ہے، اور ہر تھریڈ جمع شدہ معلومات کو ایک مخصوص فریکوئنسی پر ڈیٹا بیس کو بھیجنے کے لیے دوبارہ سیٹ کرتا ہے، کچھ اس طرح:
setInterval(sendToDB, interval)یہاں مسئلہ بالکل اس حقیقت میں مضمر ہے۔ تمام تھریڈز تقریباً ایک ہی وقت میں شروع ہوتے ہیں۔، لہذا ان کے بھیجنے کے اوقات تقریبا ہمیشہ "مقابلے کے مطابق" ہوتے ہیں۔ افوہ #2...
خوش قسمتی سے، یہ ٹھیک کرنا بہت آسان ہے، ایک "بے ترتیب" رن اپ شامل کرنا وقت کی طرف سے:
setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))#4 ہم جس چیز کی ضرورت ہے اسے محفوظ کرتے ہیں۔
تیسرا روایتی ہائی لوڈ کا مسئلہ ہے۔ کوئی ذخیرہ نہیں وہ کہاں ہے کر سکتا تھا بننا.
مثال کے طور پر، ہم نے پلان نوڈس کے لحاظ سے تجزیہ کرنا ممکن بنایا (یہ سب Seq Scan on users)، لیکن فوری طور پر سوچیں کہ وہ، زیادہ تر حصے کے لیے، ایک جیسے ہیں - وہ بھول گئے۔
نہیں، یقینا، ڈیٹا بیس پر دوبارہ کچھ نہیں لکھا جاتا، اس سے ٹرگر کاٹ جاتا ہے۔ INSERT ... ON CONFLICT DO NOTHING. لیکن یہ ڈیٹا اب بھی ڈیٹا بیس تک پہنچتا ہے، اور یہ غیر ضروری ہے۔ تنازعات کی جانچ کرنے کے لیے پڑھنا کرنا ہے. افوہ #3...
کیشنگ کو فعال کرنے سے پہلے/بعد ڈیٹا بیس کو بھیجے گئے ریکارڈز کی تعداد میں فرق واضح ہے:
اور یہ سٹوریج کے بوجھ میں کمی کے ساتھ ہے:
مجموعی طور پر
"ٹیرابائٹ فی دن" صرف خوفناک لگتا ہے۔ اگر آپ سب کچھ ٹھیک کرتے ہیں، تو یہ صرف ہے 2^40 بائٹس / 86400 سیکنڈ = ~12.5MB/sکہ یہاں تک کہ ڈیسک ٹاپ IDE سکرو بھی پکڑے گئے۔ 🙂
لیکن سنجیدگی سے، دن کے وقت بوجھ کے دس گنا "ترچھی" کے ساتھ بھی، آپ جدید SSDs کی صلاحیتوں کو آسانی سے پورا کر سکتے ہیں۔
ماخذ: www.habr.com