တည်ဆောက်သူများအတွက် B2B ဝန်ဆောင်မှု၏နမူနာကို အသုံးပြု၍ ဒေတာဘေ့စ်မေးခွန်းများကို ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်း။

ပိုမိုအကျိုးရှိသောဆာဗာသို့မရွှေ့ဘဲ ဒေတာဘေ့စ်သို့ စုံစမ်းမေးမြန်းမှုအရေအတွက် 10 ဆတိုးအောင် မည်သို့လုပ်ဆောင်မည်နည်း။ ကျွန်ုပ်တို့၏ဒေတာဘေ့စ်၏စွမ်းဆောင်ရည်ကျဆင်းမှုကိုကျွန်ုပ်တို့မည်ကဲ့သို့ကိုင်တွယ်ဖြေရှင်းခဲ့သည်၊ အသုံးပြုသူများတတ်နိုင်သမျှဝန်ဆောင်မှုပေးနိုင်ရန်နှင့်တွက်ချက်မှုအရင်းအမြစ်များကုန်ကျစရိတ်မတိုးစေဘဲ SQL queries များကိုအကောင်းဆုံးဖြစ်အောင်ပြုလုပ်ပုံတို့ကိုပြောပြပါမည်။

ဆောက်လုပ်ရေးကုမ္ပဏီများတွင် စီးပွားရေးလုပ်ငန်းစဉ်များကို စီမံခန့်ခွဲရန် ဝန်ဆောင်မှုတစ်ခု ပြုလုပ်ပါသည်။ ကုမ္ပဏီပေါင်း ၃ ထောင်လောက်က ကျွန်တော်တို့နဲ့ အလုပ်လုပ်ပါတယ်။ လူ ၁၀,ဝဝဝ ကျော်သည် ကျွန်ုပ်တို့၏စနစ်ဖြင့် နေ့စဉ် ၄-၁၀ နာရီကြာ အလုပ်လုပ်ကြသည်။ ၎င်းသည် အစီအစဉ်ရေးဆွဲခြင်း၊ အသိပေးချက်၊ သတိပေးချက်၊ အတည်ပြုခြင်းဆိုင်ရာ ပြဿနာအမျိုးမျိုးကို ဖြေရှင်းပေးသည်... ကျွန်ုပ်တို့သည် PostgreSQL 3 ကို အသုံးပြုသည်။ ကျွန်ုပ်တို့တွင် ဒေတာဘေ့စ်တွင် ဇယား 10 ခန့်ရှိပြီး မေးခွန်းပေါင်း သန်း 4 (10 အမျိုးမျိုး) ကို နေ့စဉ် လက်ခံရရှိပါသည်။ ပျမ်းမျှအားဖြင့် ကျွန်ုပ်တို့တွင် တစ်စက္ကန့်လျှင် တောင်းဆိုချက်ပေါင်း ၃-၄ဝဝဝ ရှိပြီး အတက်ကြွဆုံးအချိန်များတွင် တစ်စက္ကန့်လျှင် တောင်းဆိုချက် ၁၀ဝဝဝ ကျော်ရှိသည်။ မေးခွန်းအများစုသည် OLAP ဖြစ်သည်။ ထပ်တိုးမှုများ၊ ပြုပြင်မှုများနှင့် ဖျက်ခြင်းများ နည်းပါးလာသောကြောင့် OLTP load သည် အတော်လေး ပေါ့ပါးသည်။ ကျွန်ုပ်တို့၏ပရောဂျက်၏အတိုင်းအတာကို အကဲဖြတ်နိုင်ပြီး ကျွန်ုပ်တို့၏အတွေ့အကြုံသည် သင့်အတွက် မည်မျှအသုံးဝင်နိုင်သည်ကို နားလည်နိုင်ရန် ဤနံပါတ်များအားလုံးကို ကျွန်ုပ်ပေးထားပါသည်။

ပုံတစ်ပုံ။ ကဗျာဆန်တယ်။

