ကြီးမားသောအွန်လိုင်းအသုံးချပလီကေးရှင်းများသည် လွန်ခဲ့သည့်ဆယ်စုနှစ် နှစ်ခုအတွင်း ကျယ်ပြန့်လာခဲ့သည်။ ဤတီထွင်ဆန်းသစ်မှုများသည် ဆော့ဖ်ဝဲလ်ဖွံ့ဖြိုးတိုးတက်ရေးဆိုင်ရာ ကျွန်ုပ်တို့၏ခံယူချက်များကို ပြောင်းလဲစေပါသည်။ ဥပမာအားဖြင့် Facebook၊ Instagram၊ နှင့် Twitter တို့သည် အရွယ်အစားရှိ ပလပ်ဖောင်းများ အားလုံးဖြစ်သည်။
ကမ္ဘာတဝှမ်းရှိ သန်းပေါင်းများစွာသောလူများက ၎င်းတို့ကို တချိန်တည်းအသုံးပြုသောကြောင့် များပြားလှသော အသွားအလာနှင့် ဒေတာများကို စီမံခန့်ခွဲရန်အတွက် ဤစနစ်များကို တည်ဆောက်ရပါမည်။ ဒါက ဘယ်တုန်းကလဲ။ စနစ်ဒီဇိုင်း ရုပ်ပုံထဲသို့ဝင်
အချို့သော စံသတ်မှတ်ချက်များနှင့် ကိုက်ညီသော စနစ်အတွက် ဗိသုကာပညာ၊ အင်တာဖေ့စ်များနှင့် ဒေတာများကို ထူထောင်ခြင်းလုပ်ငန်းစဉ်ကို စနစ်ဒီဇိုင်းဟု ခေါ်သည်။ ပေါင်းစပ်ပြီး ထိရောက်သောစနစ်များဖြင့်၊ စနစ်ဒီဇိုင်းသည် သင့်လုပ်ငန်း သို့မဟုတ် အဖွဲ့အစည်း၏ တောင်းဆိုချက်များကို ဖြည့်ဆည်းပေးပါသည်။
သင့်ကုမ္ပဏီ သို့မဟုတ် အဖွဲ့အစည်းသည် ၎င်း၏ စံနှုန်းများကို ဆုံးဖြတ်ပြီးသည်နှင့် ၎င်းတို့ကို သင့်စားသုံးသူများ၏ လိုအပ်ချက်များနှင့် ကိုက်ညီသည့် ရုပ်ပိုင်းဆိုင်ရာ စနစ်ဒီဇိုင်းတွင် စတင်ထည့်သွင်းနိုင်သည်။
သင်စိတ်ကြိုက်ဖွံ့ဖြိုးတိုးတက်မှု၊ စီးပွားဖြစ်ဖြေရှင်းနည်းများ သို့မဟုတ် နှစ်ခုပေါင်းစပ်မှုဖြင့် ရွေးချယ်သည်ဖြစ်စေ သင့်စနစ်ဒီဇိုင်းကို သင်မည်ကဲ့သို့တည်ဆောက်မည်ကို ဆုံးဖြတ်မည်ဖြစ်သည်။
ကျူတိုရီရယ်တစ်ခုနှင့်အတူ ဤပို့စ်ရှိ Twitter timeline ၏ စနစ်ဒီဇိုင်းကို အသေးစိတ်ကြည့်ရှုပါမည်။ စလိုက်ကြစို့။
အဆင့် 1- အသုံးပြုမှုကိစ္စနှင့် ကန့်သတ်ချက်များကို အကြမ်းဖျင်းဖော်ပြပါ။
case ကိုသုံးပါ။
- အသုံးပြုသူတစ်ဦးသည် tweet တစ်ခုတင်သည်။
- ဝန်ဆောင်မှုသည် tweets ၏နောက်လိုက်များထံ push သတိပေးချက်များနှင့်အီးမေးလ်များပေးပို့သည်။
- အသုံးပြုသူ၏ အချိန်ဇယားကို ကြည့်ရှုသည် (အသုံးပြုသူထံမှ လုပ်ဆောင်ချက်)
- အသုံးပြုသူက home timeline ကိုကြည့်သည် (အသုံးပြုသူနောက်လိုက်နေသူများထံမှ လုပ်ဆောင်ချက်)
- သော့ချက်စာလုံးများကို အသုံးပြုသူက ရှာဖွေသည်။
- ဝန်ဆောင်မှုက တကယ်ကို ရနိုင်ပါတယ်။
ဘောင်ထဲက
- တွဒ်များကို ဤဝန်ဆောင်မှုကို အသုံးပြု၍ Twitter Firehose နှင့် အခြားသော တိုက်ရိုက်ထုတ်လွှင့်မှုများထံ ပေးပို့ပါသည်။
- ဝန်ဆောင်မှုသည် အသုံးပြုသူ၏ မြင်နိုင်မှု ဆက်တင်များအပေါ် အခြေခံ၍ တွစ်တာများကို ဖယ်ရှားသည်။
- အကယ်၍ အသုံးပြုသူက ပြန်ကြားခံရသူကို လိုက်မကြည့်ပါက ပြန်ကြားချက်ကို ဝှက်ထားပါ။
- 'ဝှက်ထားသော retweets' ရွေးချယ်မှုကို စောင့်ကြည့်ပါ။
- analytics
ကန့်သတ်ချက်များနှင့် ယူဆချက်များ
နိုင်ငံတော်ယူဆချက်
- အသွားအလာလည်း ညီတူညီမျှ မပြန့်ကျဲပါဘူး။
- tweet တစ်ခု ပေးပို့ရန် ရိုးရှင်းသင့်သည်။
- သင့်တွင် Follower သန်းပေါင်းများစွာမရှိပါက သင့်နောက်လိုက်များအားလုံးကို tweet တစ်ခုပေးပို့ခြင်းသည် မြန်ဆန်သင့်သည်။
- အသုံးပြုသူ သန်း 100 ရှိပါတယ်။
- လစဉ် tweets 15 billion သို့မဟုတ် 500 million tweets နေ့စဉ်
- tweet တစ်ခုစီတွင် ပျမ်းမျှပေးပို့မှု 10 ခု၏ fanout တစ်ခုရှိသည်။
- နေ့တိုင်း fanout သည် 5 ဘီလီယံ tweets ပေးပို့သည်။
- Fanout သည် လစဉ် tweet ပေါင်း 150 ဘီလီယံကို ပေးပို့သည်။
- လစဉ် 250 ဘီလီယံဖတ်ရန်တောင်းဆိုမှုများ
- လစဉ်ရှာဖွေမှု ၁၀ ဘီလီယံ
timeline ကို
- အချိန်ဇယားသည် သွားလာရန် လွယ်ကူသင့်သည်။
- တွစ်တာသည် စာရေးခြင်းထက်စာဖတ်ခြင်းအကြောင်းဖြစ်သည်။
- အမြန် tweet ဖတ်ခြင်းအတွက် အကောင်းဆုံးဖြစ်အောင်လုပ်ပါ။
- Tweet သုံးစွဲမှုသည် အချိန်ကုန်သည်။
ရှာရန်
- ရှာဖွေရေးလုပ်ငန်းစဉ်သည် မြန်ဆန်သင့်သည်။
- ရှာဖွေရန် အချိန်ကုန်သည်။
အသုံးပြုမှုကို တွက်ချက်ပါ။
tweet တစ်ခုစီ၏ အရွယ်အစား
- 8 bytes tweet id
- 32 bytes အသုံးပြုသူ-အိုင်ဒီ
- စာသား ၁၄၀ ဘိုက်
- မီဒီယာ - ပျမ်းမျှ 10 KB
- စုစုပေါင်း- ~10 KB
လစဉ် 150 TB လတ်ဆတ်သော tweet အကြောင်းအရာကို ထုတ်ပေးပါသည်။
- * နေ့စဉ် tweets သန်း 500 * တစ်လလျှင် ရက် 30 * tweet တစ်ခုလျှင် 10 KB
- သုံးနှစ်အတွင်း၊ လတ်ဆတ်သော tweet အကြောင်းအရာ 5.4 PB ရှိလာခဲ့သည်။
တစ်စက္ကန့်လျှင် ဖတ်ရှုရန် တောင်းဆိုချက် 100,000 ရှိသည်။
- * (တစ်စက္ကန့်လျှင် တောင်းဆိုမှု 400 / တစ်လလျှင် တောင်းဆိုမှု 1 ဘီလီယံ) လစဉ်ဖတ်ရန် တောင်းဆိုမှု 250 ဘီလီယံ
တစ်စက္ကန့်လျှင် tweets 6,000 ရှိပါတယ်။
- * (တစ်စက္ကန့်လျှင် တောင်းဆိုမှု ၄၀၀ / တစ်လလျှင် တောင်းဆိုမှု ၁ ဘီလီယံ) လစဉ် tweets ၁၅ ဘီလီယံ
fanout တွင် စက္ကန့်တိုင်း tweet ပေါင်း 60 ပေးပို့သည်။
- Fanout သည် လစဉ် tweet ပေါင်း 150 ဘီလီယံ ပေးပို့သည်* (တစ်စက္ကန့်လျှင် တောင်းဆိုမှု 400 / လလျှင် တောင်းဆိုချက် 1 ဘီလီယံ)။
စက္ကန့်တိုင်း သတင်းအချက်အလက် တောင်းဆိုမှု 4,000
- * (တစ်စက္ကန့်လျှင် တောင်းဆိုမှု ၄၀၀ / တစ်လလျှင် တောင်းဆိုချက် ၁ ဘီလီယံ) လစဉ် ရှာဖွေမှု ၁၀ ဘီလီယံ
အသုံးဝင်သော ကူးပြောင်းမှုအချို့
- လစဉ် စက္ကန့် 2.5 သန်း ဖြတ်သန်းသည်။
- တစ်စက္ကန့်လျှင် 2.5 တောင်းဆိုမှုဖြင့် တစ်လလျှင် တောင်းဆိုမှု 1 သန်း
- တစ်လလျှင် တောင်းဆိုမှု သန်း 100 x တစ်စက္ကန့်လျှင် တောင်းဆိုချက် 40
- တစ်လလျှင် တောင်းဆိုမှု 1 ဘီလီယံ = တစ်စက္ကန့်လျှင် တောင်းဆိုမှု 400
အဆင့် 2- အဆင့်မြင့် ပုံကြမ်း
အဆင့် 3- အဓိကအစိတ်အပိုင်းများကို ရှင်းပြခြင်း။
၎င်းတို့ tweet တစ်ခုကို တင်ပြပါက ဆက်စပ်ဒေတာဘေ့စ်တွင် အသုံးပြုသူ၏ အချိန်ဇယား (အသုံးပြုသူမှ လုပ်ဆောင်ချက်) ကို ဖြည့်သွင်းရန်အတွက် အသုံးပြုသူ၏ ကိုယ်ပိုင် tweet များကို သိမ်းဆည်းနိုင်ပါသည်။ တွစ်တာများ ပေးပို့ရန်နှင့် အိမ်တွင်းအချိန်လိုင်းကို ပြုစုပျိုးထောင်ရန် (အသုံးပြုသူနောက်ပါ တစ်ဦးချင်းစီထံမှ လုပ်ဆောင်ချက်)။
ပုံမှန်ဆက်စပ်ဒေတာဘေ့စ်တစ်ခုသည် followers အားလုံးကို tweets များထုတ်ပေးခြင်းဖြင့် (စက္ကန့်တိုင်း tweets 60) ကို လွှမ်းခြုံထားမည်ဖြစ်သည်။ NoSQL ဒေတာဘေ့စ် သို့မဟုတ် Memory Cache ကဲ့သို့ လျင်မြန်စွာရေးနိုင်သော ဒေတာသိုလှောင်မှုဖြင့် ကျွန်ုပ်တို့သွားလိုပေမည်။
မမ်မိုရီမှ 1 MB ကို ဆက်တိုက်ဖတ်ခြင်းသည် အကြမ်းဖျင်း 250 မိုက်ခရိုစက္ကန့်ခန့် ကြာသော်လည်း SSD မှ ဖတ်ရန် 4 ဆ ကြာပြီး disk မှ ဖတ်ရန် အဆ 80 ကြာပါသည်။
ရုပ်ပုံများနှင့် ဗီဒီယိုများကဲ့သို့သော ဒေတာများကို သိမ်းဆည်းရန် Object Store ကို အသုံးပြုနိုင်သည်။
- ပြောင်းပြန် proxy အဖြစ် လုပ်ဆောင်နေသည့် ဝဘ်ဆာဗာသည် Client ထံမှ tweet တစ်ခုကို လက်ခံရရှိသည် ။
- တောင်းဆိုချက်ကို ဝဘ်ဆာဗာမှ Write API ဆာဗာသို့ ပေးပို့သည်။
- Write API သည် tweet ကို အသုံးပြုသူ၏ timeline ရှိ SQL database တစ်ခုသို့ သိမ်းဆည်းသည်။
Fan-Out Service ကို Write API မှ ဆက်သွယ်ပြီး ၎င်းသည် အောက်ပါလုပ်ငန်းများကို လုပ်ဆောင်ပါသည်။
- အသုံးပြုသူဂရပ်ဖစ်ဝန်ဆောင်မှုကို မေးမြန်းခြင်းဖြင့် Memory Cache ရှိ သုံးစွဲသူ၏နောက်လိုက်များကို ရှာဖွေပါ။
- Memory Cache တွင်၊ tweet ကို အသုံးပြုသူ၏နောက်လိုက်များ၏ home timeline တွင် သိမ်းဆည်းထားသည်။
- နောက်လိုက် 1,000 = ရှာဖွေမှု 1,000 နှင့် ထည့်သွင်းမှုများ = O(n) လုပ်ဆောင်ချက်။
- အမြန်ရှာဖွေရန်အတွက် tweet ကို Search Index Service တွင် သိမ်းဆည်းထားသည်။
- Object Store သည် မီဒီယာကို သိမ်းဆည်းရန်အတွက် အသုံးပြုသည်။
- အကြောင်းကြားချက် ဝန်ဆောင်မှုမှတစ်ဆင့် နောက်လိုက်များသို့ တွန်းအားပေးသတိပေးချက်များ ပေးပို့သည်။
- သတိပေးချက်များကို တပြိုင်နက်တည်း ပေးပို့ရန်၊ ၎င်းသည် Queue ကို အသုံးပြုသည်။
ကျွန်ုပ်တို့၏ Memory Cache သည် Redis ဖြစ်ပါက အောက်ပါဖွဲ့စည်းပုံပါရှိသော မူရင်း Redis စာရင်းကို အသုံးပြုနိုင်ပါသည်။
အသုံးပြုသူ၏ ပင်မအချိန်လိုင်းအား Memory Cache တွင် သိမ်းဆည်းမည့် tweet အသစ်ဖြင့် အပ်ဒိတ်လုပ်မည်ဖြစ်သည်။ အောက်ပါ အများသူငှာ REST API ကို ကျွန်ုပ်တို့ အသုံးပြုပါမည်-
အသုံးပြုသူ timeline ကို အသုံးပြုသူက ကြည့်ရှုသည်။
- Web Server သည် Client ထံမှ သုံးစွဲသူ timeline တောင်းဆိုချက်ကို လက်ခံရရှိသည် ။
- တောင်းဆိုချက်ကို ဝဘ်ဆာဗာမှ Read API ဆာဗာသို့ ပေးပို့သည်။
- Read API သည် အသုံးပြုသူအချိန်ဘောင်အတွက် SQL ဒေတာဘေ့စ်ကို မေးမြန်းသည်။
REST API သည် ၎င်းတို့လိုက်ကြည့်သူများထက် tweets များအားလုံးသည် အသုံးပြုသူထံမှ အစပြုခြင်းမှလွဲ၍ REST API သည် home timeline နှင့် အလားတူအလုပ်လုပ်မည်ဖြစ်သည်။
အသုံးပြုသူတစ်ဦးသည် အဓိကစကားလုံးများကို ရှာဖွေသည်-
- ဝဘ်ဆာဗာသည် Client ထံမှ ရှာဖွေမှုတောင်းဆိုချက်ကို လက်ခံရရှိသည်။
- တောင်းဆိုချက်ကို ဝဘ်ဆာဗာမှ Search API ဆာဗာသို့ ပေးပို့သည်။
အဆင့် 4: Twitter အချိန်လိုင်း
Timeline ဖန်တီးခြင်းသည် ခက်ခဲသော အလုပ်ဖြစ်သည်။ ဝဘ် သို့မဟုတ် အပလီကေးရှင်းဆာဗာများသို့ လင့်ခ်ချိတ်ထားသော အချိန်ဇယားကို ဖန်တီးရန် လိုအပ်သည်။
သုံးစွဲသူတစ်ဦး ဝင်ရောက်သည့်အခါတိုင်း၊ timeline ဝန်ဆောင်မှုသည် နောက်လိုက်၏ဇယားရှိ သုံးစွဲသူများထံမှ နောက်ဆုံးရ tweets များကို စောင့်ထိန်းပြီး သုံးစွဲသူ၏ timeline ကို အပ်ဒိတ်လုပ်ခြင်း သို့မဟုတ် ပြန်လည်ဆန်းသစ်စေသည်။
ဤနေရာတွင် ကျွန်ုပ်တို့သည် မည်သည့်အဆင့်သတ်မှတ်ချက်စနစ်ကိုမျှ အကောင်အထည်မဖော်ပါ။ ယင်းအစား၊ အသုံးပြုသူ၏နောက်လိုက်များထံမှ ထိပ်တန်း tweets 5 ခုကို ဖန်တီးချိန်အစီအစဥ်အရ timeline တွင် ပြသသည်ဟု ကျွန်ုပ်တို့ ယူဆပါသည်။ 50-tweet refresh cutoff ကို ကျွန်ုပ်တို့ ထိန်းသိမ်းနိုင်ပါသည်။ အသုံးပြုသူသည် စာမျက်နှာကို ပြန်လည်စတင်သည့်အချိန်အထိ ၎င်းအဆင့်သို့ရောက်ရှိပြီးနောက် အချိန်ဇယားကို ပြန်လည်စတင်ခြင်း သို့မဟုတ် အချိန်ဇယားတစ်ခုတည်ဆောက်ခြင်းတို့ကို ကျွန်ုပ်တို့ရပ်ဆိုင်းထားဆဲဖြစ်သည်။
ကြာမြင့်ချိန်နှင့် စွမ်းဆောင်ရည်ဆိုင်ရာ စိုးရိမ်မှုများသည် တိုက်ရိုက်အသုံးပြုသူ ဖိဒ်ဖန်တီးမှုမှ လာမည်ဖြစ်သည်။ ယင်းအစား၊ ချက်ချင်းတင်ပြနိုင်သည့် အော့ဖ်လိုင်းစီးကြောင်းကို ဖန်တီးခြင်းသည် စွမ်းဆောင်ရည်ကို မြှင့်တင်ရန် အကောင်းဆုံးနည်းလမ်းဖြစ်သည်။ ဖန်တီးထားသည့်အချိန်ပေါ်မူတည်၍ ဖိဒ်အား ပြန်လည်စတင်ရန်အတွက် အပလီကေးရှင်းဆာဗာကို ပုံမှန် ping ပေးသည့် သီးခြားအချိန်လိုင်းဆာဗာများကို လုပ်ဆောင်ပါ။
အဆင့်သတ်မှတ်သည့် အယ်လဂိုရီသမ်သည် အရေးကြီးသော အချက်ပြမှုများကို ထည့်သွင်းစဉ်းစားသင့်ပြီး အသုံးပြုသူတစ်ဦး၏ အချိန်ဇယားကို ၎င်းတို့လိုက်ကြည့်နေသည့် အကောင့်တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော အကောင့်များမှ အကြောင်းအရာများက လွှမ်းမိုးထားခြင်းမရှိကြောင်း အာမခံရန်အတွက် အလေးချိန်ကို ပေးဆောင်သင့်သည်။
ပိုမိုတိကျစွာ၊ ကျွန်ုပ်တို့သည် လိုက်ခ်များ၊ မှတ်ချက်များ၊ မျှဝေမှုများနှင့် အပ်ဒိတ်အချိန်များကဲ့သို့သော မည်သည့် feed item ၏ဆက်စပ်မှုနှင့်ဆိုင်သော ဝန်ဆောင်မှုများကို ရွေးချယ်နိုင်ပါသည်။ ဤစံနှုန်းတစ်ခုစီကို tweet ကိုအဆင့်သတ်မှတ်ရန်အသုံးပြုသင့်သည်၊ ထို့နောက် timeline ပေါ်တွင် tweets ကိုပြသရန်ထိုအဆင့်ကိုအသုံးပြုသင့်သည်။
၎င်းတို့၏ newsfeed အတွက် အကြောင်းအရာအသစ်များ ရလာသောအခါ သုံးစွဲသူများအား ကျွန်ုပ်တို့ အမြဲသတိပေးသင့်ပါသလား။ ဒေတာအသစ်များရလာသောအခါတွင် သတိပေးချက်ရရှိရန် အသုံးပြုသူများသည် အကျိုးရှိနိုင်သည်ကို တွေ့ရှိနိုင်သည်။ သို့သော် မိုဘိုင်းလ်စက်ပစ္စည်းများတွင် ဒေတာအသုံးပြုမှုမှာ အလွန်စျေးကြီးသောအခါ၊ ၎င်းသည် bandwidth ကို ဖြုန်းတီးနိုင်သည်။
ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် မိုဘိုင်းလ်စက်ပစ္စည်းများသို့ ဒေတာကို တွန်းပို့ခြင်းမပြုဘဲ အသုံးပြုသူများအား ပို့စ်အသစ်များအတွက် “Pull to Refresh” အစား အသုံးပြုသူများကို ခွင့်ပြုနိုင်ပါသည်။
အဆင့် 5- အတိုင်းအတာ ဒီဇိုင်း
ဖြစ်နိုင်ချေရှိသော ပိတ်ဆို့မှုမှာ Fanout ဝန်ဆောင်မှုဖြစ်သည်။ Follower သန်းပေါင်းများစွာရှိတဲ့ Twitter အသုံးပြုသူတွေဟာ သူတို့ရဲ့ tweet တွေကို လွှင့်တင်ဖို့ မိနစ်အတော်ကြာ စောင့်ရပါလိမ့်မယ်။ ၎င်းသည် ဝန်ဆောင်မှုအချိန်အတွင်း tweets များကို ပြန်လည်မှာယူခြင်းဖြင့် ကျွန်ုပ်တို့ရှောင်ရှားနိုင်သည့် tweet ကို အကြောင်းပြန်မှုများဖြင့် ပြိုင်ဆိုင်မှုဖြစ်စေနိုင်သည်။
Follower အများအပြားရှိတဲ့ လူတွေဆီကနေ tweet တွေ ပြန့်ပွားမှုကိုလည်း တားဆီးနိုင်ပါတယ်။ ယင်းအစား၊ ကျွန်ုပ်တို့သည် အလွန်လိုက်စားသူများထံမှ tweets များကို ရှာဖွေခြင်း၊ ရှာဖွေမှုရလဒ်များကို အသုံးပြုသူ၏ home timeline ရလဒ်များနှင့် ပေါင်းစပ်ပြီး ဝန်ဆောင်မှုအချိန်၌ tweets များကို ပြန်လည်စီစစ်နိုင်ပါသည်။
ထပ်ဆင့်မြှင့်တင်မှုများ ပါဝင်သည်-
- အိမ်အချိန်လိုင်းတစ်ခုစီအတွက် Memory Cache တွင် ရာဂဏန်းမျှသာ tweet များကို သိမ်းဆည်းပါ။
- Memory Cache တွင်၊ လက်ရှိအသုံးပြုသူများ၏ home timeline အချက်အလက်ကိုသာ သိမ်းဆည်းထားသည်။
- လွန်ခဲ့သည့် ရက် 30 တွင် အသုံးပြုသူတစ်ဦးမှ တက်ကြွခြင်းမရှိပါက SQL Database မှ အချိန်ဇယားကို ပြန်လည်တည်ဆောက်နိုင်ပါသည်။
- အသုံးပြုသူ မည်သူဖြစ်သည်ကို သိရှိရန်၊ User Graph ဝန်ဆောင်မှုကို အသုံးပြုပါ။
- ၎င်းတို့ကို SQL Database မှပြန်လည်ရယူခြင်းဖြင့် တွစ်တာများကို Memory Cache သို့ထည့်ပါ။
- Tweet Info Service သည် တစ်လတန်ဖိုးရှိသော tweet များကိုသာ သိမ်းဆည်းနိုင်သည်။
- User Info Service တွင်၊ လက်ရှိအသုံးပြုသူများသာ သိမ်းဆည်းထားသည်။
- latency နည်းနေစေရန်၊ Search Cluster သည် tweets များကို memory တွင် ထိန်းသိမ်းထားရန် လိုအပ်ပါသည်။
ကောက်ချက်
Twitter သည် ကြီးမားသော အဖွဲ့အစည်းတစ်ခုဖြစ်သော်လည်း ၎င်းသည် ပိုမိုကောင်းမွန်သည်။ စနစ်ဒီဇိုင်းကိုနားလည်ခြင်း။. Twitter timeline ၏ မြင့်မားသောအဆင့်ခြုံငုံသုံးသပ်ချက်ကို ပေးစွမ်းရန် ကျွန်ုပ် အကောင်းဆုံးကြိုးစားခဲ့သည်။
သင့်ထံမှ အသုံးဝင်သော အချက်အလက်များကို ရရှိပြီး ကောင်းမွန်စွာ အသုံးချနိုင်မည်ဟု မျှော်လင့်ပါသည်။
တစ်ဦးစာပြန်ရန် Leave