صفحہ بندی کے سوالات میں OFFSET اور LIMIT استعمال کرنے سے گریز کریں۔

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

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

SELECT * FROM table_name LIMIT 10 OFFSET 40

جس طرح یہ ہے؟

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

کیا آپ مجھ پر اعتراض کرنا چاہتے ہیں؟ تم کر سکتے ہو کوئی خرچ وقت. ناپختہ, Shopify и مکس میکس وہ پہلے ہی وہ تکنیک استعمال کر رہے ہیں جن کے بارے میں میں آج بات کرنا چاہتا ہوں۔

کم از کم ایک بیک اینڈ ڈویلپر کا نام بتائیں جس نے کبھی استعمال نہیں کیا۔ OFFSET и LIMIT صفحہ بندی کے سوالات کرنے کے لیے۔ MVP (کم سے کم قابل عمل پروڈکٹ) اور ایسے منصوبوں میں جہاں ڈیٹا کی تھوڑی مقدار استعمال کی جاتی ہے، یہ طریقہ کافی حد تک لاگو ہوتا ہے۔ یہ "بس کام کرتا ہے،" تو بات کرنے کے لیے۔

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

آج ہم صفحہ بندی والے استفسار انجنوں کے عام طور پر استعمال ہونے والے (بہت خراب) نفاذ کے مسائل کے بارے میں بات کریں گے، اور اس طرح کے استفسارات پر عمل کرتے وقت اعلیٰ کارکردگی کیسے حاصل کی جائے۔

OFFSET اور LIMIT میں کیا خرابی ہے؟

جیسا کہ پہلے ہی کہا گیا ہے ، OFFSET и LIMIT وہ ایسے پروجیکٹس میں اچھی کارکردگی کا مظاہرہ کرتے ہیں جن میں ڈیٹا کی بڑی مقدار کے ساتھ کام کرنے کی ضرورت نہیں ہوتی ہے۔

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

اس مسئلے کو ظاہر کرنے کے لیے، ایسی صورت حال ہونی چاہیے جس میں DBMS ہر صفحہ بندی والے سوال پر ایک غیر موثر فل ٹیبل اسکین آپریشن کا سہارا لے (جبکہ اندراج اور حذف کرنے کی کارروائیاں ہو سکتی ہیں، اور ہمیں پرانے ڈیٹا کی ضرورت نہیں ہے!)۔

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

مثال کے طور پر، آپ کے پاس 100000000 صارفین کا ریکارڈ ہے اور آپ تعمیر کے ساتھ ایک سوال چلاتے ہیں OFFSET 50000000. اس کا مطلب یہ ہے کہ ڈی بی ایم ایس کو یہ تمام ریکارڈ لوڈ کرنے ہوں گے (اور ہمیں ان کی ضرورت بھی نہیں ہے!)، انہیں میموری میں رکھنا ہوگا، اور اس کے بعد، 20 نتائج کی اطلاع دی گئی ہے۔ LIMIT.

آئیے کہتے ہیں کہ یہ اس طرح نظر آسکتا ہے: "50000 سے 50020 سے 100000 تک قطاریں منتخب کریں"۔ یعنی سوال کو مکمل کرنے کے لیے سسٹم کو پہلے 50000 قطاریں لوڈ کرنے کی ضرورت ہوگی۔ کیا آپ دیکھتے ہیں کہ اسے کتنا غیر ضروری کام کرنا پڑے گا؟

اگر آپ کو مجھ پر یقین نہیں ہے، تو اس مثال پر ایک نظر ڈالیں جو میں نے خصوصیات کا استعمال کرتے ہوئے بنائی ہے۔ db-fiddle.com. 

db-fiddle.com پر مثال

وہاں، بائیں طرف، میدان میں Schema SQL، ایک کوڈ ہے جو ڈیٹا بیس میں 100000 قطاریں داخل کرتا ہے، اور دائیں طرف، فیلڈ میں Query SQL، دو سوالات دکھائے گئے ہیں۔ پہلا، سست، ایسا لگتا ہے:

SELECT *
FROM `docs`
LIMIT 10 OFFSET 85000;

اور دوسرا جو اسی مسئلے کا موثر حل ہے، اس طرح ہے:

