ElasticSearch ဖြင့် Highload ပရောဂျက်တစ်ခုတွင် ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်းကို တင်ပါ။

ဟေး ဟာဘ! ကျွန်ုပ်၏အမည်မှာ Maxim Vasiliev ဖြစ်ပြီး FINCH တွင် ခွဲခြမ်းစိတ်ဖြာသူနှင့် ပရောဂျက်မန်နေဂျာအဖြစ် လုပ်ဆောင်ပါသည်။ ယနေ့ကျွန်ုပ်တို့သည် ElasticSearch ကိုအသုံးပြု၍ ကျွန်ုပ်တို့သည် 15 မိနစ်အတွင်း တောင်းဆိုချက် 6 သန်းကို စီမံဆောင်ရွက်နိုင်ပြီး ကျွန်ုပ်တို့၏ဖောက်သည်တစ်ဦး၏ site ပေါ်တွင်နေ့စဉ်ဝန်ဆောင်မှုများကို အကောင်းဆုံးဖြစ်အောင်ပြုလုပ်နိုင်ပုံကို ပြောပြလိုပါသည်။ ကံမကောင်းစွာပဲ၊ ကျွန်ုပ်တို့တွင် NDA တစ်ခုရှိသောကြောင့်၊ ကျွန်ုပ်တို့သည် အမည်များမပါဘဲ လုပ်ဆောင်ရမည်ဖြစ်ပြီး၊ ဆောင်းပါးပါအကြောင်းအရာသည် ဤအရာကြောင့် ခံစားရမည်မဟုတ်ကြောင်း ကျွန်ုပ်တို့မျှော်လင့်ပါသည်။ သွားကြရအောင်။

ပရောဂျက်ဘယ်လိုအလုပ်လုပ်လဲ။

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

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

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

နောက်ခံအကျဉ်း

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

ကျွန်ုပ်တို့သည် Postgres တွင် ဒေတာအားလုံးကို သိမ်းဆည်းထားသည်- ငွေပေးငွေယူများမှ သတင်းအထိ။ ဒါပေမယ့် အသုံးပြုသူ အရေအတွက် တိုးလာပြီး တောင်းဆိုမှု အရေအတွက် တိုးလာပါတယ်။

နားလည်ရန်အတွက်၊ 2017 တွင် desktop site ပေါ်တွင်သာ နှစ်စဉ် session အရေအတွက်သည် 131 million ရှိသည်။ 2018 - 125 million ၊ 2019 တွင် သန်း 130 ရှိသည်။ site ၏ mobile version နှင့် mobile application မှ သန်း 100-200 ကို ထပ်ပေါင်းထည့်ပါ၊ တောင်းဆိုမှုအများအပြားကိုရရှိလိမ့်မည်။

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

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

1. အညွှန်းကိန်းများတွင် ဒေတာပမာဏ တိုးလာသည်နှင့်အမျှ ညွှန်းကိန်းများ နှေးကွေးသည်။ Elastic ဖြင့်၊ မြန်နှုန်းသည် ဒေတာပမာဏပေါ်တွင် မမူတည်ပါ။
2. စာသားအပြည့်အစုံ ရှာဖွေမှု မရှိပါ။

ထို့ကြောင့် ကျွန်ုပ်တို့သည် မိမိကိုယ်ကို Elastic ကိုရွေးချယ်ပြီး အကူးအပြောင်းအတွက် ပြင်ဆင်ခဲ့သည်။

Elastic သို့ကူးပြောင်းခြင်း။

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

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

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

2. နောက်တစ်ခုကတော့ သတင်းကဏ္ဍပါ။ ထုတ်ဝေမှုများသည် အသုံးပြုသူ၏ သတင်းစီးဆင်းမှုတွင် ပျောက်ဆုံးသွားစေရန် ဆိုက်ပေါ်တွင် နေ့တိုင်း ပေါ်လာသည်၊ ထို့ကြောင့် မထုတ်ပေးမီ ဒေတာကို စီထားရပါမည်။ ၎င်းသည် ရှာဖွေမှုဖြစ်သည်- ဆိုက်ကို စာသားကိုက်ညီမှုဖြင့် သင်ရှာဖွေနိုင်ပြီး၊ ၎င်းတို့ကို Elastic ဖြင့်လည်း ပြုလုပ်ထားသောကြောင့် အပိုထပ်ဆောင်း filter များကို ချိတ်ဆက်နိုင်သည်။

3. ထို့နောက် ကျွန်ုပ်တို့သည် ငွေပေးငွေယူ လုပ်ဆောင်ခြင်းကို ရွှေ့လိုက်ပါသည်။ အသုံးပြုသူများသည် ဝဘ်ဆိုက်ပေါ်ရှိ အချို့သော ထုတ်ကုန်တစ်ခုကို ဝယ်ယူနိုင်ပြီး ဆုမဲတွင် ပါဝင်နိုင်ပါသည်။ ထိုသို့သောဝယ်ယူမှုများပြီးနောက်၊ အထူးသဖြင့် စနေ၊ တနင်္ဂနွေနှင့် အားလပ်ရက်များတွင် ကျွန်ုပ်တို့သည် ဒေတာအများအပြားကို လုပ်ဆောင်ပါသည်။ နှိုင်းယှဉ်ကြည့်မည်ဆိုလျှင် သာမန်နေ့ရက်များတွင် ဝယ်ယူမှုအရေအတွက်သည် ၁.၅-၂ သန်းကြားရှိမည်ဆိုလျှင် အားလပ်ရက်များတွင် ကိန်းဂဏန်းသည် ၅၃ သန်းအထိ ရောက်ရှိနိုင်သည်။

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

