TL;DR- လွန်ခဲ့သည့်လေးနှစ်က ကျွန်ုပ်သည် ဆာဗာစောင့်ကြည့်ရေးကိရိယာအသစ်အတွက် အကြံတစ်ခုဖြင့် Google ကို ထွက်ခွာခဲ့သည်။ အိုင်ဒီယာမှာ အများအားဖြင့် သီးခြားလုပ်ဆောင်ချက်များကို ဝန်ဆောင်မှုတစ်ခုသို့ ပေါင်းစပ်ရန်ဖြစ်သည်။ စုဆောင်းမှု နှင့် မှတ်တမ်းခွဲခြမ်းစိတ်ဖြာခြင်း၊ မက်ထရစ်များ စုဆောင်းခြင်း၊ သတိပေးချက်များ နှင့် ဒက်ရှ်ဘုတ်များ။ အခြေခံမူများထဲမှ တစ်ခုမှာ ဝန်ဆောင်မှုသည် အမှန်တကယ်ဖြစ်ရမည်။ မြန်သည်။၊ လွယ်ကူသော၊ အပြန်အလှန်အကျိုးပြုသော၊ ပျော်ရွှင်ဖွယ်အတွေ့အကြုံများဖြင့် ပံ့ပိုးပေးပါသည်။ ၎င်းသည် ဘတ်ဂျက်အတွင်း ရှိနေစဉ် တစ်စက္ကန့်၏ အပိုင်းအစများအတွင်း multi-gigabyte ဒေတာအစုံများကို လုပ်ဆောင်ရန် လိုအပ်သည်။ လက်ရှိ မှတ်တမ်းစီမံခန့်ခွဲမှု ကိရိယာများသည် မကြာခဏ နှေးကွေးပြီး ရှုပ်ထွေးသောကြောင့် ကျွန်ုပ်တို့သည် သုံးစွဲသူများအား အတွေ့အကြုံသစ်များပေးရန် ကိရိယာတစ်ခုကို စမတ်ကျကျ ဒီဇိုင်းထုတ်ခြင်းဖြင့် စိန်ခေါ်မှုကောင်းတစ်ခုနှင့် ရင်ဆိုင်ခဲ့ရသည်။

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

Old School Power

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

သော့ချက်ထိုးထွင်းသိမြင်မှုသည် ခေတ်မီပရိုဆက်ဆာများသည် ရိုးရှင်းပြီး ရိုးရှင်းသောလုပ်ဆောင်မှုများတွင် အမှန်တကယ်ပင် မြန်ဆန်လွန်းသည် ။ I/O မြန်နှုန်းနှင့် ကွန်ရက်လုပ်ဆောင်မှုများကို အားကိုးသည့် ရှုပ်ထွေးပြီး အလွှာပေါင်းစုံစနစ်များတွင် ၎င်းကို လက်လွှတ်ရန်လွယ်ကူပြီး ယင်းစနစ်များသည် ယနေ့ခေတ်တွင် အလွန်အသုံးများသည်။ ဒါကြောင့် အလွှာတွေနဲ့ ပိုနေတဲ့ အညစ်အကြေးတွေကို လျှော့ချနိုင်တဲ့ ဒီဇိုင်းကို တီထွင်ခဲ့ပါတယ်။ ပရိုဆက်ဆာများစွာနှင့် ဆာဗာများအပြိုင်ဖြင့်၊ ရှာဖွေမှုအမြန်နှုန်းသည် တစ်စက္ကန့်လျှင် 1 TB အထိရောက်ရှိသည်။

ဤဆောင်းပါးမှ အဓိကအချက်များ

