صفحو ڪيل سوالن ۾ OFFSET ۽ LIMIT استعمال ڪرڻ کان پاسو ڪريو

اهي ڏينهن ويا آهن جڏهن توهان کي ڊيٽابيس جي ڪارڪردگي کي بهتر ڪرڻ بابت پريشان ٿيڻ جي ضرورت نه هئي. وقت بيٺو ناهي. هر نئون ٽيڪني ڪاروبار ايندڙ Facebook ٺاهڻ چاهي ٿو، جڏهن ته اهي سڀئي ڊيٽا گڏ ڪرڻ جي ڪوشش ڪري رهيا آهن جيڪي اهي هٿ ڪري سگهن ٿا. ڪاروبار کي ھن ڊيٽا جي ضرورت آھي بھترين ٽريننگ ماڊل جيڪي انھن کي پئسا ڪمائڻ ۾ مدد ڪن ٿيون. اهڙين حالتن ۾، پروگرامرز کي APIs ٺاهڻ جي ضرورت آهي جيڪي انهن کي جلدي ۽ معتبر طور تي معلومات جي وڏي مقدار سان ڪم ڪرڻ جي اجازت ڏين ٿيون.

جيڪڏهن توهان ڪنهن به وقت تائين ايپليڪيشن يا ڊيٽابيس جي پس منظر کي ڊزائين ڪري رهيا آهيو، توهان شايد صفحو ڪيل سوالن کي هلائڻ لاءِ ڪوڊ لکيو آهي. مثال طور، هن طرح:

SELECT * FROM table_name LIMIT 10 OFFSET 40

اهو طريقو آهي؟

پر جيڪڏهن توهان هن طرح ڪيو آهي توهان جو صفحو، مون کي افسوس آهي ته توهان اهو سڀ کان وڌيڪ موثر طريقي سان نه ڪيو آهي.

ڇا توهان مون تي اعتراض ڪرڻ چاهيو ٿا؟ توهان ڪري سگهو ٿا نه خرچ ڪرڻ время. سست, Shopify и ميڪسڪس اهي اڳ ۾ ئي ٽيڪنالاجي استعمال ڪري رهيا آهن جن بابت آئون اڄ ڳالهائڻ چاهيان ٿو.

نالو گهٽ ۾ گهٽ هڪ پس منظر ڊولپر جنهن ڪڏهن به استعمال نه ڪيو آهي OFFSET и LIMIT صفحن تي ٻڌل سوالن کي انجام ڏيڻ لاء. MVP ۾ (گهٽ ۾ گهٽ قابل عمل پراڊڪٽ) ۽ منصوبن ۾ جتي ڊيٽا جي ننڍي مقدار استعمال ڪئي ويندي آهي، اهو طريقو بلڪل قابل اطلاق آهي. اهو "صرف ڪم ڪري ٿو،" تنهنڪري ڳالهائڻ لاء.

پر جيڪڏهن توهان کي شروع کان قابل اعتماد ۽ ڪارائتو سسٽم ٺاهڻ جي ضرورت آهي، توهان کي اڳ ۾ ئي خيال رکڻ گهرجي ته اهڙين سسٽمن ۾ استعمال ٿيندڙ ڊيٽابيس بابت سوال ڪرڻ جي ڪارڪردگي بابت.

اڄ اسان انهن مسئلن جي باري ۾ ڳالهائينداسين جيڪي عام طور تي استعمال ٿيل (ڏاڍو خراب) پيجن ٿيل سوال انجڻ جي عملن سان، ۽ ڪيئن اعلي ڪارڪردگي حاصل ڪرڻ لاء جڏهن اهڙن سوالن تي عمل ڪندي.

OFFSET ۽ LIMIT سان ڇا غلط آهي؟

جيئن اڳ ئي چيو ويو آهي ، OFFSET и LIMIT اهي منصوبن ۾ سٺو ڪم ڪن ٿيون جيڪي ڊيٽا جي وڏي مقدار سان ڪم ڪرڻ جي ضرورت ناهي.

مسئلو تڏهن پيدا ٿئي ٿو جڏهن ڊيٽابيس اهڙي سائيز تائين وڌي وڃي جو اهو هاڻي سرور جي ياداشت ۾ نه ٿو اچي. تنهن هوندي، جڏهن هن ڊيٽابيس سان ڪم ڪري رهيا آهيو، توهان کي استعمال ڪرڻ جي ضرورت پوندي صفحو سوالن.

ھن مسئلي لاءِ پاڻ کي ظاھر ڪرڻ لاءِ، ھڪ اھڙي صورتحال ھئڻ گھرجي جنھن ۾ DBMS ھڪ غير موثر فل ٽيبل اسڪين آپريشن کي ھر صفحي تي رکيل سوالن تي ھلي ٿو (جڏھن ته داخل ڪرڻ ۽ حذف ڪرڻ جا عمل ٿي سگھن ٿا، ۽ اسان کي پراڻي ڊيٽا جي ضرورت نه آھي!).

