Odyssey လမ်းပြမြေပုံ- ချိတ်ဆက်မှုပေါင်းကူးစက်မှ ကျွန်ုပ်တို့ ဘာလိုချင်ပါသနည်း။ Andrey Borodin (2019)

၎င်း၏အစီရင်ခံစာတွင် Andrey Borodin သည် connection pooler ကိုဒီဇိုင်းဆွဲသောအခါ PgBouncer ကိုစကေးချဲ့ခြင်းအတွေ့အကြုံကိုထည့်သွင်းစဉ်းစားမည်ကိုပြောပြလိမ့်မည်။ Odysseyအဲဒါကို ထုတ်လုပ်မှုအဖြစ် လှိမ့်သွင်းလိုက်ကြတယ်။ ထို့အပြင်၊ ဗားရှင်းအသစ်များတွင် ကျွန်ုပ်တို့မြင်လိုသည့် ဆွဲကိရိယာ၏လုပ်ဆောင်ချက်များကို ဆွေးနွေးပါမည်။ ကျွန်ုပ်တို့၏လိုအပ်ချက်များကို ဖြည့်ဆည်းပေးရုံသာမက သုံးစွဲသူအသိုင်းအဝိုင်းကို ဖွံ့ဖြိုးတိုးတက်စေရန်အတွက် အရေးကြီးပါသည်။ Odyssey.

ဗီဒီယိုများ:

အားလုံးမင်္ဂလာပါ! ကျွန်တော့်နာမည် Andrew ပါ။

Yandex တွင်၊ ကျွန်ုပ်သည် open source databases ကို ပြုစုပါသည်။ ယနေ့ကျွန်ုပ်တို့သည် connection pooler connections နှင့်ပတ်သက်သော ခေါင်းစဉ်တစ်ခုရှိသည်။

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

ခေါင်းစဉ်က တော်တော်ရှုပ်ထွေးပါတယ်၊ ဘာဖြစ်လို့လဲဆိုတော့ databases တော်တော်များများမှာ connection pooler က built-in ရှိပြီး အဲဒါကို သင်သိဖို့တောင် မလိုအပ်ပါဘူး။ ဟုတ်ပါတယ်၊ နေရာတိုင်းတွင်အချို့သောဆက်တင်များရှိသည်၊ သို့သော် Postgres တွင်၎င်းသည်ဤသို့အလုပ်မလုပ်ပါ။ အပြိုင် (HighLoad++ 2019 တွင်) Postgres တွင် မေးခွန်းများထည့်သွင်းခြင်းနှင့်ပတ်သက်၍ Nikolai Samokhvalov မှ အစီရင်ခံစာတစ်ခုရှိသည်။ ကျွန်တော်နားလည်သလိုပဲ၊ သူတို့ရဲ့မေးမြန်းချက်တွေကို စုံလင်စွာပြင်ဆင်ပြီးတဲ့သူတွေက ဒီကိုလာပြီး၊ ကွန်ရက်နဲ့ အရင်းအမြစ်အသုံးချမှုဆိုင်ရာ ရှားပါးတဲ့စနစ်ပြဿနာတွေနဲ့ ရင်ဆိုင်နေကြရသူတွေပါ။ အချို့နေရာများတွင် ပြဿနာများသည် ရှင်းရှင်းလင်းလင်း မသိသာသောကြောင့် အလွန်ခက်ခဲနိုင်သည်။

Yandex တွင် Postgres ရှိသည်။ Yandex ဝန်ဆောင်မှုများစွာသည် Yandex.Cloud တွင်နေထိုင်သည်။ ထို့အပြင် Postgres တွင် တစ်စက္ကန့်လျှင် အနည်းဆုံး တောင်းဆိုမှု တစ်သန်းကို ထုတ်ပေးသည့် ဒေတာ petabytes များစွာရှိသည်။

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

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

connection pooler ရဲ့ အဓိက ရည်ရွယ်ချက်က ဘာလဲ။

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