• Brute-force ရှာဖွေမှုသည် လက်တွေ့ကမ္ဘာ၊ အကြီးစားပြဿနာများကို ဖြေရှင်းရန်အတွက် ထိရောက်သောနည်းလမ်းတစ်ခုဖြစ်သည်။
• Brute Force သည် အလုပ်မပါဘဲ ဖြေရှင်းချက်မဟုတ်ဘဲ ဒီဇိုင်းနည်းပညာတစ်ခုဖြစ်သည်။ မည်သည့်နည်းပညာကဲ့သို့ပင်၊ ၎င်းသည် အခြားပြဿနာများထက် အချို့သောပြဿနာများအတွက် ပိုမိုသင့်လျော်ပြီး ညံ့ဖျင်းခြင်း သို့မဟုတ် ကောင်းမွန်စွာအကောင်အထည်ဖော်နိုင်သည်။
• Brute force သည် အောင်မြင်မှုအတွက် အထူးကောင်းမွန်သည်။ တည်ငြိမ်သည်။ ကုန်ထုတ်စွမ်းအား။
• brute force ကို ထိရောက်စွာ အသုံးပြုခြင်းသည် ကုဒ်ကို ပိုမိုကောင်းမွန်အောင် ပြုလုပ်ရန်နှင့် လုံလောက်သော အရင်းအမြစ်များကို အချိန်တန်လျှင် အသုံးပြုရန် လိုအပ်သည်။ သင့်ဆာဗာများသည် သုံးစွဲသူမဟုတ်သော ဝန်ထုပ်ဝန်ပိုးကြီးကြီးမားမားအောက်တွင်ရှိပြီး အသုံးပြုသူ၏လုပ်ဆောင်မှုများသည် ဦးစားပေးဖြစ်နေပါက သင့်လျော်ပါသည်။
• စွမ်းဆောင်ရည်သည် အတွင်းကွင်းပတ် အယ်လဂိုရီသမ်သာမက စနစ်တစ်ခုလုံး၏ ဒီဇိုင်းပေါ်တွင် မူတည်သည်။

(ဤဆောင်းပါးသည် Memory အတွင်းရှိ ဒေတာကို ရှာဖွေခြင်းအကြောင်း ဖော်ပြထားပါသည်။ အများစုတွင်၊ အသုံးပြုသူတစ်ဦးသည် မှတ်တမ်းရှာဖွေမှုကို လုပ်ဆောင်သောအခါတွင်၊ Scalyr ဆာဗာများသည် ၎င်းကို သိမ်းဆည်းထားပြီးဖြစ်သည်။ နောက်ဆောင်းပါးတွင် ကက်ရှ်မထားသည့် မှတ်တမ်းများကို ရှာဖွေခြင်းအကြောင်း ဆွေးနွေးပါမည်။ တူညီသောမူများသည် ထိရောက်သောကုဒ်၊ brute force၊ ကြီးမားသောတွက်ချက်မှုအရင်းအမြစ်များနှင့်အတူ) ။

Brute force နည်းလမ်း

အစဉ်အလာအားဖြင့်၊ ကြီးမားသောဒေတာအစုံကို အဓိကစကားလုံးအညွှန်းကို အသုံးပြု၍ ရှာဖွေသည်။ ဆာဗာမှတ်တမ်းများတွင် အသုံးချသည့်အခါ၊ ၎င်းသည် မှတ်တမ်းရှိ သီးခြားစကားလုံးတိုင်းကို ရှာဖွေခြင်းကို ဆိုလိုသည်။ စကားလုံးတစ်လုံးစီအတွက်၊ ပါဝင်မှုအားလုံး၏ စာရင်းတစ်ခုပြုလုပ်ရန် လိုအပ်သည်။ ၎င်းသည် ဥပမာ 'error'၊ 'firefox' သို့မဟုတ် "transaction_16851951" ကဲ့သို့သော ဤစကားလုံးဖြင့် မက်ဆေ့ဂျ်အားလုံးကို ရှာရလွယ်ကူစေသည်။

ဒီနည်းလမ်းကို Google မှာသုံးခဲ့ပြီး ကောင်းကောင်းအလုပ်လုပ်ပါတယ်။ သို့သော် Scalyr တွင် ကျွန်ုပ်တို့သည် မှတ်တမ်းများကို byte byte ဖြင့် ရှာဖွေသည်။

အဘယ်ကြောင့်? abstract algorithm ရှုထောင့်မှကြည့်လျှင် သော့ချက်စာလုံးအညွှန်းများသည် brute force searches များထက် ပိုမိုထိရောက်ပါသည်။ သို့သော် ကျွန်ုပ်တို့သည် အယ်လဂိုရီသမ်များကို မရောင်းပါ၊ ကျွန်ုပ်တို့သည် စွမ်းဆောင်ရည်ကို ရောင်းချပါသည်။ စွမ်းဆောင်ရည်သည် အယ်လဂိုရီသမ်များသာမက စနစ်အင်ဂျင်နီယာဆိုင်ရာနှင့်လည်း ပတ်သက်ပါသည်။ ကျွန်ုပ်တို့သည် အရာအားလုံးကို ထည့်သွင်းစဉ်းစားရမည်- ဒေတာပမာဏ၊ ရှာဖွေမှုအမျိုးအစား၊ ရရှိနိုင်သော ဟာ့ဒ်ဝဲနှင့် ဆော့ဖ်ဝဲလ်ဆိုင်ရာ အကြောင်းအရာ။ ကျွန်ုပ်တို့၏ သီးခြားပြဿနာအတွက် 'grep' ကဲ့သို့သော အရာသည် အညွှန်းတစ်ခုထက် ပိုသင့်လျော်ကြောင်း ဆုံးဖြတ်ခဲ့သည်။

