Google Cloud Spanner- ကောင်း၊ မကောင်း၊ ရုပ်ဆိုး

မင်္ဂလာပါ Khabrovsk နေထိုင်သူများ။ ထုံးစံအတိုင်း၊ သင်တန်းအသစ်မစတင်မီ စိတ်ဝင်စားဖွယ်အကြောင်းအရာများကို ဆက်လက်မျှဝေပါသည်။ အထူးသဖြင့် ယနေ့တွင် သင့်အတွက်၊ သင်တန်းစတင်သည့်အချိန်နှင့် တိုက်ဆိုင်ရန် Google Cloud Spanner အကြောင်း ဆောင်းပါးတစ်ပုဒ်ကို ထုတ်ပြန်လိုက်ပါသည်။ "ဆော့ဖ်ဝဲရေးသားသူများအတွက် AWS".

မူရင်းတွင် ထုတ်ဝေခဲ့သည်။ Lightspeed HQ ဘလော့ဂ်.

ကမ္ဘာတစ်ဝှမ်းရှိ လက်လီရောင်းချသူများ၊ စားသောက်ဆိုင်များနှင့် အွန်လိုင်းရောင်းချသူများအတွက် cloud-based POS ဖြေရှင်းချက်အမျိုးမျိုးကို ပေးဆောင်သည့် ကုမ္ပဏီတစ်ခုအနေဖြင့် Lightspeed သည် အရောင်းအဝယ်ကိစ္စများ၊ ခွဲခြမ်းစိတ်ဖြာမှုနှင့် ရှာဖွေမှုအသုံးပြုမှုကိစ္စရပ်များအတွက် မတူညီသောဒေတာဘေ့စ်အမျိုးအစားများစွာကို အသုံးပြုပါသည်။ ဤဒေတာဘေ့စ်ပလပ်ဖောင်းတစ်ခုစီတိုင်းတွင် ၎င်း၏အားသာချက်များနှင့် အားနည်းချက်များရှိသည်။ ထို့ကြောင့်၊ Google သည် Cloud Spanner ကို စျေးကွက်သို့မိတ်ဆက်သောအခါ - အကန့်အသတ်မရှိ အလျားလိုက်အတိုင်းအတာနှင့် 99,999% ဝန်ဆောင်မှုအဆင့်သဘောတူညီချက် (SLA) ကဲ့သို့သော ဆက်စပ်ဒေတာဘေ့စ်လောကတွင် မမြင်နိုင်သောအလားအလာရှိသောအင်္ဂါရပ်များ။ — လက်ထဲရောက်ဖို့ အခွင့်အရေးကို လက်လွှတ်မခံနိုင်ဘူး။

Cloud Spanner နှင့် ကျွန်ုပ်တို့၏ အတွေ့အကြုံကို ကျယ်ကျယ်ပြန့်ပြန့် ခြုံငုံသုံးသပ်နိုင်စေရန်၊ ကျွန်ုပ်တို့အသုံးပြုခဲ့သည့် အကဲဖြတ်မှုစံနှုန်းများအပြင် အောက်ပါအကြောင်းအရာများကို အကျုံးဝင်မည်ဖြစ်ပါသည်။

1. ကျွန်ုပ်တို့၏ အကဲဖြတ်မှု စံနှုန်းများ
2. အတိုချုပ်ပြောရရင် Cloud Spanner
3. ကျွန်ုပ်တို့၏အကဲဖြတ်ချက်
4. ကျွန်ုပ်တို့၏တွေ့ရှိချက်များ

1. ကျွန်ုပ်တို့၏ အကဲဖြတ်မှု စံနှုန်းများ

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

• (မြင်သာထင်သာ) သမားရိုးကျ SQL ဒေတာဘေ့စ်ဖြေရှင်းချက်အတွက် အစားထိုးအဖြစ်
• OLAP ပံ့ပိုးမှုဖြင့် OLTP ဖြေရှင်းနည်း

မှတ်ချက်: ရိုးရှင်းပြီး နှိုင်းယှဉ်ရလွယ်ကူစေရန်၊ ဤဆောင်းပါးသည် GCP Cloud SQL နှင့် Amazon AWS RDS ဖြေရှင်းချက်မိသားစုများ၏ MySQL မျိုးကွဲများနှင့် Cloud Spanner ကို နှိုင်းယှဉ်ထားသည်။

ရိုးရာ SQL database ဖြေရှင်းချက်အတွက် Cloud Spanner ကို အသုံးပြုခြင်း။

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

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

အပလီကေးရှင်းတစ်ခုအား ဒေါင်လိုက်အရွယ်အစားချဲ့ထွင်ခြင်းသည် ပုံမှန်အားဖြင့် ပရိုဆက်ဆာ/cores ပိုများခြင်း၊ RAM ပိုများခြင်း၊ ပိုမိုမြန်ဆန်သောသိုလှောင်မှုစသည်တို့ကို ပေါင်းထည့်ခြင်းဖြင့် ပုံမှန်အားဖြင့် ဆာဗာကို အဆင့်မြှင့်တင်ခြင်းတွင် ဟာ့ဒ်ဝဲအရင်းအမြစ်များကို ထပ်ထည့်ခြင်းဖြင့် ဒေတာဘေ့စ်စွမ်းဆောင်ရည်ကို တိုးမြင့်စေသည်၊ ဒုတိယတွင် အရောင်းအဝယ်များတွင် အဓိကအားဖြင့် တိုင်းတာခြင်းနှင့် OLTP စနစ်များအတွက် ငွေပေးငွေယူကြာချိန်ကို ဖြစ်ပေါ်စေပါသည်။ ဆက်စပ်ဒေတာဘေ့စ်စနစ်များ (Multi-threaded ချဉ်းကပ်နည်းကိုအသုံးပြုသည်) ဖြစ်သည့် MySQL စကေးကို ဒေါင်လိုက်ဖြင့် ကောင်းစွာလုပ်ဆောင်နိုင်သည်။

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

