paginated queries တွင် OFFSET နှင့် LIMIT ကိုအသုံးပြုခြင်းကို ရှောင်ကြဉ်ပါ။

ဒေတာဘေ့စ်စွမ်းဆောင်ရည်ကို ပိုကောင်းအောင်လုပ်ဖို့ စိတ်ပူစရာမလိုတဲ့ နေ့တွေ ကုန်သွားပါပြီ။ အချိန်က ငြိမ်မနေပါဘူး။ နည်းပညာစွန့်ဦးတီထွင်သူတိုင်းဟာ သူတို့လက်လှမ်းမီနိုင်တဲ့ ဒေတာအားလုံးကို စုဆောင်းဖို့ ကြိုးစားရင်းနဲ့ နောက်ထပ် Facebook ကို ဖန်တီးချင်ကြပါတယ်။ လုပ်ငန်းများသည် ငွေရှာရန် ကူညီပေးသော ပိုမိုကောင်းမွန်သော မော်ဒယ်များကို လေ့ကျင့်ရန် ဤဒေတာကို လိုအပ်ပါသည်။ ထိုသို့သောအခြေအနေများတွင်၊ ပရိုဂရမ်မာများသည် အချက်အလက်အများအပြားဖြင့် လျင်မြန်စွာ ယုံကြည်စိတ်ချစွာ အလုပ်လုပ်နိုင်စေမည့် API များကို ဖန်တီးရန်လိုအပ်သည်။

အကယ်၍ သင်သည် အပလီကေးရှင်း သို့မဟုတ် ဒေတာဘေ့စ်နောက်ကွယ်တွင် အချိန်အတိုင်းအတာတစ်ခုအထိ ဒီဇိုင်းဆွဲနေပါက၊ paginated queries ကို run ရန် ကုဒ်ကို သင်ရေးသားပြီးဖြစ်နိုင်သည်။ ဥပမာ၊ ဤကဲ့သို့သော၊

SELECT * FROM table_name LIMIT 10 OFFSET 40

ဘယ်လိုပုံစံလဲ?

ဒါပေမယ့် မင်းရဲ့ pagination လုပ်ပုံက ဒီလိုဆိုရင်၊ အထိရောက်ဆုံးနည်းလမ်းနဲ့ မလုပ်ခဲ့ဘူးလို့ တောင်းပန်ပါတယ်။

မင်းက ငါ့ကို ကန့်ကွက်ချင်လား။ နိုင် မဟုတ် သုံးစွဲ время. ပျင်းရိ, Shopify и Mixmax ဒီနေ့ ကျွန်တော်ပြောချင်တဲ့ နည်းပညာတွေကို သူတို့ သုံးနေကြပါပြီ။

အသုံးမပြုဖူးသော နောက်ခံဆော့ဖ်ဝဲရေးသားသူ အနည်းဆုံးတစ်ဦးကို အမည်ပေးပါ။ OFFSET и LIMIT paginated မေးခွန်းများကိုလုပ်ဆောင်ရန်။ MVP (Minimum Viable Product) နှင့် ဒေတာအနည်းငယ်ကို အသုံးပြုသည့် ပရောဂျက်များတွင်၊ ဤချဉ်းကပ်မှုသည် အတော်လေး သက်ဆိုင်ပါသည်။ “အလုပ်ဖြစ်တယ်” လို့ ပြောလို့ရတယ်။

ဒါပေမယ့် ယုံကြည်စိတ်ချရပြီး ထိရောက်တဲ့စနစ်တွေကို အစကနေပြန်ဖန်တီးဖို့ လိုအပ်တယ်ဆိုရင်၊ ဒီလိုစနစ်တွေမှာသုံးတဲ့ databases တွေကို မေးမြန်းခြင်းရဲ့ ထိရောက်မှုကို ကြိုတင်ဂရုစိုက်သင့်ပါတယ်။

ယနေ့ကျွန်ုပ်တို့သည် paginated query engines များ၏ အသုံးများသော (ဆိုးလွန်းသည်) ကို အကောင်အထည်ဖော်ခြင်းဆိုင်ရာ ပြဿနာများနှင့် ထိုမေးခွန်းများကို လုပ်ဆောင်သည့်အခါ မြင့်မားသောစွမ်းဆောင်ရည်ကို မည်သို့ရရှိစေမည်ကို ဆွေးနွေးပါမည်။

OFFSET နှင့် LIMIT တွင် ဘာပြဿနာရှိသနည်း။