အညွှန်းများသည် ကြီးမြတ်သော်လည်း ကန့်သတ်ချက်များရှိသည်။ စကားလုံးတစ်လုံးရှာရလွယ်တယ်။ သို့သော် 'googlebot' နှင့် '404' ကဲ့သို့သော စကားလုံးများစွာပါသော မက်ဆေ့ချ်များကို ရှာဖွေခြင်းသည် ပို၍ခက်ခဲသည်။ 'uncaught exception' ကဲ့သို့သော စကားစုတစ်ခုကို ရှာဖွေခြင်းသည် ထိုစကားလုံးဖြင့် မက်ဆေ့ချ်အားလုံးကိုသာမက စကားလုံး၏ သီးခြားတည်နေရာကိုပါ မှတ်တမ်းတင်သည့် ပိုမိုခက်ခဲသော အညွှန်းတစ်ခု လိုအပ်ပါသည်။

စကားလုံးမရှာတဲ့အခါ တကယ့်အခက်အခဲက လာတာပါ။ bots များမှ အသွားအလာ မည်မျှလာသည်ကို သင်ကြည့်လိုသည်ဆိုပါစို့။ ပထမဆုံး အတွေးမှာ 'bot' ဟူသော စကားလုံးအတွက် မှတ်တမ်းများကို ရှာဖွေရန်ဖြစ်သည်။ ဤနည်းဖြင့် သင်သည် Googlebot၊ Bingbot နှင့် အခြား bot အများအပြားကို ရှာတွေ့နိုင်မည်ဖြစ်သည်။ ဒါပေမယ့် ဒီနေရာမှာ 'bot' ဟာ စကားလုံးမဟုတ်ပေမယ့် အစိတ်အပိုင်းတစ်ခုပါ။ အညွှန်းတွင် 'bot' ကို ရှာလျှင် 'Googlebot' ဟူသော စာလုံးပါသော မည်သည့်ပို့စ်ကိုမျှ ရှာမတွေ့ပါ။ အညွှန်းအတွင်းရှိ စကားလုံးတိုင်းကို စစ်ဆေးပြီးနောက် တွေ့ရှိသောသော့ချက်စာလုံးများအတွက် အညွှန်းကို စကင်န်ဖတ်ပါက၊ ရှာဖွေမှု အလွန်နှေးကွေးသွားမည်ဖြစ်သည်။ ရလဒ်အနေဖြင့် အချို့သော မှတ်တမ်းပရိုဂရမ်များသည် စကားလုံးပိုင်းရှာဖွေမှုများကို ခွင့်မပြုပါ သို့မဟုတ် (အကောင်းဆုံးအားဖြင့်) စွမ်းဆောင်ရည်နိမ့်သော အထူး syntax ကို ခွင့်ပြုပါသည်။ ဒါကို ရှောင်ချင်တယ်။

နောက်ပြဿနာတစ်ခုကတော့ သတ်ပုံသတ်ပုံပါပဲ။ တောင်းဆိုချက်အားလုံးကို သင်ရှာလိုပါသလား။ 50.168.29.7? ပါဝင်သော အမှားရှာမှတ်တမ်းများအကြောင်း [error]? စာရင်းသွင်းသူများသည် အများအားဖြင့် သတ်ပုံဖြတ်ခြင်းကို ကျော်သွားကြသည်။

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

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

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

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

Brute force သည် သင့်တွင် ရိုင်းစိုင်းသော ပြဿနာတစ်ခု (နှင့် အင်အားများစွာ) ရှိပါက အလုပ်လုပ်သည်