ထို့အပြင်၊ Postgres ကုဒ်တွင် procArray ဟုခေါ်သော array တစ်ခုရှိသည်။ ၎င်းတွင် ကွန်ရက်ချိတ်ဆက်မှုများအကြောင်း အခြေခံအချက်အလက်များ ပါရှိသည်။ ထို့အပြင် procArray လုပ်ဆောင်ခြင်း algorithms အားလုံးနီးပါးသည် linear ရှုပ်ထွေးမှုများရှိသည်; ၎င်းတို့သည် network connections ၏ array တစ်ခုလုံးကို run သည်။ ၎င်းသည် အလွန်လျင်မြန်သော စက်ဝန်းတစ်ခုဖြစ်သော်လည်း ဝင်လာသောကွန်ရက်ချိတ်ဆက်မှုများကြောင့် အရာများသည် အနည်းငယ်ပို၍စျေးကြီးပါသည်။ စျေးနည်းနည်းပိုတက်လာတဲ့အခါ ကွန်ရက်ချိတ်ဆက်မှုများစွာအတွက် အလွန်မြင့်မားတဲ့စျေးနှုန်းကို ပေးချေနိုင်ပါတယ်။

ဖြစ်နိုင်ချေ ချဉ်းကပ်မှု 3 ခု ရှိပါသည်။

• လျှောက်လွှာဘက်မှာ။
• ဒေတာဘေ့စဘက်တွင်။
• အကြား၊ ဆိုလိုသည်မှာ၊ ပေါင်းစပ်မှုအမျိုးမျိုး။

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

Application-side pool သည် အလွယ်ကူဆုံးနည်းလမ်းဖြစ်သည်။ ပြီးတော့ client drivers အားလုံးနီးပါးက သင့်အား နည်းလမ်းတစ်ခုပေးသည်- သန်းပေါင်းများစွာသော သင့်ချိတ်ဆက်မှုများကို ဒေတာဘေ့စ်သို့ ဒါဇင်များစွာသော ချိတ်ဆက်မှုများအဖြစ် ကုဒ်တွင် တင်ပြပါ။

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

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

proxy poolers အကြောင်းပြောရင်၊ အများကြီးလုပ်နိုင်တဲ့ poolers နှစ်ခုရှိတယ်။ ၎င်းတို့သည် ရေကူးကန်များသာမက၊ ၎င်းတို့သည် ရေကူးကန်များ + ပိုမိုအေးမြသော လုပ်ဆောင်နိုင်စွမ်းများဖြစ်သည်။ ဒီ Pgpool и Crunchy-Proxy.

သို့သော် ကံမကောင်းစွာဖြင့်၊ လူတိုင်းသည် ဤအပိုဆောင်းလုပ်ဆောင်ချက်ကို မလိုအပ်ပါ။ ၎င်းသည် poolers သည် session pooling ကိုသာ ပံ့ပိုးပေးသည်၊ ဆိုလိုသည်မှာ အဝင်ဖောက်သည်တစ်ခု၊ ဒေတာဘေ့စ်သို့ အထွက်ဖောက်သည်တစ်ဦးကို ဖြစ်ပေါ်စေသည်။

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

ပြီးတော့ ကျွန်တော်တို့ရဲ့ လုပ်ငန်းခွင်မှာ ဒါက မှန်ပါတယ်။ ဒါပေမယ့် ပြဿနာအနည်းငယ်ရှိပါတယ်။.

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

သေချာတာကတော့ သင် application_name_add_host ကို သုံးနိုင်ပါတယ်။ ဤသည်မှာ application_name သို့ IP လိပ်စာတစ်ခုထည့်ရန် Bouncer ဘက်ရှိ နည်းလမ်းတစ်ခုဖြစ်သည်။ သို့သော် application_name ကို အပိုချိတ်ဆက်မှုတစ်ခုဖြင့် သတ်မှတ်သည်။

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

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

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

ကျွန်ုပ်တို့သည် ဤဆက်တင်ကို ထည့်ထားသည့် Bouncer အတွက် သေးငယ်သော patch တစ်ခုကို ရေးခဲ့သည်၊ ဆိုလိုသည်မှာ ဖောက်သည်များကို ရေကူးကန်တွင် ကန့်သတ်ထားသည်။

Postgres ဘက်တွင် ၎င်းကို ချိတ်ဆက်မှု အရေအတွက်ဖြင့် ဒေတာဘေ့စ်ရှိ အခန်းကဏ္ဍများကို ကန့်သတ်ထားသည်။

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

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

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

PgBouncers များ ပိုမိုလိုအပ်ကြောင်း ကျွန်ုပ်တို့ နိဂုံးချုပ်လိုက်ရပါသည်။

https://lwn.net/Articles/542629/

Bouncer ကို အနည်းငယ် ဖာထေးထားပါသည်။

