အွန်လိုင်းဆိုက်များမှ ကြော်ငြာကမ်ပိန်းများဆိုင်ရာ ဒေတာကို စုဆောင်းပုံ (ထုတ်ကုန်ဆီသို့ ဆူးလမ်းကြောင်း)

အွန်လိုင်းကြော်ငြာနယ်ပယ်သည် နည်းပညာအဆင့်မြင့်ပြီး တတ်နိုင်သမျှ အလိုအလျောက်လုပ်ဆောင်သင့်သည်ဟု ထင်ရသည်။ ဘာဖြစ်လို့လဲဆိုတော့ Yandex၊ Mail.Ru၊ Google နဲ့ Facebook တို့လို သူတို့ရဲ့နယ်ပယ်မှာ အကြီးစားကြီးတွေနဲ့ ကျွမ်းကျင်သူတွေ အလုပ်လုပ်နေလို့ပါပဲ။ သို့သော် ထွက်ပေါ်လာသည့်အတိုင်း၊ ပြီးပြည့်စုံမှုတွင် ကန့်သတ်ချက်မရှိသည့်အပြင် အလိုအလျောက်လုပ်ဆောင်ရန် တစ်ခုခု အမြဲရှိနေပါသည်။

အရင်းအမြစ်

ဆက်သွယ်ရေးအဖွဲ့ Dentsu Aegis ကွန်ရက် ရုရှား ဒစ်ဂျစ်တယ်ကြော်ငြာဈေးကွက်တွင် အကြီးမားဆုံးကစားသမားဖြစ်ပြီး ၎င်း၏လုပ်ငန်းလုပ်ငန်းစဉ်များကို အကောင်းဆုံးဖြစ်အောင်နှင့် အလိုအလျောက်လုပ်ဆောင်ရန် နည်းပညာတွင် တက်ကြွစွာ ရင်းနှီးမြှုပ်နှံထားသည်။ အွန်လိုင်းကြော်ငြာစျေးကွက်၏မဖြေရှင်းနိုင်သောပြဿနာများထဲမှတစ်ခုမှာ မတူညီသောအင်တာနက်ပလက်ဖောင်းများမှ ကြော်ငြာကမ်ပိန်းများအတွက် စာရင်းဇယားများစုဆောင်းခြင်းတာဝန်ဖြစ်သည်။ ဤပြဿနာအတွက် ဖြေရှင်းချက်သည် နောက်ဆုံးတွင် ထုတ်ကုန်တစ်ခု ဖန်တီးမှုကို ဖြစ်ပေါ်စေခဲ့သည်။ D1.Digital (DiVan အဖြစ်ဖတ်ပါ)၊ ကျွန်ုပ်တို့ပြောလိုသည့် ဖွံ့ဖြိုးတိုးတက်မှု။

အဘယ်ကြောင့်နည်း

1. ပရောဂျက်စတင်ချိန်တွင်၊ စျေးကွက်တွင် ကြော်ငြာကမ်ပိန်းများတွင် စာရင်းဇယားများကို အလိုအလျောက်စုဆောင်းခြင်းပြဿနာကို ဖြေရှင်းပေးသည့် အဆင်သင့်လုပ်ထားသော ထုတ်ကုန်တစ်ခုမျှ မရှိပါ။ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့၏လိုအပ်ချက်များကို ကျွန်ုပ်တို့ကိုယ်တိုင်မှလွဲ၍ မည်သူမျှ ဖြည့်ဆည်းပေးမည်မဟုတ်ပါ။

Improvado၊ Roistat၊ Supermetrics၊ SegmentStream ကဲ့သို့သော ဝန်ဆောင်မှုများသည် ပလပ်ဖောင်းများ၊ လူမှုကွန်ရက်များနှင့် Google Analitycs တို့နှင့် ပေါင်းစည်းကာ ကြော်ငြာကမ်ပိန်းများကို အဆင်ပြေစွာ ခွဲခြမ်းစိတ်ဖြာပြီး ထိန်းချုပ်ရန်အတွက် ခွဲခြမ်းစိတ်ဖြာမှု ဒက်ရှ်ဘုတ်များကို တည်ဆောက်နိုင်စေပါသည်။ ကျွန်ုပ်တို့၏ထုတ်ကုန်ကို မတီထွင်မီ၊ ဆိုက်များမှ အချက်အလက်စုဆောင်းရန် ဤစနစ်အချို့ကို အသုံးပြုရန် ကြိုးစားခဲ့သော်လည်း ကံမကောင်းစွာဖြင့်၊ ၎င်းတို့သည် ကျွန်ုပ်တို့၏ပြဿနာများကို မဖြေရှင်းနိုင်ခဲ့ပါ။

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

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