Brute force သည် အတွင်းပိုင်းကွင်းငယ်များဖြင့် ရိုးရှင်းသော ပြဿနာများတွင် အကောင်းဆုံးလုပ်ဆောင်သည်။ မကြာခဏဆိုသလို သင်သည် အလွန်မြင့်မားသောအမြန်နှုန်းဖြင့် လုပ်ဆောင်ရန် အတွင်းပိုင်းပတ်ပတ်လည်ကို အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်နိုင်သည်။ ကုဒ်သည် ရှုပ်ထွေးပါက၊ ၎င်းကို optimize လုပ်ရန် ပိုခက်ခဲသည်။

ကျွန်ုပ်တို့၏ရှာဖွေရေးကုဒ်တွင် မူလက အလွန်ကြီးမားသော အတွင်းကွင်းတစ်ခုရှိသည်။ ကျွန်ုပ်တို့သည် 4K ဖြင့် စာမျက်နှာများတွင် မက်ဆေ့ချ်များကို သိမ်းဆည်းထားသည်။ စာမျက်နှာတစ်ခုစီတွင် မက်ဆေ့ချ်အချို့ (UTF-8) နှင့် စာတစ်ခုစီအတွက် မက်တာဒေတာများ ပါရှိသည်။ မက်တာဒေတာသည် တန်ဖိုး၏ အရှည်၊ အတွင်းမက်ဆေ့ခ်ျ ID နှင့် အခြားအကွက်များကို ကုဒ်နံပါတ်ပေးသည့် ဖွဲ့စည်းပုံတစ်ခုဖြစ်သည်။ ရှာဖွေမှုစက်ဝန်းသည် ဤကဲ့သို့ ဖြစ်သည်-

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

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

အစပိုင်းတွင်၊ ထိုသို့သောကုဒ်သည် brute force optimization အတွက် အလွန်သင့်လျော်သည်ဟု ထင်ရသည်။ "အစစ်အမှန်အလုပ်" ၌ String.indexOf() CPU ပရိုဖိုင်ကိုတောင် မလွှမ်းမိုးထားဘူး။ ဆိုလိုသည်မှာ၊ ဤနည်းလမ်းကို အကောင်းဆုံးဖြစ်အောင်လုပ်ရုံမျှဖြင့် သိသာထင်ရှားသောအကျိုးသက်ရောက်မှုကို ဆောင်ကြဉ်းမည်မဟုတ်ပေ။

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

ဤဗားရှင်းသည် မြင်ကွင်းပေါ်တွင် တိုက်ရိုက်အလုပ်လုပ်သည်။ raw byte[] 4K စာမျက်နှာတစ်ခုလုံးတွင် မက်ဆေ့ခ်ျအားလုံးကို တစ်ပြိုင်နက် ရှာဖွေပါ။

၎င်းသည် brute force method အတွက် ပိုကောင်းအောင်ပြုလုပ်ရန် ပိုမိုလွယ်ကူသည်။ ပို့စ်တစ်ခုစီတွင် သီးခြားမဟုတ်ဘဲ 4K စာမျက်နှာတစ်ခုလုံးအတွက် အတွင်းပိုင်းရှာဖွေမှု လှည့်ပတ်ကို တစ်ပြိုင်နက် ခေါ်ဆိုသည်။ ဒေတာကူးယူခြင်း ၊ အရာဝတ္ထုများကို ခွဲဝေပေးခြင်း မရှိပါ။ ထို့အပြင် ပိုမိုရှုပ်ထွေးသော မက်တာဒေတာ လုပ်ဆောင်ချက်များကို ရလဒ်သည် အပြုသဘောဆောင်သည့် မက်ဆေ့ခ်ျတိုင်းတွင်မဟုတ်ဘဲ ရလဒ်ကောင်းနေမှသာ ခေါ်ဆိုပါသည်။ ဤနည်းဖြင့် ကျွန်ုပ်တို့သည် ကြီးမားသောတန်ချိန်ကို ဖယ်ရှားပြီး ကျန်ဝန်အား သေးငယ်သော အတွင်းပိုင်းရှာဖွေမှု ကွင်းဆက်တွင် စုစည်းထားကာ၊ ၎င်းသည် နောက်ထပ် ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ရန် သင့်လျော်ပါသည်။

ကျွန်ုပ်တို့၏ အမှန်တကယ် ရှာဖွေမှု အယ်လဂိုရီသမ်ကို အခြေခံထားသည်။ Leonid Volnitsky ၏စိတ်ကူးကောင်း. ၎င်းသည် အဆင့်တစ်ခုစီတွင် ရှာဖွေရေးစာကြောင်း၏ အရှည်ခန့်ကို ကျော်သွားသည့် Boyer-Moore algorithm နှင့် ဆင်တူသည်။ အဓိက ခြားနားချက်မှာ မှားယွင်းသော တိုက်ဆိုင်မှုများကို လျှော့ချရန် တစ်ကြိမ်လျှင် နှစ်ဘိုက် စစ်ဆေးခြင်း ဖြစ်သည်။