ပြောပြီးသားအတိုင်း၊ OFFSET и LIMIT ၎င်းတို့သည် ဒေတာပမာဏများစွာဖြင့် လုပ်ဆောင်ရန်မလိုအပ်သော ပရောဂျက်များတွင် ကောင်းစွာလုပ်ဆောင်နိုင်သည်။

ဒေတာဘေ့စ်သည် ဆာဗာ၏မှတ်ဉာဏ်တွင် အံမဝင်တော့သည့် အရွယ်အစားအထိ ကြီးထွားလာသောအခါ ပြဿနာဖြစ်လာသည်။ သို့သော်၊ ဤဒေတာဘေ့စ်နှင့်အလုပ်လုပ်သောအခါ၊ သင်သည် paginated queries ကိုအသုံးပြုရန်လိုအပ်သည်။

ဤပြဿနာကို ထင်ရှားစေရန်အတွက်၊ DBMS သည် paginated query တစ်ခုစီတွင် ထိရောက်မှုမရှိသော Full Table Scan လုပ်ဆောင်ချက်ကို လုပ်ဆောင်ပေးသည့် အခြေအနေတစ်ခုရှိရမည် (ထည့်သွင်းခြင်းနှင့် ဖျက်ခြင်းလုပ်ဆောင်မှုများ ဖြစ်ပေါ်နိုင်ပြီး၊ ကျွန်ုပ်တို့သည် ခေတ်မမီသောဒေတာ မလိုအပ်ပါ။)။