Horizontal scaling သည် ဆာဗာများကို အစုအဝေးတစ်ခုသို့ နောက်ထပ်ဆာဗာများ ပေါင်းထည့်သည့် ချဉ်းကပ်မှုတစ်ခုဖြစ်ပြီး၊ အကောင်းဆုံးအားဖြင့် ဆာဗာအရေအတွက်ကို ထည့်သွင်းထားသောကြောင့် စွမ်းဆောင်ရည်ကို တစ်ပြေးညီ တိုးမြင့်စေသည်။ လူများစု ရိုးရာ ဒေတာဘေ့စ်စနစ်များသည် ရေပြင်ညီအတိုင်း ကောင်းစွာ မတိုင်းတာနိုင် သို့မဟုတ် အတိုင်းအတာ လုံးဝမလုပ်ဆောင်ပါ။ ဥပမာအားဖြင့်၊ MySQL သည် slave readers များကို ပေါင်းထည့်ခြင်းဖြင့် read operations အတွက် အလျားလိုက် အတိုင်းအတာ လုပ်နိုင်သော်လည်း ရေးရန်အတွက် အလျားလိုက် အတိုင်းအတာ မရနိုင်ပါ။

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

အပြည့်အဝဖော်ပြသည်။ ဝန်ဆောင်မှုတစ်ခုအနေဖြင့် DBMS ရှုထောင့်အမျိုးမျိုးကနေ အကဲဖြတ်ရမယ်။ အခြေခံအနေဖြင့်၊ Google၊ GCP Cloud SQL နှင့် Amazon၊ AWS RDS အတွက် လူကြိုက်အများဆုံး DBMS ကို ကျွန်ုပ်တို့ယူထားပါသည်။ ကျွန်ုပ်တို့၏အကဲဖြတ်မှုတွင် ကျွန်ုပ်တို့သည် အောက်ပါအမျိုးအစားများကို အာရုံစိုက်ခဲ့သည်-

• အသွင်အပြင်မြေပုံဆွဲခြင်း- SQL၊ DDL၊ DML၊ ချိတ်ဆက်မှု စာကြည့်တိုက်များ/ချိတ်ဆက်ကိရိယာများ၊ ငွေပေးငွေယူ ပံ့ပိုးကူညီမှု စသည်ဖြင့်။
• ဖွံ့ဖြိုးတိုးတက်ရေး ပံ့ပိုးမှု- လွယ်ကူသော ဖွံ့ဖြိုးတိုးတက်မှုနှင့် စမ်းသပ်မှု။
• စီမံခန့်ခွဲရေး ပံ့ပိုးမှု- ဥပမာ စီမံခန့်ခွဲမှု- ဥပမာ၊ အတက်/အဆင်း နှင့် သာဓကများကို အဆင့်မြှင့်တင်ခြင်း၊ SLA၊ အရန်သိမ်းခြင်းနှင့် ပြန်လည်ရယူခြင်း လုံခြုံရေး/ဝင်ရောက်ထိန်းချုပ်မှု။

OLAP-enabled OLTP ဖြေရှင်းချက်အဖြစ် Cloud Spanner ကို အသုံးပြုခြင်း။

Google သည် Cloud Spanner ကို ခွဲခြမ်းစိတ်ဖြာမှုလုပ်ဆောင်ရန်အတွက် ဒီဇိုင်းထုတ်ထားကြောင်း ရှင်းရှင်းလင်းလင်း မဖော်ပြထားသော်လည်း ၎င်းသည် OLAP အလုပ်တာဝန်များအတွက် ဒီဇိုင်းထုတ်ထားသည့် Apache Impala & Kudu နှင့် YugaByte ကဲ့သို့သော အခြားအင်ဂျင်များနှင့် ရည်ညွှန်းချက်အချို့ကို မျှဝေပါသည်။

Cloud Spanner သည် တစ်သမတ်တည်း အတိုင်းအတာ-ထုတ် HTAP (hybrid အရောင်းအ၀ယ်ပြုလုပ်ခြင်း/ခွဲခြမ်းစိတ်ဖြာမှုလုပ်ဆောင်ခြင်း) အင်ဂျင်ကို (အနည်းနှင့်အများ) အသုံးပြုနိုင်သော OLAP အင်္ဂါရပ်အစုံပါရှိသော အခွင့်အလမ်းအနည်းငယ်သာရှိသော်လည်း၊ ၎င်းသည် ကျွန်ုပ်တို့၏အာရုံစိုက်မှုကို ခံထိုက်သည်ဟု ကျွန်ုပ်တို့ယူဆပါသည်။

ယင်းကို စိတ်ထဲတွင် ကျွန်ုပ်တို့သည် အောက်ပါအမျိုးအစားများကို ကြည့်ရှုခဲ့သည်-

• ဒေတာဖွင့်ခြင်း၊ အညွှန်းများနှင့် ပိုင်းခြားခြင်း ပံ့ပိုးမှု
• Query Performance နှင့် DML

2. အတိုချုပ်ပြောရရင် Cloud Spanner

Google Spanner သည် ၎င်း၏ကိုယ်ပိုင်ဝန်ဆောင်မှုများစွာအတွက် Google အသုံးပြုသည့် အစုလိုက်ဆက်စပ်ဒေတာဘေ့စ်စီမံခန့်ခွဲမှုစနစ် (RDBMS) ဖြစ်သည်။ Google သည် ၎င်းအား ယေဘူယျအားဖြင့် Google Cloud Platform အသုံးပြုသူများအတွက် 2017 အစောပိုင်းတွင် ရရှိစေခဲ့သည်။

ဤသည်မှာ Cloud Spanner ရည်ညွှန်းချက်အချို့ဖြစ်သည်-