ကျွန်ုပ်တို့၏ အကောင်အထည်ဖော်မှုသည် ရှာဖွေမှုတစ်ခုစီအတွက် 64K ရှာဖွေမှုဇယားကို ဖန်တီးရန် လိုအပ်သော်လည်း ၎င်းသည် ကျွန်ုပ်တို့ရှာဖွေနေသည့်ဒေတာ၏ gigabytes နှင့် နှိုင်းယှဉ်၍မရပါ။ အတွင်းကွင်းသည် core တစ်ခုတည်းတွင် တစ်စက္ကန့်လျှင် gigabytes များစွာကို လုပ်ဆောင်သည်။ လက်တွေ့တွင်၊ တည်ငြိမ်သောစွမ်းဆောင်ရည်သည် core တစ်ခုစီတွင်တစ်စက္ကန့်လျှင် 1,25 GB ဝန်းကျင်ရှိပြီး တိုးတက်မှုအတွက် နေရာရှိပါသည်။ အတွင်းစက်ဝိုင်း၏ အပြင်ဘက်ရှိ ထိပ်ပိုင်းအချို့ကို ဖယ်ရှားပစ်ရန် ဖြစ်နိုင်ပြီး Java အစား C တွင် အတွင်းကွင်းပတ်တစ်ခုဖြင့် စမ်းသပ်ရန် စီစဉ်ထားပါသည်။

ငါတို့က အင်အားသုံးတယ်။

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

1 အူတိုင်: မှန်ကန်စွာအသုံးပြုသောအခါ၊ ခေတ်မီပရိုဆက်ဆာ၏ တစ်ခုတည်းသော core သည် ၎င်း၏ကိုယ်ပိုင်ညာဘက်တွင် အစွမ်းထက်သည်။

8 cores: ကျွန်ုပ်တို့သည် လက်ရှိတွင် Amazon hi1.4xlarge နှင့် i2.4xlarge SSD ဆာဗာများတွင် လုပ်ဆောင်နေပြီး တစ်ခုစီတွင် 8 cores (16 threads) ရှိသည်။ အထက်တွင်ဖော်ပြခဲ့သည့်အတိုင်း ဤ core များသည် များသောအားဖြင့် နောက်ခံလုပ်ဆောင်မှုများနှင့် အလုပ်များနေပါသည်။ အသုံးပြုသူသည် ရှာဖွေမှုပြုလုပ်သောအခါ၊ နောက်ခံလုပ်ဆောင်မှုများကို ဆိုင်းငံ့ထားပြီး ရှာဖွေမှုအတွက် core 8 ခုလုံးကို ဖယ်ရှားပေးပါသည်။ ရှာဖွေမှုသည် အများအားဖြင့် စက္ကန့်ပိုင်းအတွင်း ပြီးဆုံးပြီး နောက်တွင် နောက်ခံအလုပ်များ ပြန်လည်စတင်သည် (ရှာဖွေမှုမေးခွန်းများ၏ အတားအဆီးသည် အရေးကြီးသော နောက်ခံလုပ်ငန်းကို အနှောင့်အယှက်မဖြစ်စေကြောင်း သေချာစေသည်)။

16 cores: ယုံကြည်စိတ်ချရမှုအတွက်၊ ကျွန်ုပ်တို့သည် ဆာဗာများကို master/slave အုပ်စုများအဖြစ် စုစည်းထားပါသည်။ မာစတာတစ်ခုစီတွင် ၎င်း၏အမိန့်အောက်တွင် SSD တစ်ခုနှင့် EBS ဆာဗာတစ်ခုရှိသည်။ ပင်မဆာဗာ ပျက်သွားပါက၊ SSD ဆာဗာသည် ချက်ချင်း နေရာယူသည်။ တစ်ချိန်လုံးနီးပါး၊ မာစတာနှင့်ကျွန်သည် ကောင်းမွန်စွာအလုပ်လုပ်သည်၊ ထို့ကြောင့် ဒေတာဘလောက်တစ်ခုစီကို မတူညီသောဆာဗာနှစ်ခုတွင် ရှာဖွေနိုင်သည် (EBS slave ဆာဗာတွင် အားနည်းသည့်ပရိုဆက်ဆာပါရှိသည်၊ ထို့ကြောင့် ကျွန်ုပ်တို့က ၎င်းကိုမစဉ်းစားပါ)။ ကျွန်ုပ်တို့သည် ၎င်းတို့ကြားတွင် လုပ်ဆောင်စရာများကို ပိုင်းခြားထားသောကြောင့် ကျွန်ုပ်တို့တွင် စုစုပေါင်း cores 16 ခု ရနိုင်ပါသည်။