TCP port ကို ပြန်လည်အသုံးပြုခြင်းဖြင့် Bouncers အများအပြားကို မြှင့်တင်နိုင်စေရန် ၎င်းတို့က ပြုလုပ်ခဲ့သည်။ လည်ပတ်မှုစနစ်သည် အဝိုင်း-ရော်ဘင်ကို အသုံးပြု၍ ၎င်းတို့ကြားမှ ဝင်လာသော TCP ချိတ်ဆက်မှုများကို အလိုအလျောက် လွှဲပြောင်းပေးပါသည်။

၎င်းသည် သုံးစွဲသူများအတွက် ပွင့်လင်းမြင်သာမှုရှိသောကြောင့် သင့်တွင် Bouncer တစ်ခုရှိပုံရသည်၊ သို့သော် Bouncers များလည်ပတ်နေသည့်ကြားတွင် idle connections အပိုင်းပိုင်းများရှိနေပါသည်။

အခိုက်အတန့်တွင် ဤ Bouncers 3 ကောင်စီသည် ၎င်းတို့၏ အူတိုင်ကို 100% ကိုက်စားသည်ကို သတိပြုမိပေမည်။ Bouncers အနည်းငယ် လိုအပ်ပါသည်။ အဘယ်ကြောင့်?

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

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

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

ဤသည်မှာ 16 cores 16% ဖြင့် load လုပ်သည့် PgBouncers 100 ခု၏ ဥပမာတစ်ခုဖြစ်သည်။

ကျွန်ုပ်တို့သည် ကက်စကိတ် PgBouncer သို့ ရောက်လာသည်။ ၎င်းသည် Bouncer ဖြင့်ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုတွင်အောင်မြင်နိုင်သည့်အကောင်းဆုံးဖွဲ့စည်းမှုဖြစ်သည်။ ကျွန်ုပ်တို့၏ ပြင်ပ Bouncers များကို TCP လက်ဆွဲခြင်းအတွက် အသုံးပြုပြီး ပြင်ပချိတ်ဆက်မှုများကို အလွန်အကျွံမကွဲကွဲစေရန်အတွက် အတွင်းပိုင်း Bouncers များကို အမှန်တကယ်ပေါင်းစပ်ရန်အတွက် အသုံးပြုပါသည်။

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

ကျွန်ုပ်တို့၏ တိုးတက်မှုအားလုံးကို open source အဖြစ် မြှင့်တင်နိုင်သည်ဟု ထင်ရသော်လည်း Bouncer ကို ကောင်းစွာ မပံ့ပိုးနိုင်ပါ။ ဥပမာအားဖြင့်၊ ဆိပ်ကမ်းတစ်ခုတွင် PgBouncers အများအပြားကို run နိုင်စွမ်းသည် လွန်ခဲ့သော တစ်လက ကျူးလွန်ခဲ့သည်။ လွန်ခဲ့သောနှစ်ပေါင်းများစွာက ဤအင်္ဂါရပ်ကို ဆွဲထုတ်ရန် တောင်းဆိုမှုတစ်ခုရှိခဲ့သည်။

https://www.postgresql.org/docs/current/libpq-cancel.html

https://github.com/pgbouncer/pgbouncer/pull/79

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

၎င်းကို ဖာထေးထားပြီး၊ ဤပြဿနာကို Bouncer ၏ အထက်ပိုင်းသို့ ပေါင်းမထည့်ရသေးပါ။

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

ကျွန်ုပ်တို့သည် multithreading ကို အဓိကအလုပ်အဖြစ် သတ်မှတ်သည်။ အဝင် TLS ချိတ်ဆက်မှုလှိုင်းကို ကောင်းစွာကိုင်တွယ်နိုင်ရန်လိုအပ်သည်။