• တစ်သမတ်တည်း အတိုင်းအတာ ကြီးမားသော RDBMS အစုအဝေး- ဒေတာ ညီညွတ်မှုကို သေချာစေရန် ဟာ့ဒ်ဝဲ အချိန်ကို ထပ်တူပြုခြင်းကို အသုံးပြုသည်။
• ဇယားဖြတ်ကျော်ငွေပေးငွေယူပံ့ပိုးမှု- ငွေပေးငွေယူများသည် ဇယားအများအပြားကို ချဲ့ထွင်နိုင်သည် - ဇယားတစ်ခုတည်းတွင် မလိုအပ်ဘဲ ( Apache HBase သို့မဟုတ် Apache Kudu ကဲ့သို့မဟုတ်ပါ)။
• ပင်မသော့ကိုအခြေခံသည့်ဇယားများ- ဇယားများအားလုံးတွင် ဇယားအတွင်းရှိ ကော်လံအများအပြားပါ၀င်နိုင်သည့် အဓိကသော့ (PC) ပါရှိရပါမည်။ Tabular ဒေတာကို PC အစီအစဉ်တွင် သိမ်းဆည်းထားသောကြောင့် ၎င်းကို PC ရှာဖွေခြင်းအတွက် အလွန်ထိရောက်ပြီး မြန်ဆန်စေသည်။ အခြားသော PC-based စနစ်များကဲ့သို့ပင်၊ အကောင်အထည်ဖော်မှုကို အောင်မြင်ရန် စိတ်ထဲတွင် ကြိုတင်ဒီဇိုင်းထုတ်ထားသော အသုံးပြုမှုကိစ္စများဖြင့် အကောင်အထည်ဖော်ရမည်ဖြစ်သည်။ အကောင်းဆုံးစွမ်းဆောင်ရည်.
• အစင်းကြောင်းဇယားများ- ဇယားများသည် တစ်ခုနှင့်တစ်ခုအပေါ်တွင် ရုပ်ပိုင်းဆိုင်ရာ မှီခိုမှုများရှိနိုင်သည်။ ကလေးဇယားရှိ အတန်းများကို မိဘဇယားရှိ အတန်းများနှင့် ယှဉ်နိုင်သည်။ ဤချဉ်းကပ်မှုသည် ဖောက်သည်များနှင့် ၎င်းတို့၏ ငွေတောင်းခံလွှာများကို ပူးတွဲတည်နေရာရှာဖွေခြင်းကဲ့သို့သော ဒေတာမော်ဒယ်ပုံစံအဆင့်အတွင်း ဖော်ထုတ်နိုင်သည့် ဆက်ဆံရေးများကို ရှာဖွေမှုကို အရှိန်မြှင့်စေသည်။
• အညွှန်းများ- Cloud Spanner သည် ဒုတိယအညွှန်းကိန်းများကို ပံ့ပိုးပေးသည်။ အညွှန်းတွင် အညွှန်းပြုထားသော ကော်လံများနှင့် PC ကော်လံများအားလုံး ပါဝင်သည်။ ဆန္ဒရှိပါက အညွှန်းတွင် အခြားသော အညွှန်းမဟုတ်သော ကော်လံများလည်း ပါဝင်နိုင်သည်။ မေးမြန်းချက်များကို အရှိန်မြှင့်ရန် အညွှန်းကို ပင်မဇယားဖြင့် ကြားဖြတ်နိုင်သည်။ အညွှန်းကိန်းတွင် သိမ်းဆည်းထားသော နောက်ထပ်ကော်လံအများဆုံးအရေအတွက်ကဲ့သို့သော အညွှန်းကိန်းများအတွက် ကန့်သတ်ချက်များစွာရှိသည်။ ထို့အပြင်၊ အညွှန်းများမှတစ်ဆင့် မေးမြန်းမှုများသည် အခြားသော RDBMS များကဲ့သို့ ရိုးရှင်းမည်မဟုတ်ပါ။

“Cloud Spanner သည် ရှားပါးသောကိစ္စများတွင်သာ အညွှန်းတစ်ခုကို အလိုအလျောက်ရွေးချယ်သည်။ အထူးသဖြင့်၊ Cloud Spanner သည် သိမ်းဆည်းထားခြင်းမရှိသော ကော်လံများကို query တစ်ခုမှ တောင်းဆိုပါက ဒုတိယအညွှန်းကို အလိုအလျောက်ရွေးချယ်မည်မဟုတ်ပါ။ အညွှန်း "။

• ဝန်ဆောင်မှုအဆင့်သဘောတူညီချက် (SLA)- SLA 99,99% ဖြင့် ဒေသတစ်ခုတွင် ဖြန့်ကျက်မှု။ 99,999% SLA ဖြင့် ဒေသပေါင်းစုံ ဖြန့်ကျက်မှုများ။ SLA ကိုယ်တိုင်က သဘောတူညီချက်တစ်ခုမျှသာဖြစ်ပြီး မည်သည့်အာမခံချက်မှမဟုတ်သော်လည်း၊ Google ရှိလူများသည် ထိုသို့သောပြင်းထန်သောတောင်းဆိုမှုကိုပြုလုပ်ရန် ခက်ခဲသောဒေတာအချို့ရှိသည်ဟု ကျွန်တော်ယုံကြည်ပါသည်။ (ကိုးကားရန်အတွက်၊ 99,999% သည် တစ်လလျှင် ဝန်ဆောင်မှုမရရှိနိုင်သည့် 26,3 စက္ကန့်ကို ဆိုလိုသည်။)
• ပိုများသော: https://cloud.google.com/spanner/

မှတ်ချက်: Apache Tephra ပရောဂျက်သည် Apache HBase သို့ ပိုမိုကောင်းမွန်သော ငွေပေးငွေယူ ပံ့ပိုးမှု ပံ့ပိုးပေးသည် (ယခုလည်း Apache Phoenix တွင် ဘီတာအဖြစ် အကောင်အထည်ဖော်နေသည်)။

3. ကျွန်ုပ်တို့၏အကဲဖြတ်ချက်

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

Sharded MySQL အတွက် Cloud Spanner ကို ကျွန်ုပ်တို့ အကဲဖြတ်ပါသည်။

Google Cloud SQL နှင့် Amazon AWS RDS၊ cloud စျေးကွက်တွင် လူကြိုက်အများဆုံး OLTP DBMS နှစ်ခုတွင် အင်္ဂါရပ်များစွာရှိသည်။ သို့သော်၊ ဤဒေတာဘေ့စ်များကို node တစ်ခု၏အရွယ်အစားထက်ကျော်လွန်ရန်၊ သင်သည် application partitioning ကိုလုပ်ဆောင်ရန်လိုအပ်သည်။ ဤချဉ်းကပ်မှုသည် အပလီကေးရှင်းများနှင့် စီမံခန့်ခွဲမှုနှစ်ခုလုံးအတွက် ထပ်လောင်းရှုပ်ထွေးမှုကို ဖန်တီးပေးသည်။ Spanner သည် များစွာသော shards အများအပြားကို instance တစ်ခုတည်းအဖြစ် ပေါင်းစပ်ခြင်း၏ အခြေအနေတွင် အံဝင်ခွင်ကျဖြစ်ပြီး မည်သည့်အင်္ဂါရပ်များ (ရှိပါက) စတေးရန် လိုအပ်မည်ကို ကျွန်ုပ်တို့ ကြည့်ရှုခဲ့ပါသည်။

SQL၊ DML နှင့် DDL ပံ့ပိုးမှုအပြင် ချိတ်ဆက်ကိရိယာနှင့် စာကြည့်တိုက်များလား။