အူတိုင်များစွာ: မဝေးတော့သောအနာဂတ်တွင်၊ ကျွန်ုပ်တို့သည် အသေးအဖွဲမဟုတ်သော တောင်းဆိုမှုတိုင်းကို လုပ်ဆောင်ရာတွင် ၎င်းတို့အားလုံးပါဝင်သည့်နည်းလမ်းဖြင့် ဆာဗာများတစ်လျှောက် ဒေတာဖြန့်ဝေပါမည်။ အူတိုင်တိုင်း အလုပ်လုပ်ပါလိမ့်မယ်။ [မှတ်ချက်: ကျွန်ုပ်တို့သည် အစီအစဉ်ကို အကောင်အထည်ဖော်ပြီး ရှာဖွေမှုအမြန်နှုန်းကို 1 TB/s အထိ တိုးမြှင့်လိုက်သည်၊ ဆောင်းပါး၏အဆုံးတွင် မှတ်ချက်ကို ကြည့်ပါ။].

ရိုးရှင်းမှုသည် ယုံကြည်စိတ်ချရမှုကို အာမခံသည်။

brute force method ၏နောက်ထပ်အားသာချက်မှာ ၎င်း၏ မျှတသော တသမတ်တည်း စွမ်းဆောင်ရည်ဖြစ်သည်။ ပုံမှန်အားဖြင့်၊ ရှာဖွေမှုသည် ပြဿနာနှင့် ဒေတာအစုံ၏အသေးစိတ်အချက်များအတွက် အလွန်အထိခိုက်မခံပါ (အဲဒါကို "ကြမ်း" ဟုခေါ်သည်)။

သော့ချက်စာလုံးအညွှန်းသည် တစ်ခါတစ်ရံတွင် မယုံနိုင်လောက်အောင် မြန်ဆန်သောရလဒ်များကို ထုတ်ပေးနိုင်ပြီး အခြားအချိန်များတွင်လည်း မရရှိပါ။ 'customer_50' ဟူသော ဝေါဟာရသည် သုံးကြိမ်တိတိ ပေါ်လာသည့် 5987235982 GB မှတ်တမ်းများ သင့်တွင် ရှိသည်ဟု ဆိုကြပါစို့။ ဤအသုံးအနှုန်းအတွက် ရှာဖွေခြင်းသည် အညွှန်းမှ တိုက်ရိုက်ရေတွက်ပြီး ချက်ခြင်း အပြီးသတ်ပါမည်။ သို့သော် ရှုပ်ထွေးသော wildcard ရှာဖွေမှုသည် သော့ချက်စာလုံးပေါင်း ထောင်ပေါင်းများစွာကို စကင်န်ဖတ်နိုင်ပြီး အချိန်ကြာမြင့်နိုင်သည်။

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

brute force method ၏ ရိုးရှင်းမှုသည် ၎င်း၏ စွမ်းဆောင်ရည်သည် ၎င်း၏ သီအိုရီ အမြင့်ဆုံးနှင့် နီးစပ်သည်ဟု ဆိုလိုသည်။ မမျှော်လင့်ထားသော ဒစ်ပြားများပိုလျှံခြင်း၊ လော့ခ်ချခြင်း၊ ညွှန်မှတ်လိုက်ခြင်း နှင့် ပျက်ကွက်ခြင်းအတွက် အခြားအကြောင်းရင်းထောင်ပေါင်းများစွာအတွက် ရွေးချယ်ခွင့်နည်းပါးသည်။ ကျွန်ုပ်တို့၏အလုပ်အများဆုံးဆာဗာတွင်ပြီးခဲ့သည့်အပတ်က Scalyr အသုံးပြုသူများမှတောင်းဆိုမှုများကိုကြည့်ရှုခဲ့သည်။ တောင်းဆိုမှု ၁၄,၀၀၀ ရှိခဲ့သည်။ သူတို့ထဲက ရှစ်ယောက်တိတိက တစ်စက္ကန့်ထက် ပိုကြာတယ်။ 14% သည် 000 မီလီစက္ကန့်အတွင်း ပြီးစီးသည် (မှတ်တမ်းခွဲခြမ်းစိတ်ဖြာမှုကိရိယာများကို အသုံးမပြုပါက၊ ကျွန်ုပ်ကို ယုံကြည်ပါ။ မြန်တယ်။).

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

