VKontakte မက်ဆေ့ဂျ်ဒေတာဘေ့စ်ကို အစကနေ ပြန်ရေးပြီး ရှင်သန်ပါ။

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

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

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

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

အမှုသမိုင်း

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

2009 ခုနှစ်အကုန်တွင် ပထမဆုံး text-engine repository ကို ရေးသားခဲ့ပြီး 2010 တွင် မက်ဆေ့ချ်များကို ၎င်းထံသို့ လွှဲပြောင်းပေးခဲ့သည်။

စာသားအင်ဂျင်တွင် မက်ဆေ့ချ်များကို စာရင်းများထဲတွင် သိမ်းဆည်းထားသည် - "စာတိုက်ပုံးများ" အမျိုးအစား။ ထိုစာရင်းတစ်ခုစီကို ဤမက်ဆေ့ဂျ်အားလုံးကို ပိုင်ဆိုင်သော အသုံးပြုသူ uid က ဆုံးဖြတ်သည်။ မက်ဆေ့ဂျ်တစ်ခုတွင် ရည်ညွှန်းချက်များ အစုံပါရှိသည်- အပြန်အလှန်ပြောဆိုသူ အမှတ်အသား၊ စာသား၊ ပူးတွဲပါဖိုင်များနှင့် အခြားအရာများ။ “ဘောက်စ်” အတွင်းရှိ မက်ဆေ့ဂျ် သတ်မှတ်စနစ်သည် local_id ဖြစ်ပြီး၊ ၎င်းသည် မည်သည့်အခါမှ မပြောင်းလဲဘဲ မက်ဆေ့ချ်အသစ်များအတွက် စဉ်ဆက်မပြတ် သတ်မှတ်ပေးထားသည်။ “ဘောက်စ်များ” သည် သီးခြားဖြစ်ပြီး အင်ဂျင်အတွင်း၌ တစ်ခုနှင့်တစ်ခု ထပ်တူပြု၍မရပါ၊ ၎င်းတို့အကြား ဆက်သွယ်မှုမှာ PHP အဆင့်တွင် ဖြစ်ပေါ်သည်။ အတွင်းမှ text-engine ၏ ဒေတာဖွဲ့စည်းပုံနှင့် လုပ်ဆောင်နိုင်စွမ်းများကို ကြည့်ရှုနိုင်သည်။ ဒီမှာ.

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

2011 ခုနှစ် မေလတွင်၊ VKontakte သည် ပါဝင်သူအများအပြားနှင့် စကားပြောဆိုမှုများ— multi-chat များကို မိတ်ဆက်ခဲ့သည်။ ၎င်းတို့နှင့် လုပ်ဆောင်ရန်၊ အဖွဲ့ဝင်-ချတ်များနှင့် ချတ်အဖွဲ့ဝင်များ အစုအဖွဲ့အသစ်နှစ်ခုကို ပြုစုပျိုးထောင်ခဲ့သည်။ ပထမတစ်ခုက သုံးစွဲသူများ၏ ချတ်များအကြောင်း ဒေတာကို သိမ်းဆည်းသည်၊ ဒုတိယတစ်ခုသည် သုံးစွဲသူများ၏ အချက်အလက်များကို ချတ်များဖြင့် သိမ်းဆည်းသည်။ စာရင်းများကိုယ်တိုင်အပြင်၊ ဥပမာအားဖြင့်၊ ဖိတ်ခေါ်သောအသုံးပြုသူနှင့် ၎င်းတို့ကို ချတ်သို့ထည့်သွင်းသည့်အချိန်တို့ ပါဝင်သည်။

"PHP၊ ချတ်သို့ မက်ဆေ့ချ်ပို့ကြပါစို့" ဟု သုံးစွဲသူက ပြောသည်။
"လာပါ၊ {username}" ဟု PHP ကဆိုသည်။