ဒါကိုလုပ်ဖို့၊ Machinarium လို့ခေါ်တဲ့ သီးခြားစာကြည့်တိုက်တစ်ခုကို တီထွင်ရမှာ ဖြစ်ပြီး၊ ကွန်ရက်ချိတ်ဆက်မှုရဲ့ စက်အခြေအနေတွေကို ဆက်တိုက်ကုဒ်အဖြစ် ဖော်ပြဖို့ ဒီဇိုင်းထုတ်ထားပါတယ်။ libpq အရင်းအမြစ်ကုဒ်ကိုကြည့်လျှင် သင့်အား ရလဒ်တစ်ခုပြန်ပေးနိုင်သည့် ရှုပ်ထွေးလှသောခေါ်ဆိုမှုအချို့ကို တွေ့ရမည်ဖြစ်ပြီး “ငါ့ကို နောက်မှခေါ်ပါ။ လောလောဆယ် ကျွန်တော့်မှာ IO ရှိတယ်၊ ဒါပေမယ့် IO ထွက်သွားတဲ့အခါ ပရိုဆက်ဆာမှာ Load တစ်ခုရှိနေမယ်။" ၎င်းသည် အဆင့်ပေါင်းများစွာ အစီအစဉ်တစ်ခုဖြစ်သည်။ ကွန်ရက်ဆက်သွယ်ရေးကို များသောအားဖြင့် နိုင်ငံတော်စက်ဖြင့် ဖော်ပြသည်။ "အရင်တုန်းက အရွယ်အစား N ရဲ့ packet header တစ်ခုကို လက်ခံရရှိခဲ့ရင်၊ အခု N bytes ကို စောင့်နေပါတယ်" "SYNC packet တစ်ခုကို ပို့ခဲ့ရင်၊ အခု ကျွန်တော် ရလဒ် metadata ပါတဲ့ packet တစ်ခုကို စောင့်နေပါတယ်။" ရလဒ်သည် ဝင်္ကပါကို လိုင်းစကင်န်အဖြစ်သို့ ပြောင်းလဲသွားသကဲ့သို့ အတော်လေးခက်ခဲသော၊ တန်ပြန်နားလည်နိုင်သော ကုဒ်တစ်ခုဖြစ်သည်။ state machine အစား ပရိုဂရမ်မာသည် သာမန် imperative code ပုံစံဖြင့် အပြန်အလှန်ဆက်သွယ်ခြင်း၏ အဓိကလမ်းကြောင်းကို ဖော်ပြရန်အတွက် ၎င်းကို ပြုလုပ်ခဲ့ခြင်းဖြစ်သည်။ ဤမဖြစ်မနေကုဒ်တွင်၊ ကွန်ရက်မှဒေတာကိုစောင့်ဆိုင်းပြီး execution context ကိုအခြား coroutine (green thread) သို့ပေးပို့ခြင်းဖြင့် execution sequence ကို အနှောင့်အယှက်ဖြစ်စေမည့်နေရာများကို ထည့်သွင်းရန်လိုအပ်ပါသည်။ ဤချဉ်းကပ်နည်းသည် ဝင်္ကပါထဲတွင် မျှော်လင့်ထားဆုံးလမ်းကြောင်းကို ဆက်တိုက်ချရေးပြီး ၎င်းတွင် အကိုင်းအခက်များထည့်သည့်အချက်နှင့် ဆင်တူသည်။

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

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

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

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

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

ကျွန်ုပ်တို့သည် Yandex.Cloud ၏အကျိုးစီးပွားအတွက် လုပ်ဆောင်ပါသည်။ သင်သည် စီမံခန့်ခွဲထားသော PostgreSQL ကိုအသုံးပြုပြီး ချိတ်ဆက်မှုပေါင်းကူးစက်ကို တပ်ဆင်ထားပါက၊ သင်သည် ယုတ္တိပုံတူပွားမှုကို အပြင်ဘက်တွင် ဖန်တီးနိုင်သည်၊ ဆိုလိုသည်မှာ၊ သင်သည် ယုတ္တိပုံတူပွားမှုကို အသုံးပြု၍ ကျွန်ုပ်တို့ကို ထားခဲ့လိုပါက၊ Bouncer သည် ယုတ္တိတန်သောပုံတူပွားမှုကို ပြင်ပသို့ ထုတ်လွှတ်မည်မဟုတ်ပါ။

ဤသည်မှာ ယုတ္တိပုံတူပွားခြင်းကို သတ်မှတ်ခြင်း၏ ဥပမာတစ်ခုဖြစ်သည်။

ထို့အပြင်၊ ကျွန်ုပ်တို့သည် အပြင်ပန်းရုပ်ပုံတူကူးခြင်းအတွက် ပံ့ပိုးမှုရှိပါသည်။ Cloud တွင်၊ ဤအရာသည် မဖြစ်နိုင်ပါ၊ အဘယ်ကြောင့်ဆိုသော် အစုအဖွဲ့သည် သင့်အား သူ့အကြောင်း အချက်အလက်များစွာ ပေးလိမ့်မည်ဖြစ်သောကြောင့်၊ သို့သော် သင်၏ထည့်သွင်းမှုများတွင်၊ သင်သည် Odyssey ရှိ connection pooler မှတဆင့် ရုပ်ပိုင်းဆိုင်ရာပုံတူပွားမှုကို လိုအပ်ပါက၊ ၎င်းသည် ဖြစ်နိုင်သည်။