ပထမဦးစွာ၊ မည်သည့်ဒေတာဘေ့စ်ဖြင့်စတင်သောအခါ၊ သင်သည်ဒေတာမော်ဒယ်တစ်ခုဖန်တီးရန်လိုအပ်သည်။ JDBC Spanner ကို သင့်စိတ်ကြိုက် SQL tool သို့ ချိတ်ဆက်နိုင်သည်ဟု သင်ယူဆပါက ၎င်းနှင့် သင့်ဒေတာကို မေးမြန်းနိုင်သော်လည်း ဇယားတစ်ခုဖန်တီးရန် သို့မဟုတ် ပြင်ဆင်ခြင်း (DDL) သို့မဟုတ် ထည့်သွင်း/အပ်ဒိတ်/ဖျက်ခြင်းအတွက် ၎င်းကို အသုံးမပြုနိုင်ပါ။ လုပ်ဆောင်ချက်များ (DML)။ Google ၏တရားဝင် JDBC သည် ယင်းနှစ်ခုလုံးကို မပံ့ပိုးပါ။

"ယာဉ်မောင်းများသည် DML သို့မဟုတ် DDL ထုတ်ပြန်ချက်များကို လောလောဆယ် မပံ့ပိုးပါ။"
Spanner စာရွက်စာတမ်း

GCP ကွန်ဆိုးလ်တွင် အခြေအနေက ပိုကောင်းမည်မဟုတ်ပါ - သင်သည် SELECT မေးမြန်းမှုများကိုသာ ပေးပို့နိုင်ပါသည်။ ကံကောင်းစွာပဲ ငွေပေးငွေယူများအပါအဝင် အသိုက်အဝန်းမှ DML နှင့် DDL အတွက် ပံ့ပိုးမှုရှိသော JDBC driver တစ်ခုရှိသည်။ github.com/olavloite/spanner-jdbc. ဤဒရိုင်ဘာသည် အလွန်အသုံးဝင်သော်လည်း၊ Google ၏ကိုယ်ပိုင် JDBC ဒရိုက်ဘာမရှိခြင်းသည် အံ့သြစရာဖြစ်သည်။ ကံကောင်းစွာဖြင့်၊ Google သည် သုံးစွဲသူစာကြည့်တိုက်များ (gRPC ကိုအခြေခံ၍) ပံ့ပိုးမှုပေးသည်- C#၊ Go၊ Java၊ node.js၊ PHP၊ Python နှင့် Ruby။

Cloud Spanner စိတ်ကြိုက် API များကို မဖြစ်မနေအသုံးပြုခြင်းသည် (JDBC တွင် DDL နှင့် DML မရှိခြင်းကြောင့်) ချိတ်ဆက်မှုပေါင်းကန်များ သို့မဟုတ် ဒေတာဘေ့စ်ချိတ်ဆက်မှုဘောင်များ (ဥပမာ Spring MVC) ကဲ့သို့သော ဆက်စပ်ကုဒ်ဧရိယာများအတွက် ကန့်သတ်ချက်အချို့ကို ဖြစ်ပေါ်စေသည်။ ပုံမှန်အားဖြင့်၊ JDBC ကိုအသုံးပြုသည့်အခါ၊ စမ်းသပ်ပြီး ကောင်းမွန်စွာအလုပ်လုပ်သည့် သင်နှစ်သက်သောချိတ်ဆက်မှုရေကန် (ဥပမာ HikariCP၊ DBCP၊ C3PO စသည်ဖြင့်) ကို လွတ်လပ်စွာရွေးချယ်နိုင်သည်။ စိတ်ကြိုက် Spanner APIs များတွင်၊ ကျွန်ုပ်တို့ကိုယ်တိုင် ဖန်တီးထားသော မူဘောင်များ/စည်းနှောင်မှုဆိုင်ရာ အစုအဝေးများ/ဆက်ရှင်များကို အားကိုးရပါမည်။

ပင်မသော့ (PC) ဗဟိုပြုဒီဇိုင်းသည် Cloud Spanner အား PC မှတစ်ဆင့် ဒေတာရယူသည့်အခါ အလွန်လျင်မြန်စေရန် ခွင့်ပြုသော်လည်း အချို့သော စုံစမ်းမှုပြဿနာများကိုလည်း မိတ်ဆက်ပေးပါသည်။

• ပင်မသော့တန်ဖိုးကို အပ်ဒိတ်လုပ်၍မရပါ။ မူရင်း PC မှ entry ကို ဖျက်ပြီး value အသစ်ဖြင့် ပြန်ထည့်ရပါမည်။ (၎င်းသည် အခြားသော PC ဦးတည်သော ဒေတာဘေ့စ်/သိုလှောင်မှုအင်ဂျင်များနှင့် ဆင်တူသည်။)
• UPDATE နှင့် DELETE ထုတ်ပြန်ချက်တိုင်းသည် မည်သည့်နေရာတွင် PC ကိုမဆို သတ်မှတ်ရမည်ဖြစ်ပြီး၊ ထို့ကြောင့် ထုတ်ပြန်ချက်အားလုံးကို ဖျက်ရန် အချည်းနှီးမဖြစ်နိုင်ပါ - အသေးစိပ်မေးခွန်းတစ်ခု အမြဲရှိရပါမည်၊ ဥပမာ- UPDATE xxx WHERE ID IN (SELECT id မှ table1)
• PC အကွက်အတွက် sequence ကို သတ်မှတ်ပေးသည့် အလိုအလျောက် တိုးပေးသည့် ရွေးစရာမရှိခြင်း သို့မဟုတ် အလားတူအရာများ။ ၎င်းကိုလုပ်ဆောင်ရန်အတွက်၊ သက်ဆိုင်ရာတန်ဖိုးကို အပလီကေးရှင်းဘက်တွင် ဖန်တီးရပါမည်။

အလယ်တန်း အညွှန်းကိန်းများ

Google Cloud Spanner တွင် ဒုတိယအညွှန်းကိန်းများအတွက် built-in ပံ့ပိုးမှုရှိသည်။ ဤသည်မှာ အခြားနည်းပညာများတွင် အမြဲမရှိသော အလွန်ကောင်းမွန်သော အင်္ဂါရပ်တစ်ခုဖြစ်သည်။ Apache Kudu သည် လက်ရှိတွင် ဒုတိယအညွှန်းကိန်းများကို လုံးဝမပံ့ပိုးပါ၊ နှင့် Apache HBase သည် အညွှန်းများကို တိုက်ရိုက်မပံ့ပိုးပါ၊ သို့သော် ၎င်းတို့ကို Apache Phoenix မှတဆင့် ထည့်နိုင်သည်။

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

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

