رپورٹ کچھ نقطہ نظر پیش کرتا ہے جو اجازت دیتا ہے ایس کیو ایل استفسارات کی کارکردگی کی نگرانی کریں جب ان میں روزانہ لاکھوں ہوتے ہیں۔، اور سینکڑوں مانیٹر شدہ PostgreSQL سرورز ہیں۔
کون سے تکنیکی حل ہمیں معلومات کی اتنی بڑی مقدار کو مؤثر طریقے سے پروسیس کرنے کی اجازت دیتے ہیں، اور یہ ایک عام ڈویلپر کی زندگی کو کیسے آسان بناتا ہے؟
کون دلچسپی رکھتا ہے؟ مخصوص مسائل اور اصلاح کی مختلف تکنیکوں کا تجزیہ ایس کیو ایل کے سوالات اور PostgreSQL میں عام DBA مسائل کو حل کرنا - آپ بھی کر سکتے ہیں۔ اس موضوع پر.
میرا نام کیرل بورووکوف ہے، میں نمائندگی کرتا ہوں۔ . خاص طور پر، میں اپنی کمپنی میں ڈیٹا بیس کے ساتھ کام کرنے میں مہارت رکھتا ہوں۔
آج میں آپ کو بتاؤں گا کہ ہم استفسارات کو کس طرح بہتر بناتے ہیں، جب آپ کو کسی ایک سوال کی کارکردگی کو "الگ الگ" کرنے کی ضرورت نہیں ہے، بلکہ مسئلہ کو اجتماعی طور پر حل کرنا ہے۔ جب لاکھوں درخواستیں ہیں، اور آپ کو کچھ تلاش کرنے کی ضرورت ہے۔ حل کے نقطہ نظر یہ بڑا مسئلہ.
عام طور پر، ہمارے ایک ملین کلائنٹس کے لیے ٹینسر ہے۔ : کارپوریٹ سوشل نیٹ ورک، ویڈیو کمیونیکیشن کے حل، اندرونی اور بیرونی دستاویزات کے بہاؤ کے لیے، اکاؤنٹنگ اور گوداموں کے لیے اکاؤنٹنگ سسٹم،... یعنی مربوط کاروباری انتظام کے لیے ایسا "میگا کمبائن"، جس میں 100 سے زیادہ مختلف ہیں۔ اندرونی منصوبوں.
اس بات کو یقینی بنانے کے لیے کہ وہ سب کام کرتے ہیں اور عام طور پر ترقی کرتے ہیں، ہمارے پاس پورے ملک میں 10 ترقیاتی مراکز ہیں، جن میں مزید ہیں۔ 1000 ڈویلپرز.
ہم 2008 سے PostgreSQL کے ساتھ کام کر رہے ہیں اور ہم جس پر کارروائی کرتے ہیں اس کی ایک بڑی مقدار جمع کر لی ہے - کلائنٹ ڈیٹا، شماریاتی، تجزیاتی، بیرونی انفارمیشن سسٹم سے ڈیٹا - 400TB سے زیادہ. صرف پیداوار میں تقریباً 250 سرورز ہیں، اور مجموعی طور پر تقریباً 1000 ڈیٹا بیس سرورز ہیں جن کی ہم نگرانی کرتے ہیں۔
ایس کیو ایل ایک اعلانیہ زبان ہے۔ آپ یہ بیان نہیں کرتے کہ کسی چیز کو "کیسے" کام کرنا چاہئے، لیکن "کیا" آپ حاصل کرنا چاہتے ہیں۔ DBMS بہتر جانتا ہے کہ کس طرح شامل ہونا ہے - اپنے ٹیبلز کو کیسے جوڑنا ہے، کون سی شرائط عائد کرنی ہیں، انڈیکس سے کیا گزرے گا، کیا نہیں...
کچھ DBMSs اشارے قبول کرتے ہیں: "نہیں، ان دو ٹیبلز کو فلاں اور فلاں قطار میں جوڑیں،" لیکن PostgreSQL ایسا نہیں کر سکتا۔ یہ سرکردہ ڈویلپرز کی شعوری پوزیشن ہے: "ہم ڈویلپرز کو کسی قسم کے اشارے استعمال کرنے کی اجازت دینے کے بجائے استفسار کے اصلاح کار کو ختم کرنا چاہتے ہیں۔"
لیکن، اس حقیقت کے باوجود کہ PostgreSQL "باہر" کو خود پر قابو پانے کی اجازت نہیں دیتا ہے، یہ بالکل اجازت دیتا ہے دیکھو اس کے اندر کیا ہو رہا ہے۔جب آپ اپنا استفسار چلاتے ہیں، اور اس میں کہاں دشواری ہو رہی ہے۔
عام طور پر، ایک ڈویلپر [DBA کو] عام طور پر کن کلاسک مسائل کے ساتھ آتا ہے؟ "یہاں ہم نے درخواست کو پورا کیا، اور ہمارے ساتھ سب کچھ سست ہے، سب کچھ لٹکا ہوا ہے، کچھ ہو رہا ہے... کسی قسم کی پریشانی!"
وجوہات تقریباً ہمیشہ ایک جیسی ہوتی ہیں:
- غیر موثر استفسار الگورتھم
ڈویلپر: "اب میں اسے جوائن کے ذریعے SQL میں 10 ٹیبل دے رہا ہوں..." - اور توقع کرتا ہے کہ اس کے حالات معجزانہ طور پر مؤثر طریقے سے "کھلائے" جائیں گے اور اسے سب کچھ جلدی مل جائے گا۔ لیکن معجزات رونما نہیں ہوتے، اور اس طرح کے تغیرات والا کوئی بھی نظام (ایک سے 10 میزیں) ہمیشہ کسی نہ کسی قسم کی خرابی پیش کرتا ہے۔ [] - پرانے اعدادوشمار
یہ نکتہ خاص طور پر PostgreSQL کے لیے بہت متعلقہ ہے، جب آپ سرور پر ایک بڑا ڈیٹا سیٹ "ڈالتے" ہیں، ایک درخواست کرتے ہیں، اور یہ آپ کے ٹیبلیٹ کو "جنسی طور پر" بناتا ہے۔ کیونکہ کل اس میں 10 ریکارڈ تھے، اور آج 10 ملین ہیں، لیکن PostgreSQL کو ابھی تک اس کا علم نہیں ہے، اور ہمیں اس کے بارے میں بتانے کی ضرورت ہے۔ [] - وسائل پر "پلگ"
آپ نے ایک کمزور سرور پر ایک بڑا اور بھاری بھرکم ڈیٹا بیس انسٹال کیا ہے جس میں کافی ڈسک، میموری، یا پروسیسر کی کارکردگی نہیں ہے۔ اور بس... کہیں پرفارمنس سیلنگ ہے جس کے اوپر آپ مزید کود نہیں سکتے۔ - مسدود کرنا
یہ ایک مشکل نکتہ ہے، لیکن یہ مختلف ترمیمی سوالات (INSERT، UPDATE، DELETE) کے لیے سب سے زیادہ متعلقہ ہیں - یہ ایک الگ بڑا موضوع ہے۔
ایک منصوبہ حاصل کرنا
...اور ہر چیز کے لیے ہم ایک منصوبہ کی ضرورت ہے؟! ہمیں یہ دیکھنے کی ضرورت ہے کہ سرور کے اندر کیا ہو رہا ہے۔
PostgreSQL کے لیے استفسار پر عمل درآمد کا منصوبہ متن کی نمائندگی میں استفسار کے عمل کے الگورتھم کا ایک درخت ہے۔ یہ بالکل وہی الگورتھم ہے جو، منصوبہ ساز کے تجزیہ کے نتیجے میں، سب سے زیادہ موثر پایا گیا۔
ہر ٹری نوڈ ایک آپریشن ہے: ٹیبل یا انڈیکس سے ڈیٹا بازیافت کرنا، بٹ میپ بنانا، دو ٹیبلز کو جوڑنا، جوڑنا، آپس میں جوڑنا، یا سلیکشنز کو خارج کرنا۔ استفسار پر عمل کرنے میں اس درخت کے نوڈس سے گزرنا شامل ہے۔
استفسار کا منصوبہ حاصل کرنے کے لیے، سب سے آسان طریقہ بیان پر عمل درآمد کرنا ہے۔ EXPLAIN. تمام حقیقی صفات کے ساتھ حاصل کرنے کے لئے، یہ ہے کہ، اصل میں بیس پر ایک سوال کو انجام دینے کے لئے - EXPLAIN (ANALYZE, BUFFERS) SELECT ....
برا حصہ: جب آپ اسے چلاتے ہیں، تو یہ "یہاں اور ابھی" ہوتا ہے، لہذا یہ صرف مقامی ڈیبگنگ کے لیے موزوں ہے۔ اگر آپ ایک انتہائی بھری ہوئی سرور لیتے ہیں جو ڈیٹا کی تبدیلیوں کے زبردست بہاؤ کے تحت ہے، اور آپ دیکھتے ہیں: "اوہ! یہاں ہمارے پاس ایک سست عمل درآمد ہے۔سی اے درخواست۔" آدھا گھنٹہ، ایک گھنٹہ پہلے - جب آپ چلا رہے تھے اور لاگز سے یہ درخواست حاصل کر رہے تھے، اسے سرور پر واپس لا رہے تھے، آپ کا پورا ڈیٹا سیٹ اور اعداد و شمار تبدیل ہو گئے۔ آپ اسے ڈیبگ کرنے کے لیے چلاتے ہیں - اور یہ تیزی سے چلتا ہے! اور آپ سمجھ نہیں سکتے کیوں، کیوں؟ یہ تھا آہستہ آہستہ.
یہ سمجھنے کے لیے کہ اس وقت کیا ہوا تھا جب سرور پر درخواست کی گئی تھی، ہوشیار لوگوں نے لکھا . یہ تقریباً تمام عام پوسٹگری ایس کیو ایل ڈسٹری بیوشنز میں موجود ہے، اور اسے صرف کنفگ فائل میں چالو کیا جا سکتا ہے۔
اگر اسے معلوم ہوتا ہے کہ کچھ درخواست آپ کی بتائی گئی حد سے زیادہ چل رہی ہے، تو ایسا ہوتا ہے۔ اس درخواست کے منصوبے کا "اسنیپ شاٹ" اور انہیں لاگ میں ایک ساتھ لکھتا ہے۔.
لگتا ہے اب سب کچھ ٹھیک ہے، ہم لاگ پر جاتے ہیں اور وہاں دیکھتے ہیں... [text footcloth] لیکن ہم اس کے بارے میں کچھ نہیں کہہ سکتے، اس حقیقت کے علاوہ کہ یہ ایک بہترین منصوبہ ہے کیونکہ اس پر عمل درآمد میں 11ms کا وقت لگا۔
سب کچھ ٹھیک لگ رہا ہے - لیکن کچھ بھی واضح نہیں ہے کہ اصل میں کیا ہوا. عام وقت کے علاوہ، ہم واقعی کچھ بھی نہیں دیکھتے ہیں۔ کیونکہ سادہ متن کے ایسے "میمنے" کو دیکھنا عام طور پر بصری نہیں ہوتا ہے۔
لیکن یہاں تک کہ اگر یہ واضح نہیں ہے، یہاں تک کہ اگر یہ تکلیف دہ ہے، اس سے زیادہ بنیادی مسائل ہیں:
- نوڈ اشارہ کرتا ہے۔ پورے ذیلی درخت کے وسائل کا مجموعہ اس کے تحت. یعنی، آپ صرف یہ نہیں جان سکتے کہ اس مخصوص انڈیکس اسکین پر کتنا وقت صرف کیا گیا ہے اگر اس کے تحت کوئی نیسٹڈ حالت ہے۔ ہمیں متحرک طور پر یہ دیکھنا چاہیے کہ آیا اندر "بچے" اور مشروط متغیرات، CTEs موجود ہیں - اور ان سب کو "ہمارے ذہنوں میں" گھٹا دیں۔
- دوسرا نقطہ: نوڈ پر اشارہ کیا گیا وقت ہے۔ سنگل نوڈ پر عمل درآمد کا وقت. اگر یہ نوڈ، مثال کے طور پر، کئی بار ٹیبل ریکارڈز کے ذریعے ایک لوپ کے نتیجے میں عمل میں لایا گیا، تو اس نوڈ کے چکروں کی تعداد — پلان میں بڑھ جاتی ہے۔ لیکن جوہری عمل درآمد کا وقت خود منصوبہ بندی کے لحاظ سے ایک ہی رہتا ہے۔ یعنی، یہ سمجھنے کے لیے کہ اس نوڈ کو مجموعی طور پر کتنی دیر تک انجام دیا گیا، آپ کو ایک چیز کو دوسری سے ضرب دینے کی ضرورت ہے - دوبارہ، "آپ کے سر میں۔"
ایسے حالات میں، سمجھیں کہ "سب سے کمزور کڑی کون ہے؟" تقریبا ناممکن. لہذا، یہاں تک کہ ڈویلپر خود بھی "دستی" میں لکھتے ہیں کہ "منصوبے کو سمجھنا ایک فن ہے جسے سیکھنا چاہیے، تجربہ...".
لیکن ہمارے پاس 1000 ڈویلپرز ہیں، اور آپ ان میں سے ہر ایک تک یہ تجربہ نہیں پہنچا سکتے۔ میں، آپ، وہ جانتے ہیں، لیکن وہاں موجود کوئی نہیں جانتا۔ شاید وہ سیکھے گا، یا شاید نہیں، لیکن اسے ابھی کام کرنے کی ضرورت ہے - اور اسے یہ تجربہ کہاں سے ملے گا؟
منصوبہ بندی کا تصور
لہذا، ہم نے محسوس کیا کہ ان مسائل سے نمٹنے کے لئے، ہمیں ضرورت ہے منصوبے کا اچھا تصور.
ہم سب سے پہلے "مارکیٹ کے ذریعے" گئے - آئیے انٹرنیٹ پر دیکھیں کہ کیا موجود ہے۔
لیکن یہ پتہ چلا کہ نسبتاً بہت کم "لائیو" حل ہیں جو کم و بیش ترقی پذیر ہیں - لفظی طور پر، صرف ایک: بذریعہ ہیوبرٹ لباکزیوسکی۔ جب آپ "فیڈ" فیلڈ میں پلان کی ایک متن کی نمائندگی کرتے ہیں، تو یہ آپ کو تجزیہ کردہ ڈیٹا کے ساتھ ایک ٹیبل دکھاتا ہے:
- نوڈ کا اپنا پروسیسنگ وقت
- پورے ذیلی درخت کے لیے کل وقت
- اعدادوشمار کے لحاظ سے متوقع ریکارڈز کی تعداد جو بازیافت کیے گئے تھے۔
- نوڈ جسم خود
اس سروس میں لنکس کے آرکائیو کو شیئر کرنے کی صلاحیت بھی ہے۔ آپ نے اپنا منصوبہ وہاں پھینک دیا اور کہا: "ارے، واسیا، یہ ایک لنک ہے، وہاں کچھ گڑبڑ ہے۔"
لیکن چھوٹے مسائل بھی ہیں۔
سب سے پہلے، "کاپی پیسٹ" کی ایک بڑی مقدار۔ آپ لاگ کا ایک ٹکڑا لیں، اسے وہاں چپکا دیں، اور پھر، اور دوبارہ۔
دوم، پڑھے گئے ڈیٹا کی مقدار کا کوئی تجزیہ نہیں۔ - وہی بفر جو آؤٹ پٹ ہے۔ EXPLAIN (ANALYZE, BUFFERS)، ہم اسے یہاں نہیں دیکھتے ہیں۔ وہ صرف یہ نہیں جانتا کہ انہیں کیسے الگ کرنا ہے، انہیں سمجھنا اور ان کے ساتھ کام کرنا ہے۔ جب آپ بہت سا ڈیٹا پڑھ رہے ہوتے ہیں اور محسوس کرتے ہیں کہ آپ ڈسک اور میموری کیش کو غلط طور پر مختص کر رہے ہیں، تو یہ معلومات بہت اہم ہے۔
تیسرا منفی نقطہ اس منصوبے کی انتہائی کمزور ترقی ہے۔ کمٹ بہت چھوٹے ہیں، یہ اچھا ہے اگر ہر چھ ماہ میں ایک بار، اور کوڈ پرل میں ہو۔
لیکن یہ سب "دھن" ہے، ہم کسی نہ کسی طرح اس کے ساتھ رہ سکتے تھے، لیکن ایک چیز ہے جس نے ہمیں اس خدمت سے بہت دور کر دیا۔ یہ کامن ٹیبل ایکسپریشن (CTE) اور مختلف ڈائنامک نوڈس جیسے InitPlan/SubPlan کے تجزیہ میں غلطیاں ہیں۔
اگر آپ اس تصویر پر یقین رکھتے ہیں، تو ہر انفرادی نوڈ کا کل عمل درآمد کا وقت پوری درخواست کے کل عمل درآمد کے وقت سے زیادہ ہے۔ یہ آسان ہے - اس CTE کے جنریشن ٹائم کو CTE اسکین نوڈ سے منہا نہیں کیا گیا تھا۔. لہذا، ہمیں اب صحیح جواب نہیں معلوم کہ CTE اسکین میں کتنا وقت لگا۔
تب ہم نے محسوس کیا کہ اب وقت آگیا ہے کہ ہم اپنا لکھیں - hurray! ہر ڈویلپر کہتا ہے: "اب ہم خود لکھیں گے، یہ بہت آسان ہو جائے گا!"
ہم نے ویب سروسز کے لیے مخصوص اسٹیک لیا: Node.js + Express پر مبنی ایک کور، خوبصورت خاکوں کے لیے بوٹسٹریپ اور D3.js کا استعمال کیا گیا۔ اور ہماری توقعات پوری طرح درست ثابت ہوئیں - ہمیں 2 ہفتوں میں پہلا پروٹو ٹائپ موصول ہوا:
- کسٹم پلان پارسر
یعنی، اب ہم PostgreSQL کی طرف سے تیار کردہ کسی بھی منصوبے کو پارس کر سکتے ہیں۔ - متحرک نوڈس کا درست تجزیہ - CTE اسکین، InitPlan، سب پلان
- بفر کی تقسیم کا تجزیہ - جہاں ڈیٹا کے صفحات میموری سے پڑھے جاتے ہیں، کہاں مقامی کیشے سے، کہاں ڈسک سے
- واضح ہو گیا
تاکہ لاگ میں یہ سب کچھ "کھدو" نہ ہو، بلکہ تصویر میں "کمزور ترین لنک" کو فوراً دیکھا جائے۔
ہمیں کچھ اس طرح ملا، جس میں نحو کو نمایاں کرنا شامل ہے۔ لیکن عام طور پر ہمارے ڈویلپرز اب پلان کی مکمل نمائندگی کے ساتھ کام نہیں کرتے ہیں، بلکہ ایک مختصر کے ساتھ۔ سب کے بعد، ہم نے پہلے ہی تمام نمبروں کو پارس کیا ہے اور انہیں بائیں اور دائیں پھینک دیا ہے، اور درمیان میں ہم نے صرف پہلی لائن چھوڑ دی ہے، یہ کس قسم کا نوڈ ہے: سی ٹی ای اسکین، سی ٹی ای جنریشن یا سیک اسکین کسی علامت کے مطابق۔
یہ مختصر نمائندگی ہے جسے ہم کہتے ہیں۔ منصوبہ ٹیمپلیٹ.
اور کیا سہولت ہو گی؟ یہ دیکھنا آسان ہوگا کہ ہمارے کل وقت کا کون سا حصہ کس نوڈ کے لیے مختص کیا گیا ہے - اور صرف "اسے چسپاں" کریں پائی چارٹ.
ہم نوڈ کی طرف اشارہ کرتے ہیں اور دیکھتے ہیں - یہ پتہ چلتا ہے کہ Seq Scan نے کل وقت کے ایک چوتھائی سے بھی کم وقت لیا، اور باقی 3/4 CTE Scan کے ذریعے لیا گیا۔ وحشت! یہ CTE اسکین کے "آگ کی شرح" کے بارے میں ایک چھوٹا سا نوٹ ہے اگر آپ اسے اپنے سوالات میں فعال طور پر استعمال کرتے ہیں۔ وہ بہت تیز نہیں ہیں - وہ باقاعدہ ٹیبل اسکیننگ سے بھی کمتر ہیں۔
لیکن عام طور پر ایسے خاکے زیادہ دلچسپ، زیادہ پیچیدہ ہوتے ہیں، جب ہم فوری طور پر کسی حصے کی طرف اشارہ کرتے ہیں اور دیکھتے ہیں، مثال کے طور پر، کہ آدھے سے زیادہ وقت میں کچھ Seq Scan "کھا" جاتا ہے۔ مزید یہ کہ، اندر ایک قسم کا فلٹر تھا، اس کے مطابق بہت سارے ریکارڈز کو ضائع کر دیا گیا تھا... آپ اس تصویر کو براہ راست ڈویلپر کو پھینک سکتے ہیں اور کہہ سکتے ہیں: "واسیا، یہاں آپ کے لیے سب کچھ خراب ہے! اس کا اندازہ لگائیں، دیکھو - کچھ غلط ہے!
قدرتی طور پر، کچھ "ریک" شامل تھے.
پہلی چیز جو ہم نے دیکھی وہ تھی راؤنڈنگ کا مسئلہ۔ پلان میں ہر انفرادی نوڈ کا وقت 1 μs کی درستگی کے ساتھ ظاہر کیا گیا ہے۔ اور جب نوڈ سائیکلوں کی تعداد، مثال کے طور پر، 1000 سے زیادہ ہو جاتی ہے - عمل درآمد کے بعد PostgreSQL کو "درستگی کے اندر" تقسیم کیا جاتا ہے، پھر جب واپس کیلکولیشن کرتے ہیں تو ہمیں کل وقت ملتا ہے "کہیں 0.95ms اور 1.05ms کے درمیان"۔ جب گنتی مائیکرو سیکنڈز تک جاتی ہے، تو یہ ٹھیک ہے، لیکن جب یہ پہلے سے ہی [ملی] سیکنڈز کا ہو، تو آپ کو اس معلومات کو مدنظر رکھنا ہوگا جب "کس نے کتنا استعمال کیا" پلان کے نوڈس کو وسائل کو "کھولتے" ہیں۔
دوسرا نکتہ، زیادہ پیچیدہ، متحرک نوڈس کے درمیان وسائل (وہ بفرز) کی تقسیم ہے۔ اس سے ہمیں پروٹوٹائپ کے پہلے 2 ہفتوں کے علاوہ مزید 4 ہفتے خرچ ہوئے۔
اس قسم کا مسئلہ حاصل کرنا کافی آسان ہے - ہم CTE کرتے ہیں اور قیاس کے مطابق اس میں کچھ پڑھتے ہیں۔ درحقیقت، PostgreSQL "سمارٹ" ہے اور وہاں براہ راست کچھ نہیں پڑھے گا۔ پھر ہم اس سے پہلا ریکارڈ لیتے ہیں، اور اسی CTE سے ایک سو پہلا ریکارڈ لیتے ہیں۔
ہم منصوبے کو دیکھتے ہیں اور سمجھتے ہیں - یہ عجیب بات ہے، ہمارے پاس Seq Scan میں 3 بفرز (ڈیٹا پیجز) "کھپے" ہیں، 1 مزید CTE Scan میں، اور 2 مزید CTE Scan میں۔ یعنی، اگر ہم ہر چیز کا خلاصہ کریں تو ہمیں 6 ملے گا، لیکن ٹیبلیٹ سے ہم صرف 3 پڑھتے ہیں! CTE اسکین کہیں سے بھی کچھ نہیں پڑھتا ہے، لیکن پروسیس میموری کے ساتھ براہ راست کام کرتا ہے۔ یعنی، یہاں کچھ واضح طور پر غلط ہے!
درحقیقت، یہ پتہ چلتا ہے کہ یہاں وہ تمام 3 صفحات کے ڈیٹا ہیں جو Seq Scan سے مانگے گئے تھے، پہلے 1 نے 1st CTE Scan کے لیے کہا، پھر 2nd، اور 2 مزید اسے پڑھ کر سنایا گیا۔ 3 صفحات کا ڈیٹا پڑھا گیا، 6 نہیں۔
اور اس تصویر نے ہمیں یہ سمجھنے کی طرف راغب کیا کہ کسی منصوبے پر عمل درآمد اب ایک درخت نہیں ہے، بلکہ محض ایک قسم کا تیزابی گراف ہے۔ اور ہمیں اس طرح کا ایک خاکہ ملا، تاکہ ہم سمجھ سکیں کہ "پہلی جگہ سے کیا آیا ہے۔" یعنی، یہاں ہم نے pg_class سے ایک CTE بنایا، اور اسے دو بار مانگا، اور جب ہم نے دوسری بار اس کے لیے کہا تو ہمارا تقریباً سارا وقت برانچ پر گزر گیا۔ یہ واضح ہے کہ 2 ویں اندراج کو پڑھنا ٹیبلیٹ سے صرف 101st اندراج کو پڑھنے سے کہیں زیادہ مہنگا ہے۔
ہم نے کچھ دیر کے لیے سانس چھوڑی۔ انہوں نے کہا: "اب، نو، آپ کنگ فو جانتے ہیں! اب ہمارا تجربہ آپ کی سکرین پر ہے۔ اب آپ اسے استعمال کر سکتے ہیں۔"
لاگ انسولڈیشن
ہمارے 1000 ڈویلپرز نے راحت کی سانس لی۔ لیکن ہم سمجھ گئے کہ ہمارے پاس صرف سینکڑوں "جنگی" سرورز ہیں، اور ڈویلپرز کی جانب سے یہ سب "کاپی پیسٹ" بالکل بھی آسان نہیں ہے۔ ہمیں احساس ہوا کہ ہمیں اسے خود جمع کرنا ہے۔
عام طور پر، ایک معیاری ماڈیول ہے جو اعداد و شمار جمع کر سکتا ہے، تاہم، اسے بھی ترتیب میں چالو کرنے کی ضرورت ہے - یہ . لیکن وہ ہمیں پسند نہیں آیا۔
سب سے پہلے، یہ ایک ہی ڈیٹا بیس میں مختلف اسکیموں کا استعمال کرتے ہوئے ایک ہی سوالات کو تفویض کرتا ہے۔ مختلف QueryIds. یعنی اگر آپ پہلے کرتے ہیں۔ SET search_path = '01'; SELECT * FROM user LIMIT 1;اور پھر SET search_path = '02'; اور ایک ہی درخواست، پھر اس ماڈیول کے اعدادوشمار کے مختلف ریکارڈ ہوں گے، اور میں اسکیموں کو مدنظر رکھے بغیر، خاص طور پر اس درخواست پروفائل کے تناظر میں عمومی اعدادوشمار جمع کرنے کے قابل نہیں رہوں گا۔
دوسرا نکتہ جس نے ہمیں اسے استعمال کرنے سے روکا۔ منصوبوں کی کمی. یعنی کوئی منصوبہ نہیں، صرف درخواست ہے۔ ہم دیکھتے ہیں کہ کیا سست ہو رہا تھا، لیکن ہم نہیں سمجھتے کہ کیوں۔ اور یہاں ہم تیزی سے بدلتے ہوئے ڈیٹاسیٹ کے مسئلے کی طرف لوٹتے ہیں۔
اور آخری لمحے - "حقائق" کی کمی. یعنی، آپ استفسار پر عمل درآمد کی کسی خاص مثال پر توجہ نہیں دے سکتے ہیں - وہاں کوئی نہیں ہے، صرف مجموعی اعداد و شمار موجود ہیں۔ اگرچہ اس کے ساتھ کام کرنا ممکن ہے، لیکن یہ بہت مشکل ہے۔
اس لیے ہم نے کاپی پیسٹ سے لڑنے کا فیصلہ کیا اور لکھنا شروع کیا۔ جمع کرنے والا.
کلکٹر SSH کے ذریعے جڑتا ہے، ایک سرٹیفکیٹ کا استعمال کرتے ہوئے ڈیٹا بیس کے ساتھ سرور سے محفوظ کنکشن قائم کرتا ہے، اور tail -F لاگ فائل میں اس سے "لگتا ہے"۔ تو اس سیشن میں ہمیں پوری لاگ فائل کا مکمل "آئینہ" ملتا ہے۔، جسے سرور تیار کرتا ہے۔ سرور پر بوجھ خود کم سے کم ہے، کیونکہ ہم وہاں کسی بھی چیز کو پارس نہیں کرتے ہیں، ہم صرف ٹریفک کا عکس بناتے ہیں۔
چونکہ ہم نے پہلے ہی Node.js میں انٹرفیس لکھنا شروع کر دیا تھا، اس لیے ہم اس میں کلکٹر لکھتے رہے۔ اور اس ٹیکنالوجی نے خود کو درست ثابت کیا ہے، کیونکہ یہ جاوا اسکرپٹ کو کمزور فارمیٹ شدہ ٹیکسٹ ڈیٹا کے ساتھ کام کرنے کے لیے استعمال کرنا بہت آسان ہے، جو کہ لاگ ہے۔ اور بیک اینڈ پلیٹ فارم کے طور پر Node.js انفراسٹرکچر آپ کو آسانی سے اور آسانی سے نیٹ ورک کنکشن کے ساتھ اور درحقیقت کسی بھی ڈیٹا اسٹریمز کے ساتھ کام کرنے کی اجازت دیتا ہے۔
اس کے مطابق، ہم دو رابطوں کو "مسلسل" کرتے ہیں: پہلا لاگ کو خود "سننا" اور اسے اپنے پاس لے جانا، اور دوسرا وقتاً فوقتاً اڈے سے پوچھنا۔ "لیکن لاگ سے پتہ چلتا ہے کہ oid 123 والا نشان بلاک ہے،" لیکن اس کا ڈویلپر کے لیے کوئی مطلب نہیں ہے، اور ڈیٹا بیس سے پوچھنا اچھا ہو گا، "OID = 123 ویسے بھی کیا ہے؟" اور اس لیے ہم وقتاً فوقتاً اڈے سے پوچھتے ہیں کہ ہم ابھی تک اپنے بارے میں کیا نہیں جانتے۔
"صرف ایک چیز ہے جس کا آپ نے خیال نہیں رکھا، ہاتھی جیسی شہد کی مکھیوں کی ایک قسم ہے!..." ہم نے اس سسٹم کو اس وقت تیار کرنا شروع کیا جب ہم 10 سرورز کی نگرانی کرنا چاہتے تھے۔ ہماری سمجھ میں سب سے اہم، جہاں کچھ مسائل پیدا ہوئے جن سے نمٹنا مشکل تھا۔ لیکن پہلی سہ ماہی کے دوران، ہمیں نگرانی کے لیے ایک سو موصول ہوئے - کیونکہ سسٹم نے کام کیا، ہر کوئی اسے چاہتا تھا، ہر کوئی آرام دہ تھا۔
ان سب کو شامل کرنے کی ضرورت ہے، ڈیٹا کا بہاؤ بڑا اور فعال ہے۔ درحقیقت، ہم جس چیز کی نگرانی کرتے ہیں، جس سے ہم نمٹ سکتے ہیں، وہی ہے جو ہم استعمال کرتے ہیں۔ ہم PostgreSQL کو ڈیٹا اسٹوریج کے طور پر بھی استعمال کرتے ہیں۔ اور آپریٹر کے مقابلے میں اس میں ڈیٹا "ڈالنے" کے لیے کچھ بھی تیز نہیں ہے۔ COPY ابھی تک نہیں.
لیکن محض "ڈالنا" ڈیٹا واقعی ہماری ٹیکنالوجی نہیں ہے۔ کیونکہ اگر آپ کے پاس سو سرورز پر فی سیکنڈ تقریباً 50k درخواستیں ہیں، تو اس سے روزانہ 100-150GB لاگز پیدا ہوں گے۔ لہذا، ہمیں احتیاط سے بنیاد کو "کاٹنا" پڑا.
سب سے پہلے، ہم نے کیا دن بہ دن تقسیمکیونکہ، بڑے پیمانے پر، کوئی بھی دنوں کے درمیان ارتباط میں دلچسپی نہیں رکھتا ہے۔ اس سے کیا فرق پڑتا ہے جو آپ کے پاس کل تھا، اگر آج رات آپ نے ایپلیکیشن کا نیا ورژن تیار کیا ہے - اور پہلے سے ہی کچھ نئے اعدادوشمار۔
دوسرا، ہم نے سیکھا (مجبور کیا گیا) استعمال کرتے ہوئے لکھنے میں بہت، بہت تیز COPY. یعنی نہ صرف COPYکیونکہ وہ اس سے تیز ہے۔ INSERT، اور اس سے بھی تیز۔
تیسرا نکتہ - مجھے کرنا پڑا بالترتیب محرکات اور غیر ملکی کلیدوں کو چھوڑ دیں۔. یعنی، ہمارے پاس کوئی حوالہ جاتی سالمیت نہیں ہے۔ کیونکہ اگر آپ کے پاس ایک ٹیبل ہے جس میں FKs کا ایک جوڑا ہے، اور آپ ڈیٹا بیس کے ڈھانچے میں کہتے ہیں کہ "یہاں ایک لاگ ریکارڈ ہے جس کا حوالہ FK کے ذریعہ دیا گیا ہے، مثال کے طور پر، ریکارڈز کے ایک گروپ کو"، تو جب آپ اسے داخل کرتے ہیں، PostgreSQL اس کے سوا کچھ نہیں بچا ہے کہ اسے کیسے لیا جائے اور اسے ایمانداری سے کیا جائے۔ SELECT 1 FROM master_fk1_table WHERE ... شناخت کنندہ کے ساتھ جسے آپ داخل کرنے کی کوشش کر رہے ہیں - صرف یہ چیک کرنے کے لیے کہ یہ ریکارڈ وہاں موجود ہے، کہ آپ اپنے اندراج کے ساتھ اس غیر ملکی کلید کو "توڑ" نہیں دیتے۔
ٹارگٹ ٹیبل اور اس کے اشاریہ جات کے ایک ریکارڈ کے بجائے، ہمیں ان تمام جدولوں سے پڑھنے کا اضافی فائدہ ملتا ہے جن کا یہ حوالہ دیتا ہے۔ لیکن ہمیں اس کی بالکل ضرورت نہیں ہے - ہمارا کام کم سے کم بوجھ کے ساتھ زیادہ سے زیادہ اور جلد از جلد ریکارڈ کرنا ہے۔ تو FK - نیچے!
اگلا نقطہ جمع اور ہیشنگ ہے۔ ابتدائی طور پر، ہم نے ان کو ڈیٹا بیس میں لاگو کیا - آخر کار، جب کوئی ریکارڈ آجائے تو اسے فوری طور پر کسی قسم کے ٹیبلٹ میں کرنا آسان ہے۔ "پلس ون" دائیں ٹرگر میں. ٹھیک ہے، یہ آسان ہے، لیکن ایک ہی بری چیز - آپ ایک ریکارڈ داخل کرتے ہیں، لیکن دوسرے ٹیبل سے کچھ اور پڑھنے اور لکھنے پر مجبور ہیں۔ مزید یہ کہ، آپ نہ صرف پڑھتے اور لکھتے ہیں، آپ ہر بار بھی کرتے ہیں۔
اب تصور کریں کہ آپ کے پاس ایک ٹیبل ہے جس میں آپ صرف ان درخواستوں کی تعداد گنتے ہیں جو ایک مخصوص میزبان سے گزری ہیں: +1, +1, +1, ..., +1. اور آپ کو، اصولی طور پر، اس کی ضرورت نہیں ہے - یہ سب ممکن ہے۔ کلیکٹر پر میموری میں رقم اور ایک ہی بار میں ڈیٹا بیس کو بھیجیں۔ +10.
جی ہاں، کچھ مسائل کی صورت میں، آپ کی منطقی سالمیت "ختم ہو سکتی ہے"، لیکن یہ تقریباً غیر حقیقی معاملہ ہے - کیونکہ آپ کے پاس ایک عام سرور ہے، اس کے کنٹرولر میں بیٹری ہے، آپ کے پاس ٹرانزیکشن لاگ، لاگ پر لاگ ان ہے۔ فائل سسٹم... عام طور پر، یہ اس کے قابل نہیں ہے۔ ٹرگرز/FK چلانے سے آپ کی پیداواری صلاحیت کا نقصان آپ کو اٹھانے والے اخراجات کے قابل نہیں ہے۔
ہیشنگ کے ساتھ بھی ایسا ہی ہے۔ ایک خاص درخواست آپ تک پہنچتی ہے، آپ ڈیٹا بیس میں اس سے ایک مخصوص شناخت کنندہ کا حساب لگاتے ہیں، اسے ڈیٹا بیس میں لکھتے ہیں اور پھر سب کو بتاتے ہیں۔ سب کچھ اس وقت تک ٹھیک ہے جب تک کہ، ریکارڈنگ کے وقت، دوسرا شخص آپ کے پاس نہیں آتا جو وہی چیز ریکارڈ کرنا چاہتا ہے - اور آپ کو بلاک کر دیا جاتا ہے، اور یہ پہلے سے ہی خراب ہے۔ لہذا، اگر آپ کچھ IDs کی جنریشن کو کلائنٹ کو منتقل کر سکتے ہیں (ڈیٹا بیس کے نسبت)، تو یہ کرنا بہتر ہے۔
ہمارے لیے متن سے MD5 استعمال کرنا بالکل درست تھا - درخواست، منصوبہ، ٹیمپلیٹ،... ہم کلکٹر کی طرف سے اس کا حساب لگاتے ہیں، اور ڈیٹا بیس میں ریڈی میڈ ID کو "ڈال" دیتے ہیں۔ MD5 کی لمبائی اور روزانہ کی تقسیم ہمیں ممکنہ تصادم کے بارے میں فکر کرنے کی اجازت نہیں دیتی ہے۔
لیکن یہ سب تیزی سے ریکارڈ کرنے کے لیے، ہمیں ریکارڈنگ کے طریقہ کار میں ہی ترمیم کرنے کی ضرورت تھی۔
آپ عام طور پر ڈیٹا کیسے لکھتے ہیں؟ ہمارے پاس کچھ قسم کا ڈیٹاسیٹ ہے، ہم اسے کئی جدولوں میں تقسیم کرتے ہیں، اور پھر اسے کاپی کرتے ہیں - پہلے پہلی میں، پھر دوسرے میں، تیسرے میں... یہ تکلیف دہ ہے، کیونکہ ایسا لگتا ہے کہ ہم تین مراحل میں ایک ڈیٹا اسٹریم لکھ رہے ہیں۔ ترتیب وار ناخوشگوار۔ کیا یہ تیزی سے کیا جا سکتا ہے؟ کر سکتے ہیں!
ایسا کرنے کے لیے، ان بہاؤ کو ایک دوسرے کے ساتھ متوازی طور پر گلنا ہی کافی ہے۔ یہ پتہ چلتا ہے کہ ہمارے پاس غلطیاں، درخواستیں، ٹیمپلیٹس، بلاکنگز، ... الگ الگ تھریڈز میں اڑ رہے ہیں - اور ہم یہ سب متوازی طور پر لکھتے ہیں۔ اس کے لیے کافی ہے۔ ہر انفرادی ٹارگٹ ٹیبل کے لیے ایک کاپی چینل کو مسلسل کھلا رکھیں.
یعنی کلکٹر پر ہمیشہ ایک ندی ہوتی ہے۔، جس میں میں اپنی ضرورت کا ڈیٹا لکھ سکتا ہوں۔ لیکن تاکہ ڈیٹا بیس اس ڈیٹا کو دیکھے، اور کوئی اس ڈیٹا کے لکھے جانے کے انتظار میں نہ پھنس جائے، COPY کو کچھ وقفوں پر روکا جانا چاہیے۔. ہمارے لیے، سب سے زیادہ مؤثر دورانیہ تقریباً 100ms تھا - ہم اسے بند کر کے فوراً دوبارہ اسی میز پر کھول دیتے ہیں۔ اور اگر کچھ چوٹیوں کے دوران ہمارے پاس ایک بہاؤ کافی نہیں ہے، تو ہم ایک خاص حد تک پولنگ کرتے ہیں۔
مزید برآں، ہمیں پتہ چلا کہ اس طرح کے لوڈ پروفائل کے لیے، کوئی بھی جمع، جب ریکارڈ بیچوں میں جمع کیا جاتا ہے، برا ہے۔ کلاسیکی برائی ہے۔ INSERT ... VALUES اور مزید 1000 ریکارڈ۔ کیونکہ اس وقت آپ کے پاس میڈیا پر لکھنے کی چوٹی ہے، اور باقی سب جو ڈسک پر کچھ لکھنے کی کوشش کر رہے ہیں انتظار کر رہے ہوں گے۔
ایسی بے ضابطگیوں سے چھٹکارا پانے کے لیے، بس کچھ بھی جمع نہ کریں، بالکل بفر مت کرو. اور اگر ڈسک پر بفرنگ ہوتی ہے (خوش قسمتی سے، Node.js میں Stream API آپ کو معلوم کرنے کی اجازت دیتا ہے) - اس کنکشن کو ملتوی کریں۔ جب آپ کو کوئی واقعہ موصول ہوتا ہے کہ یہ دوبارہ مفت ہے، تو جمع شدہ قطار سے اسے لکھیں۔ اور جب یہ مصروف ہو تو، پول سے اگلا مفت لیں اور اسے لکھیں۔
ڈیٹا ریکارڈنگ کے لیے اس نقطہ نظر کو متعارف کرانے سے پہلے، ہمارے پاس تقریباً 4K تحریری آپریشنز تھے، اور اس طرح ہم نے لوڈ کو 4 گنا کم کیا۔ اب وہ نئے مانیٹر شدہ ڈیٹا بیس کی وجہ سے مزید 6 گنا بڑھ چکے ہیں - 100MB/s تک۔ اور اب ہم پچھلے 3 مہینوں کے لاگز کو تقریباً 10-15TB کے حجم میں اسٹور کرتے ہیں، امید ہے کہ صرف تین مہینوں میں کوئی بھی ڈویلپر کسی بھی مسئلے کو حل کر سکے گا۔
ہم مسائل کو سمجھتے ہیں۔
لیکن صرف یہ تمام ڈیٹا اکٹھا کرنا اچھا، مفید، متعلقہ ہے، لیکن کافی نہیں ہے - اسے سمجھنے کی ضرورت ہے۔ کیونکہ یہ روزانہ لاکھوں مختلف منصوبے ہیں۔
لیکن لاکھوں بے قابو ہیں، ہمیں پہلے "چھوٹا" کرنا چاہیے۔ اور، سب سے پہلے، آپ کو یہ فیصلہ کرنے کی ضرورت ہے کہ آپ اس "چھوٹی" چیز کو کس طرح منظم کریں گے۔
ہم نے تین اہم نکات کی نشاندہی کی ہے:
- کون یہ درخواست بھیجی
یعنی، یہ کس ایپلی کیشن سے "آیا": ویب انٹرفیس، بیک اینڈ، ادائیگی کا نظام یا کچھ اور۔ - جہاں یہ ہوا
کس مخصوص سرور پر؟ کیونکہ اگر آپ کے پاس ایک ایپلی کیشن کے تحت کئی سرورز ہیں، اور اچانک ایک "بیوقوف ہو جاتا ہے" (کیونکہ "ڈسک بوسیدہ ہے"، "میموری لیک ہو گئی ہے"، کوئی اور مسئلہ)، تو آپ کو خاص طور پر سرور کو ایڈریس کرنے کی ضرورت ہے۔ - کے طور پر مسئلہ خود کو کسی نہ کسی طریقے سے ظاہر کرتا ہے۔
یہ سمجھنے کے لیے کہ "کس نے" ہمیں درخواست بھیجی ہے، ہم ایک معیاری ٹول استعمال کرتے ہیں - ایک سیشن متغیر ترتیب دینا: SET application_name = '{bl-host}:{bl-method}'; - ہم کاروباری منطق کے میزبان کا نام بھیجتے ہیں جس سے درخواست آرہی ہے، اور اس طریقہ یا درخواست کا نام جس نے اسے شروع کیا تھا۔
درخواست کے "مالک" کو پاس کرنے کے بعد، اسے لاگ میں آؤٹ پٹ ہونا چاہیے - اس کے لیے ہم متغیر کو ترتیب دیتے ہیں۔ log_line_prefix = ' %m [%p:%v] [%d] %r %a'. دلچسپی رکھنے والوں کے لیے، شاید اس سب کا کیا مطلب ہے. یہ پتہ چلتا ہے کہ ہم لاگ میں دیکھتے ہیں:
- وقت
- عمل اور لین دین کے شناخت کنندگان
- ڈیٹا بیس کا نام
- اس شخص کا IP جس نے یہ درخواست بھیجی ہے۔
- اور طریقہ کا نام
تب ہم نے محسوس کیا کہ مختلف سرورز کے درمیان ایک درخواست کے باہمی تعلق کو دیکھنا زیادہ دلچسپ نہیں ہے۔ ایسا اکثر نہیں ہوتا ہے کہ آپ کے پاس ایسی صورتحال ہوتی ہے جہاں ایک ایپلی کیشن یہاں اور وہاں یکساں طور پر خراب ہوجاتی ہے۔ لیکن یہاں تک کہ اگر یہ ایک جیسا ہے تو، ان میں سے کسی بھی سرور کو دیکھیں۔
تو یہاں کٹ ہے۔ "ایک سرور - ایک دن" یہ ہمارے لیے کسی بھی تجزیہ کے لیے کافی ثابت ہوا۔
پہلا تجزیاتی حصہ وہی ہے۔ "نمونہ" - تمام عددی اشارے سے پاک، منصوبہ کی پیشکش کی ایک مختصر شکل۔ دوسرا کٹ ایپلی کیشن یا طریقہ ہے، اور تیسرا کٹ مخصوص پلان نوڈ ہے جس کی وجہ سے ہمیں پریشانی ہوئی ہے۔
جب ہم مخصوص مثالوں سے ٹیمپلیٹس کی طرف چلے گئے تو ہمیں بیک وقت دو فائدے ملے:
- تجزیہ کے لیے اشیاء کی تعداد میں متعدد کمی
ہمیں اب مسئلہ کا تجزیہ ہزاروں سوالات یا منصوبوں سے نہیں بلکہ درجنوں ٹیمپلیٹس سے کرنا ہے۔ - ٹائم لائن
یعنی، ایک مخصوص حصے میں "حقائق" کا خلاصہ کرکے، آپ دن کے وقت ان کی ظاہری شکل دکھا سکتے ہیں۔ اور یہاں آپ سمجھ سکتے ہیں کہ اگر آپ کے پاس کوئی ایسا نمونہ ہے جو ہوتا ہے، مثال کے طور پر، ایک گھنٹہ میں ایک بار، لیکن یہ دن میں ایک بار ہونا چاہیے، تو آپ کو سوچنا چاہیے کہ کیا غلط ہوا - یہ کس نے کیا اور کیوں، شاید یہ یہاں ہونا چاہیے۔ نہیں کرنا چاہیے یہ ایک اور غیر عددی، خالصتاً بصری، تجزیہ کا طریقہ ہے۔
باقی طریقے ان اشارے پر مبنی ہیں جو ہم پلان سے نکالتے ہیں: اس طرح کا پیٹرن کتنی بار ہوا، کل اور اوسط وقت، ڈسک سے کتنا ڈیٹا پڑھا گیا، اور میموری سے کتنا...
کیونکہ، مثال کے طور پر، آپ میزبان کے لیے تجزیاتی صفحہ پر آتے ہیں، دیکھو - کچھ ڈسک پر بہت زیادہ پڑھنا شروع ہو رہا ہے۔ سرور پر موجود ڈسک اسے سنبھال نہیں سکتی - کون اس سے پڑھتا ہے؟
اور آپ کسی بھی کالم کے مطابق ترتیب دے سکتے ہیں اور فیصلہ کر سکتے ہیں کہ آپ ابھی کس چیز سے نمٹیں گے - پروسیسر یا ڈسک پر بوجھ، یا درخواستوں کی کل تعداد... ہم نے اسے ترتیب دیا، "سب سے اوپر" کو دیکھا، اسے ٹھیک کیا اور ایپلیکیشن کا نیا ورژن متعارف کرایا۔
اور فوری طور پر آپ مختلف ایپلی کیشنز کو دیکھ سکتے ہیں جو ایک ہی ٹیمپلیٹ کے ساتھ آتی ہیں جیسے درخواست سے SELECT * FROM users WHERE login = 'Vasya'. فرنٹ اینڈ، بیک اینڈ، پروسیسنگ... اور آپ حیران ہیں کہ اگر صارف اس کے ساتھ بات چیت نہیں کرتا ہے تو پروسیسنگ کیوں پڑھے گی۔
اس کے برعکس طریقہ یہ ہے کہ ایپلیکیشن سے فوری طور پر دیکھیں کہ یہ کیا کرتا ہے۔ مثال کے طور پر، فرنٹ اینڈ یہ ہے، یہ، یہ، اور یہ ایک گھنٹے میں ایک بار (ٹائم لائن مدد کرتی ہے)۔ اور سوال فوری طور پر پیدا ہوتا ہے: ایسا لگتا ہے کہ ایک گھنٹے میں ایک بار کچھ کرنا فرنٹ اینڈ کا کام نہیں ہے ...
کچھ عرصے کے بعد، ہمیں احساس ہوا کہ ہمارے پاس مجموعی کمی ہے۔ پلان نوڈس کی طرف سے اعداد و شمار. ہم نے صرف ان نوڈس کو منصوبوں سے الگ کیا جو خود ٹیبل کے ڈیٹا کے ساتھ کچھ کرتے ہیں (انڈیکس کے ذریعہ پڑھیں / لکھیں یا نہیں)۔ درحقیقت، پچھلی تصویر کے مقابلے میں صرف ایک پہلو شامل کیا گیا ہے۔ اس نوڈ نے ہمارے پاس کتنے ریکارڈ لائے؟، اور کتنے کو مسترد کر دیا گیا (فلٹر کے ذریعے ہٹائی گئی قطاریں)۔
آپ کے پاس پلیٹ میں کوئی مناسب انڈیکس نہیں ہے، آپ اس سے درخواست کرتے ہیں، یہ انڈیکس سے گزرتا ہے، Seq Scan میں آتا ہے... آپ نے ایک کے علاوہ تمام ریکارڈز کو فلٹر کر دیا ہے۔ آپ کو روزانہ 100M فلٹر شدہ ریکارڈز کی ضرورت کیوں ہے؟ کیا انڈیکس کو رول اپ کرنا بہتر نہیں ہے؟
نوڈ کے حساب سے تمام منصوبوں کا تجزیہ کرنے کے بعد، ہم نے محسوس کیا کہ منصوبوں میں کچھ مخصوص ڈھانچے ہیں جن کے مشکوک نظر آنے کا بہت امکان ہے۔ اور ڈویلپر کو یہ بتانا اچھا ہوگا: "دوست، یہاں آپ پہلے انڈیکس کے حساب سے پڑھیں، پھر ترتیب دیں، اور پھر کاٹ دیں" - ایک اصول کے طور پر، ایک ریکارڈ موجود ہے۔
ہر ایک جس نے سوالات لکھے ہیں شاید اس نمونے کا سامنا کرنا پڑا ہے: "مجھے واسیا کے لئے آخری آرڈر دیں، اس کی تاریخ۔ بالکل اسی "ریک" پر قدم رکھیں۔
لیکن ہم جانتے ہیں کہ یہ ایک "ریک" ہے - تو کیوں نہ فوری طور پر ڈویلپر کو بتائیں کہ اسے کیا کرنا چاہیے۔ اسی مناسبت سے، اب جب کوئی پلان کھولتے ہیں، ہمارے ڈویلپر کو فوری طور پر تجاویز کے ساتھ ایک خوبصورت تصویر نظر آتی ہے، جہاں وہ اسے فوراً کہتے ہیں: "آپ کو یہاں اور وہاں مسائل ہیں، لیکن وہ اس طرح اور اس طرح حل ہو جاتے ہیں۔"
نتیجے کے طور پر، تجربے کی مقدار جو شروع میں مسائل کے حل کے لیے درکار تھی اور اب اس میں نمایاں کمی آئی ہے۔ یہ ہمارے پاس ایک قسم کا آلہ ہے۔
ماخذ: www.habr.com