Odyssey တွင် PgBouncer နှင့် လုံးဝသဟဇာတရှိသော စောင့်ကြည့်မှု ရှိပါသည်။ ကျွန်ုပ်တို့တွင် တူညီသော command များအားလုံးနီးပါးကို လုပ်ဆောင်သည့် တူညီသော ကွန်ဆိုးလ်တစ်ခုရှိသည်။ တစ်ခုခုပျောက်ဆုံးနေပါက၊ ဆွဲထုတ်ရန်တောင်းဆိုချက်တစ်ခု သို့မဟုတ် အနည်းဆုံးပြဿနာတစ်ခု GitHub တွင် ပေးပို့ပါ၊ လိုအပ်သောအမိန့်များကို ကျွန်ုပ်တို့ ဖြည့်စွက်ပါမည်။ သို့သော် ကျွန်ုပ်တို့တွင် PgBouncer console ၏ အဓိကလုပ်ဆောင်နိုင်စွမ်းရှိပြီးသားဖြစ်သည်။

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

သင်သည် PgBouncer နှင့် 100% လိုက်ဖက်မှုရှိရန် လိုအပ်ပါက ဤအင်္ဂါရပ်ကို ပိတ်ထားသည်။ ကျွန်ုပ်တို့သည် ဘေးကင်းသောဘက်တွင်ရှိနေရန် Bouncer ကဲ့သို့ အလားတူပြုမူနိုင်သည်။

ပုံစံ

Odyssey အရင်းအမြစ်ကုဒ်အကြောင်း စကားအနည်းငယ်။

https://github.com/yandex/odyssey/pull/66

ဥပမာအားဖြင့်၊ "Pause / Resume" command များရှိသည်။ ဒေတာဘေ့စ်ကို အပ်ဒိတ်လုပ်ရန် ၎င်းတို့ကို အများအားဖြင့် အသုံးပြုကြသည်။ Postgres ကို အပ်ဒိတ်လုပ်ရန် လိုအပ်ပါက ချိတ်ဆက်မှုပေါင်းကူးစက်တွင် ခေတ္တရပ်နိုင်သည်၊ pg_upgrade ပြုလုပ်ပြီးနောက် ပြန်လည်စတင်ပါ။ ပြီးတော့ Client ဘက်ကနေ Database ဟာ ရိုးရိုးနှေးကွေးနေပုံပါပဲ။ ဤလုပ်ဆောင်ချက်ကို အသိုင်းအဝိုင်းမှလူများက ကျွန်ုပ်တို့ထံ ယူဆောင်လာခဲ့သည်။ သူမ မအေးသေးဘူး၊ ဒါပေမယ့် မကြာခင်မှာ အရာအားလုံးဖြစ်လာလိမ့်မယ်။ (အေးခဲနေပြီ)

https://github.com/yandex/odyssey/pull/73 - အေးခဲနေပြီ။

ထို့အပြင်၊ PgBouncer ရှိအင်္ဂါရပ်အသစ်များထဲမှတစ်ခုသည် Yandex.Cloud တွင်အလုပ်မလုပ်သောသူတစ်ဦးမှကျွန်ုပ်တို့ထံယူဆောင်လာသော SCRAM Authentication အတွက်ပံ့ပိုးမှုဖြစ်သည်။ နှစ်ခုလုံးသည် ရှုပ်ထွေးပြီး အရေးကြီးသော လုပ်ဆောင်နိုင်စွမ်းများဖြစ်သည်။

ဒါကြောင့် Odyssey က ဘာနဲ့လုပ်ထားတာလဲဆိုတာ ပြောပြချင်ပါတယ်၊ အခုပဲ ကုဒ်နည်းနည်းရေးချင်ပါသေးတယ်။

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

Machinarium စာကြည့်တိုက်သည် thread အကောင်အထည်ဖော်ရေးစာကြည့်တိုက်ဖြစ်သည်။ ဤ Machinarium ၏ သေးငယ်သော အပိုင်းအစကို စုစည်းဘာသာစကားဖြင့် ရေးသားထားသည်။ ဒါပေမယ့် မစိုးရိမ်ပါနဲ့၊ 15 လိုင်းပဲရှိတယ်။

Odyssey ဗိသုကာ ကော်ရိုတင်းများကို လုပ်ဆောင်နေသည့် ပင်မစက်တစ်ခုရှိသည်။ ဤစက်သည် အဝင် TCP ချိတ်ဆက်မှုများကို လက်ခံပြီး အလုပ်သမားများအကြား ဖြန့်ဝေပေးသည်။

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