2. အွန်လိုင်းကြော်ငြာဈေးကွက်သည် တစ်နှစ်ထက်တစ်နှစ် ကြီးထွားလာပြီး 2018 ခုနှစ်တွင် ကြော်ငြာဘတ်ဂျက်အရ အစဉ်အလာအကြီးဆုံး တီဗီကြော်ငြာဈေးကွက်ကို ကျော်တက်သွားခဲ့သည်။ ဒီတော့ အတိုင်းအတာတစ်ခုရှိတယ်။.

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

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

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

မဟာအစီအစဉ်

စစချင်းအားဖြင့်၊ ကျွန်ုပ်တို့သည် စံပြစနစ်တစ်ခု၏ မျှော်မှန်းချက်တစ်ခုကို ဖွဲ့စည်းခဲ့သည်-

• 1C ကော်ပိုရိတ်စနစ်မှ ကြော်ငြာကမ်ပိန်းများကို အမျိုးမျိုးသော ပလက်ဖောင်းပေါ်တွင် ၎င်းတို့၏အမည်များ၊ ကာလများ၊ ဘတ်ဂျက်များနှင့် နေရာချထားမှုများဖြင့် ၎င်းထဲသို့ အလိုအလျောက် ထည့်သွင်းသင့်သည်။
• ကြော်ငြာလှုံ့ဆော်မှုတစ်ခုအတွင်း နေရာချထားမှုတစ်ခုစီအတွက်၊ ဖြစ်နိုင်ခြေရှိသော စာရင်းဇယားအားလုံးကို နေရာချထားမှုပြုလုပ်နေသည့် ဆိုက်များမှ အလိုအလျောက် ဒေါင်းလုဒ်လုပ်ထားသင့်သည်၊ နှစ်သက်မှုအရေအတွက်၊ ကလစ်နှိပ်မှု၊ ကြည့်ရှုမှုများစသည်ဖြင့်၊
• အချို့သော ကြော်ငြာကမ်ပိန်းများကို Adriver၊ Weborama၊ DCM စသည်ဖြင့် ခေါ်ဝေါ်သော ကြော်ငြာစနစ်များဖြင့် ခြေရာခံပါသည်။ Mediascope ကုမ္ပဏီသည် ရုရှားတွင် စက်မှုအင်တာနက်မီတာလည်း ရှိပါသည်။ ကျွန်ုပ်တို့၏အစီအစဉ်အရ၊ လွတ်လပ်သောနှင့်စက်မှုလုပ်ငန်းစောင့်ကြည့်လေ့လာခြင်းမှဒေတာများကိုသက်ဆိုင်ရာကြော်ငြာလှုံ့ဆော်မှုများထဲသို့အလိုအလျောက်ထည့်သွင်းသင့်သည်။
• အင်တာနက်ပေါ်ရှိ ကြော်ငြာကမ်ပိန်းအများစုသည် Google Analytics ကို အသုံးပြု၍ ခြေရာခံထားသည့် အချို့သောပစ်မှတ်လုပ်ဆောင်ချက်များ (ဝယ်ယူမှု၊ ဖုန်းခေါ်ဆိုမှု၊ စမ်းသပ်မှုတစ်ခုအတွက် အကောင့်ဖွင့်ခြင်းစသည်) ကို ရည်ရွယ်ပြီး ကမ်ပိန်း၏အခြေအနေနှင့် ကိန်းဂဏန်းများကို နားလည်ရန် အရေးကြီးသည့် စာရင်းဇယားများ၊ ကျွန်ုပ်တို့၏ tool တွင်ထည့်သွင်းသင့်သည်။

ပထမအချက်က အဖုအထစ်တွေပါ။