ကျွန်ုပ်တို့ ဖွံ့ဖြိုးတိုးတက်မှုကို စတင်သောအခါ၊ ဒေတာဘေ့စ်ပေါ်၌ မည်သို့သော ဝန်ထုပ်ဝန်ပိုးများ ကျရောက်လာမည်ကို ကျွန်ုပ်တို့ အမှန်တကယ် မတွေးခဲ့မိဘဲ ဆာဗာမှ ဆွဲယူခြင်းကို ရပ်သွားပါက ကျွန်ုပ်တို့ ဘာလုပ်မည်နည်း။ ဒေတာဘေ့စ်ကို ဒီဇိုင်းဆွဲသောအခါ၊ ကျွန်ုပ်တို့သည် ယေဘုယျ အကြံပြုချက်များကို လိုက်နာပြီး မိမိကိုယ်ကို ခြေမချရန် ကြိုးစားသော်လည်း "ပုံစံကို မသုံးပါနှင့် Entity Attribute တန်ဖိုးများ ငါတို့မဝင်ဘူး။ ကျွန်ုပ်တို့သည် ပုံမှန်ပြုလုပ်ခြင်း၏ အခြေခံမူများပေါ်တွင် အခြေခံ၍ ဒီဇိုင်းထုတ်ထားပြီး၊ ဒေတာ ထပ်လောင်းခြင်းကို ရှောင်ရှားကာ အချို့သော မေးမြန်းချက်များကို အရှိန်မြှင့်ရန် ဂရုမစိုက်ပါ။ ပထမဆုံး အသုံးပြုသူများ ရောက်ရှိလာသည်နှင့် တပြိုင်နက် စွမ်းဆောင်ရည် ပြဿနာတစ်ခု ကြုံတွေ့ခဲ့ရသည်။ ခါတိုင်းလိုပဲ၊ ဒီအတွက် ကျွန်တော်တို့ လုံး၀ ကြိုတင်ပြင်ဆင်မှု မရှိပါဘူး။ ပထမပြဿနာများ သည် ရိုးရှင်းသည် ။ စည်းကမ်းအတိုင်း၊ အညွှန်းအသစ်တစ်ခုထည့်ခြင်းဖြင့် အရာအားလုံးကို ဖြေရှင်းခဲ့သည်။ ဒါပေမယ့် ရိုးရိုး patches အလုပ်မလုပ်တော့တဲ့ အချိန်ရောက်လာတယ်။ ကျွန်ုပ်တို့သည် အတွေ့အကြုံမရှိ၍ ပြဿနာများကိုဖြစ်စေသောအရာကို နားလည်ရန် ပို၍ခက်ခဲလာသည်ကို သိရှိနားလည်လာသဖြင့် ဆာဗာကို မှန်ကန်စွာသတ်မှတ်နိုင်စေရန် ကူညီပေးသော ကျွမ်းကျင်သူများကို ငှားရမ်းကာ စောင့်ကြည့်ချိတ်ဆက်ကာ မည်သည့်နေရာတွင် ရှာဖွေရမည်ကို ပြသခဲ့သည်။ စာရင်းဇယား.

ပုံနှစ်ပုံ။ စာရင်းအင်း

ထို့ကြောင့် ကျွန်ုပ်တို့တွင် တစ်နေ့လျှင် ကျွန်ုပ်တို့၏ဒေတာဘေ့စ်ပေါ်တွင် လုပ်ဆောင်သည့် မတူညီသောမေးခွန်းပေါင်း 10 ခန့်ရှိသည်။ ဤ 10 တွင် ပျမ်းမျှ ကွပ်မျက်ချိန် 2-3 ms ဖြင့် အကြိမ် 0.1-0.3 သန်း ကွပ်မျက်သည့် ဘီလူးများ ရှိပြီး တစ်နေ့လျှင် အကြိမ် 30 ဟုခေါ်သော ပျမ်းမျှ ကွပ်မျက်ချိန် စက္ကန့် 100 နှင့် စုံစမ်းမှုများ ရှိပါသည်။

