سب کو سلام! میں جاوا + اسپرنگ میں مائیکرو سروسز لکھنے والا بیک اینڈ ڈویلپر ہوں۔ میں Tinkoff میں اندرونی مصنوعات کی ترقی کی ٹیموں میں سے ایک میں کام کرتا ہوں۔
ہماری ٹیم میں، ڈی بی ایم ایس میں سوالات کو بہتر بنانے کا سوال اکثر پیدا ہوتا ہے۔ آپ ہمیشہ تھوڑا تیز بننا چاہتے ہیں، لیکن آپ ہمیشہ سوچ سمجھ کر بنائے گئے اشاریہ جات کے ساتھ حاصل نہیں کر سکتے ہیں — آپ کو کچھ حل تلاش کرنا ہوں گے۔ ڈیٹا بیس کے ساتھ کام کرتے وقت معقول اصلاح کی تلاش میں ویب کے ارد گرد گھومنے پھرنے میں سے ایک کے دوران، میں نے پایا ، ایس کیو ایل پرفارمنس کے مصنف نے وضاحت کی ہے۔ یہ وہ نایاب قسم کا بلاگ ہے جس میں آپ لگاتار تمام مضامین پڑھ سکتے ہیں۔
میں آپ کے لیے مارکس کے ایک مختصر مضمون کا ترجمہ کرنا چاہوں گا۔ اسے کسی حد تک منشور کہا جا سکتا ہے جو ایس کیو ایل کے معیار کے مطابق آفسیٹ آپریشن کی کارکردگی کے پرانے لیکن پھر بھی متعلقہ مسئلے کی طرف توجہ مبذول کروانے کی کوشش کرتا ہے۔
کچھ جگہوں پر میں وضاحت اور تبصرے کے ساتھ مصنف کی تکمیل کروں گا۔ میں ایسی تمام جگہوں کو "تقریبا" کے طور پر حوالہ دوں گا۔ مزید وضاحت کے لیے
چھوٹا تعارف
میرے خیال میں بہت سے لوگ جانتے ہیں کہ آفسیٹ کے ذریعے پیج سلیکٹ کے ساتھ کام کرنا کتنا مشکل اور سست ہے۔ کیا آپ جانتے ہیں کہ اسے زیادہ موثر ڈیزائن کے ساتھ آسانی سے تبدیل کیا جا سکتا ہے؟
لہذا، آفسیٹ مطلوبہ لفظ ڈیٹا بیس کو درخواست میں پہلے n ریکارڈز کو چھوڑنے کے لیے کہتا ہے۔ تاہم، ڈیٹا بیس کو ابھی بھی ڈسک سے ان پہلے n ریکارڈز کو پڑھنے کی ضرورت ہے، دی گئی ترتیب میں (نوٹ: چھانٹنا لاگو کریں اگر یہ مخصوص ہے)، اور اس کے بعد ہی n+1 سے ریکارڈ واپس کرنا ممکن ہوگا۔ سب سے دلچسپ بات یہ ہے کہ مسئلہ DBMS میں مخصوص نفاذ میں نہیں ہے، بلکہ معیار کے مطابق اصل تعریف میں ہے:
…قطاریں پہلے کے مطابق ترتیب دی جاتی ہیں۔ اور پھر میں مخصوص قطاروں کی تعداد کو چھوڑ کر محدود شروع سے…
-SQL:2016، حصہ 2، 4.15.3 اخذ کردہ میزیں (نوٹ: فی الحال سب سے زیادہ استعمال شدہ معیار)
یہاں اہم نکتہ یہ ہے کہ آفسیٹ ایک پیرامیٹر لیتا ہے - چھوڑنے کے لیے ریکارڈز کی تعداد، اور بس۔ اس تعریف کے بعد، DBMS صرف تمام ریکارڈز کو بازیافت کر سکتا ہے اور پھر غیر ضروری کو ضائع کر سکتا ہے۔ ظاہر ہے، آفسیٹ کی یہ تعریف ہمیں اضافی کام کرنے پر مجبور کرتی ہے۔ اور اس سے کوئی فرق نہیں پڑتا کہ یہ SQL ہے یا NoSQL۔
بس تھوڑا سا اور درد
آفسیٹ کے مسائل وہیں ختم نہیں ہوتے، اور اس کی وجہ یہ ہے۔ اگر، ڈسک سے ڈیٹا کے دو صفحات کو پڑھنے کے درمیان، دوسرا آپریشن ایک نیا ریکارڈ داخل کرتا ہے، اس صورت میں کیا ہوگا؟
جب آفسیٹ کا استعمال پچھلے صفحات سے ریکارڈ کو چھوڑنے کے لیے کیا جاتا ہے، مختلف صفحات کے پڑھنے کے درمیان ایک نیا ریکارڈ شامل کرنے کی صورت میں، آپ کو زیادہ تر ممکنہ طور پر ڈپلیکیٹس ملیں گے (نوٹ: یہ تب ممکن ہے جب ہم ترتیب کے ذریعے ترتیب کا استعمال کرتے ہوئے صفحہ بہ صفحہ پڑھیں، پھر ہمارے آؤٹ پٹ کے وسط میں اسے ایک نئی انٹری مل سکتی ہے)۔
اعداد و شمار واضح طور پر اس صورت حال کو ظاہر کرتا ہے. بیس پہلے 10 ریکارڈز کو پڑھتا ہے، جس کے بعد ایک نیا ریکارڈ داخل کیا جاتا ہے، جو تمام پڑھے جانے والے ریکارڈز کو 1 سے پورا کرتا ہے۔ پھر بیس اگلے 10 ریکارڈز سے ایک نیا صفحہ لیتا ہے اور 11ویں سے شروع نہیں ہوتا، جیسا کہ ہونا چاہیے، بلکہ 10 واں، اس ریکارڈ کو نقل کرنا۔ اس اظہار کے استعمال سے وابستہ دیگر بے ضابطگییں ہیں، لیکن یہ سب سے عام ہے۔
جیسا کہ ہم پہلے ہی جان چکے ہیں، یہ کسی مخصوص DBMS یا ان کے نفاذ کے مسائل نہیں ہیں۔ مسئلہ ایس کیو ایل کے معیار کے مطابق صفحہ بندی کی وضاحت میں ہے۔ ہم DBMS کو بتاتے ہیں کہ کون سا صفحہ لانا ہے یا کتنے ریکارڈ کو چھوڑنا ہے۔ ڈیٹا بیس اس طرح کی درخواست کو بہتر بنانے کے قابل نہیں ہے، کیونکہ اس کے لیے بہت کم معلومات موجود ہیں۔
یہ بھی واضح کرنے کے قابل ہے کہ یہ کسی مخصوص مطلوبہ الفاظ کا مسئلہ نہیں ہے، بلکہ استفسار کے الفاظ کے ساتھ ہے۔ اس کے علاوہ اور بھی کئی نحو ہیں جو اپنی پریشانی کی نوعیت میں یکساں ہیں:
- آفسیٹ کلیدی لفظ جیسا کہ پہلے ذکر کیا گیا ہے۔
- دو مطلوبہ الفاظ کی حد [آفسیٹ] کی تعمیر (حالانکہ حد خود اتنی بری نہیں ہے)۔
- قطار کی تعداد (مثال کے طور پر، row_number()، rownum، وغیرہ) کی بنیاد پر نچلی حدوں سے فلٹر کرنا۔
یہ تمام تاثرات صرف آپ کو بتاتے ہیں کہ کتنی لائنوں کو چھوڑنا ہے، کوئی اضافی معلومات یا سیاق و سباق نہیں۔
بعد میں اس مضمون میں، آفسیٹ کی ورڈ کو ان تمام اختیارات کے خلاصے کے طور پر استعمال کیا گیا ہے۔
آف سیٹ کے بغیر زندگی
اب آئیے تصور کریں کہ ان تمام مسائل کے بغیر ہماری دنیا کیسی ہوگی۔ یہ پتہ چلتا ہے کہ آفسیٹ کے بغیر زندگی اتنی مشکل نہیں ہے: ایک انتخاب کے ساتھ، آپ صرف وہ قطاریں منتخب کر سکتے ہیں جو ہم نے ابھی تک نہیں دیکھی ہیں (نوٹ: یعنی وہ جو پچھلے صفحے پر نہیں تھیں)، جہاں کی شرط کا استعمال کرتے ہوئے.
اس معاملے میں، ہم اس حقیقت سے شروع کرتے ہیں کہ سلیکٹس کو ایک آرڈر شدہ سیٹ پر عمل میں لایا جاتا ہے (اچھے پرانے آرڈر کی طرف سے)۔ چونکہ ہمارے پاس آرڈر شدہ سیٹ ہے، اس لیے ہم صرف وہی ڈیٹا حاصل کرنے کے لیے کافی آسان فلٹر استعمال کر سکتے ہیں جو پچھلے صفحے کے آخری ریکارڈ کے پیچھے ہے:
SELECT ...
FROM ...
WHERE ...
AND id < ?last_seen_id
ORDER BY id DESC
FETCH FIRST 10 ROWS ONLYیہ اس نقطہ نظر کا پورا اصول ہے۔ بے شک، بہت سے کالموں کے حساب سے چھانٹتے وقت چیزیں زیادہ مزہ آتی ہیں، لیکن خیال اب بھی وہی ہے۔ یہ نوٹ کرنا ضروری ہے کہ یہ ڈیزائن بہت سے لوگوں پر لاگو ہوتا ہے۔ -فیصلے
اس نقطہ نظر کو سیک میتھڈ یا کی سیٹ پیجنیشن کہا جاتا ہے۔ یہ فلوٹنگ رزلٹ کے مسئلے کو حل کرتا ہے (نوٹ: صفحہ پڑھنے کے درمیان لکھنے کی صورت حال پہلے بیان کی گئی ہے) اور یقیناً، جو ہم سب کو پسند ہے، یہ کلاسک آفسیٹ سے زیادہ تیز اور مستحکم کام کرتا ہے۔ استحکام اس حقیقت میں مضمر ہے کہ درخواست پر کارروائی کا وقت درخواست کردہ ٹیبل کی تعداد کے تناسب سے نہیں بڑھتا ہے (نوٹ: اگر آپ صفحہ بندی کے مختلف طریقوں کے کام کے بارے میں مزید جاننا چاہتے ہیں، تو آپ . آپ وہاں مختلف طریقوں کے لیے تقابلی معیارات بھی تلاش کر سکتے ہیں)۔
سلائیڈوں میں سے ایک کلیدوں کے ذریعے صفحہ بندی، یقیناً، قادر مطلق نہیں ہے - اس کی اپنی حدود ہیں۔ سب سے اہم بات یہ ہے کہ وہ بے ترتیب صفحات کو پڑھنے کی صلاحیت نہیں رکھتی ہے (نوٹ: متضاد طور پر)۔ تاہم، لامتناہی سکرولنگ کے دور میں (نوٹ: سامنے والے سرے پر)، یہ ایسی کوئی پریشانی نہیں ہے۔ کلک کرنے کے لیے صفحہ نمبر بتانا ویسے بھی UI ڈیزائن میں ایک برا فیصلہ ہے (نوٹ: مضمون کے مصنف کی رائے)۔
آلات کے بارے میں کیا خیال ہے؟
کلیدوں پر صفحہ بندی اکثر اس طریقہ کار کے لیے آلہ کار کی حمایت کی کمی کی وجہ سے موزوں نہیں ہوتی ہے۔ زیادہ تر ترقیاتی ٹولز، بشمول مختلف فریم ورک، آپ کو یہ انتخاب کرنے کی اجازت نہیں دیتے ہیں کہ صفحہ بندی کیسے کی جائے گی۔
صورتحال اس حقیقت سے مزید گھمبیر ہو گئی ہے کہ بیان کردہ طریقہ کو استعمال کی جانے والی ٹیکنالوجیز میں اینڈ ٹو اینڈ سپورٹ کی ضرورت ہے - DBMS سے لے کر لامتناہی سکرولنگ کے ساتھ براؤزر میں AJAX کی درخواست پر عمل درآمد تک۔ صرف صفحہ نمبر بتانے کے بجائے، اب آپ کو ایک ساتھ تمام صفحات کے لیے کلیدوں کا ایک سیٹ بتانا ہوگا۔
تاہم، کیز پر صفحہ بندی کی حمایت کرنے والے فریم ورکس کی تعداد بتدریج بڑھ رہی ہے۔ ہمارے پاس اس وقت کیا ہے:
- جاوا کے لیے؛
- روبی کے لیے؛
- и جینگو کے لیے؛
- ازگر کے لیے؛
- JPA کے نفاذ کے لیے معیار API؛
- پرل کے لیے
- Node.js کے لیے میپر .
(نوٹ: کچھ لنکس اس حقیقت کی وجہ سے ہٹا دیے گئے تھے کہ ترجمہ کے وقت کچھ لائبریریوں کو 2017-2018 سے اپ ڈیٹ نہیں کیا گیا تھا۔ اگر آپ دلچسپی رکھتے ہیں تو آپ اصل ماخذ کو دیکھ سکتے ہیں۔)
اس وقت آپ کی مدد کی ضرورت ہے۔ اگر آپ کسی ایسے فریم ورک کو تیار کرتے ہیں یا اس کی حمایت کرتے ہیں جو صفحہ بندی کا کوئی استعمال کرتا ہے، تو میں آپ سے درخواست کرتا ہوں، میں آپ سے درخواست کرتا ہوں کہ کیز پر صفحہ بندی کے لیے مقامی مدد فراہم کریں۔ اگر آپ کے سوالات ہیں یا مدد کی ضرورت ہے تو مجھے مدد کرنے میں خوشی ہوگی (, , ) (نوٹ: مارکس کے ساتھ میرے تجربے سے، میں کہہ سکتا ہوں کہ وہ واقعی اس موضوع کو پھیلانے کے لیے پرجوش ہیں)۔
اگر آپ ریڈی میڈ حل استعمال کرتے ہیں جو آپ کے خیال میں کلیدوں کے ذریعے صفحہ بندی کے لیے تعاون کے لائق ہیں، تو ایک درخواست بنائیں یا یہاں تک کہ اگر ممکن ہو تو ایک ریڈی میڈ حل پیش کریں۔ آپ اس مضمون کا لنک بھی دے سکتے ہیں۔
حاصل يہ ہوا
کلیدوں کے ذریعے صفحہ بندی جیسا آسان اور مفید نقطہ نظر وسیع پیمانے پر نہ ہونے کی وجہ یہ نہیں ہے کہ اسے تکنیکی طور پر لاگو کرنا مشکل ہے یا کسی بڑی کوشش کی ضرورت ہے۔ بنیادی وجہ یہ ہے کہ بہت سے لوگ آفسیٹ کے ساتھ دیکھنے اور کام کرنے کے عادی ہیں - یہ نقطہ نظر خود معیار کے مطابق ہے۔
نتیجے کے طور پر، بہت کم لوگ صفحہ بندی کے نقطہ نظر کو تبدیل کرنے کے بارے میں سوچتے ہیں، اور اس کی وجہ سے، فریم ورک اور لائبریریوں کی طرف سے سازگار تعاون خراب طور پر ترقی کر رہا ہے۔ لہذا، اگر آفسیٹ سے پاک صفحہ بندی کا خیال اور ہدف آپ کے قریب ہے، تو اسے پھیلانے میں مدد کریں!
ماخذ:
مصنف: مارکس وائننڈ
ماخذ: www.habr.com