ကိုယ်စားပြုမှု?

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

ခွဲတမ်းနှင့် ကန့်သတ်ချက်များကို အသေးစိတ်ဖော်ပြသည့်အပိုင်းအတွက် Cloud Spanner စာရွက်စာတမ်းကို ကြည့်ပါ (spanner/quotas) အထူးသဖြင့် အချို့သောအက်ပ်လီကေးရှင်းများအတွက် ပြဿနာရှိနိုင်သည့်အချက်တစ်ခုရှိသည်- Cloud Spanner သည် ဥပမာတစ်ခုလျှင် အများဆုံးဒေတာဘေ့စ် 100 ကန့်သတ်ချက်ရှိသည်။ ရှင်းနေသည်မှာ၊ ၎င်းသည် ဒေတာဘေ့စ် 100 ကျော်အထိ အတိုင်းအတာအထိ ဒီဇိုင်းထုတ်ထားသည့် ဒေတာဘေ့စ်အတွက် အဓိက ပိတ်ဆို့မှုတစ်ခု ဖြစ်နိုင်သည်။ ကံကောင်းစွာဖြင့်၊ ကျွန်ုပ်တို့၏ Google နည်းပညာဆိုင်ရာ ကိုယ်စားလှယ်နှင့် စကားပြောပြီးနောက်၊ ဤကန့်သတ်ချက်ကို Google ပံ့ပိုးကူညီမှုမှတစ်ဆင့် တန်ဖိုးအားလုံးနီးပါးအထိ တိုးမြှင့်နိုင်သည်ကို တွေ့ရှိခဲ့သည်။

ဖွံ့ဖြိုးတိုးတက်ရေး အထောက်အပံ့ ?

Cloud Spanner သည် ၎င်း၏ API နှင့် လုပ်ဆောင်ရန်အတွက် အလွန်ကောင်းမွန်သော ပရိုဂရမ်းမင်းဘာသာစကား ပံ့ပိုးမှုကို ပေးပါသည်။ တရားဝင်ပံ့ပိုးထားသောစာကြည့်တိုက်များသည် C#၊ Go၊ Java၊ node.js၊ PHP၊ Python နှင့် Ruby နယ်ပယ်များတွင်ဖြစ်သည်။ စာရွက်စာတမ်းသည် အလွန်အသေးစိတ်ဖြစ်သော်လည်း အခြားအဆင့်မြင့်နည်းပညာများကဲ့သို့ပင်၊ လူသုံးအများဆုံးဒေတာဘေ့စ်နည်းပညာများနှင့်နှိုင်းယှဉ်ပါက အသိုင်းအဝိုင်းသည် အလွန်သေးငယ်သောကြောင့် အသုံးများသောအသုံးပြုမှုနည်းပါးသောကိစ္စများ သို့မဟုတ် ပြဿနာများကိုဖြေရှင်းရာတွင် အချိန်ပိုကြာသွားနိုင်သည်။

ဒီတော့ ဒေသဖွံ့ဖြိုးရေးကို ပံ့ပိုးပေးဖို့ကော။

ဝုဏ်အတွင်းတွင် Cloud Spanner ဖြစ်ရပ်တစ်ခုကို ဖန်တီးရန် နည်းလမ်းရှာမတွေ့ပါ။ ကျွန်ုပ်တို့ရရှိသော အနီးစပ်ဆုံးအရာမှာ Docker ပုံဖြစ်သည်။ ပိုးဟပ်မူအရ တူညီသော်လည်း လက်တွေ့တွင် အလွန်ကွဲပြားပါသည်။ ဥပမာအားဖြင့်၊ CockroachDB သည် PostgreSQL JDBC ကိုသုံးနိုင်သည်။ ဖွံ့ဖြိုးတိုးတက်မှုပတ်ဝန်းကျင်သည် ထုတ်လုပ်မှုပတ်ဝန်းကျင်နှင့် အနီးစပ်ဆုံးဖြစ်သင့်သောကြောင့် Cloud Spanner သည် Spanner အပြည့်အစုံကို အားကိုးရမည်ဖြစ်သောကြောင့် စံပြမဟုတ်ပါ။ ကုန်ကျစရိတ်သက်သာစေရန်၊ ဒေသတစ်ခုတည်း သာဓကတစ်ခုကို သင်ရွေးချယ်နိုင်သည်။

အုပ်ချုပ်ရေး ပံ့ပိုးမှု ?

Cloud Spanner ဥပမာကိုဖန်တီးခြင်းသည် အလွန်ရိုးရှင်းပါသည်။ သင်သည် ဒေသပေါင်းစုံ သို့မဟုတ် ဒေသတစ်ခုတည်း သာဓကတစ်ခုဖန်တီးရန်၊ ဒေသ(များ) နှင့် node အရေအတွက်ကို သတ်မှတ်ရန်သာ လိုအပ်သည်။ တစ်မိနစ်မပြည့်မီတွင်၊ သင်၏ဥပမာသည် လည်ပတ်နေလိမ့်မည်။

အခြေခံ မက်ထရစ်အများအပြားကို Google Console ရှိ Spanner စာမျက်နှာမှ တိုက်ရိုက်ကြည့်ရှုနိုင်သည်။ သင်သည် မက်ထရစ်အဆင့်သတ်မှတ်ချက်များနှင့် သတိပေးချက်မူဝါဒများကို သတ်မှတ်နိုင်သည့် Stackdriver မှတစ်ဆင့် ပိုမိုအသေးစိတ်ကြည့်ရှုမှုများကို ရရှိနိုင်သည်။

အရင်းအမြစ်များကို အသုံးပြုခွင့်ရှိပါသလား။