10 queries အားလုံးကို optimize လုပ်ရန်မဖြစ်နိုင်ပါ၊ ထို့ကြောင့် database ၏စွမ်းဆောင်ရည်ကိုမှန်ကန်စွာတိုးတက်စေရန်အတွက်ကျွန်ုပ်တို့၏ကြိုးပမ်းအားထုတ်မှုများကိုမည်သည့်နေရာတွင်ညွှန်ကြားရမည်ကိုရှာဖွေရန်ဆုံးဖြတ်ခဲ့သည်။ အကြိမ်ကြိမ်ပြန်လုပ်ပြီးနောက်၊ ကျွန်ုပ်တို့သည် တောင်းဆိုချက်များကို အမျိုးအစားများအဖြစ် ခွဲစပြုလာသည်။

ထိပ်တန်းတောင်းဆိုမှုများ

ဤအရာများသည် အချိန်အများဆုံး (စုစုပေါင်းအချိန်) ကြာသော အလေးဆုံးမေးခွန်းများဖြစ်သည်။ ၎င်းတို့သည် မကြာခဏ ခေါ်ဝေါ်သော မေးခွန်းများ သို့မဟုတ် လုပ်ဆောင်ရန် အလွန်ကြာသော စုံစမ်းမေးမြန်းမှုများဖြစ်သည် (အကြာကြီးနှင့် မကြာခဏ မေးမြန်းမှုများသည် မြန်နှုန်းအတွက် တိုက်ပွဲ၏ ပထမအကြိမ် ထပ်ကျော့မှုတွင် အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ထားသည်)။ ရလဒ်အနေဖြင့်၊ ဆာဗာသည် ၎င်းတို့၏လုပ်ဆောင်မှုတွင် အချိန်အများဆုံးဖြုန်းသည်။ ထို့အပြင်၊ ထိပ်တန်းတောင်းဆိုမှုများကို စုစုပေါင်းလုပ်ဆောင်ချိန်နှင့် IO အချိန် သီးခြားစီခွဲခြားရန် အရေးကြီးပါသည်။ ထိုသို့သောမေးခွန်းများကို ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ရန် နည်းလမ်းများသည် အနည်းငယ်ကွဲပြားပါသည်။

ကုမ္ပဏီအားလုံး၏ ပုံမှန်အလေ့အကျင့်မှာ TOP တောင်းဆိုမှုများဖြင့် လုပ်ဆောင်ခြင်းဖြစ်သည်။ ၎င်းတို့ထဲမှ အနည်းငယ်သာ ရှိပါသည်၊ စုံစမ်းမှုတစ်ခုပင်လျှင် အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ခြင်းဖြင့် အရင်းအမြစ်များ၏ 5-10% ကို လွတ်ကင်းစေနိုင်သည်။ သို့သော်၊ ပရောဂျက်ကြီးလာသည်နှင့်အမျှ၊ ထိပ်တန်းမေးခွန်းများကို ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်းသည် ပို၍အသေးအဖွဲမဟုတ်သော အလုပ်ဖြစ်လာသည်။ ရိုးရှင်းသောနည်းလမ်းများအားလုံးကို အကောင်အထည်ဖော်ပြီးဖြစ်ပြီး၊ အလွန်လေးလံသောတောင်းဆိုချက်သည် အရင်းအမြစ်များ၏ 3-5% ကိုသာ ရယူသည်။ စုစုပေါင်း TOP queries သည် အချိန်၏ 30-40% ထက်နည်းပါက၊ ၎င်းတို့ကို လျင်မြန်စွာ လုပ်ဆောင်နိုင်စေရန် သင် အားထုတ်ထားပြီးသား ဖြစ်နိုင်ပြီး နောက်အုပ်စုမှ မေးမြန်းချက်များကို အကောင်းဆုံးဖြစ်အောင် ဆက်လက်လုပ်ဆောင်ရန် အချိန်တန်ပြီဖြစ်သည်။
ဤအဖွဲ့တွင် ထိပ်တန်းမေးခွန်းများ မည်မျှပါဝင်သင့်သည်ဆိုသည့်မေးခွန်းကို ဖြေရန်ကျန်နေသေးသည်။ များသောအားဖြင့် အနည်းဆုံး 10 ယူသော်လည်း 20 ထက်မပိုပါ။ TOP အဖွဲ့တွင် ပထမအကြိမ်နှင့် နောက်ဆုံးအချိန်သည် 10 ကြိမ်ထက် မပိုကြောင်း သေချာစေရန် ကြိုးစားပါသည်။ ဆိုလိုသည်မှာ၊ query execution time သည် 1st မှ 10th သို့ သိသိသာသာကျဆင်းသွားပါက၊ drop သည် တဖြည်းဖြည်းပိုလာပါက၊ group size ကို 10 သို့မဟုတ် 15 သို့တိုး၍ TOP-20 ကိုယူပါသည်။