Odyssey သည် ပုံမှန် Postgres စမ်းသပ်မှုအစုံကို အသုံးပြု၍ စမ်းသပ်သည်။ ကျွန်ုပ်တို့သည် Bouncer မှတဆင့် install-check ကိုလုပ်ဆောင်ပြီး Odyssey မှတဆင့်၊ ကျွန်ုပ်တို့သည် null div ကိုရရှိသည်။ Bouncer နှင့် Odyssey တွင် အတိအကျတူညီခြင်းမရှိသော ရက်စွဲပုံစံချခြင်းဆိုင်ရာ စမ်းသပ်မှုများစွာရှိသည်။

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

ထို့အပြင်၊ ကျွန်ုပ်တို့၏ cascade configuration ကြောင့်၊ ကျွန်ုပ်တို့သည် အမျိုးမျိုးသောအစုအဝေးများ- Postgres + Odyssey၊ PgBouncer + Odyssey၊ Odyssey + Odyssey ကိုသေချာစေရန်အတွက် Odyssey သည် cascade ရှိအစိတ်အပိုင်းတစ်ခုခုတွင်အဆုံးသတ်ပါက၊ ၎င်းသည်လည်းအလုပ်လုပ်ဆဲဖြစ်သည် ကျွန်ုပ်တို့မျှော်လင့်ထားသည့်အတိုင်း

Rake

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

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

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

Pluggable Authentication Method သည် Built-in Lunux ကိရိယာများကို အသုံးပြု၍ စစ်မှန်ကြောင်းအထောက်အထားပြနိုင်သည့် စွမ်းရည်ဖြစ်သည်။ PgBouncer တွင် PAM မှ တုံ့ပြန်မှုကို စောင့်ဆိုင်းရန် သီးခြား thread တစ်ခုရှိသကဲ့သို့ လက်ရှိချိတ်ဆက်မှုကို ဆောင်ရွက်ပေးပြီး ၎င်းတို့အား PAM thread တွင် နေထိုင်ရန် တောင်းဆိုနိုင်သည့် ပင်မ PgBouncer thread တစ်ခုပါရှိသည်။

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

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

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

အောက်ခြေလိုင်း၊ သင့်တွင် ကွန်ရက်ချိတ်ဆက်မှုပေါင်း 20 ရှိလျှင် ၎င်းတို့အားလုံးကို လက်ခံပါမည်။ နှင့် client ဘက်မှ libpq သည် အချိန်ကုန်သွားသည်များကို အစီရင်ခံတင်ပြပါမည်။ ပုံမှန်အားဖြင့် 000 စက္ကန့်ဖြစ်ပုံရသည်။

၎င်းတို့အားလုံးသည် ဒေတာဘေ့စ်ကို တစ်ချိန်တည်းတွင် မဝင်နိုင်ပါက၊ ၎င်းတို့အားလုံးသည် ကိန်းဂဏန်းမဟုတ်သော ထပ်စမ်းခြင်းဖြင့် ဖုံးအုပ်ထားနိုင်သောကြောင့် ဒေတာဘေ့စ်သို့ မဝင်နိုင်ပါ။

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

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

လမ်းပြမြေပုံ

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

သြဂုတ်လ 2019 ရက်နေ့အထိ။

ဤသည်မှာ သြဂုတ်လတွင် Odyssey လမ်းပြမြေပုံအတိုင်းဖြစ်သည်။

• ကျွန်ုပ်တို့သည် SCRAM နှင့် PAM စစ်မှန်ကြောင်းအထောက်အထားပြခြင်းကို လိုချင်ပါသည်။
• ကျွန်ုပ်တို့သည် အသင့်အနေအထားတွင် စာဖတ်ခြင်းတောင်းဆိုချက်များကို ထပ်ဆင့်ပေးလိုပါသည်။
• အွန်လိုင်းကို ပြန်စချင်ပါတယ်။
• ဆာဗာပေါ်တွင် ခေတ္တရပ်ပေးနိုင်သည်။

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