MySQL သည် အသုံးပြုသူခွင့်ပြုချက်/အခန်းကဏ္ဍများအတွက် ကျယ်ပြန့်ပြီး အလွန်အသေးစိတ်ဆက်တင်များကို ပေးဆောင်သည်။ သီးခြားဇယားတစ်ခုသို့ ဝင်ရောက်ခွင့် သို့မဟုတ် ၎င်း၏ကော်လံများ၏ အပိုင်းခွဲတစ်ခုကိုပင် အလွယ်တကူ စီစဉ်သတ်မှတ်နိုင်သည်။ Cloud Spanner သည် သင့်အား အလွန်မြင့်မားသောအဆင့်တွင် မူဝါဒများနှင့် ခွင့်ပြုချက်များကိုသာ သတ်မှတ်ခွင့်ပြုသည့် Google ၏ Identity & Access Management (IAM) ကိရိယာကို အသုံးပြုပါသည်။ အကြမ်းဖျင်းဆုံးရွေးချယ်မှုမှာ ထုတ်လုပ်မှုအသုံးပြုမှုကိစ္စအများစုနှင့် မကိုက်ညီသည့် ဒေတာဘေ့စ်အဆင့် ကြည်လင်ပြတ်သားမှုဖြစ်သည်။ ဤကန့်သတ်ချက်သည် သင့်အား သင်၏ကုဒ်၊ အခြေခံအဆောက်အအုံ သို့မဟုတ် Spanner အရင်းအမြစ်များကို ခွင့်ပြုချက်မရှိဘဲ အသုံးပြုခြင်းမှ ကာကွယ်ရန် နောက်ထပ်လုံခြုံရေးအစီအမံများကို ထည့်သွင်းခိုင်းစေပါသည်။

အရန်များ?

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

မေးမြန်းမှု စွမ်းဆောင်ရည်

ဒေတာဖွင့်ရန်နှင့် စမ်းသပ်မေးမြန်းရန် Yahoo! Cloud Serving Benchmark အောက်ဖော်ပြပါဇယားတွင် YCSB workload B ကို 95% မှ 5% write ratio ဖြင့်ပြသထားသည်။

* load test ကို n1-standard-32 Compute Engine (CE) (32 vCPU၊ 120 GB memory) တွင် လုပ်ဆောင်ခဲ့ပြီး စမ်းသပ်မှုမှာ စမ်းသပ်မှုများတွင် မည်သည့်အခါမှ ပိတ်ဆို့မှုမရှိခဲ့ပါ။
** YCSB instance တစ်ခုတွင် အများဆုံး thread အရေအတွက်သည် 400 ဖြစ်ပါသည်။ စုစုပေါင်း 2400 threads ရရှိရန် YCSB tests ၏ parallel instances စုစုပေါင်း ခြောက်ခုကို run ရပါမည်။

စံနှုန်းရလဒ်များ၊ အထူးသဖြင့် CPU load နှင့် TPS ပေါင်းစပ်မှုကိုကြည့်ပါက Cloud Spanner အတိုင်းအတာသည် အတော်လေး ကောင်းမွန်ကြောင်း ကျွန်ုပ်တို့ ရှင်းရှင်းလင်းလင်း သိမြင်နိုင်ပါသည်။ thread အများအပြားမှ ဖန်တီးထားသော လေးလံသောဝန်ကို Cloud Spanner အစုအဝေးရှိ node အများအပြားဖြင့် ထေမိပါသည်။ latency သည် အလွန်မြင့်မားပုံရပြီး အထူးသဖြင့် 2400 threads ဖြင့်လည်ပတ်သောအခါ၊ ပိုမိုတိကျသောကိန်းဂဏာန်းများရရှိရန် ကွန်ပျူတာအင်ဂျင်အသေးစား 6 ခုဖြင့် ပြန်လည်စမ်းသပ်ရန် လိုအပ်ပါသည်။ အပြိုင်စမ်းသပ်မှု 6 ခုပါသော CE instance တစ်ခုစီအစား YCSB စမ်းသပ်မှုတစ်ခုစီကို လုပ်ဆောင်ပါမည်။ ဤနည်းဖြင့်၊ Cloud Spanner နှင့် CE စစ်ဆေးမှုလုပ်ဆောင်နေသည့် ကွန်ရက်ချိတ်ဆက်မှုဖြင့် Cloud Spanner တောင်းဆိုမှု latency နှင့် latency အကြား ခွဲခြားရန် ပိုမိုလွယ်ကူလာမည်ဖြစ်သည်။

Cloud Spanner သည် OLAP အဖြစ် မည်သို့လုပ်ဆောင်သနည်း။

ပိုင်းခြားခြင်း?

ဒေတာများကို ရုပ်ပိုင်းဆိုင်ရာနှင့်/သို့မဟုတ် ယုတ္တိနည်းကျကျ သီးခြားခွဲခြမ်းခွဲခြင်းဟုခေါ်သော partitions သည် OLAP အင်ဂျင်အများစုတွင်တွေ့ရသော အလွန်ရေပန်းစားသောအယူအဆတစ်ခုဖြစ်သည်။ Partitions များသည် query performance နှင့် database ကို ထိန်းသိမ်းနိုင်မှုကို သိသာထင်ရှားစွာ တိုးတက်စေနိုင်သည်။ ပိုင်းခြားခြင်းသို့ နက်နဲသွားခြင်းသည် သီးခြားဆောင်းပါး(များ) ဖြစ်ပေလိမ့်မည်၊ ထို့ကြောင့် အပိုင်းခွဲခြင်းနှင့် ခွဲပိုင်းခွဲခြင်းအစီအစဉ်ရှိခြင်း၏ အရေးကြီးပုံကို ဖော်ပြကြပါစို့။ ဒေတာများကို အပိုင်းခွဲများအဖြစ် ခွဲခြမ်းကာ အပိုင်းခွဲများအထိ ခွဲခြမ်းစိတ်ဖြာနိုင်စွမ်းသည် ခွဲခြမ်းစိတ်ဖြာမေးမြန်းမှု စွမ်းဆောင်ရည်အတွက် သော့ချက်ဖြစ်သည်။

Cloud Spanner သည် ထိုသို့သော အပိုင်းများကို မပံ့ပိုးပါ။ ၎င်းသည် data များကို internally ဟုခေါ်သည်။ ကှဲပွားစေ-s သည် အဓိကသော့ချက်ဘောင်များကို အခြေခံထားသည်။ Cloud Spanner အစုအဝေးတွင် ဝန်ကိုချိန်ခွင်လျှာညှိရန် အလိုအလျောက် ပိုင်းဖြတ်ခြင်းကို လုပ်ဆောင်ပါသည်။ Cloud Spanner ၏ အလွန်အသုံးဝင်သောအင်္ဂါရပ်မှာ ပင်မဇယား၏အခြေခံဝန်ကို ပိုင်းခြားခြင်း (အခြားဇယားတစ်ခုနှင့် စွက်ဖက်မှုမရှိသော) ဖြစ်သည်။ Spanner သည် ၎င်းတွင် ပါဝင်ခြင်းရှိမရှိကို အလိုအလျောက် သိရှိသည်။ ကှဲပွားစေ အခြားဒေတာများထက် မကြာခဏဖတ်သောဒေတာ ကှဲပွားစေ-ah, နှင့်နောက်ထပ်ခွဲခွာခြင်းအပေါ်ဆုံးဖြတ်နိုင်ပါသည်။ ဤနည်းအားဖြင့်၊ ပေးပို့မှုအား ထိရောက်စွာ တိုးမြင့်စေသည့် တောင်းဆိုချက်တစ်ခုတွင် အပို node များပါ၀င်နိုင်သည်။