လယ် သမား

ဤအရာများသည် နောက်ဆုံး 5-10% မှလွဲ၍ TOP ပြီးနောက် ချက်ချင်းရောက်လာသော တောင်းဆိုချက်များအားလုံးဖြစ်သည်။ အများအားဖြင့်၊ ဤမေးခွန်းများကို ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်းသည် ဆာဗာစွမ်းဆောင်ရည်ကို များစွာမြှင့်တင်ရန် အခွင့်အလမ်းဖြစ်သည်။ ဤတောင်းဆိုမှုများသည် 80% အထိ အလေးချိန်ရှိနိုင်သည်။ ဒါပေမယ့် သူတို့ရဲ့ရှယ်ယာဟာ 50% ကျော်လွန်သွားရင်တောင်မှ သူတို့ကို ပိုပြီးသေချာကြည့်ဖို့ အချိန်တန်ပါပြီ။

အမြီး

ဖော်ပြခဲ့သည့်အတိုင်း၊ ဤမေးခွန်းများသည် အဆုံးတွင်ရောက်လာပြီး အချိန်၏ 5-10% ယူသည်။ အလိုအလျောက် မေးမြန်းမှု ခွဲခြမ်းစိတ်ဖြာမှု ကိရိယာများကို အသုံးမပြုပါက ၎င်းတို့ကို မေ့ထားနိုင်ပြီး ၎င်းတို့ကို ပိုမိုကောင်းမွန်အောင် ပြုပြင်ခြင်းသည်လည်း စျေးသက်သာပါသည်။

အုပ်စုတစ်ခုစီကို ဘယ်လိုအကဲဖြတ်မလဲ။

PostgreSQL အတွက် ထိုသို့သော အကဲဖြတ်မှုကို ကူညီပေးသော SQL query ကို ကျွန်ုပ်အသုံးပြုသည် (ကျွန်ုပ်သည် အခြား DBMSs များစွာအတွက် အလားတူ query တစ်ခုကို ရေးသားနိုင်သည်မှာ သေချာပါသည်)

TOP-MEDIUM-TAIL အဖွဲ့များ၏ အရွယ်အစားကို ခန့်မှန်းရန် SQL query

SELECT sum(time_top) AS sum_top, sum(time_medium) AS sum_medium, sum(time_tail) AS sum_tail
FROM
(
  SELECT CASE WHEN rn <= 20              THEN tt_percent ELSE 0 END AS time_top,
         CASE WHEN rn > 20 AND rn <= 800 THEN tt_percent ELSE 0 END AS time_medium,
         CASE WHEN rn > 800              THEN tt_percent ELSE 0 END AS time_tail
  FROM (
    SELECT total_time / (SELECT sum(total_time) FROM pg_stat_statements) * 100 AS tt_percent, query,
    ROW_NUMBER () OVER (ORDER BY total_time DESC) AS rn
    FROM pg_stat_statements
    ORDER BY total_time DESC
  ) AS t
)
AS ts