"စားပွဲအပြည့်စကင်န်" (သို့မဟုတ် "ဇယားဆက်တိုက်စကင်န်"၊ ဆက်တိုက်စကင်န်ဆိုတာဘာလဲ။ ၎င်းသည် DBMS သည် ဇယား၏အတန်းတစ်ခုစီကို စဉ်ဆက်မပြတ်ဖတ်သည်၊ ဆိုလိုသည်မှာ ၎င်းတွင်ပါရှိသောဒေတာများကို ပေးထားသည့်အခြေအနေတစ်ခုနှင့် လိုက်လျောညီထွေရှိမရှိ စစ်ဆေးပေးသည့် လုပ်ဆောင်ချက်တစ်ခုဖြစ်သည်။ ဤဇယားကို စကင်ဖတ်ခြင်း အမျိုးအစားသည် အနှေးဆုံးဟု လူသိများသည်။ အမှန်မှာ ၎င်းကို လုပ်ဆောင်သောအခါတွင် ဆာဗာ၏ဒစ်ခွဲစနစ်ပါ၀င်သည့် အဝင်/အထွက် လုပ်ဆောင်ချက်များစွာကို လုပ်ဆောင်သည်။ disks များပေါ်တွင်သိမ်းဆည်းထားသောဒေတာများနှင့်အလုပ်လုပ်ခြင်းနှင့်ဆက်စပ်နေသော latency ကြောင့်အခြေအနေသည်ပိုမိုဆိုးရွားလာပြီး disk မှ memory သို့ data များကိုလွှဲပြောင်းခြင်းသည်အရင်းအမြစ်-အလွန်အကျွံလုပ်ဆောင်မှုတစ်ခုဖြစ်သည်။

ဥပမာအားဖြင့်၊ သင့်တွင် အသုံးပြုသူ 100000000 ၏ မှတ်တမ်းများ ရှိပြီး တည်ဆောက်ပုံနှင့် မေးမြန်းချက်တစ်ခုကို သင်လုပ်ဆောင်သည် OFFSET 50000000. ဆိုလိုသည်မှာ DBMS သည် ဤမှတ်တမ်းများအားလုံးကို တင်ရပါမည် (၎င်းတို့ကို ကျွန်ုပ်တို့ပင် မလိုအပ်ပါ!)၊ ၎င်းတို့ကို မှတ်ဉာဏ်ထဲတွင် ထည့်ထားပြီးနောက်တွင် အစီရင်ခံထားသော ရလဒ် 20 ကို ယူပါဟု ဆိုပါသည်။ LIMIT.

၎င်းသည် ဤကဲ့သို့သောပုံပေါက်သည်ဟု ဆိုကြပါစို့- "50000 မှ 50020 မှ 100000 အတန်းများကို ရွေးပါ"။ ဆိုလိုသည်မှာ၊ စနစ်သည် query ကို အပြီးသတ်ရန် အတန်း 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 စာမျက်နှာ၏ထိပ်တွင်။ ၎င်းကိုလုပ်ဆောင်ပြီးနောက်၊ ကျွန်ုပ်တို့သည် မေးမြန်းမှုလုပ်ဆောင်ချိန်နှင့်ပတ်သက်သည့် အချက်အလက်များကို နှိုင်းယှဉ်ပါသည်။ ထိရောက်မှုမရှိသော query တစ်ခုကို လုပ်ဆောင်ခြင်းသည် ဒုတိယတစ်ခုကို လုပ်ဆောင်ခြင်းထက် အနည်းဆုံး အဆ 30 ပိုကြာသည် (ဤအချိန်သည် run တစ်ခုနှင့်တစ်ခု run မှုကွဲပြားသည်၊ ဥပမာအားဖြင့်၊ ပထမ query သည် 37 ms ကြာမြင့်သည်ဟု system မှ တင်ပြနိုင်သော်လည်း၊ ဒုတိယ - 1 ms) ။

ဒေတာတွေ ပိုရှိနေရင် အရာအားလုံးက ပိုတောင်ဆိုးလာလိမ့်မယ် (ဒါကို ယုံချင်ရင် ငါ့မှာ ကြည့်ပါ။ နမူနာ အတန်း 10 သန်း)။

ကျွန်ုပ်တို့ ယခုလေးတင် ဆွေးနွေးခဲ့သည့်အရာသည် သင့်အား ဒေတာဘေ့စ်မေးခွန်းများကို မည်သို့လုပ်ဆောင်ကြောင်းကို ထိုးထွင်းသိမြင်စေသင့်သည်။

တန်ဖိုးမြင့်လေ သတိပြုပါ။ OFFSET - တောင်းဆိုမှုပြီးမြောက်ရန် အချိန်ပိုကြာလိမ့်မည်။

OFFSET နှင့် LIMIT ပေါင်းစပ်ရာ၌ အဘယ်အရာကို အသုံးပြုရမည်နည်း။

ပေါင်းစပ်အစား OFFSET и LIMIT အောက်ဖော်ပြပါအစီအစဥ်အတိုင်း တည်ဆောက်ထားသော အဆောက်အဦကို အသုံးပြု၍ရကျိုးနပ်ပါသည်။

SELECT * FROM table_name WHERE id > 10 LIMIT 20

၎င်းသည် cursor အခြေခံ pagination ဖြင့် query execute ဖြစ်သည်။

ပြည်တွင်းမှာ လက်ရှိသိမ်းဆည်းမယ့်အစား OFFSET и LIMIT တောင်းဆိုချက်တစ်ခုစီဖြင့် ၎င်းတို့ကို ပေးပို့ပါ၊ နောက်ဆုံးရရှိထားသော အဓိကသော့ကို သိမ်းဆည်းထားရန် လိုအပ်သည် (များသောအားဖြင့် ၎င်းသည် ဤအရာဖြစ်သည်။ ID) နှင့် LIMITထို့ကြောင့်၊ အထက်ဖော်ပြပါမေးခွန်းများနှင့် အလားတူမေးခွန်းများကို ရရှိမည်ဖြစ်ပါသည်။

အဘယ်ကြောင့်? အဓိကအချက်မှာ ဖတ်ပြီးသည့်နောက်ဆုံးအတန်း၏ identifier ကို အတိအလင်းသတ်မှတ်ခြင်းဖြင့် လိုအပ်သည့်ဒေတာကို စတင်ရှာဖွေရန် လိုအပ်သည့်နေရာကို သင်၏ DBMS အား ပြောပြခြင်းဖြစ်သည်။ ထို့အပြင်၊ သော့အသုံးပြုမှုကြောင့် ရှာဖွေမှုကို ထိထိရောက်ရောက် လုပ်ဆောင်နိုင်မည်ဖြစ်ပြီး၊ စနစ်သည် သတ်မှတ်ထားသည့် အပိုင်းအခြားပြင်ပတွင် လိုင်းများဖြင့် အာရုံထွေပြားနေစရာ မလိုပေ။

အမျိုးမျိုးသောမေးခွန်းများ၏အောက်ပါစွမ်းဆောင်ရည်နှိုင်းယှဉ်ချက်ကိုကြည့်ရှုကြပါစို့။ ဒါကတော့ ထိရောက်မှုမရှိတဲ့ မေးခွန်းတစ်ခုပါ။

တောင်းဆိုမှုနှေးကွေး

ဤတွင် ဤတောင်းဆိုချက်၏ အကောင်းဆုံးဗားရှင်းတစ်ခုဖြစ်သည်။

အမြန်တောင်းဆိုပါ။

မေးခွန်းနှစ်ခုလုံးသည် အတိအကျတူညီသောဒေတာပမာဏကို ပြန်ပေးသည်။ ဒါပေမယ့် ပထမတစ်ခုက ပြီးဖို့ 12,80 စက္ကန့်နဲ့ ဒုတိယတစ်ခုက 0,01 စက္ကန့် ကြာပါတယ်။ ကွာခြားမှုကို သင်ခံစားရပါသလား။

အလားအလာရှိသောပြဿနာများ

အဆိုပြုထားသော မေးမြန်းမှုနည်းလမ်းကို ထိရောက်စွာလုပ်ဆောင်ရန်အတွက်၊ ဇယားတွင် ကိန်းပြည့်သတ်မှတ်မှုကဲ့သို့သော ထူးခြားသော၊ ဆက်တိုက်အညွှန်းကိန်းများပါရှိသော ကော်လံ (သို့မဟုတ်) ကော်လံများ ရှိရပါမည်။ အချို့သောကိစ္စရပ်များတွင်၊ ၎င်းသည် ဒေတာဘေ့စ်နှင့်အလုပ်လုပ်ခြင်း၏အရှိန်ကို တိုးမြှင့်ရန်အတွက် ထိုသို့သောမေးခွန်းများကိုအသုံးပြုခြင်း၏အောင်မြင်မှုကို ဆုံးဖြတ်နိုင်သည်။

ထုံးစံအတိုင်း၊ စုံစမ်းမေးမြန်းမှုများကို တည်ဆောက်သည့်အခါ၊ သင်သည် ဇယားများ၏ တိကျသော တည်ဆောက်မှုပုံစံကို ထည့်သွင်းစဉ်းစားရန် လိုအပ်ပြီး လက်ရှိ ဇယားများတွင် အကောင်းဆုံး လုပ်ဆောင်မည့် အဆိုပါ ယန္တရားများကို ရွေးချယ်ပါ။ ဥပမာအားဖြင့်၊ ဆက်စပ်ဒေတာအမြောက်အမြားဖြင့် စုံစမ်းမေးမြန်းမှုများတွင် လုပ်ဆောင်ရန် လိုအပ်ပါက၊ ၎င်းကို စိတ်ဝင်စားဖွယ် တွေ့ရှိနိုင်သည်။ ဤ ဆောင်းပါး။

အကယ်၍ ကျွန်ုပ်တို့သည် ပင်မသော့ကို ပျောက်ဆုံးသွားသည့် ပြဿနာနှင့် ကြုံတွေ့ရပါက၊ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင် များစွာသော ဆက်စပ်မှုရှိသော ဇယားတစ်ခုရှိလျှင်၊ အသုံးပြုခြင်း၏ ရိုးရာနည်းလမ်း၊ OFFSET и LIMITကျွန်ုပ်တို့နှင့်ကိုက်ညီရန်အာမခံပါသည်။ သို့သော် ၎င်း၏အသုံးပြုမှုသည် နှေးကွေးနိုင်ချေရှိသော မေးခွန်းများကို ဖြစ်ပေါ်စေနိုင်သည်။ ထိုသို့သောအခြေအနေမျိုးတွင်၊ paginated queries များကိုကိုင်တွယ်ရန်သာလိုအပ်သော်လည်း၊ auto-incrementing main key ကိုအသုံးပြုရန်အကြံပြုလိုပါသည်။

ဒီအကြောင်းအရာကို စိတ်ဝင်စားတယ်ဆိုရင်- ဒီမှာ, ဒီမှာ и ဒီမှာ - များစွာသောအသုံးဝင်သောပစ္စည်းများ။

ရလဒ်များကို

ကျွန်ုပ်တို့ရေးဆွဲနိုင်သည့် အဓိကနိဂုံးမှာ ကျွန်ုပ်တို့ပြောနေသည့်ဒေတာဘေ့စ်များ၏အရွယ်အစားမည်မျှပင်ရှိပါစေ၊ query execution ၏အမြန်နှုန်းကို အမြဲတမ်းခွဲခြမ်းစိတ်ဖြာရန် လိုအပ်ပါသည်။ ယနေ့ခေတ်တွင်၊ ဖြေရှင်းချက်များ၏ ချဲ့ထွင်နိုင်မှုသည် အလွန်အရေးကြီးပြီး အချို့သောစနစ်တစ်ခုတွင် အစကတည်းက အရာအားလုံးကို မှန်ကန်စွာ ဒီဇိုင်းထုတ်ထားပါက၊ ၎င်းသည် အနာဂတ်တွင် developer ကို ပြဿနာများစွာမှ ကယ်တင်နိုင်မည်ဖြစ်သည်။

ဒေတာဘေ့စ်မေးခွန်းများကို သင်မည်ကဲ့သို့ခွဲခြမ်းစိတ်ဖြာပြီး ပိုမိုကောင်းမွန်အောင်လုပ်ဆောင်သနည်း။

source: www.habr.com