ဒေတာကို တင်နေလား။

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

• သင်၏ဒေတာကို အဓိကသော့ဖြင့် စီပါ။
• သူတို့ကို 10* နဲ့ ခွဲပါnodes အရေအတွက် သီးခြားအပိုင်းများ။
• ဒေတာကို အပြိုင်တင်နိုင်သည့် အလုပ်တာဝန်အစုံကို ဖန်တီးပါ။

ဤဒေတာဖွင့်ခြင်းသည် Cloud Spanner node အားလုံးကို အသုံးပြုပါသည်။

ကျွန်ုပ်တို့သည် 10M အတန်း၏ဒေတာအတွဲတစ်ခုထုတ်လုပ်ရန် YCSB အလုပ်ဝန် A ကိုအသုံးပြုခဲ့သည်။

* load test ကို n1-standard-32 compute engine (32 vCPU၊ 120 GB memory) တွင် လုပ်ဆောင်ခဲ့ပြီး စမ်းသပ်မှုမှာ စမ်းသပ်မှုများတွင် မည်သည့်အခါမှ ပိတ်ဆို့မှုမရှိခဲ့ပါ။
** ထုတ်လုပ်မှုလုပ်ငန်းတာဝန်အတွက် တစ်ခုတည်းသော node စနစ်ထည့်သွင်းခြင်းကို မထောက်ခံပါ။

အထက်တွင်ဖော်ပြခဲ့သည့်အတိုင်း၊ Cloud Spanner သည် ၎င်းတို့၏ဝန်အားအပေါ်အခြေခံ၍ ပိုင်းခြားမှုများကို အလိုအလျောက်လုပ်ဆောင်ပေးသောကြောင့် ဆက်တိုက်စမ်းသပ်မှုအကြိမ်ကြိမ်ပြုလုပ်ပြီးနောက် ရလဒ်များပိုမိုကောင်းမွန်လာသည်။ ဤနေရာတွင်တင်ပြထားသောရလဒ်များသည် ကျွန်ုပ်တို့ရရှိသောအကောင်းဆုံးရလဒ်များဖြစ်သည်။ အထက်ဖော်ပြပါ နံပါတ်များကို ကြည့်ပါ၊ အစုအဝေးရှိ node အရေအတွက်များ တိုးလာသည်နှင့်အမျှ Cloud Spanner သည် မည်ကဲ့သို့ အတိုင်းအတာ (ကောင်းစွာ) တိုင်းတာသည်ကို ကျွန်ုပ်တို့ မြင်တွေ့နိုင်ပါသည်။ ထင်ရှားသော ကိန်းဂဏာန်းများသည် အထက်ဖော်ပြပါ ကဏ္ဍတွင် ဖော်ပြထားသည့်အတိုင်း ရောနှောထားသော အလုပ်ချိန်များအတွက် ရလဒ်များ (95% ဖတ်ပြီး 5% ရေးသည်) နှင့် ဆန့်ကျင်ဘက်ဖြစ်သော အလွန်နိမ့်သော ပျမ်းမျှကြာချိန်များဖြစ်သည်။

ချဲ့ထွင်မလား။

Cloud Spanner nodes အရေအတွက်ကို တိုးမြှင့်ခြင်းနှင့် လျှော့ချခြင်းသည် တစ်ချက်နှိပ်ရုံဖြင့် လုပ်ဆောင်ရမည့် အလုပ်ဖြစ်သည်။ ဒေတာကို လျင်မြန်စွာ တင်လိုပါက၊ သင်၏ instance ကို အမြင့်ဆုံးသို့ မြှင့်တင်ရန် (ကျွန်ုပ်တို့၏ အခြေအနေတွင် ၎င်းသည် US-EAST ဒေသတွင် 25 node များဖြစ်သည်)၊ ထို့နောက် ဒေတာအားလုံးပြည့်သွားသည်နှင့် သင့်ပုံမှန် load အတွက် သတ်မှတ်ချက်ပြည့်မီသော node အရေအတွက်ကို လျှော့ချပါ ဒေတာဘေ့စ်၊ 2TB/node ကန့်သတ်ချက်ကို ရည်ညွှန်းသည်။

အလွန်သေးငယ်သော ဒေတာဘေ့စ်တစ်ခုဖြင့်ပင် ဤကန့်သတ်ချက်ကို ကျွန်ုပ်တို့အား သတိရမိပါသည်။ load စမ်းသပ်မှုများစွာကို လုပ်ဆောင်ပြီးနောက်၊ ကျွန်ုပ်တို့၏ဒေတာဘေ့စ်သည် အရွယ်အစား 155 GB ခန့်ရှိပြီး 1 node instance တစ်ခုသို့ ချဲ့ထွင်သောအခါတွင်၊ ကျွန်ုပ်တို့သည် အောက်ပါအမှားအယွင်းကို ရရှိခဲ့ပါသည်။

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

Cloud Spanner အစုအဝေးရှိ node အရေအတွက် တိုးခြင်းနှင့် လျှော့ချခြင်းကို REST API ကိုအသုံးပြု၍ အလိုအလျောက်လုပ်ဆောင်နိုင်သည်။ ၎င်းသည် အလုပ်များသော အလုပ်ချိန်အတွင်း တိုးများလာသော system load ကို လျှော့ချရန်အတွက် အထူးအသုံးဝင်ပါသည်။

OLAP မေးခွန်းများ၏ စွမ်းဆောင်ရည်။