ကျွန်ုပ်တို့၏ ကတိကဝတ်ပြုထားသော ဆော့ဖ်ဝဲလ်ဖွံ့ဖြိုးတိုးတက်မှုဆိုင်ရာ လိုက်လျောညီထွေရှိသော အခြေခံမူများ (လျင်မြန်သော၊ အရာခပ်သိမ်း) ကို ကျွန်ုပ်တို့က MVP ကို ​​ဦးစွာတီထွင်ပြီးနောက် ရည်ရွယ်ထားသည့် ပန်းတိုင်ဆီသို့ ထပ်တလဲလဲ ရွေ့လျားရန် ဆုံးဖြတ်ခဲ့သည်။
ကျွန်ုပ်တို့၏ထုတ်ကုန်အပေါ်အခြေခံ၍ MVP တည်ဆောက်ရန်ဆုံးဖြတ်ခဲ့သည်။ DANBo (Dentsu Aegis ကွန်ရက်ဘုတ်အဖွဲ့)ကျွန်ုပ်တို့၏ဖောက်သည်များ၏ ကြော်ငြာကမ်ပိန်းများအကြောင်း ယေဘုယျအချက်အလက်များပါရှိသော ဝဘ်အက်ပလီကေးရှင်းတစ်ခုဖြစ်သည်။

MVP အတွက်၊ ပရောဂျက်ကို အကောင်အထည်ဖော်ရာတွင် အတတ်နိုင်ဆုံး ရိုးရှင်းအောင်ပြုလုပ်ထားသည်။ ပေါင်းစည်းမှုအတွက် ကန့်သတ်ထားသော ပလက်ဖောင်းများစာရင်းကို ကျွန်ုပ်တို့ ရွေးချယ်ထားပါသည်။ ၎င်းတို့သည် Yandex.Direct၊ Yandex.Display၊ RB.Mail၊ MyTarget၊ Adwords၊ DBM၊ VK၊ FB နှင့် အဓိက adserving စနစ်များဖြစ်သည့် Adriver နှင့် Weborama တို့ဖြစ်သည်။

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

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

ပွင့်ပွင့်လင်းလင်းမြင်ရသည်မှာ ကြောက်စရာကောင်းသည်-

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

ဝဘ်ဆိုက်တစ်ခုစီအတွက်၊ သီးခြား windows ဝန်ဆောင်မှုကို ရေးသားထားပြီး၊ ဆိုက်၏ API တွင် ဝန်ဆောင်မှုအကောင့်တစ်ခုအောက်တွင် တစ်နေ့တစ်ကြိမ် ဝင်ရောက်ပြီး သတ်မှတ်ထားသော ကမ်ပိန်း ID များအတွက် စာရင်းဇယားများကို ဒေါင်းလုဒ်လုပ်ထားသည်။ adserving စနစ်တွေနဲ့ အလားတူပါပဲ။

ဒေါင်းလုဒ်လုပ်ထားသောဒေတာကို စိတ်ကြိုက်ဒိုင်ခွက်ငယ်ပုံစံဖြင့် အင်တာဖေ့စ်ပေါ်တွင် ပြသထားသည်-

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