ဤအစီအစဥ်တွင် အားနည်းချက်များရှိသည်။ Synchronization သည် PHP ၏တာဝန်ဖြစ်နေဆဲဖြစ်သည်။ ကြီးမားသော ချတ်များနှင့် ၎င်းတို့ထံ မက်ဆေ့ချ်များ တစ်ပြိုင်နက် ပေးပို့သော သုံးစွဲသူများသည် အန္တရာယ်ရှိသော ဇာတ်လမ်းတစ်ခုဖြစ်သည်။ text-engine instance သည် uid ပေါ်တွင်မူတည်သောကြောင့်၊ ချတ်ပါဝင်သူများသည် မတူညီသောအချိန်များတွင် တူညီသောမက်ဆေ့ဂျ်ကို လက်ခံရရှိနိုင်ပါသည်။ တိုးတက်မှု ရပ်တန့်နေလျှင် ဤအရာဖြင့် နေထိုင်နိုင်သည်။ ဒါပေမယ့် အဲဒါဖြစ်မလာဘူး။

2015 နှစ်ကုန်တွင်၊ ကျွန်ုပ်တို့သည် ကွန်မြူနတီမက်ဆေ့ချ်များကို စတင်ခဲ့ပြီး 2016 ခုနှစ်အစတွင် ၎င်းတို့အတွက် API တစ်ခုကို စတင်ခဲ့ပါသည်။ အသိုင်းအဝိုင်းများတွင် chatbot ကြီးများ ထွန်းကားလာသည်နှင့်အမျှ load distribution ကိုပင် မေ့သွားနိုင်သည်။

ကောင်းမွန်သော ဘော့တ်တစ်ခုသည် တစ်နေ့လျှင် မက်ဆေ့ချ်ပေါင်း သန်းပေါင်းများစွာကို ထုတ်ပေးသည် - စကားပြောဆိုတတ်သည့် သုံးစွဲသူအများစုပင်လျှင် ယင်းကို ဂုဏ်ယူဝံ့ကြွားနိုင်မည်မဟုတ်ပေ။ ဆိုလိုသည်မှာ ထိုကဲ့သို့သော bot များနေထိုင်ခဲ့သည့် text-engine ၏ဖြစ်ရပ်အချို့သည် အပြည့်အဝခံစားလာရတော့သည်။

2016 တွင် Message engine များသည် chat-member နှင့် member-chats ပေါင်း 100 နှင့် text-engines 8000 တို့ဖြစ်သည်။ ၎င်းတို့ကို 64 GB မမ်မိုရီတစ်ခုစီတွင် ဆာဗာတစ်ထောင်တွင် လက်ခံကျင်းပခဲ့သည်။ ပထမအကြိမ် အရေးပေါ်တိုင်းတာမှုအနေဖြင့် မမ်မိုရီကို နောက်ထပ် 32 GB တိုးမြှင့်ခဲ့သည်။ ခန့်မှန်းချက်တွေကို ကျွန်တော်တို့ ခန့်မှန်းတယ်။ ပြင်းထန်သောပြောင်းလဲမှုမရှိဘဲ၊ ၎င်းသည် နောက်ထပ်တစ်နှစ်ခန့် လုံလောက်မည်ဖြစ်သည်။ သင်သည် ဟာ့ဒ်ဝဲကို ကိုင်ထားရန် သို့မဟုတ် ဒေတာဘေ့စ်များကို ၎င်းတို့ကိုယ်တိုင် အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ရန် လိုအပ်သည်။

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

အယူအဆသစ်

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

လိုအပ်သော အနိမ့်ဆုံးမှာ ဒေတာဘေ့စ်အသစ်နှစ်ခုဖြစ်သည်။

• ချက်တင်အင်ဂျင်။ ၎င်းသည် ချတ် vector များ၏ သိုလှောင်မှု ဖြစ်သည်။ ချတ်တစ်ခုစီတွင် ၎င်းနှင့်သက်ဆိုင်သော မက်ဆေ့ချ်များ၏ ပုံသဏ္ဍာန်တစ်ခုရှိသည်။ မက်ဆေ့ဂျ်တစ်ခုစီတွင် ချတ်အတွင်း၌ စာသားနှင့် သီးသန့်မက်ဆေ့ချ်တစ်ခုပါရှိသည် - chat_local_id။
• အသုံးပြုသူ-အင်ဂျင်။ ၎င်းသည် သုံးစွဲသူများထံ လင့်ခ်များ - အသုံးပြုသူများ၏ သိုလှောင်မှုတစ်ခုဖြစ်သည်။ အသုံးပြုသူတစ်ဦးစီတွင် peer_id ၏ vector တစ်ခုစီရှိ (အပြန်အလှန်ပြောဆိုသူများ - အခြားအသုံးပြုသူများ၊ ချတ်မျိုးစုံ သို့မဟုတ် အသိုင်းအဝိုင်းများ) နှင့် မက်ဆေ့ချ်များ၏ vector တစ်ခုရှိသည်။ peer_id တစ်ခုစီတွင် ၎င်းနှင့်ဆက်စပ်သော မက်ဆေ့ချ်များ၏ vector တစ်ခုရှိသည်။ မက်ဆေ့ဂျ်တစ်ခုစီတွင် chat_local_id တစ်ခုနှင့် ထိုအသုံးပြုသူအတွက် ထူးခြားသောမက်ဆေ့ဂျ် ID တစ်ခုပါရှိသည် - user_local_id။

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