မေးမြန်းမှု၏ရလဒ်သည် ကော်လံသုံးခုဖြစ်ပြီး တစ်ခုစီတွင် ဤအဖွဲ့မှမေးမြန်းချက်များကို လုပ်ဆောင်ရန် အချိန်ရာခိုင်နှုန်းများပါရှိသည်။ တောင်းဆိုချက်အတွင်းတွင် အုပ်စုတစ်ခုမှ အခြားတောင်းဆိုမှုများကို ခွဲထုတ်သည့် နံပါတ် (20 နှင့် 800) တွင် နံပါတ်နှစ်ခုရှိသည်။

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

TOP တောင်းဆိုမှုများ၏ ဝေစုသည် သိသိသာသာ လျော့ကျသွားကြောင်း ပုံကြမ်းတွင် ပြသထားသော်လည်း “အလယ်အလတ် တောင်သူလယ်သမားများ” တိုးလာပါသည်။
အစပိုင်းတွင်၊ ထိပ်တန်းတောင်းဆိုချက်များတွင် ပြောင်ပြောင်တင်းတင်း အမှားအယွင်းများ ပါဝင်သည်။ အချိန်ကြာလာသည်နှင့်အမျှ၊ ကလေးဘဝရောဂါများ ပျောက်ကွယ်သွားကာ TOP တောင်းဆိုမှုများ၏ဝေစုမှာ လျော့နည်းလာပြီး ခက်ခဲသောတောင်းဆိုမှုများကို အရှိန်မြှင့်ရန် ပို၍ပို၍ ကြိုးစားအားထုတ်မှုများ ပြုလုပ်ခဲ့ရသည်။

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

SELECT * FROM (
  SELECT ROW_NUMBER () OVER (ORDER BY total_time DESC) AS rn, total_time / (SELECT sum(total_time) FROM pg_stat_statements) * 100 AS tt_percent, query
  FROM pg_stat_statements
  ORDER BY total_time DESC
) AS T
WHERE
rn <= 20 -- TOP
-- rn > 20 AND rn <= 800 -- MEDIUM
-- rn > 800  -- TAIL

ဤသည်မှာ ထိပ်တန်းမေးခွန်းများကို အရှိန်မြှင့်ရန် ကူညီပေးသော အသုံးအများဆုံးနည်းပညာများစာရင်းဖြစ်သည်-

• စနစ်၏ ပြန်လည်ဒီဇိုင်းဆွဲခြင်း ဥပမာ၊ ဒေတာဘေ့စ်သို့ အချိန်အခါအလိုက် မေးမြန်းမှုများအစား မက်ဆေ့ချ်ပွဲစားကို အသုံးပြု၍ အသိပေးချက်ယုတ္တိကို ပြန်လည်လုပ်ဆောင်ခြင်း
• အညွှန်းများထည့်ခြင်း သို့မဟုတ် ပြောင်းလဲခြင်း။
• ORM မေးခွန်းများကို စင်စစ် SQL သို့ ပြန်လည်ရေးသားခြင်း။
• ပျင်းရိသောဒေတာကို ပြန်ရေးခြင်းသည် ယုတ္တိဗေဒကိုဖွင့်ခြင်း။
• ဒေတာပုံမှန်မဟုတ်ခြင်းမှတဆင့် သိမ်းဆည်းခြင်း ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင် ဇယားချိတ်ဆက်မှု Delivery -> Invoice -> Request -> Application ရှိသည်။ ဆိုလိုသည်မှာ ပေးပို့မှုတစ်ခုစီသည် အခြားဇယားများမှတစ်ဆင့် အက်ပ်တစ်ခုနှင့် ဆက်စပ်နေသည်။ တောင်းဆိုချက်တစ်ခုစီရှိ ဇယားအားလုံးကို လင့်ခ်မချိတ်စေရန်၊ ကျွန်ုပ်တို့သည် ပေးပို့မှုဇယားရှိ တောင်းဆိုချက်နှင့် လင့်ခ်ကို မိတ္တူပွားထားသည်။
• အကိုးအကားစာအုပ်များဖြင့် ငြိမ်ဇယားများကို သိမ်းဆည်းထားပြီး ပရိုဂရမ်မှတ်ဉာဏ်တွင် ဇယားများကို ပြောင်းလဲခဲပါသည်။

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