• အဓိကပြဿနာမှာ စနစ်ထဲသို့ တင်ရန်အတွက် ဒေတာပြင်ဆင်ခြင်း၏ ရှုပ်ထွေးမှုဖြစ်သည်။ ထို့အပြင်၊ နေရာချထားမှုဒေတာကို မဖွင့်မီ တင်းကြပ်စွာ သတ်မှတ်ထားသော ဖော်မတ်သို့ ပြောင်းရပါမည်။ ဒေါင်းလုဒ်ဖိုင်တွင် မတူညီသောဆိုက်များမှ entity identifiers များ ထည့်သွင်းရန် လိုအပ်ပါသည်။ နည်းပညာပိုင်းဆိုင်ရာ မလေ့ကျင့်ရသေးသော အသုံးပြုသူများသည် ဆိုက်ပေါ်တွင် ဤသတ်မှတ်သူများကို ရှာဖွေရမည့်နေရာနှင့် ဖိုင်အတွင်းသို့ ၎င်းတို့ထည့်သွင်းရမည့်နေရာကို ရှင်းပြရန် အလွန်ခက်ခဲသည့်အချက်နှင့် ရင်ဆိုင်နေရသည်။ ဝဘ်ဆိုက်များတွင် စည်းရုံးလှုံ့ဆော်မှုများ လုပ်ဆောင်နေသည့် ဌာနများရှိ ဝန်ထမ်းအရေအတွက်နှင့် လည်ပတ်မှုတို့ကို ထည့်သွင်းစဉ်းစားခြင်းဖြင့် ကျွန်ုပ်တို့ဘက်မှ ပံ့ပိုးကူညီမှု အများအပြားကို ဖြစ်ပေါ်စေပြီး ကျွန်ုပ်တို့ လုံးဝ မကျေနပ်နိုင်ပါ။
• အခြားပြဿနာမှာ ကြော်ငြာပလပ်ဖောင်းအားလုံးတွင် ကြော်ငြာကမ်ပိန်းများကို အခြားအကောင့်များသို့ လွှဲအပ်ဝင်ရောက်ခွင့်အတွက် ယန္တရားများ မပါရှိပါ။ သို့သော် ကိုယ်စားလှယ်အဖွဲ့ ယန္တရားတစ်ခု ရရှိနိုင်သော်လည်း ကြော်ငြာရှင်များအားလုံးသည် ၎င်းတို့၏ ကမ်ပိန်းများကို ပြင်ပအကောင့်များသို့ ဝင်ရောက်ခွင့်ပေးရန် ဆန္ဒမရှိကြပါ။
• အရေးကြီးသောအချက်မှာ ကျွန်ုပ်တို့၏ 1C စာရင်းကိုင်စနစ်ထဲသို့ ၎င်းတို့ထည့်သွင်းထားပြီးသော အစီအစဥ်အညွှန်းများနှင့် နေရာချထားမှုအသေးစိတ်အချက်များအားလုံးကို ၎င်းတို့သည် ပြန်လည်ထည့်သွင်းရမည်ဖြစ်သောကြောင့် သုံးစွဲသူများကြားတွင် ဒေါသအမျက်ဒေါသဖြစ်ခဲ့ရသည်။ ဒန်ဘို.

နေရာချထားခြင်းဆိုင်ရာ သတင်းအချက်အလက်များ၏ အဓိကရင်းမြစ်သည် ကျွန်ုပ်တို့၏ 1C စနစ်ဖြစ်သင့်ပြီး ဒေတာအားလုံးကို တိကျမှန်ကန်စွာ အချိန်မှန်ရိုက်ထည့်ခြင်းဖြစ်သင့်သည် (ဤနေရာတွင် အချက်မှာ ပြေစာများကို 1C ဒေတာအပေါ်အခြေခံ၍ ထုတ်ပေးရခြင်းဖြစ်ပါသည်၊ ထို့ကြောင့် 1C ထဲသို့ ဒေတာမှန်ကန်စွာ ထည့်သွင်းခြင်း KPI သည် လူတိုင်းအတွက် ဦးစားပေးဖြစ်သည်။) ဤသည်မှာ စနစ်၏ သဘောတရားအသစ် ထွက်ပေါ်လာခြင်းဖြစ်သည်...။

ခံယူချက်

ကျွန်ုပ်တို့ ပထမဆုံးလုပ်ဆောင်ရန် ဆုံးဖြတ်ခဲ့သည်မှာ အင်တာနက်ပေါ်ရှိ ကြော်ငြာကမ်ပိန်းများဆိုင်ရာ ကိန်းဂဏန်းများကို သီးခြားထုတ်ကုန်တစ်ခုအဖြစ် ခွဲထုတ်ခြင်းဖြစ်သည်- D1.Digital.

အယူအဆသစ်တွင်၊ ကျွန်ုပ်တို့သည် ထဲသို့ဝင်ရန် ဆုံးဖြတ်ခဲ့သည်။ D1.Digital 1C မှ ၎င်းတို့အတွင်း ကြော်ငြာလှုံ့ဆော်မှုများနှင့် နေရာချထားမှုများဆိုင်ရာ အချက်အလက်များ၊ ထို့နောက် ဆိုက်များနှင့် AdServing စနစ်များမှ စာရင်းဇယားများကို ဤနေရာများသို့ ဆွဲယူပါ။ ၎င်းသည် သုံးစွဲသူများအတွက် ဘဝကို သိသာထင်ရှားစွာ ရိုးရှင်းစေရန် (ပုံမှန်အတိုင်း၊ ဆော့ဖ်ဝဲရေးသားသူများထံ အလုပ်ပိုထည့်ပါ) နှင့် ပံ့ပိုးမှုပမာဏကို လျှော့ချရန် ယူဆပါသည်။

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