SELECT *
FROM `docs`
WHERE id > 85000
LIMIT 10;

ان درخواستوں کو پورا کرنے کے لیے، صرف بٹن پر کلک کریں۔ Run صفحے کے اوپری حصے میں۔ ایسا کرنے کے بعد، ہم استفسار کے عمل کے وقت کے بارے میں معلومات کا موازنہ کرتے ہیں۔ اس سے پتہ چلتا ہے کہ ایک ناکارہ استفسار کو انجام دینے میں دوسرے سوال پر عمل درآمد کرنے میں کم از کم 30 گنا زیادہ وقت لگتا ہے (یہ وقت رن سے رن تک مختلف ہوتا ہے؛ مثال کے طور پر، سسٹم یہ رپورٹ کر سکتا ہے کہ پہلی استفسار کو مکمل ہونے میں 37 ایم ایس لگے، لیکن اس پر عمل درآمد دوسرا - 1 ایم ایس)۔

اور اگر زیادہ ڈیٹا ہے تو سب کچھ اور بھی خراب نظر آئے گا (اس بات کا یقین کرنے کے لیے، میرا مثال کے طور پر 10 ملین قطاروں کے ساتھ)۔

ہم نے ابھی جو بات کی ہے اس سے آپ کو اس بارے میں کچھ بصیرت ملنی چاہئے کہ ڈیٹا بیس کے سوالات کو حقیقت میں کیسے پروسیس کیا جاتا ہے۔

براہ کرم نوٹ کریں کہ قیمت جتنی زیادہ ہوگی۔ OFFSET - درخواست کو مکمل ہونے میں جتنا زیادہ وقت لگے گا۔

OFFSET اور LIMIT کے امتزاج کے بجائے مجھے کیا استعمال کرنا چاہیے؟

مرکب کے بجائے OFFSET и LIMIT یہ مندرجہ ذیل اسکیم کے مطابق تعمیر کردہ ڈھانچے کا استعمال کرنے کے قابل ہے:

SELECT * FROM table_name WHERE id > 10 LIMIT 20

یہ کرسر پر مبنی صفحہ بندی کے ساتھ استفسار پر عمل درآمد ہے۔

موجودہ کو مقامی طور پر ذخیرہ کرنے کے بجائے OFFSET и LIMIT اور انہیں ہر درخواست کے ساتھ منتقل کریں، آپ کو آخری موصول شدہ بنیادی کلید کو ذخیرہ کرنے کی ضرورت ہے (عام طور پر یہ ہے ID) اور LIMIT، نتیجے کے طور پر، مندرجہ بالا سے ملتے جلتے سوالات حاصل کیے جائیں گے۔

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

آئیے مختلف سوالات کے درج ذیل کارکردگی کے موازنہ پر ایک نظر ڈالتے ہیں۔ یہاں ایک غیر موثر استفسار ہے۔

سست درخواست

اور یہاں اس درخواست کا ایک بہتر ورژن ہے۔

فوری درخواست

دونوں استفسارات بالکل یکساں ڈیٹا واپس کرتے ہیں۔ لیکن پہلے والے کو مکمل ہونے میں 12,80 سیکنڈ لگتے ہیں، اور دوسرے کو 0,01 سیکنڈ لگتے ہیں۔ کیا آپ فرق محسوس کرتے ہیں؟

ممکنہ مسائل

استفسار کے مجوزہ طریقہ کو مؤثر طریقے سے کام کرنے کے لیے، جدول میں ایک کالم (یا کالم) ہونا چاہیے جس میں منفرد، ترتیب وار اشاریہ جات ہوں، جیسے کہ عددی شناخت کنندہ۔ کچھ مخصوص معاملات میں، یہ ڈیٹا بیس کے ساتھ کام کرنے کی رفتار بڑھانے کے لیے اس طرح کے سوالات کے استعمال کی کامیابی کا تعین کر سکتا ہے۔

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

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

اگر آپ اس موضوع میں دلچسپی رکھتے ہیں - یہاں, یہاں и یہاں - کئی مفید مواد۔

کے نتائج

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

آپ ڈیٹا بیس کے سوالات کا تجزیہ اور اصلاح کیسے کرتے ہیں؟

ماخذ: www.habr.com