အဆင်သင့်ဖြစ်နေစေရန် ရှေ့သို့ဖတ်ရန်သာ မေးမြန်းချက်များနှင့် စပ်လျဉ်း? ကျွန်ုပ်တို့တွင် တောင်းဆိုချက်များကို မလုပ်ဆောင်ဘဲ လေကို ရိုးရှင်းစွာ အပူပေးမည့် ပုံတူများရှိသည်။ ရှုံးနိမ့်မှုနှင့် ကူးပြောင်းမှုကို ပံ့ပိုးပေးရန် ၎င်းတို့ကို လိုအပ်ပါသည်။ ဒေတာစင်တာတစ်ခုတွင် ပြဿနာများရှိပါက အသုံးဝင်သောအလုပ်အချို့ဖြင့် ၎င်းတို့ကို သိမ်းပိုက်လိုပါသည်။ အဘယ်ကြောင့်ဆိုသော် ကျွန်ုပ်တို့သည် တူညီသော ဗဟိုပရိုဆက်ဆာများကို configure လုပ်၍မရသောကြောင့်၊ တူညီသော memory မတူသောကြောင့်၊ သို့မဟုတ်ပါက replication အလုပ်မလုပ်သောကြောင့်ဖြစ်သည်။

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

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

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

၎င်းသည် open source ဖြစ်သောကြောင့် အကောင်အထည်ဖော်ရန် အချိန်အတိုင်းအတာတစ်ခုပေးရန် ခက်ခဲသည်။ သို့သော် PgBouncer မှ ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက်များကဲ့သို့ 2,5 နှစ်မဟုတ်ဟု ကျွန်ုပ်မျှော်လင့်ပါသည်။ ဤသည်မှာ Odyssey တွင် ကျွန်ုပ်မြင်လိုသော အင်္ဂါရပ်ဖြစ်သည်။

ရပ်ရွာထဲမှာ လူတွေက ပြင်ဆင်ထားတဲ့ ထုတ်ပြန်ချက်အတွက် ထောက်ခံမှုအကြောင်း မေးကြတယ်။. ယခုသင်ပြင်ဆင်ထားသောထုတ်ပြန်ချက်ကို နည်းလမ်းနှစ်မျိုးဖြင့် ဖန်တီးနိုင်ပါပြီ။ ပထမဦးစွာ သင်သည် "ပြင်ဆင်ထားသည်" ဟုအမည်ရသည့် SQL command ကို execute လုပ်နိုင်သည်။ ဤ SQL command ကိုနားလည်ရန် Bouncer ဘက်ရှိ SQL ကိုနားလည်ရန်သင်ယူရန်လိုအပ်သည်။ ကျွန်ုပ်တို့သည် parser တစ်ခုလုံးကို လိုအပ်သောကြောင့် ၎င်းသည် overkill ဖြစ်လိမ့်မည်။ SQL command တိုင်းကို ခွဲခြမ်းစိတ်ဖြာလို့ မရပါဘူး။

သို့သော် proto3 ရှိ message protocol အဆင့်တွင် ပြင်ဆင်ထားသော ကြေငြာချက်တစ်ခု ရှိပါသည်။ ပြင်ဆင်ထားတဲ့ ထုတ်ပြန်ချက်တစ်ခုကို ဖန်တီးလိုက်တဲ့ အချက်အလက်တွေဟာ ဖွဲ့စည်းပုံပုံစံနဲ့ ရောက်လာတဲ့အခါ ဒါက နေရာပါပဲ။ ထို့အပြင် အချို့သော server ချိတ်ဆက်မှုတွင် client မှ ပြင်ဆင်ထားသော statements များကို ဖန်တီးရန် တောင်းဆိုကြောင်း နားလည်မှုကို ကျွန်ုပ်တို့ ပံ့ပိုးပေးနိုင်ပါသည်။ ငွေပေးငွေယူကို ပိတ်ထားသော်လည်း ဆာဗာနှင့် ကလိုင်းယင့်အကြား ချိတ်ဆက်မှုကို ဆက်လက်ထိန်းသိမ်းထားရန် လိုအပ်ပါသည်။

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

အခြားဆာဗာချိတ်ဆက်မှုတွင် ထိုသို့သောပြင်ဆင်ထားသောထုတ်ပြန်ချက်ကိုဖန်တီးပြီးသော client သည် သင့်ထံလာပါက ၎င်းကိုဖန်တီးပါဟု Andres Freund မှပြောကြားခဲ့သည်။ ဒါပေမယ့် client အစား database ထဲမှာ queries တွေကို execute လုပ်ရတာ နည်းနည်းမှားပုံပေါ်ပေမယ့် database နဲ့ အပြန်အလှန်အပြန်အလှန်ဆက်ဆံဖို့အတွက် protocol ရေးတဲ့ developer ရဲ့အမြင်အရတော့ network connection ကို ရိုးရိုးရှင်းရှင်းပဲ ပေးထားရင် အဆင်ပြေမှာပါ။ အဲဒီလို ပြင်ဆင်ထားတဲ့ မေးခွန်းတစ်ခုရှိတယ်။

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

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