PERIODICITY အချိန်တိုင်း

ယခု အပ်ဒိတ်များကို အောက်ပါအခြေအနေများအရ အဖြစ်အပျက်ကိုအခြေခံ၍ ပြင်ဆင်သတ်မှတ်ထားပါသည်။

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

ဒီနေရာမှာ Elastic ရဲ့ အားသာချက်တွေကို ထပ်ပြီးပြောပြရကျိုးနပ်ပါတယ်။ Postgres တွင်၊ တောင်းဆိုချက်တစ်ခုပေးပို့သည့်အခါ၊ မှတ်တမ်းအားလုံးကို ရိုးသားစွာလုပ်ဆောင်သည့်အချိန်အထိ စောင့်ရပါမည်။ မှတ်တမ်း 10 ကို Elastic သို့ ပေးပို့နိုင်ပြီး Shards အားလုံးတွင် မှတ်တမ်းများ ဖြန့်ဝေရန် မစောင့်ဆိုင်းဘဲ ချက်ခြင်း စတင်နိုင်သည်။ ဟုတ်ပါတယ်၊ အချို့သော Shard သို့မဟုတ် Replica များသည် ဒေတာကိုချက်ချင်းမမြင်နိုင်သော်လည်း အရာအားလုံးသည် မကြာမီတွင်ရရှိနိုင်မည်ဖြစ်သည်။

ပေါင်းစည်းရေးနည်းလမ်းများ

Elastic နှင့် ပေါင်းစပ်ရန် နည်းလမ်း 2 ခု ရှိပါသည်။

1. TCP မှတဆင့် မူရင်း client မှတဆင့်။ မူရင်းမောင်းသူသည် တဖြည်းဖြည်းသေဆုံးသွားသည်- ၎င်းကို ပံ့ပိုးမပေးတော့ပါ၊ ၎င်းတွင် အလွန်အဆင်မပြေသည့် အထားအသိုတစ်ခုရှိသည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ၎င်းကို လက်တွေ့တွင် မသုံးဘဲ လုံးဝ စွန့်လွှတ်ရန် ကြိုးစားသည်။
2. JSON တောင်းဆိုမှုများနှင့် Lucene syntax နှစ်မျိုးလုံးကို အသုံးပြုနိုင်သည့် HTTP အင်တာဖေ့စ်မှတဆင့်။ နောက်ဆုံးတစ်ခုသည် Elastic ကိုအသုံးပြုသောစာသားအင်ဂျင်ဖြစ်သည်။ ဤဗားရှင်းတွင်၊ HTTP မှတဆင့် JSON တောင်းဆိုမှုများကို Batch လုပ်နိုင်စွမ်းရှိသည်။ ဤသည်မှာ ကျွန်ုပ်တို့အသုံးပြုရန် ကြိုးစားနေသည့် ရွေးချယ်မှုဖြစ်သည်။

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

နှိုင်းယှဉ်ရန် ကိန်းဂဏန်းအချို့

• အုပ်စုဖွဲ့ခြင်းမပြုဘဲ စာတွဲ 20 တွင် Postgres ဆုငွေအသုံးပြုသူများကို ကယ်တင်ခြင်း- 460713 မှတ်တမ်းများကို 42 စက္ကန့်အတွင်း
• 10 threads အတွက် elastic + reactive client + 1000 element အတွက် batch : 596749 records 11 seconds
• 10 threads အတွက် Elastic + reactive client + element 1000 အတွက် batch- ၄ မိနစ်အတွင်း ၂၃၈၀၁၆၈၄ မှတ်

ယခုကျွန်ုပ်တို့သည် JSON ကို Batch/not Batch အဖြစ်တည်ဆောက်ပေးသော HTTP တောင်းဆိုမှုမန်နေဂျာကိုရေးသားပြီး စာကြည့်တိုက်မည်သို့ပင်ဖြစ်စေ မည်သည့် HTTP ကလိုင်းယင့်မှတဆင့်ပေးပို့သည် ။ တောင်းဆိုချက်များကို တပြိုင်တည်း သို့မဟုတ် တပြိုင်နက်တည်း ပေးပို့ရန်လည်း သင်ရွေးချယ်နိုင်သည်။

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

ကြီးမားတဲ့ပရိုမိုးရှင်း

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

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

2019 ခုနှစ်အစတွင်၊ ကျွန်ုပ်တို့သည် ElasticSearch လိုအပ်ကြောင်း ဆုံးဖြတ်ခဲ့သည်။ တစ်နှစ်ပတ်လုံး၊ ကျွန်ုပ်တို့သည် Elastic တွင် လက်ခံရရှိသည့်ဒေတာကို စီမံဆောင်ရွက်ပေးပြီး ၎င်းတို့၏ထုတ်ပေးမှုကို မိုဘိုင်းအက်ပ်နှင့် ဝဘ်ဆိုက်၏ api တွင် စီစဉ်ဆောင်ရွက်ခဲ့ပါသည်။ ရလဒ်အနေနဲ့ နောက်နှစ်မှာ မဲဆွယ်စည်းရုံးရေးကာလမှာ ကျွန်တော်တို့ ဆောင်ရွက်ပြီးဖြစ်ပါတယ်။ 15 မိနစ်အတွင်း 131 တင်သွင်းခဲ့သည်။

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

နိဂုံး/နိဂုံး

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

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

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

⌘⌘⌘

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

source: www.habr.com