ကျွန်ုပ်တို့သည် ဤအပိုင်းတွင် Spanner ကို အကဲဖြတ်ရာတွင် အချိန်များစွာကို အသုံးပြုရန် မူလက စီစဉ်ထားပါသည်။ SELECT COUNTs အများအပြားပြီးနောက်၊ စမ်းသပ်ခြင်းသည် တိုတောင်းမည်ဖြစ်ပြီး Spanner သည် OLAP အတွက် သင့်လျော်သောအင်ဂျင်မဟုတ်ကြောင်း ကျွန်ုပ်တို့ချက်ချင်းသိရှိနားလည်ပါသည်။ အစုအဝေးရှိ နံပါတ်များ မည်သို့ပင်ရှိစေကာမူ 10M အတန်းဇယားရှိ အတန်းအရေအတွက်ကို ရွေးချယ်ခြင်းသည် 55 နှင့် 60 စက္ကန့်ကြား ကြာပါသည်။ ထို့အပြင်၊ အလယ်အလတ်ရလဒ်များကို သိမ်းဆည်းရန် မမ်မိုရီပိုလိုအပ်သည့် မည်သည့်မေးခွန်းမဆို OOM အမှားကြောင့် မအောင်မြင်ပါ။

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

Todd Lipcon ၏ ဆောင်းပါးတွင် TPC-H စုံစမ်းမေးမြန်းချက်များအတွက် နံပါတ်အချို့ကို တွေ့ရှိနိုင်သည်။ Nosql-kudu-spanner-slides.html၊ ဆလိုက် 42 နှင့် 43။ ဤနံပါတ်များသည် ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ရလဒ်များ (ကံမကောင်းစွာဖြင့်) နှင့်ကိုက်ညီပါသည်။

4. ကျွန်ုပ်တို့၏ကောက်ချက်

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

Cloud Spanner ကို စတင်အကဲဖြတ်သောအခါ၊ ၎င်း၏ စီမံခန့်ခွဲမှုအင်္ဂါရပ်များသည် အခြားသော Google SQL ဖြေရှင်းချက်များနှင့် မဝေးလွန်းသော သို့မဟုတ် အနည်းဆုံးတော့ အကွာအဝေးနှင့် တန်းတူဖြစ်ရန် မျှော်လင့်ပါသည်။ သို့သော် မိတ္တူများ အပြည့်အ၀မရှိခြင်းနှင့် အရင်းအမြစ်များသို့ ဝင်ရောက်ခွင့်အပေါ် အလွန်ကန့်သတ်ထိန်းချုပ်မှုကြောင့် ကျွန်ုပ်တို့ အံ့အားသင့်ခဲ့ရသည်။ အမြင်မရှိ၊ ဒေသဖွံ့ဖြိုးရေးပတ်ဝန်းကျင်မရှိ၊ ပံ့ပိုးမထားသော အတွဲများ၊ DML နှင့် DDL ပံ့ပိုးမှုမပါဘဲ JDBC စသည်တို့ကို ဖော်ပြခြင်းမဟုတ်ပါ။

ဒါဆို အရောင်းအ၀ယ်ဒေတာဘေ့စ်ကို အတိုင်းအတာတစ်ခုအထိ လိုအပ်နေတဲ့သူတစ်ယောက် ဘယ်ကိုသွားမလဲ။ စျေးကွက်တွင် အသုံးပြုမှုကိစ္စအားလုံးနှင့် ကိုက်ညီမည့် တစ်ခုတည်းသော အဖြေတစ်ခု မတွေ့ပါ။ အပိတ်နှင့် ပွင့်လင်းအရင်းအမြစ်ဖြေရှင်းချက်များစွာရှိသည် (ဤဆောင်းပါးတွင်ဖော်ပြထားသည့်အချို့) တစ်ခုစီတွင် ၎င်းတို့၏အားသာချက်များနှင့် အားနည်းချက်များရှိသော်လည်း ၎င်းတို့အနက်မှ SaaS သည် 99,999% SLA နှင့် မြင့်မားသောလိုက်ဖက်ညီမှုဖြင့် SaaS ကို မကမ်းလှမ်းပါ။ မြင့်မားသော SLA သည် သင်၏အဓိကပန်းတိုင်ဖြစ်ပြီး စိတ်ကြိုက် cloud အစုံလိုက်ဖြေရှင်းချက်တစ်ခုကို တည်ဆောက်ရန် မလိုလားပါက၊ Cloud Spanner သည် သင်ရှာဖွေနေသည့်ဖြေရှင်းချက်ဖြစ်နိုင်ပါသည်။ ဒါပေမယ့် သူ့ရဲ့ ကန့်သတ်ချက်အားလုံးကို သိထားသင့်ပါတယ်။

တရားမျှတစေရန်အတွက်၊ Cloud Spanner သည် 2017 နွေဦးပေါက်တွင်သာ အများပြည်သူသို့ ဖြန့်ချိခဲ့ခြင်းဖြစ်ပြီး ၎င်း၏လက်ရှိချို့ယွင်းချက်အချို့သည် နောက်ဆုံးတွင် ပျောက်ကွယ်သွားနိုင်ကြောင်း (မျှော်လင့်ထားသည်) နှင့် ၎င်းတို့ပြုလုပ်သည့်အခါတွင် ၎င်းသည် ဂိမ်းပြောင်းလဲမှုတစ်ခု ဖြစ်လာနိုင်သည်ဟု မျှော်လင့်ရန် သင့်လျော်ပါသည်။ နောက်ဆုံးတွင်၊ Cloud Spanner သည် Google အတွက် ဘေးထွက်ပရောဂျက်တစ်ခုမျှသာ မဟုတ်ပါ။ Google သည် ၎င်းကို အခြား Google ထုတ်ကုန်များအတွက် အခြေခံအဖြစ် အသုံးပြုသည်။ Google သည် မကြာသေးမီက Google Cloud Storage တွင် Megastore ကို Cloud Spanner ဖြင့် အစားထိုးလိုက်သောအခါ၊ Google Cloud Storage သည် ကမ္ဘာလုံးဆိုင်ရာ စကေးပေါ်ရှိ အရာဝတ္ထုများစာရင်းအတွက် အလွန်ကိုက်ညီမှုရှိလာစေရန် ခွင့်ပြုခဲ့သည် (ထိုအရာသည် ကိစ္စမဟုတ်သေးပါ။ Amazon ရဲ့ S3).

ဒီတော့ မျှော်လင့်ချက်ရှိသေးတယ်... ငါတို့မျှော်လင့်တယ်။

ဒါပါပဲ။ ဆောင်းပါးရေးသားသူကဲ့သို့ ကျွန်ုပ်တို့လည်း ဆက်လက်မျှော်လင့်ထားသော်လည်း ယင်းနှင့်ပတ်သက်၍ သင်မည်သို့ထင်မြင်သနည်း။ မှတ်ချက်များတွင်ရေးပါ။

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

source: www.habr.com