အဲဒီနောက် ဒုတိယတောင်းဆိုချက်ဖြစ်တဲ့ အလယ်တန်းတောင်သူလယ်သမားအုပ်စုကို အာရုံစိုက်ခဲ့တယ်။ ၎င်းတွင် နောက်ထပ်မေးခွန်းများစွာရှိပြီး အုပ်စုတစ်ခုလုံးကို ခွဲခြမ်းစိတ်ဖြာရန် အချိန်များစွာယူရမည်ဟု ထင်ရသည်။ သို့သော်၊ မေးမြန်းမှုအများစုသည် အကောင်းဆုံးဖြစ်အောင်ပြုလုပ်ရန် အလွန်ရိုးရှင်းပြီး ပြဿနာများစွာကို မတူညီသောပုံစံများဖြင့် အကြိမ်ပေါင်းများစွာ ထပ်ခါတလဲလဲ ပြုလုပ်ခဲ့ကြသည်။ ဤသည်မှာ အလားတူမေးခွန်းများစွာအတွက် ကျွန်ုပ်တို့အသုံးပြုခဲ့သည့် ပုံမှန်ကောင်းမွန်အောင်လုပ်ဆောင်မှုအချို့၏နမူနာများဖြစ်ပြီး ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ထားသောမေးခွန်းအုပ်စုတစ်ခုစီသည် ဒေတာဘေ့စ်ကို 3-5% ဖြင့် ဖြုတ်ချခဲ့သည်။

• COUNT နှင့် ဇယားအပြည့်စကင်န်ကို အသုံးပြု၍ မှတ်တမ်းများရှိနေခြင်းကို စစ်ဆေးမည့်အစား EXISTS ကို စတင်အသုံးပြုသည်
• ကွဲပြားမှုကို ဖယ်ရှားလိုက်သည် (ယေဘုယျ စာရွက်မရှိသော်လည်း တစ်ခါတစ်ရံ တောင်းဆိုမှုကို အကြိမ် 10-100 အရှိန်မြှင့်ခြင်းဖြင့် အလွယ်တကူ ဖယ်ရှားနိုင်သည်)။

  ဥပမာအားဖြင့်၊ ပို့ဆောင်မှုဇယားကြီးတစ်ခုမှ ယာဉ်မောင်းအားလုံးကို ရွေးချယ်ရန် query တစ်ခုအစား (DELIVERY)

  SELECT DISTINCT P.ID, P.FIRST_NAME, P.LAST_NAME
  FROM DELIVERY D JOIN PERSON P ON D.DRIVER_ID = P.ID
  

  အတော်လေးသေးငယ်သော PERSON စားပွဲပေါ်တွင် စုံစမ်းမှုတစ်ခု ပြုလုပ်ခဲ့သည်။

  SELECT P.ID, P.FIRST_NAME, P.LAST_NAME
  FROM PERSON
  WHERE EXISTS(SELECT D.ID FROM DELIVERY WHERE D.DRIVER_ID = P.ID)
  

  ကျွန်ုပ်တို့သည် ဆက်စပ်ဆက်နွယ်သော subquery ကိုအသုံးပြုထားပုံရသော်လည်း ၎င်းသည် 10 ဆထက်ပိုမိုမြန်ဆန်စေသည်။

• များစွာသော ကိစ္စများတွင်၊ COUNT ကို လုံးလုံးနှင့် စွန့်ပစ်ခဲ့သည်။
  အနီးစပ်ဆုံးတန်ဖိုးကို တွက်ချက်ခြင်းဖြင့် အစားထိုးသည်။
• အစား

  UPPER(s) LIKE JOHN%’ 
  

  အသုံး

  s ILIKE “John%”
  