ڇا آهي "مڪمل ٽيبل اسڪين" (يا "ترتيب واري ٽيبل اسڪين"، ترتيب واري اسڪين)؟ هي هڪ آپريشن آهي جنهن دوران 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, نتيجي طور، مٿي ڄاڻايل سوالن سان گڏ حاصل ڪيا ويندا.

ڇو؟ نقطي اهو آهي ته واضح طور تي پڙتال جي آخري قطار جي سڃاڻپ ڪندڙ کي بيان ڪندي، توهان پنهنجي ڊي بي ايم ايس کي ٻڌايو جتي اهو ضروري ڊيٽا ڳولڻ شروع ڪرڻ جي ضرورت آهي. ان کان علاوه، ڳولا، چيڪ جي استعمال جي مهرباني، موثر طريقي سان ڪيو ويندو؛ سسٽم کي مخصوص حد کان ٻاهر لڪير کان پريشان ٿيڻ جي ضرورت ناهي.

اچو ته مختلف سوالن جي مقابلي ۾ هيٺين ڪارڪردگي تي هڪ نظر رکون. هتي هڪ غير موثر سوال آهي.

سست درخواست

۽ هتي هن درخواست جو هڪ بهتر نسخو آهي.

جلدي درخواست

ٻنهي سوالن کي ڊيٽا جي ساڳئي مقدار واپس آڻيندي. پر پهريون مڪمل ٿيڻ ۾ 12,80 سيڪنڊن جو وقت وٺندو آهي، ۽ ٻيو هڪ 0,01 سيڪنڊ وٺندو آهي. ڇا توهان فرق محسوس ڪندا آهيو؟

ممڪن مسئلا

تجويز ڪيل سوال جي طريقي سان مؤثر طريقي سان ڪم ڪرڻ لاء، ٽيبل ۾ لازمي طور تي هڪ ڪالمن (يا ڪالمن) هجڻ گهرجي، جنهن ۾ منفرد، ترتيب وار انڊيڪس، جهڙوڪ هڪ عددي سڃاڻپ ڪندڙ. ڪجهه مخصوص حالتن ۾، اهو ڊيٽابيس سان ڪم ڪرڻ جي رفتار کي وڌائڻ لاء اهڙن سوالن کي استعمال ڪرڻ جي ڪاميابي جو اندازو لڳائي سگھي ٿو.

قدرتي طور تي، سوالن جي تعمير ڪرڻ وقت، توهان کي جدولن جي مخصوص آرڪيٽيڪچر کي ڌيان ڏيڻ جي ضرورت آهي ۽ انهن ميکانيزم کي چونڊڻ جي ضرورت آهي جيڪا موجوده ٽيبل تي بهترين ڪم ڪندي. مثال طور، جيڪڏهن توهان کي لاڳاپيل ڊيٽا جي وڏي مقدار سان سوالن ۾ ڪم ڪرڻ جي ضرورت آهي، توهان شايد اهو دلچسپ ڳولي سگهو ٿا هي مضمون.

جيڪڏهن اسان کي هڪ بنيادي چاٻي غائب ٿيڻ جي مسئلي سان منهن ڏيڻو پوي ٿو، مثال طور، جيڪڏهن اسان وٽ هڪ ٽيبل آهي جنهن سان ڪيترن ئي رشتن سان، پوء استعمال ڪرڻ جو روايتي طريقو OFFSET и LIMIT، اسان کي مناسب ڪرڻ جي ضمانت آهي. پر ان جو استعمال ممڪن طور تي سست سوالن جي نتيجي ۾ ٿي سگھي ٿو. اهڙين حالتن ۾، آئون استعمال ڪرڻ جي صلاح ڏيندس هڪ آٽو-وڌندڙ پرائمري ڪيچ، جيتوڻيڪ اهو صرف گهربل سوالن کي سنڀالڻ جي ضرورت آهي.

جيڪڏھن توھان ھن موضوع ۾ دلچسپي رکو ٿا - ڏس, ڏس и ڏس - ڪيترائي مفيد مواد.

نتيجو

بنيادي نتيجو جيڪو اسان ڪڍي سگھون ٿا اهو آهي ته، اسان ڊيٽابيس جي ڪهڙي سائيز بابت ڳالهائي رهيا آهيون، اهو هميشه ضروري آهي ته سوال جي عمل جي رفتار جو تجزيو ڪيو وڃي. اڄڪلهه، حل جي گنجائش انتهائي اهم آهي، ۽ جيڪڏهن هر شيء صحيح طريقي سان ٺهيل آهي هڪ خاص سسٽم تي ڪم ڪرڻ جي شروعات کان، اهو، مستقبل ۾، ڊولپر کي ڪيترن ئي مسئلن کان بچائي سگهي ٿو.

توهان ڊيٽابيس جي سوالن کي ڪيئن تجزيو ۽ بهتر بڻائي سگهو ٿا؟

جو ذريعو: www.habr.com