ကိစ္စအများစုတွင် ကျွန်ုပ်တို့၏ဒေတာဘေ့စ်များတွင် disk နှင့်အလုပ်လုပ်ခြင်းသည် binary log of change (binlog)၊ static snapshots နှင့် memory ရှိ တစ်စိတ်တစ်ပိုင်းပုံတစ်ပုံ၏ပေါင်းစပ်မှုအပေါ်အခြေခံသည်။ နေ့စဥ်အတွင်း အပြောင်းအလဲများကို binlog တွင်ရေးထားပြီး လက်ရှိအခြေအနေ၏လျှပ်တစ်ပြက်ကို အခါအားလျော်စွာ ဖန်တီးပါသည်။ လျှပ်တစ်ပြက်ရိုက်ချက်သည် ကျွန်ုပ်တို့၏ရည်ရွယ်ချက်များအတွက် အကောင်းဆုံးပြင်ဆင်ထားသော ဒေတာဖွဲ့စည်းပုံများစုစည်းမှုတစ်ခုဖြစ်သည်။ ၎င်းတွင် ခေါင်းစီး (ပုံ၏ မက်တာညွှန်းကိန်း) နှင့် metafiles အစုတစ်ခု ပါဝင်သည်။ ခေါင်းစီးကို RAM တွင် အပြီးအပိုင်သိမ်းဆည်းထားပြီး လျှပ်တစ်ပြက်ရိုက်ချက်မှ ဒေတာကို ရှာဖွေရမည့်နေရာကို ညွှန်ပြသည်။ metafile တစ်ခုစီတွင် အချိန်နှင့်တပြေးညီ လိုအပ်မည့် ဒေတာများ ပါဝင်သည်—ဥပမာ၊ အသုံးပြုသူတစ်ဦးနှင့် သက်ဆိုင်သည်။ လျှပ်တစ်ပြက်ရိုက်ချက်ခေါင်းစီးကို အသုံးပြု၍ ဒေတာဘေ့စ်ကို သင်မေးမြန်းသောအခါ၊ လိုအပ်သော metafile ကိုဖတ်ပြီး လျှပ်တစ်ပြက်ရိုက်ချက်ဖန်တီးပြီးနောက် ဖြစ်ပေါ်ခဲ့သော binlog တွင် ပြောင်းလဲမှုများကို ထည့်သွင်းစဉ်းစားပါသည်။ ဤချဉ်းကပ်မှု၏ အကျိုးကျေးဇူးများအကြောင်း ပိုမိုဖတ်ရှုနိုင်ပါသည်။ ဒီမှာ.

တစ်ချိန်တည်းမှာပင်၊ ဟာ့ဒ်ဒရိုက်ပေါ်ရှိ ဒေတာကိုယ်တိုင်က တစ်နေ့လျှင် တစ်ကြိမ်သာ ပြောင်းလဲခြင်း - မော်စကိုမြို့၌ ညဥ့်နက်သောအခါ၊ ဝန်အနည်းငယ်သာပါသည်။ ယင်းကြောင့် (ဒစ်ခ်ပေါ်ရှိ တည်ဆောက်ပုံသည် တစ်နေ့တာလုံး မပြတ်မသားဖြစ်နေကြောင်းကို သိရှိခြင်း)၊ ကျွန်ုပ်တို့သည် ပုံသေအရွယ်အစားရှိသော arrays များဖြင့် vector များကို အစားထိုးရန် တတ်နိုင်သည် - ၎င်းကြောင့် မှတ်ဉာဏ်တွင် တိုးလာပါသည်။