ဤပြဿနာကိုဖြေရှင်းရန်အတွက်၊ ကျွန်ုပ်တို့သည် မတူညီသောစနစ်များရှိအရာများကို အတူတကွချိတ်ဆက်ပေးမည့် ထူးခြားသော hashed key ဖြစ်သည့် DANBoID ကိုတီထွင်ရမည်ဖြစ်ပြီး ၎င်းသည် ဒေါင်းလုဒ်လုပ်ထားသောဒေတာအတွဲများတွင် မျှမျှတတလွယ်ကူပြီး ထူးခြားစွာဖော်ထုတ်နိုင်မည်ဖြစ်သည်။ ဤသတ်မှတ်ချက်ကို တစ်ဦးချင်းနေရာချထားမှုတစ်ခုစီအတွက် အတွင်းပိုင်း 1C စနစ်တွင် ထုတ်ပေးပြီး ဆိုက်များအားလုံးရှိ ကမ်ပိန်းများ၊ နေရာချထားမှုများနှင့် ကောင်တာများသို့ လွှဲပြောင်းပေးပါသည်။ နေရာအားလုံးတွင် DANBoID ထည့်သွင်းခြင်းအလေ့အကျင့်ကို အကောင်အထည်ဖော်ရန် အချိန်အနည်းငယ်ကြာခဲ့သော်လည်း ကျွန်ုပ်တို့လုပ်ဆောင်နိုင်ခဲ့သည်။ :)

ထို့နောက် ဆိုက်များအားလုံးတွင် စာရင်းဇယားများကို အလိုအလျောက်စုဆောင်းရန်အတွက် API ရှိသည်မဟုတ်ကြောင်းနှင့် API တစ်ခုပါရှိသည့်တိုင် လိုအပ်သည့်ဒေတာအားလုံးကို ပြန်မပေးကြောင်း ကျွန်ုပ်တို့ သိရှိလာပါသည်။

ဤအဆင့်တွင်၊ ပေါင်းစပ်မှုအတွက် ပလပ်ဖောင်းများစာရင်းကို သိသိသာသာလျှော့ချရန် ဆုံးဖြတ်ခဲ့ပြီး ကြော်ငြာကမ်ပိန်းအများစုတွင် ပါဝင်သည့် အဓိကပလက်ဖောင်းများကို အာရုံစိုက်ရန် ဆုံးဖြတ်ခဲ့သည်။ ဤစာရင်းတွင် ကြော်ငြာစျေးကွက်တွင် အကြီးဆုံးကစားသမားများ (Google၊ Yandex၊ Mail.ru)၊ လူမှုကွန်ရက်များ (VK၊ Facebook၊ Twitter)၊ အဓိက ကြော်ငြာဝန်ဆောင်မှုနှင့် ခွဲခြမ်းစိတ်ဖြာမှုစနစ်များ (DCM၊ Adriver၊ Weborama၊ Google Analytics) နှင့် အခြားပလပ်ဖောင်းများ ပါဝင်သည်။

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

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

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

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

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

ဖြေရှင်းချက် ဗိသုကာ ၁.၀

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

ဗိသုကာပညာကို ဒီဇိုင်းဆွဲသောအခါ၊ ကျွန်ုပ်တို့သည် ပြင်ပစနစ်များဖြစ်သော 1C၊ ကြော်ငြာပလပ်ဖောင်းများနှင့် ကြော်ငြာစနစ်များအားလုံးကို သီးခြားဝန်ဆောင်မှုများအဖြစ် ခွဲခြားထားသည်။
အဓိက အယူအဆမှာ ဝဘ်ဆိုက်များသို့ ချိတ်ဆက်မှုအားလုံးတွင် တူညီသော API ရှိပြီး ကျွန်ုပ်တို့အတွက် အဆင်ပြေသော အင်တာဖေ့စ်တစ်ခုသို့ ဆိုက် API ကို ယူဆောင်လာပေးသည့် အဒက်တာများဖြစ်သည်။

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