သီးခြားတောင်းဆိုမှုတစ်ခုစီသည် တစ်ခါတစ်ရံ 3-1000 ကြိမ် အရှိန်မြှင့်ခဲ့သည်။ အထင်ကြီးလောက်စရာ စွမ်းဆောင်ရည်ရှိသော်လည်း၊ ပထမတော့ 10 ms ကြာမြင့်သော query ကို အကောင်းဆုံးဖြစ်အောင်လုပ်ရန် အကြောင်းမရှိသလို၊ 3rd တရာ အလေးဆုံးမေးခွန်းများထဲမှ တစ်ခုဖြစ်ပြီး ဒေတာဘေ့စ်တင်ချိန်စုစုပေါင်း၏ ရာခိုင်နှုန်း ရာချီအထိ နေရာယူပါသည်။ သို့သော် တူညီသော စာရွက်ကို အမျိုးအစားတူ မေးမြန်းချက်အုပ်စုတွင် အသုံးပြုခြင်းဖြင့် ရာခိုင်နှုန်းအနည်းငယ် ပြန်ရရှိခဲ့သည်။ မေးခွန်းရာပေါင်းများစွာကို ကိုယ်တိုင်ပြန်လည်သုံးသပ်ပြီး အချိန်မဖြုန်းစေရန်အတွက်၊ ကျွန်ုပ်တို့သည် အမျိုးအစားတူညီသောမေးခွန်းများကိုရှာဖွေရန် ပုံမှန်အသုံးအနှုန်းများကိုအသုံးပြုသည့် ရိုးရှင်းသော script အများအပြားကို ရေးသားခဲ့သည်။ ရလဒ်အနေဖြင့်၊ စုံစမ်းမေးမြန်းသည့်အုပ်စုများကို အလိုအလျောက်ရှာဖွေခြင်းသည် ကျွန်ုပ်တို့အား ကျိုးနွံစွာအားထုတ်ခြင်းဖြင့် ကျွန်ုပ်တို့၏စွမ်းဆောင်ရည်ကို ပိုမိုတိုးတက်စေပါသည်။

ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် တူညီသော ဟာ့ဒ်ဝဲကို လုပ်ဆောင်နေသည်မှာ သုံးနှစ်ရှိပြီဖြစ်သည်။ ပျမ်းမျှနေ့စဉ်ဝန်သည် 30% ခန့်ဖြစ်ပြီး အမြင့်ဆုံးတွင် 70% ရှိသည်။ တောင်းဆိုမှုအရေအတွက်နှင့် သုံးစွဲသူအရေအတွက်သည် ၁၀ ဆခန့် တိုးလာခဲ့သည်။ TOP-MEDIUM တောင်းဆိုမှုများ၏ ဤတူညီသောအုပ်စုများကို စဉ်ဆက်မပြတ်စောင့်ကြည့်ပေးသောကြောင့် ဤအရာအားလုံးကို ကျေးဇူးတင်ပါသည်။ TOP အဖွဲ့တွင် တောင်းဆိုချက်အသစ်တစ်ခု ပေါ်လာသည်နှင့် ချက်ချင်းဆိုသလို ၎င်းကို ပိုင်းခြားစိတ်ဖြာပြီး အရှိန်မြှင့်ရန် ကြိုးစားပါသည်။ ကျွန်ုပ်တို့သည် စုံစမ်းမှုခွဲခြမ်းစိတ်ဖြာမှု scripts များကို အသုံးပြု၍ တစ်ပတ်လျှင် တစ်ကြိမ် MEDIUM အဖွဲ့အား ပြန်လည်သုံးသပ်ပါသည်။ ကျွန်ုပ်တို့သည် အကောင်းဆုံးဖြစ်အောင်လုပ်နည်းကို သိထားပြီးဖြစ်သည့် မေးခွန်းအသစ်များကို တွေ့ပါက ၎င်းတို့ကို အမြန်ပြောင်းပါ။ တစ်ခါတရံတွင် မေးခွန်းများစွာကို တစ်ပြိုင်နက် အသုံးချနိုင်သော ပိုမိုကောင်းမွန်အောင် ပြုလုပ်နိုင်သည့် နည်းလမ်းအသစ်များကို ကျွန်ုပ်တို့ ရှာဖွေတွေ့ရှိပါသည်။