အစီအစဥ်အသစ်တွင် မက်ဆေ့ချ်ပို့ခြင်းမှာ အောက်ပါအတိုင်းဖြစ်သည်-

1. PHP backend သည် စာတိုပေးပို့ရန် တောင်းဆိုချက်ဖြင့် သုံးစွဲသူ-အင်ဂျင်ကို ဆက်သွယ်သည်။
2. user-engine သည် တောင်းဆိုချက်ကို အလိုရှိသော chat-engine instance သို့ ပြန်ပို့သည်၊ ၎င်းသည် user-engine chat_local_id - ဤချတ်အတွင်းမှ မက်ဆေ့ချ်အသစ်၏ ထူးခြားသော အထောက်အထားတစ်ခုဖြစ်သည်။ ထို့နောက် chat_engine သည် ချတ်ရှိ လက်ခံသူအားလုံးကို မက်ဆေ့ချ် ထုတ်လွှင့်သည်။
3. user-engine သည် chat-engine မှ chat_local_id ကို လက်ခံရရှိပြီး user_local_id ကို PHP သို့ ပြန်ပေးသည် - ဤအသုံးပြုသူအတွက် ထူးခြားသော မက်ဆေ့ချ် identifier ဖြစ်သည်။ API မှတစ်ဆင့် မက်ဆေ့ချ်များနှင့် အလုပ်လုပ်ရန် ဥပမာအားဖြင့် ဤအမှတ်အသားကို အသုံးပြုသည်။

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

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

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

မက်ဆေ့ချ်များတွင် ချုံ့နိုင်စေရန် အသုံးဝင်သော စာသားအများစုတွင် အချက်အလက်အများအပြားပါရှိသည်။ မက်ဆေ့ချ်တစ်ခုချင်းစီကိုပင် တိကျစွာ သိမ်းဆည်းနိုင်စေရန် အရေးကြီးပါသည်။ မက်ဆေ့ချ်များကို ချုံ့ရန် အသုံးပြုသည်။ Huffman algorithm ကျွန်ုပ်တို့၏ကိုယ်ပိုင် heuristics ဖြင့် ဥပမာအားဖြင့်၊ မက်ဆေ့ချ်များတွင် “စကားလုံးမဟုတ်သော” ဟူသော စကားလုံးများသည် နေရာလွတ်များ၊ ပုဒ်ဖြတ်အမှတ်အသားများနှင့် အစားထိုးကြောင်း ကျွန်ုပ်တို့သိကြပြီး ရုရှားဘာသာစကားအတွက် သင်္ကေတများအသုံးပြုခြင်း၏ အင်္ဂါရပ်အချို့ကိုလည်း မှတ်သားထားကြသည်။

ချတ်များထက် အသုံးပြုသူ အလွန်နည်းသောကြောင့် chat-engine တွင် ကျပန်းဝင်ရောက်ခွင့်ဒစ်တောင်းဆိုမှုများကို သိမ်းဆည်းရန်အတွက် ကျွန်ုပ်တို့သည် အသုံးပြုသူ-အင်ဂျင်တွင် မက်ဆေ့ချ်များကို သိမ်းဆည်းပါသည်။

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

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

ဒေတာရွှေ့ပြောင်းခြင်း။

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

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

ချတ်အဖွဲ့ဝင်များအတွက် တန်းစီသည်။ ၎င်းတွင်ဖြစ်ရပ်ပေါင်း 100 ပါဝင်ပြီး chat-engine တွင် 4 ရှိသည်။ ဒေတာလွှဲပြောင်းရန်၊ ၎င်းကို လိုက်လျောညီထွေဖြစ်စေရန် လိုအပ်သည် - ၎င်းအတွက်၊ ချတ်အဖွဲ့ဝင်များကို တူညီသော ကော်ပီ 4,ဝဝဝ တွင် ပိုင်းခြားထားပြီး၊ ထို့နောက် chat-အဖွဲ့ဝင် binlog ၏ဖတ်ရှုခြင်းကို chat-engine တွင်ဖွင့်ထားသည်။