ချိတ်ဆက်သူများနှင့် ဝဘ်အပလီကေးရှင်းများအကြား ဆက်သွယ်ရန်အတွက် ကျွန်ုပ်တို့သည် Connector Proxy ဟုခေါ်သော နောက်ထပ်ဝန်ဆောင်မှုတစ်ခုကို ဖန်တီးရပါမည်။ ၎င်းသည် Service Discovery နှင့် Task Scheduler ၏ လုပ်ဆောင်ချက်များကို လုပ်ဆောင်သည်။ ဤဝန်ဆောင်မှုသည် ချိတ်ဆက်ကိရိယာတစ်ခုစီအတွက် ဒေတာစုဆောင်းခြင်းလုပ်ငန်းကို ညတိုင်း လုပ်ဆောင်ပါသည်။ ဝန်ဆောင်မှုအလွှာတစ်ခုရေးခြင်းသည် မက်ဆေ့ချ်ပွဲစားကို ချိတ်ဆက်ခြင်းထက် ပိုမိုလွယ်ကူသည်၊ ကျွန်ုပ်တို့အတွက် ရလဒ်ကို တတ်နိုင်သမျှမြန်မြန်ရရန် အရေးကြီးပါသည်။

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

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

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

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

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

ဒေတာအားလုံးသည် MongoDB တွင် ကောင်းကောင်းမလိုက်ဖက်ကြောင်း မကြာမီ ကျွန်ုပ်တို့တွေ့ရှိခဲ့ပြီး ဥပမာအားဖြင့်၊ ဆက်စပ်ဒေတာဘေ့စ်တစ်ခုတွင် နေ့စဉ်စာရင်းအင်းများကို သိမ်းဆည်းရန် ပို၍အဆင်ပြေပါသည်။ ထို့ကြောင့်၊ ဆက်စပ်ဒေတာဘေ့စ်တစ်ခုအတွက် ပိုမိုသင့်လျော်သော ချိတ်ဆက်သူများအတွက်၊ PostgreSQL သို့မဟုတ် MS SQL Server ကို သိုလှောင်မှုအဖြစ် ကျွန်ုပ်တို့ စတင်အသုံးပြုခဲ့သည်။

ရွေးချယ်ထားသော ဗိသုကာပညာနှင့် နည်းပညာများသည် D1.Digital ထုတ်ကုန်ကို လျင်မြန်စွာ တည်ဆောက်ပြီး စတင်နိုင်စေပါသည်။ ထုတ်ကုန်ဖွံ့ဖြိုးတိုးတက်မှု နှစ်နှစ်ကျော်ကာလအတွင်း၊ ကျွန်ုပ်တို့သည် ဝဘ်ဆိုက်များသို့ ချိတ်ဆက်မှု ၂၃ ခုကို တီထွင်ခဲ့ပြီး၊ ပြင်ပကုမ္ပဏီ API များနှင့် တန်ဖိုးမဖြတ်နိုင်သော အတွေ့အကြုံများကို ရရှိခဲ့ပြီး၊ တစ်ခုစီတွင် ၎င်းတို့ကိုယ်ပိုင်ရှိသည့် မတူညီသောဆိုက်များ၏ အန္တရာယ်များကို ရှောင်ရှားရန် သင်ယူခဲ့ပြီး အနည်းဆုံး 23 API ၏ ဖွံ့ဖြိုးတိုးတက်မှုအတွက် အထောက်အကူဖြစ်စေပါသည်။ ဆိုက်များ၊ လှုံ့ဆော်မှုပေါင်း 3 နီးပါးနှင့် နေရာချထားမှု 15 ကျော်အတွက် အချက်အလက်များကို အလိုအလျောက်ဒေါင်းလုဒ်လုပ်ထားသော ဆိုက်များသည် ထုတ်ကုန်၏လည်ပတ်မှုနှင့် ပတ်သက်၍ အသုံးပြုသူများထံမှ တုံ့ပြန်ချက်အများအပြားကို စုဆောင်းခဲ့ပြီး ဤအကြံပြုချက်အပေါ် အခြေခံ၍ ထုတ်ကုန်၏ အဓိကလုပ်ငန်းစဉ်ကို အကြိမ်ပေါင်းများစွာ ပြောင်းလဲနိုင်ခဲ့သည်။