မှတ်တမ်းရှာဖွေမှု လုပ်ဆောင်ချက်

ဤသည်မှာ Scalyr ရှာဖွေမှုကို လုပ်ဆောင်ချက်တွင် ပြသသည့် ကာတွန်းတိုတစ်ခုဖြစ်သည်။ အများသူငှာ Github သိုလှောင်မှုတိုင်းရှိ ပွဲတိုင်းကို တင်သွင်းသည့် သရုပ်ပြအကောင့်တစ်ခုရှိသည်။ ဤသရုပ်ပြတွင်၊ ကျွန်ုပ်သည် တစ်ပတ်၏ဒေတာတန်ဖိုးကို ဆန်းစစ်ကြည့်သည်- ခန့်မှန်းခြေအားဖြင့် 600 MB အကြမ်းမှတ်တမ်းများ။

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

နိဂုံးချုပ်

ဒေတာအများအပြားကို စီမံဆောင်ရွက်ရာတွင် ကောင်းမွန်သော အယ်လဂိုရီသမ်ကို ရွေးချယ်ရန် အရေးကြီးသော်လည်း "ကောင်း" သည် "ဖန်စီ" ဟု မဆိုလိုပါ။ သင့်ကုဒ်သည် လက်တွေ့တွင် မည်သို့အလုပ်လုပ်မည်ကို စဉ်းစားပါ။ algorithms ၏ သီအိုရီပိုင်းခြားစိတ်ဖြာချက်သည် လက်တွေ့ကမ္ဘာတွင် အလွန်အရေးပါသော အချက်အချို့ကို ချန်ထားခဲ့သည်။ ရိုးရှင်းသော အယ်လဂိုရီသမ်များသည် ပိုကောင်းအောင်ပြုလုပ်ရန် ပိုမိုလွယ်ကူပြီး အနားသတ်အခြေအနေများတွင် ပိုမိုတည်ငြိမ်ပါသည်။

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

ရက်စက်ကြမ်းကြုတ်သောနည်းလမ်းကို အသုံးပြု၍ မှတ်တမ်းအစုတစ်ခုအတွင်း အမြန်၊ ယုံကြည်စိတ်ချရသော၊ လိုက်လျောညီထွေရှိသော ရှာဖွေမှုကို အကောင်အထည်ဖော်ခဲ့သည်။ ဤအကြံဉာဏ်များသည် သင့်ပရောဂျက်များအတွက် အသုံးဝင်မည်ဟု မျှော်လင့်ပါသည်။

တည်းဖြတ်ရန်- ခေါင်းစဉ်နှင့် စာသားများသည် "Search at 20 GB per second" မှ "Search at 1 TB per second" သို့ လွန်ခဲ့သောနှစ်အနည်းငယ်အတွင်း စွမ်းဆောင်ရည်တိုးလာမှုကို ထင်ဟပ်စေပါသည်။ ဤအမြန်နှုန်း တိုးလာရခြင်းမှာ ကျွန်ုပ်တို့၏ တိုးပွားလာသော ဖောက်သည်အခြေခံကို ဝန်ဆောင်မှုပေးရန်အတွက် ယနေ့ ကျွန်ုပ်တို့ လုပ်ဆောင်နေသော EC2 ဆာဗာ အမျိုးအစားနှင့် အရေအတွက် အပြောင်းအလဲများကြောင့် ဖြစ်ပါသည်။ လုပ်ငန်းလည်ပတ်မှုစွမ်းဆောင်ရည်ကို သိသိသာသာ မြှင့်တင်ပေးမည့် မကြာမီတွင် အပြောင်းအလဲများ ရှိလာမည်ဖြစ်ပြီး ၎င်းတို့ကို မျှဝေရန် ကျွန်ုပ်တို့ မစောင့်နိုင်တော့ပါ။

source: www.habr.com