ယခု chat-engine သည် chat-member များထံမှ multi-chat အကြောင်းသိသော်လည်း အပြန်အလှန်ဆွေးနွေးသူနှစ်ဦးနှင့် dialogues အကြောင်း ဘာမှမသိသေးပါ။ ထိုသို့သော ဆွေးနွေးပွဲများသည် သုံးစွဲသူများကို ရည်ညွှန်းသည့် text-engine တွင် တည်ရှိသည်။ ဤနေရာတွင် ကျွန်ုပ်တို့သည် ဒေတာကို "head-on" ယူလိုက်သည်- chat-engine instance တစ်ခုစီသည် ၎င်းတို့တွင် လိုအပ်သည့် dialogue ရှိမရှိ၊ text-engine instance အားလုံးကို မေးသည်။

ချတ်အင်ဂျင်သည် အစုံလိုက်ချတ်များရှိနေသည်ကို သိပြီး အဲဒီမှာ ဘာဆွေးနွေးမှုများရှိလဲ သိသည်။
ချတ်တစ်ခုစီတွင် မက်ဆေ့ချ်စာရင်းတစ်ခုဖြင့် အဆုံးသတ်နိုင်ရန် သင်သည် Multi-chat chat များတွင် မက်ဆေ့ချ်များကို ပေါင်းစပ်ရန်လိုအပ်သည်။ ပထမဦးစွာ၊ ချတ်အင်ဂျင်သည် ဤချတ်မှ အသုံးပြုသူမက်ဆေ့ဂျ်အားလုံးကို စာသားအင်ဂျင်မှ ထုတ်ယူသည်။ အချို့သောကိစ္စများတွင်၎င်းတို့အများအပြား (သန်းရာပေါင်းများစွာအထိ) ရှိသော်လည်းအလွန်ရှားပါးသောခြွင်းချက်အနေဖြင့်ချတ်သည် RAM နှင့်လုံးဝကိုက်ညီသည်။ ကျွန်ုပ်တို့တွင် အစီအစဥ်မတင်ရသေးသော မက်ဆေ့ချ်များရှိပြီး၊ တစ်ခုစီတွင် ကော်ပီအများအပြားရှိပါသည်- နောက်ဆုံးတွင်၊ ၎င်းတို့အားလုံးကို အသုံးပြုသူများနှင့်သက်ဆိုင်သည့် မတူညီသောစာသား-အင်ဂျင်ဖြစ်ရပ်များမှ ဆွဲထုတ်ထားပါသည်။ ရည်ရွယ်ချက်မှာ မက်ဆေ့ချ်များကို စီရန်ဖြစ်ပြီး မလိုအပ်သော နေရာယူထားသော ကော်ပီများကို ဖယ်ရှားရန်ဖြစ်သည်။

မက်ဆေ့ဂျ်တစ်ခုစီတွင် ပေးပို့သည့်အချိန်နှင့် စာတိုပါရှိသော အချိန်တံဆိပ်တစ်ခုပါရှိသည်။ စီရန်အချိန်ကို ကျွန်ုပ်တို့အသုံးပြုသည် - ကျွန်ုပ်တို့သည် multichat ပါဝင်သူများ၏ ရှေးအကျဆုံးမက်ဆေ့ချ်များသို့ ညွှန်ပြချက်များကို ထားရှိကာ ရည်ရွယ်ထားသော ကော်ပီများ၏ စာသားမှ hash များကို နှိုင်းယှဉ်ကာ အချိန်တံဆိပ်ကို တိုးမြှင့်ခြင်းဆီသို့ ဦးတည်သွားပါသည်။ မိတ္တူများတွင် တူညီသော hash နှင့် timestamp ပါရှိမည်မှာ ယုတ္တိရှိသော်လည်း လက်တွေ့တွင် ယင်းသည် အမြဲတမ်းမဟုတ်ပေ။ သင်မှတ်မိသည့်အတိုင်း၊ အဟောင်းအစီအစဥ်တွင် ထပ်တူပြုခြင်းအား PHP မှလုပ်ဆောင်ခဲ့သည် - ရှားပါးသောကိစ္စများတွင် တူညီသောမက်ဆေ့ချ်ကို ပေးပို့သည့်အချိန်သည် မတူညီသောအသုံးပြုသူများကြားတွင် မတူညီပါ။ ဤကိစ္စများတွင်၊ ကျွန်ုပ်တို့သည် အချိန်တံဆိပ်ကို တည်းဖြတ်ရန် မိမိကိုယ်ကို ခွင့်ပြုခဲ့သည် - များသောအားဖြင့် တစ်စက္ကန့်အတွင်း။ ဒုတိယပြဿနာမှာ မတူညီသောလက်ခံသူအတွက် မတူညီသော မက်ဆေ့ချ်များ၏ အစီအစဥ်ဖြစ်သည်။ ထိုသို့သောအခြေအနေမျိုးတွင်၊ မတူညီသောအသုံးပြုသူများအတွက် မတူညီသော မှာယူမှုရွေးချယ်စရာများနှင့်အတူ အပိုကော်ပီတစ်ခုကို ဖန်တီးရန် ကျွန်ုပ်တို့ခွင့်ပြုထားပါသည်။

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

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

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

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