ဖြေရှင်းချက် ဗိသုကာ ၁.၀

ဖွံ့ဖြိုးတိုးတက်မှုစတင်ချိန်မှ နှစ်နှစ်ကျော်သွားခဲ့ပါပြီ။ D1.Digital. စနစ်တွင် ဝန်အဆက်မပြတ်တိုးလာခြင်းနှင့် ဒေတာရင်းမြစ်အသစ်များ ပိုများလာခြင်းတို့ကြောင့် လက်ရှိဖြေရှင်းချက်ဗိသုကာတွင် ပြဿနာများကို တဖြည်းဖြည်းထင်ရှားစေသည်။

ပထမပြဿနာမှာ ဝဘ်ဆိုက်များမှ ဒေါင်းလုဒ်လုပ်ထားသော ဒေတာပမာဏနှင့် သက်ဆိုင်သည်။ အကြီးဆုံးဆိုက်များမှ လိုအပ်သော အချက်အလက်အားလုံးကို စုဆောင်းခြင်းနှင့် မွမ်းမံပြင်ဆင်ခြင်းတို့မှာ အချိန်များစွာကြာလာသည်ဟူသောအချက်နှင့် ရင်ဆိုင်ခဲ့ရသည်။ ဥပမာအားဖြင့်၊ နေရာချထားမှုအများစုအတွက် စာရင်းအင်းများကို ကျွန်ုပ်တို့ခြေရာခံသည့် AdRiver adserving စနစ်မှ ဒေတာစုဆောင်းခြင်းသည် 12 နာရီခန့် ကြာပါသည်။

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

အခြားပြဿနာမှာ ဒေါင်းလုဒ်လုပ်ထားသော ဒေတာကို လုပ်ဆောင်ခြင်းနှင့် သက်ဆိုင်သည်။ ယခုအခါ နေရာချထားမှုစာရင်းအင်းအသစ်များရောက်ရှိလာသောအခါ၊ ဒေတာကုန်ကြမ်းတင်ခြင်း၊ ဝဘ်ဆိုက်တစ်ခုစီအတွက် စုစည်းမက်ထရစ်များတွက်ချက်ခြင်း၊ မတူညီသောရင်းမြစ်များမှ ဒေတာများကို အချင်းချင်း နှိုင်းယှဉ်ခြင်းနှင့် ကမ်ပိန်းအတွက် အကျဉ်းချုပ်မက်ထရစ်များ တွက်ချက်ခြင်းတို့ပါ၀င်သည့် အဆင့်ဆင့်သော မက်ထရစ်များကို ပြန်လည်တွက်ချက်ခြင်းလုပ်ငန်းစဉ်ကို စတင်လိုက်ပါသည်။ ၎င်းသည် တွက်ချက်မှုအားလုံးကို လုပ်ဆောင်သည့် ဝဘ်အက်ပလီကေးရှင်းတွင် ဝန်အများကြီးကို ဖြစ်စေသည်။ အကြိမ်များစွာ၊ ပြန်လည်တွက်ချက်မှုလုပ်ငန်းစဉ်အတွင်း၊ အပလီကေးရှင်းသည် စနစ်နှင့်အသုံးပြုသူများ၏လုပ်ဆောင်မှုအပေါ် အဆိုးရွားဆုံးအကျိုးသက်ရောက်မှုဖြစ်သည့် 10-15 GB ခန့်ရှိသော ဆာဗာရှိ မမ်မိုရီအားလုံးကို စားသုံးခဲ့သည်။

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

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

တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့သည် Docker နှင့် Kubernetes သို့ ချိတ်ဆက်မှုများကို စတင်အသုံးပြုခဲ့သည်။
ကျွန်ုပ်တို့သည် Kubernetes သို့ပြောင်းရွှေ့ရန် အချိန်အတော်ကြာ စီစဉ်ခဲ့ပြီး CI/CD ဆက်တင်များကို စမ်းသပ်ခဲ့သော်လည်း အမှားတစ်ခုကြောင့် ဆာဗာပေါ်ရှိ 20 GB မမ်မိုရီကို ဆာဗာတွင် XNUMX GB ထက်ပို၍ စားမိသောအခါမှ စတင်၍ ရွှေ့ခဲ့သည် . စုံစမ်းစစ်ဆေးမှုအတွင်း၊ ချိတ်ဆက်ကိရိယာကို အမှားပြင်ဆင်ပြီးသည့်တိုင် နောက်ဆုံးတွင် ကျန်ရှိနေခဲ့သည့် Kubernetes အစုအဝေးသို့ ပြောင်းရွှေ့ခဲ့သည်။