အရေးကြီးဆုံးကတော့ ကျွန်တော်လိုချင်တာက version 1.0 (Version 1.1 ကထွက်ရှိပြီးသား)။ အမှန်မှာ Odyssey သည် ယခု ဗားရှင်း 1.0rc တွင် ရှိနေပြီး၊ ဆိုလိုသည်မှာ ဖြန့်ချိရေး ကိုယ်စားလှယ်လောင်း ဖြစ်သည်။ ပြီးတော့ ကျွန်တော်စာရင်းသွင်းထားတဲ့ ပြဿနာအားလုံးဟာ memory ယိုစိမ့်မှုမှလွဲပြီး အတိအကျတူညီတဲ့ဗားရှင်းနဲ့ ဖြေရှင်းပေးခဲ့ပါတယ်။

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

ကွန်မြူနတီရှိလူအများအပြားက ထိုဗားရှင်း 1.0 တွင် ခေတ္တရပ်ခြင်းနှင့် SCRAM တို့ကို တောင်းဆိုခဲ့ကြသည်။ သို့သော် ၎င်းသည် ကျွန်ုပ်တို့သည် SCRAM နှင့် ခေတ္တရပ်ခြင်းတို့ကို မသတ်ရသေးသောကြောင့် နောက်ဗားရှင်းကို ထုတ်လုပ်ရန် လိုအပ်မည်ဟု ဆိုလိုပါသည်။ သို့သော် ဖြစ်နိုင်ချေ များသောအားဖြင့် ဤပြဿနာကို လျင်မြန်စွာ ဖြေရှင်းနိုင်မည်ဖြစ်သည်။

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

ဒီအပိုင်းလေး အဆုံးထိ နားထောင်ချင်ပါတယ် ။ ကျေးဇူးတင်ပါသည်!

မေးခွန်းများကို

ကျွန်ုပ်သည် ကျွန်ုပ်၏ကိုယ်ပိုင် application_name ကို သတ်မှတ်ပါက၊ Odyssey တွင် ငွေပေးငွေယူပေါင်းစည်းခြင်းအပါအဝင် ၎င်းကို မှန်ကန်စွာ ထပ်ဆင့်ပေးပို့နိုင်မည်လား။

Odyssey သို့မဟုတ် Bouncer

Odyssey မှာ။ Bouncer တွင်၎င်းကိုပစ်ချသည်။

အစုံလုပ်မယ်။

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

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

အစီရင်ခံစာအတွက် Andrey ကျေးဇူးတင်ပါတယ်၊ အစီရင်ခံစာကောင်း။ Odyssey က မိနစ်တိုင်း ပိုမြန်ပြီး ဖွံ့ဖြိုးလာတာကို ဝမ်းသာပါတယ်။ ဒီအတိုင်းဆက်သွားချင်ပါတယ်။ Odyssey သည် မတူညီသောဒေတာဘေ့စ်များသို့ တစ်ပြိုင်နက်ချိတ်ဆက်နိုင်စေရန်အတွက် Multi data-source connection ရှိရန် သင့်အား ကျွန်ုပ်တို့တောင်းဆိုထားပြီးဖြစ်သည်

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

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

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

ဟုတ်ပါတယ်။ pcache တွင် သင်လိုချင်သော data blocks များ ရှိမည်မဟုတ်ပါ၊ အစစ်အမှန် cache တွင် သင်လိုချင်သော tables နှင့်ပတ်သက်သော အချက်အလက်များ ရှိမည်မဟုတ်ပါ၊ အစီအစဉ်များတွင် parseed queries များ ရှိမည်မဟုတ်ပါ၊ လုံးဝမရှိတော့ပါ။

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

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

ဟုတ်တယ်၊ ကိုယ်အလေးချိန်တိုးတယ်။

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

Nginx တွင် ဤရွေးချယ်ခွင့်ရှိသည်။ slowly start ဆာဗာအတွက် အစုအဝေးတစ်ခုအတွင်း။ ပြီးတော့ သူက ဝန်ကို တဖြည်းဖြည်း တိုးလာတယ်။

ဟုတ်တယ်၊ စိတ်ကူးကောင်းတယ်၊ အဲဒါကိုရောက်တဲ့အခါ စမ်းကြည့်မယ်။

source: www.habr.com