ဒေတာကို ချတ်အဖွဲ့ဝင်များနှင့် အသုံးပြုသူအင်ဂျင်များသို့ ရေးမှတ်ထားပါသည် (ယင်းစနစ်ဟောင်းအရ ပုံမှန်လုပ်ဆောင်မှုတွင်ကဲ့သို့ စာသား-အင်ဂျင်သို့မဟုတ်ပါ)။ user-engine သည် chat-engine သို့ တောင်းဆိုချက်ကို proxy ပေးသည် - ဤနေရာတွင် အပြုအမူသည် ဤချတ်ကို ပေါင်းစည်းပြီးဖြစ်သည် သို့မဟုတ် မပါဝင်ခြင်းအပေါ် မူတည်ပါသည်။ ချတ်ကို မပေါင်းရသေးပါက၊ ချက်တင်အင်ဂျင်သည် မက်ဆေ့ချ်ကို သူ့ဘာသာသူ မရေးနိုင်ဘဲ ၎င်း၏လုပ်ဆောင်မှုသည် စာသားအင်ဂျင်တွင်သာ ဖြစ်ပေါ်ပါသည်။ ချတ်ကို chat-engine သို့ ပေါင်းပြီးပါက၊ ၎င်းသည် chat_local_id ကို အသုံးပြုသူ-အင်ဂျင်သို့ ပြန်ပေးကာ လက်ခံသူအားလုံးထံ မက်ဆေ့ချ်ပို့ပါသည်။ user-engine သည် data အားလုံးကို text-engine သို့ proxy ပေးသည် - ထို့ကြောင့် တစ်ခုခုဖြစ်သွားပါက၊ အင်ဂျင်အဟောင်းတွင် လက်ရှိ data အားလုံးကို အမြဲပြန်ယူနိုင်မည်ဖြစ်သည်။ text-engine သည် user_local_id ကို ပြန်ပေးသည်၊ ၎င်းသည် user-engine မှ သိမ်းဆည်းပြီး backend သို့ ပြန်သွားသည်။

ရလဒ်အနေဖြင့်၊ အသွင်ကူးပြောင်းရေးလုပ်ငန်းစဉ်သည် ဤကဲ့သို့ဖြစ်ပုံရသည်- ကျွန်ုပ်တို့သည် အချည်းနှီးသော အသုံးပြုသူအင်ဂျင်နှင့် ချတ်အင်ဂျင်အစုအဝေးများကို ချိတ်ဆက်ပါသည်။ chat-engine သည် chat-members binlog တစ်ခုလုံးကို ဖတ်ပြီး အထက်ဖော်ပြပါ အစီအစဉ်အတိုင်း proxying စတင်သည်။ ကျွန်ုပ်တို့သည် ဒေတာဟောင်းကို လွှဲပြောင်းပြီး တစ်ပြိုင်တည်းလုပ်ဆောင်ထားသော အစုအဝေးနှစ်ခု (အဟောင်းနှင့် အသစ်) ကို ရယူလိုက်ပါ။ ကျန်သည်မှာ စာသား-အင်ဂျင်မှ အသုံးပြုသူ-အင်ဂျင်သို့ ပြောင်းပြီး proxying ကို ပိတ်ရန်ဖြစ်သည်။

ရလဒ်များကို

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