Kubernetes သည် အဆင်ပြေကြောင်း ကျွန်ုပ်တို့ လျင်မြန်စွာ သဘောပေါက်ခဲ့ပြီး ခြောက်လအတွင်း ချိတ်ဆက်မှု 7 ခုနှင့် အရင်းအမြစ်အများဆုံးသုံးစွဲသည့် Connectors Proxy ကို ထုတ်လုပ်မှုအစုသို့ လွှဲပြောင်းပေးခဲ့သည်။

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

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

အဆိုပါပြဿနာများကိုဖြေရှင်းရန်အတွက်ကျွန်ုပ်တို့သည်ဗိသုကာ 2.0 ကိုတီထွင်ခဲ့သည်။

ဗိသုကာဗားရှင်းအသစ်၏ အဓိကကွာခြားချက်မှာ Web API အစား ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုများအကြား မက်ဆေ့ချ်များဖလှယ်ရန် RabbitMQ နှင့် MassTransit စာကြည့်တိုက်ကို အသုံးပြုပါသည်။ ဒါကိုလုပ်ဖို့၊ Connectors Hub ဖြစ်လာအောင် Connectors Proxy ကို လုံးလုံးနီးပါး ပြန်ရေးရပါမယ်။ ဝန်ဆောင်မှု၏ အဓိကအခန်းကဏ္ဍမှာ ချိတ်ဆက်သူများနှင့် နောက်ကြောင်းသို့ တောင်းဆိုချက်များကို ထပ်ဆင့်ပေးပို့ခြင်းတွင် မရှိတော့သော်လည်း ချိတ်ဆက်သူများထံမှ မက်ထရစ်များစုစည်းမှုကို စီမံခန့်ခွဲရာတွင် အမည်ပြောင်းထားသည်။

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

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

အခုကျွန်တော်တို့ဘယ်မှာလဲ

Proof-of-concept ဗိသုကာ 2.0 ထုတ်ကုန် D1.Digital ချိတ်ဆက်ကိရိယာအစုံအလင်ဖြင့် စမ်းသပ်မှုပတ်ဝန်းကျင်တွင် အဆင်သင့်ဖြစ်နေပါပြီ။ လုပ်ဆောင်ရန်ကျန်သည်မှာ ပလပ်ဖောင်းအသစ်တွင် အခြားချိတ်ဆက်ကိရိယာ 20 ခုကို ပြန်လည်ရေးသားရန်၊ ဒေတာကို မှန်ကန်စွာတင်ထားကြောင်းနှင့် မက်ထရစ်များအားလုံးကို မှန်ကန်စွာတွက်ချက်ပြီး ဒီဇိုင်းတစ်ခုလုံးကို ထုတ်လုပ်မှုအဖြစ် ပြောင်းလဲရန်ဖြစ်သည်။

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

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

ဗဟိုဝဘ်အပလီကေးရှင်းအပါအဝင် အပလီကေးရှင်းများအားလုံးကို Docker နှင့် Kubernetes သို့ လွှဲပြောင်းရန်လည်း စီစဉ်ထားပါသည်။ ဗိသုကာအသစ်နှင့် ပေါင်းစပ်လိုက်ခြင်းဖြင့်၊ ၎င်းသည် အသုံးပြုထားသော အရင်းအမြစ်များကို ဖြန့်ကျက်ခြင်း၊ စောင့်ကြည့်ခြင်းနှင့် ထိန်းချုပ်ခြင်းတို့ကို သိသိသာသာ ရိုးရှင်းစေသည်။

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

ယေဘူယျအားဖြင့်၊ အစီအစဥ်တွေက ကြီးကျယ်ခမ်းနားတယ်၊ ဆက်သွားကြရအောင် :)

R&D Dentsu Aegis Network Russia ဆောင်းပါးရေးသားသူ Georgy Ostapenko (shmiigaa), Mikhail Kotsik (hitexx)

source: www.habr.com