ကျွန်ုပ်တို့၏ခန့်မှန်းချက်များအရ၊ လက်ရှိဆာဗာသည် အသုံးပြုသူအရေအတွက်ကို နောက်ထပ် 3-5 ဆ တိုးလာမှုကို ခံနိုင်ရည်ရှိမည်ဖြစ်သည်။ မှန်ပါသည်၊ ကျွန်ုပ်တို့တွင် နောက်ထပ် ace တစ်ခုရှိသည် - အကြံပြုထားသည့်အတိုင်း မှန်သို့ SELECT မေးခွန်းများကို မလွှဲပြောင်းရသေးပါ။ သို့သော် ကျွန်ုပ်တို့သည် ဤအရာကို သတိရှိရှိမလုပ်ပါ၊ အဘယ်ကြောင့်ဆိုသော် ကျွန်ုပ်တို့သည် “လေးလံသောအမြောက်များ” ကိုမဖွင့်မီ “စမတ်” ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်း၏ဖြစ်နိုင်ချေများကို ဦးစွာကုန်ဆုံးလိုသောကြောင့်ဖြစ်သည်။
ပြီးခဲ့သောအလုပ်အား ဝေဖန်ပိုင်းခြားကြည့်ခြင်းဖြင့် ဒေါင်လိုက်စကေးကို အသုံးပြုရန် အကြံပြုနိုင်သည်။ ကျွမ်းကျင်သူများ၏အချိန်ကိုဖြုန်းတီးမည့်အစား ပိုမိုအားကောင်းသောဆာဗာကိုဝယ်ပါ။ အထူးသဖြင့် ကျွန်ုပ်တို့သည် ဒေါင်လိုက်စကေးချဲ့ခြင်း၏ ကန့်သတ်ချက်များကို မကုန်ဆုံးသေးသောကြောင့် ဆာဗာသည် ထိုမျှလောက် ကုန်ကျမည်မဟုတ်ပါ။ သို့သော် တောင်းဆိုမှုအရေအတွက်သည် ၁၀ ဆသာတိုးလာသည်။ နှစ်များစွာကြာလာသည်နှင့်အမျှ၊ စနစ်၏လုပ်ဆောင်နိုင်စွမ်းသည် တိုးတက်လာခဲ့ပြီး ယခုအခါ တောင်းဆိုမှုအမျိုးအစားများ ပိုမိုများပြားလာပါသည်။ ကက်ရှ်လုပ်ခြင်းကြောင့် တည်ရှိနေသော လုပ်ဆောင်နိုင်စွမ်းကို တောင်းဆိုမှုနည်းပါးပြီး ပိုမိုထိရောက်သော တောင်းဆိုမှုများတွင် လုပ်ဆောင်ပါသည်။ ဆိုလိုသည်မှာ စစ်မှန်သော acceleration coefficient ကိုရရှိရန် အခြား 10 နှင့် လုံခြုံစွာ မြှောက်နိုင်သည်ဟု ဆိုလိုသည်။ ထို့ကြောင့် ရှေးရိုးဆန်သော ခန့်မှန်းချက်များအရ၊ အရှိန်သည် အဆ ၅၀ သို့မဟုတ် ထို့ထက်ပိုသည်ဟု ဆိုနိုင်သည်။ ဆာဗာကို ဒေါင်လိုက် လှည့်ခြင်းသည် အဆ ၅၀ ပိုကုန်ကျသည်။ အထူးသဖြင့် optimization ကိုလုပ်ဆောင်ပြီးသည်နှင့်အချိန်တိုင်းအလုပ်လုပ်သည်နှင့်ငှားရမ်းထားသောဆာဗာအတွက်ငွေတောင်းခံလွှာသည်လစဉ်လာပါသည်။

source: www.habr.com