ယုတ္တိဗေဒဆိုင်ရာ ပြောင်းလဲမှုများသည် အမှန်တကယ်ပင် ကြီးမားလှသည်။ ပြီးတော့ ဒါဟာ ကြီးမားတဲ့အဖွဲ့တစ်ဖွဲ့နဲ့ ကုဒ်လိုင်းပေါင်းမြောက်မြားစွာရဲ့ ဖွံ့ဖြိုးတိုးတက်မှု နှစ်တွေကို အမြဲတမ်းဆိုလိုတာမဟုတ်ဘူးဆိုတာကို သတိပြုစေချင်ပါတယ်။ chat-engine နှင့် user-engine တို့သည် မက်ဆေ့ချုံ့မှုအတွက် Huffman ကဲ့သို့ ထပ်လောင်းဇာတ်လမ်းများအားလုံးနှင့်အတူ တင်သွင်းလာသော စာများအတွက် Splay သစ်ပင်များနှင့် ဖွဲ့စည်းပုံသည် ကုဒ်လိုင်း 20 ထက်နည်းပါသည်။ ၎င်းတို့ကို 3 လအတွင်း developer 10 ဦးကရေးသားခဲ့သည် (သို့သော်၎င်းကိုမှတ်သားထားသင့်သည်။ အားလုံး သုံး developer - ကမ္ဘာ့ချန်ပီယံများ အားကစားအစီအစဉ်များတွင်).

ထို့အပြင်၊ ဆာဗာအရေအတွက်ကို နှစ်ဆတိုးမည့်အစား၊ ကျွန်ုပ်တို့သည် ၎င်းတို့၏အရေအတွက်ကို ထက်ဝက်လျှော့ချခဲ့သည် - ယခုအခါ အသုံးပြုသူအင်ဂျင်နှင့် ချက်တင်အင်ဂျင်သည် ရုပ်ပိုင်းဆိုင်ရာစက် 500 တွင် နေထိုင်လျက်ရှိပြီး အစီအစဉ်အသစ်တွင် ဝန်ဆောင်ရန်နေရာ ကျယ်ဝန်းပါသည်။ ကျွန်ုပ်တို့သည် စက်ကိရိယာအတွက် ငွေအမြောက်အမြား စုဆောင်းခဲ့သည် - တစ်နှစ်လျှင် ဒေါ်လာ 5 သန်း + $ 750 လည်ပတ်မှုအသုံးစရိတ်များ။

အရှုပ်ထွေးဆုံးနှင့် အကြီးစားပြဿနာများအတွက် အကောင်းဆုံးဖြေရှင်းနည်းများကို ရှာဖွေရန် ကျွန်ုပ်တို့ ကြိုးစားနေပါသည်။ ကျွန်ုပ်တို့တွင် ၎င်းတို့များစွာရှိသည် - ထို့ကြောင့် ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်ဌာနရှိ အရည်အချင်းရှိသော developer များကို ရှာဖွေနေပါသည်။ အကယ်၍ သင်သည် ထိုကဲ့သို့သော ပြဿနာများကို ဖြေရှင်းနည်းကို နှစ်သက်ပြီး အယ်လဂိုရီသမ်များနှင့် ဒေတာဖွဲ့စည်းပုံများကို ကောင်းစွာ တတ်ကျွမ်းပါက၊ အဖွဲ့တွင် ပါဝင်ရန် သင့်အား ဖိတ်ခေါ်အပ်ပါသည်။ ကျွန်ုပ်တို့ထံ ဆက်သွယ်ပါ။ HR, чтобы узнать подробности ။

ဤဇာတ်လမ်းသည် သင့်အကြောင်းမဟုတ်သော်လည်း၊ အကြံပြုချက်များကို ကျွန်ုပ်တို့တန်ဖိုးထားကြောင်း ကျေးဇူးပြု၍ သတိပြုပါ။ သူငယ်ချင်းတစ်ယောက်အကြောင်းပြောပြပါ။ developer ရာထူးများ၊ အကယ်၍ သူသည် စမ်းသပ်ကာလကို အောင်မြင်စွာ ပြီးမြောက်ပါက သင်သည် အပိုဆုငွေ 100 ရူဘယ်ကို ရရှိမည်ဖြစ်သည်။

source: www.habr.com