په پاڼه شوي پوښتنو کې د OFFSET او LIMIT کارولو څخه ډډه وکړئ

هغه ورځې تیرې شوې کله چې تاسو د ډیټابیس فعالیت اصلاح کولو په اړه اندیښنه نلرئ. وخت په ټپه ولاړ نه دی. هر نوی ټیکنالوژي متشبثین غواړي راتلونکی فیسبوک رامینځته کړي، پداسې حال کې چې هڅه کوي ټول معلومات راټول کړي چې دوی یې لاس ته راوړي. سوداګرۍ دې ډیټا ته اړتیا لري ترڅو غوره ماډلونه وروزي چې د دوی سره د پیسو ګټلو کې مرسته وکړي. په داسې شرایطو کې، پروګرام کونکي اړتیا لري چې APIs رامینځته کړي چې دوی ته اجازه ورکوي په چټکه او باوري توګه د ډیرو معلوماتو سره کار وکړي.

که تاسو د هر وخت لپاره غوښتنلیک یا ډیټابیس بیکینډ ډیزاین کوئ، نو تاسو شاید د پاڼې پوښښ پوښتنو چلولو لپاره کوډ لیکلی وي. د مثال په توګه، دا ډول:

SELECT * FROM table_name LIMIT 10 OFFSET 40

دا څنګه ده؟

خو که دا کار مو کړی وي، نو زه په بخښنه غواړم ووایم چې تاسو دا په خورا اغیزمنه توګه نه دی ترسره کړی.

ته غواړې چې پر ما اعتراض وکړې؟ تاسو کولی شئ نه لګول время. پوځيان له, Shopify и مکس میکس دوی لا دمخه هغه تخنیکونه کاروي چې زه یې نن ورځ په اړه خبرې کول غواړم.

لږترلږه د یو بیک انډ پراختیا کونکي نوم ورکړئ چې هیڅکله یې نه دی کارولی OFFSET и LIMIT د مخونو پوښتنو ترسره کولو لپاره. په MVP کې (لږترلږه ګټور محصول) او په هغو پروژو کې چیرې چې لږ مقدار ډاټا کارول کیږي، دا طریقه خورا د تطبیق وړ ده. دا "یوازې کار کوي،" نو د خبرو کولو لپاره.

مګر که تاسو له پیل څخه د باور وړ او موثر سیسټمونو رامینځته کولو ته اړتیا لرئ ، نو تاسو باید دمخه په داسې سیسټمونو کې کارول شوي ډیټابیسونو پوښتنې کولو موثریت ته پاملرنه وکړئ.

نن ورځ موږ به د هغو ستونزو په اړه وغږیږو چې په عام ډول کارول شوي (ډیر خراب) د مخ شوي پوښتنو انجنونو پلي کولو سره ، او څنګه د دې ډول پوښتنو پلي کولو پرمهال لوړ فعالیت ترلاسه کول.

د OFFSET او LIMIT سره څه ستونزه ده؟

لکه څنګه چې مخکې وویل شول ، OFFSET и LIMIT دوی په پروژو کې ښه فعالیت کوي چې اړتیا نلري د لوی مقدار ډیټا سره کار وکړي.

ستونزه هغه وخت رامینځته کیږي کله چې ډیټابیس دومره اندازې ته وده ورکړي چې دا نور د سرور په حافظه کې نه فټ کیږي. په هرصورت، کله چې د دې ډیټابیس سره کار کول، تاسو اړتیا لرئ چې د مخ شوي پوښتنو څخه کار واخلئ.

د دې لپاره چې دا ستونزه پخپله ښکاره شي، باید داسې یو حالت وي چې DBMS د هرې پاڼې شوي پوښتنې په اړه د بشپړ جدول سکین عملیاتو ته لاره هواره کړي (پداسې حال کې چې د ننوتلو او حذف کولو عملیات ممکن واقع شي، او موږ زاړه ډاټا ته اړتیا نلرو!).

د "بشپړ جدول سکین" (یا "د ترتیب میز سکین"، ترتیب سکین) څه شی دی؟ دا یو عملیات دی چې په ترڅ کې یې DBMS په ترتیب سره د میز هر قطار لوستل کوي، دا هغه معلومات دي چې پدې کې شامل دي، او د ورکړل شوي حالت سره مطابقت لپاره یې ګوري. دا ډول میز سکین خورا ورو پیژندل کیږي. حقیقت دا دی چې کله دا اجرا کیږي، ډیری ان پټ/آؤټ پټ عملیات ترسره کیږي چې د سرور ډیسک فرعي سیسټم پکې شامل وي. وضعیت په ډیسکونو کې زیرمه شوي ډیټا سره کار کولو پورې اړوند د ځنډ له امله خراب شوی ، او دا حقیقت چې له ډیسک څخه حافظې ته د ډیټا لیږدول د سرچینې ژور عملیات دي.

د مثال په توګه، تاسو د 100000000 کاروونکو ریکارډونه لرئ او تاسو د ساختمان سره یوه پوښتنه پرمخ وړئ OFFSET 50000000. دا پدې مانا ده چې DBMS باید دا ټول ریکارډونه پورته کړي (او موږ حتی دوی ته اړتیا نلرو!)، په حافظه کې یې وسپارو، او له هغې وروسته، ووایه، 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 ms وخت نیولی، مګر د پلټنې اجرا کول دوهم - 1 ms).

او که چیرې ډیر معلومات شتون ولري ، نو هرڅه به نور هم خراب ښکاري (د دې لپاره د قناعت لپاره ، زما نظر وګورئ مثال د 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