မှတ်ချက်။ ဘာသာပြန်: Jaana Dogan သည် Go တွင်ရေးသားထားသော ကုမ္ပဏီ၏ထုတ်လုပ်မှုဝန်ဆောင်မှုများကို ကြည့်ရှုနိုင်စေရန် လက်ရှိလုပ်ဆောင်နေသော Google တွင် အတွေ့အကြုံရင့်အင်ဂျင်နီယာတစ်ဦးဖြစ်သည်။ အင်္ဂလိပ်စကားပြောပရိသတ်များကြားတွင် ရေပန်းစားလာခဲ့သည့် ဤဆောင်းပါးတွင် သူမသည် DBMS များ (နှင့် တစ်ခါတစ်ရံတွင် ယေဘုယျအားဖြင့် ဖြန့်ဝေသည့်စနစ်များ) နှင့် ပတ်သက်သော အချက် 17 ချက်ကို စုဆောင်းခဲ့ပြီး ကြီးမားသော/လိုအပ်နေသော application များကို developer များအတွက် အသုံးဝင်စေမည့် DBMSs (ယေဘုယျအားဖြင့် ဖြန့်ဝေပေးသည့်စနစ်များ) ဖြစ်သည်။
ကွန်ပြူတာစနစ်အများစုသည် ၎င်းတို့၏အခြေအနေများကို ခြေရာခံကာ ဒေတာသိမ်းဆည်းမှုစနစ်အချို့ လိုအပ်ပါသည်။ ဒေတာဆုံးရှုံးမှုနှင့် ပြတ်တောက်မှုဖြစ်စေသည့် ဒီဇိုင်းအမှားများ ပြုလုပ်သည့်လမ်းတစ်လျှောက် အချိန်အတော်ကြာ ဒေတာဘေ့စ်များနှင့်ပတ်သက်သည့် ဗဟုသုတများကို ကျွန်ုပ်စုဆောင်းခဲ့သည်။ သတင်းအချက်အလက် အများအပြားကို စီမံဆောင်ရွက်သော စနစ်များတွင်၊ ဒေတာဘေ့စ်များသည် စနစ်တည်ဆောက်ပုံ၏ အလယ်ဗဟိုတွင် ရှိပြီး အကောင်းဆုံးဖြေရှင်းနည်းကို ရွေးချယ်ရာတွင် အဓိကအစိတ်အပိုင်းတစ်ခုအဖြစ် လုပ်ဆောင်သည်။ ဒေတာဘေ့စ်၏လုပ်ဆောင်မှုကို အနီးကပ်အာရုံစိုက်ထားသော်လည်း၊ အပလီကေးရှင်းဆော့ဖ်ဝဲရေးသားသူများသည် ကြိုတင်မျှော်မှန်းရန်ကြိုးစားသည့်ပြဿနာများသည် ရေခဲတောင်၏အစွန်အဖျားသာဖြစ်သည်။ ဤအခန်းဆက်ဆောင်းပါးများတွင်၊ ဤနယ်ပယ်တွင် အထူးမကျွမ်းကျင်သော developer များအတွက် အသုံးဝင်မည့် အကြံဥာဏ်အချို့ကို ကျွန်ုပ်မျှဝေပါသည်။
- 99,999% ကွန်ရက်သည် ပြဿနာမဖြစ်စေပါက သင်ကံကောင်းပါသည်။
- ACID ဆိုသည်မှာ ကွဲပြားသောအရာများစွာကို ဆိုလိုသည်။
- ဒေတာဘေ့စ်တစ်ခုစီတွင် လိုက်လျောညီထွေရှိမှုနှင့် သီးခြားခွဲထားမှုကို သေချာစေရန်အတွက် ၎င်း၏ကိုယ်ပိုင်ယန္တရားများရှိသည်။
- ပုံမှန်အတိုင်းထိန်းသိမ်းရန်ခက်ခဲသောအခါတွင် အကောင်းမြင်သောပိတ်ဆို့ခြင်းသည် ကယ်တင်ခြင်းသို့ရောက်ပါသည်။
- ညစ်ပတ်သောစာဖတ်ခြင်းနှင့် ဒေတာဆုံးရှုံးခြင်းအပြင် အခြားကွဲလွဲချက်များလည်း ရှိသေးသည်။
- ဒေတာဘေ့စ်နှင့် အသုံးပြုသူသည် လုပ်ဆောင်မှုလမ်းကြောင်းအပေါ် အမြဲတမ်းသဘောမတူပါ။
- အပလီကေးရှင်းအဆင့် ခွဲဝေမှုအား အပလီကေးရှင်းပြင်ပသို့ ရွှေ့နိုင်သည်။
- အလိုအလျောက်တိုးလာခြင်းသည် အန္တရာယ်ရှိနိုင်သည်။
- Stale data သည် အသုံးဝင်နိုင်ပြီး လော့ခ်ချရန် မလိုအပ်ပါ။
- ပုံပျက်ခြင်းများသည် အချိန်တိုင်းရင်းမြစ်များအတွက် ပုံမှန်ဖြစ်သည်။
- နှောင့်နှေးခြင်းသည် အဓိပ္ပါယ်များစွာရှိသည်။
- တိကျသော ငွေပေးငွေယူအတွက် စွမ်းဆောင်ရည်လိုအပ်ချက်များကို အကဲဖြတ်ရပါမည်။
- လျှို့ဝှက်ငွေပေးချေမှုများသည် အန္တရာယ်ရှိနိုင်သည်။
- ငွေပေးချေမှုများကို အပလီကေးရှင်းအခြေအနေနှင့် မချိတ်ဆက်သင့်ပါ။
- Query Planner များသည် databases များအကြောင်း များစွာပြောပြနိုင်ပါသည်။
- အွန်လိုင်း ရွှေ့ပြောင်းခြင်းသည် ခက်ခဲသော်လည်း ဖြစ်နိုင်သည်။
- ဒေတာဘေ့စ်တွင် သိသာထင်ရှားစွာ တိုးလာခြင်းသည် မှန်းဆမရသော တိုးများလာစေသည်။
ဤဆောင်းပါး၏ အစောပိုင်းဗားရှင်းအတွက် ၎င်းတို့၏ တုံ့ပြန်ချက်အတွက် Emmanuel Odeke၊ Rein Henrichs နှင့် အခြားသူများကို ကျေးဇူးတင်လိုပါသည်။
99,999% ကွန်ရက်သည် ပြဿနာမဖြစ်စေပါက သင်ကံကောင်းပါသည်။
ခေတ်မီကွန်ရက်နည်းပညာများ မည်မျှယုံကြည်စိတ်ချရပြီး ကွန်ရက်ချို့ယွင်းမှုများကြောင့် စနစ်များ မည်မျှကြာကြာ ကျဆင်းသွားသည်နှင့် ပတ်သက်၍ မေးခွန်းထုတ်စရာဖြစ်နေဆဲဖြစ်သည်။ ဤပြဿနာနှင့်ပတ်သက်သည့် သတင်းအချက်အလက်သည် ရှားပါးပြီး သုတေသနကို အထူးပြုကွန်ရက်များ၊ စက်ကိရိယာများနှင့် ပုဂ္ဂိုလ်ရေးဆိုင်ရာ အဖွဲ့အစည်းကြီးများက လွှမ်းမိုးထားလေ့ရှိသည်။
Spanner (Google ၏ ကမ္ဘာလုံးဆိုင်ရာ ဖြန့်ကျက်ထားသော ဒေတာဘေ့စ်) အတွက် 99,999% ရရှိနိုင်မှုနှုန်းဖြင့် Google ကသာ တောင်းဆိုထားသည်။ ပြဿနာများသည် network နှင့်သက်ဆိုင်သည်။ တစ်ချိန်တည်းမှာပင်၊ ကုမ္ပဏီသည် ၎င်း၏ အထူးပြုကွန်ရက်ကို မြင့်မားစွာရရှိနိုင်မှု၏ “ပင်မမဏ္ဍိုင်” ဟုခေါ်သည်။ လေ့လာချက် 2014 ခုနှစ်တွင် ဆောင်ရွက်ခဲ့သော စိန်ခေါ်မှုများထဲမှ တစ်ခု၊" 1994 ခုနှစ်တွင် Peter Deutsch ရေးဆွဲခဲ့သည်။ ကွန်ရက်သည် အမှန်တကယ် ယုံကြည်စိတ်ချရပါသလား။
ကျယ်ပြန့်သောအင်တာနက်အတွက် ဆောင်ရွက်သော ကုမ္ပဏီကြီးများ၏ ပြင်ပတွင် ကျယ်ကျယ်ပြန့်ပြန့် သုတေသနပြုချက် မရှိပါ။ ၎င်းတို့၏ဖောက်သည်များ၏ ပြဿနာများ၏ ရာခိုင်နှုန်းသည် ကွန်ရက်နှင့်ပတ်သက်သည့် အဓိက ကစားသမားများထံမှ လုံလောက်သော ဒေတာလည်း မရှိပါ။ အင်တာနက်တစ်ခုလုံးကို နာရီပေါင်းများစွာကြာအောင် ဖယ်ရှားပေးနိုင်သည့် ကြီးမားသော cloud ဝန်ဆောင်မှုပေးသူများ၏ ကွန်ရက်အစုအဝေးတွင် ပြတ်တောက်သွားသည်ကို ကျွန်ုပ်တို့ ကောင်းစွာသိရှိထားပြီး ၎င်းတို့သည် လူနှင့် ကုမ္ပဏီအများအပြားကို ထိခိုက်စေသည့် ထင်ရှားသောဖြစ်ရပ်များဖြစ်သောကြောင့် ဖြစ်သည်။ ကွန်ရက်ပြတ်တောက်မှုများသည် အဆိုပါကိစ္စများအားလုံးကို မီးမောင်းထိုးပြခြင်းမဟုတ်သော်လည်း နောက်ထပ်ကိစ္စများစွာတွင် ပြဿနာများဖြစ်စေနိုင်သည်။ cloud ဝန်ဆောင်မှုများ၏ ဖောက်သည်များသည် ပြဿနာများ၏ အကြောင်းရင်းများကို ဘာမှ မသိပါ။ ချို့ယွင်းမှုရှိပါက ဝန်ဆောင်မှုပေးသူဘက်မှ ကွန်ရက်အမှားအယွင်းတစ်ခုအဖြစ် သတ်မှတ်ရန် မဖြစ်နိုင်ပေ။ ၎င်းတို့အတွက်၊ ပြင်ပဝန်ဆောင်မှုများသည် black boxes ဖြစ်သည်။ ကြီးမားသော ဝန်ဆောင်မှုပေးသူမရှိဘဲ သက်ရောက်မှုကို အကဲဖြတ်ရန် မဖြစ်နိုင်ပေ။
ကစားသမားကြီးများသည် ၎င်းတို့၏စနစ်များအကြောင်း တင်ပြခဲ့ရာတွင်၊ ကွန်ရက်အခက်အခဲများ ဖြစ်နိုင်ခြေရှိသော အချိန်ပိုင်းပြဿနာများ၏ ရာခိုင်နှုန်းအနည်းငယ်သာရှိလျှင် သင်ကံကောင်းသည်ဟု ပြောရန် စိတ်ချရပါသည်။ ကွန်ရက်ဆက်သွယ်မှုများသည် ဟာ့ဒ်ဝဲချို့ယွင်းမှု၊ topology အပြောင်းအလဲများ၊ စီမံခန့်ခွဲရေးပုံစံပြောင်းလဲမှုများနှင့် လျှပ်စစ်ဓာတ်အားပြတ်တောက်မှုကဲ့သို့သော လောကီအရာများကို ကြုံတွေ့နေရဆဲဖြစ်သည်။ ဖြစ်နိုင်ခြေရှိသော ပြဿနာများစာရင်းကို မကြာသေးမီက ပေါင်းထည့်လိုက်ကြောင်း သိလိုက်ရသဖြင့် အံ့သြမိပါသည်။ (ဟုတ်တယ်၊ မင်းပြောတာ မှန်တယ်)။
ACID ဆိုသည်မှာ ကွဲပြားခြားနားသော အရာများစွာကို ဆိုလိုပါသည်။
အတိုကောက် ACID သည် Atomicity, Consistency, Isolation, Reliability ကို ကိုယ်စားပြုသည်။ ချို့ယွင်းချက်များ၊ အမှားအယွင်းများ၊ ဟာ့ဒ်ဝဲ ချို့ယွင်းမှုများ စသည်တို့တွင် ၎င်းတို့၏ တရားဝင်မှုကို သေချာစေရန်အတွက် အဆိုပါ လွှဲပြောင်းမှုများ၏ ဂုဏ်သတ္တိများကို ရည်ရွယ်ပါသည်။ ACID သို့မဟုတ် အလားတူအစီအစဥ်များမရှိဘဲ၊ ၎င်းတို့အတွက် တာဝန်ရှိသည်နှင့် ဒေတာဘေ့စ်အတွက် တာဝန်ရှိသည်တို့ကို ပိုင်းခြားရန် ခက်ခဲမည်ဖြစ်သည်။ ဆက်စပ်ငွေပေးချေမှုဆိုင်ရာဒေတာဘေ့စ်အများစုသည် ACID နှင့်လိုက်လျောညီထွေဖြစ်အောင်ကြိုးစားသော်လည်း NoSQL ကဲ့သို့သောချဉ်းကပ်မှုအသစ်များသည်အကောင်အထည်ဖော်ရန်စျေးကြီးသောကြောင့် ACID လွှဲပြောင်းခြင်းမရှိဘဲဒေတာဘေ့စ်များစွာကိုတိုးပွားစေသည်။
ကျွန်တော်စက်မှုလုပ်ငန်းကိုစစချင်းတုန်းကတော့ ACID concept က ဘယ်လိုဆက်စပ်မှုရှိတယ် ဆိုတာကို ကျွန်တော်တို့ရဲ့ နည်းပညာပိုင်းဆိုင်ရာခေါင်းဆောင်က ပြောခဲ့ပါတယ်။ တရားမျှတစေရန်အတွက် ACID သည် တင်းကျပ်သော အကောင်အထည်ဖော်မှုစံနှုန်းထက် အကြမ်းဖျင်းဖော်ပြချက်ဖြစ်သည်ဟု ယူဆပါသည်။ ယနေ့တွင် ၎င်းသည် တိကျသော ပြဿနာအမျိုးအစားတစ်ခုကို ပြုစုပျိုးထောင်ပေးသောကြောင့် (နှင့် ဖြစ်နိုင်ချေရှိသော ဖြေရှင်းနည်းများစွာကို အကြံပြုပေးသည်) ဖြစ်သောကြောင့်၊
DBMS တိုင်းသည် ACID နှင့် ကိုက်ညီသည်မဟုတ်ပါ။ တစ်ချိန်တည်းမှာပင်၊ ACID ကို ပံ့ပိုးပေးသည့် ဒေတာဘေ့စ် အကောင်အထည်ဖော်မှုများသည် လိုအပ်ချက်အစုံအလင်ကို ကွဲပြားစွာ နားလည်ပါသည်။ ACID အကောင်အထည်ဖော်မှု နောက်ကျရခြင်း၏ အကြောင်းရင်းတစ်ခုမှာ ACID လိုအပ်ချက်များကို အကောင်အထည်ဖော်ရန်အတွက် အပေးအယူလုပ်ရမည့် အပေးအယူများစွာကြောင့် ဖြစ်သည်။ ဖန်တီးသူများသည် ၎င်းတို့၏ဒေတာဘေ့စ်များကို ACID နှင့် လိုက်လျောညီထွေဖြစ်စေသောအဖြစ် တင်ပြနိုင်သော်လည်း အနားသတ်ကိစ္စများ၏အဓိပ္ပာယ်ဖွင့်ဆိုမှုသည် "ဖြစ်နိုင်ဖွယ်မရှိ" ဖြစ်ရပ်များကို ကိုင်တွယ်သည့်ယန္တရားကဲ့သို့ပင် သိသိသာသာကွဲပြားနိုင်သည်။ အနည်းဆုံးတော့၊ developer များသည် ၎င်းတို့၏ အထူးအပြုအမူနှင့် ဒီဇိုင်းအပေးအယူများကို မှန်ကန်စွာ နားလည်သဘောပေါက်နိုင်ရန် အခြေခံအကောင်အထည်ဖော်မှုများ၏ ရှုပ်ထွေးပွေလီသောအဆင့်မြင့်နားလည်မှုကို ရရှိနိုင်သည်။
MongoDB သည် ACID လိုအပ်ချက်များနှင့် ကိုက်ညီခြင်း ရှိ၊ မရှိ ဗားရှင်း 4 ကို ထုတ်ဝေပြီးနောက်တွင်ပင် ဆက်လက်ဆွေးနွေးနေပါသည်။ MongoDB ကို အချိန်အတော်ကြာ ပံ့ပိုးမထားပါ။ ပုံမှန်အားဖြင့် ဒေတာကို စက္ကန့် 60 တိုင်း တစ်ကြိမ်ထက် မပိုစေဘဲ disk သို့ ကတိပြုထားသည်။ အောက်ပါအဖြစ်အပျက်ကို မြင်ယောင်ကြည့်ပါ- အပလီကေးရှင်းတစ်ခုသည် စာနှစ်စောင်ရေးသည် (w1 နှင့် w2)။ MongoDB သည် w1 ကို အောင်မြင်စွာ သိမ်းဆည်းထားသော်လည်း ဟာ့ဒ်ဝဲချို့ယွင်းမှုကြောင့် w2 သည် ပျောက်ဆုံးသွားပါသည်။
မြင်ကွင်းကို သရုပ်ဖော်သည့် ပုံကြမ်း။ MongoDB သည် ဒစ်ခ်သို့ ဒေတာမရေးမီတွင် ပျက်စီးသွားပါသည်။
disk သို့ အပ်နှံခြင်းသည် စျေးကြီးသော လုပ်ငန်းစဉ်တစ်ခုဖြစ်သည်။ မကြာခဏ ကျူးလွန်မှုများကို ရှောင်ကြဉ်ခြင်းဖြင့်၊ developer များသည် ယုံကြည်စိတ်ချရမှုစရိတ်ဖြင့် မှတ်တမ်းတင်ခြင်းစွမ်းဆောင်ရည်ကို မြှင့်တင်ပေးပါသည်။ MongoDB သည် လက်ရှိတွင် မှတ်တမ်းများကို ပံ့ပိုးပေးသော်လည်း ညစ်ညမ်းသောစာများသည် 100ms တိုင်းတွင် မှတ်တမ်းများကို မူရင်းအတိုင်း ဖမ်းယူထားသောကြောင့် ညစ်ညမ်းသောရေးသားမှုများသည် ဒေတာခိုင်မာမှုကို သက်ရောက်မှုရှိနေဆဲဖြစ်သည်။ ဆိုလိုသည်မှာ၊ အန္တရာယ်အလွန်နည်းပါးသော်လည်း၊ မှတ်တမ်းများနှင့် ၎င်းတို့တွင်ဖော်ပြထားသော ပြောင်းလဲမှုများအတွက် အလားတူအခြေအနေမျိုး ဖြစ်နိုင်သေးသည်။
ဒေတာဘေ့စ်တစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင် ညီညွတ်မှုနှင့် သီးခြားယန္တရားများရှိသည်။
ACID လိုအပ်ချက်များအနက်၊ ညီညွတ်မှုနှင့် သီးခြားခွဲထားမှုသည် အပေးအယူအကွာအဝေးပိုမိုကျယ်ပြန့်သောကြောင့် မတူညီသောအကောင်အထည်ဖော်မှုအရေအတွက် အများဆုံးဖြစ်ကြောင်း ဂုဏ်ယူပါသည်။ ညီညွတ်မှုနှင့် သီးခြားခွဲထားမှုသည် အလွန်စျေးကြီးသော လုပ်ဆောင်ချက်များဖြစ်သည်ဟု ဆိုရပါမည်။ ၎င်းတို့သည် ပေါင်းစပ်ညှိနှိုင်းမှုနှင့် ဒေတာညီညွတ်မှုအတွက် ပြိုင်ဆိုင်မှုကို တိုးမြှင့်ရန် လိုအပ်သည်။ ဒေတာစင်တာအများအပြားတွင် (အထူးသဖြင့် ၎င်းတို့သည် မတူညီသော ပထဝီဝင်ဒေသများတွင် တည်ရှိပါက) ဒေတာဘေ့စ်ကို အလျားလိုက် အတိုင်းအတာဖြင့် တိုင်းတာရန် လိုအပ်သောအခါတွင် ပြဿနာ၏ ရှုပ်ထွေးမှုသည် သိသိသာသာ တိုးလာသည်။ ရရှိနိုင်မှု လျော့နည်းစေပြီး ကွန်ရက်ခွဲဝေမှုကို တိုးမြင့်စေသောကြောင့် ညီညွတ်မှုအဆင့်ကို မြင့်မားစွာရရှိရန်မှာ အလွန်ခက်ခဲပါသည်။ ဤဖြစ်စဉ်၏ ယေဘူယျရှင်းပြချက်အတွက် ကျွန်ုပ်သည် သင့်အားကိုးကားရန် အကြံပြုအပ်ပါသည်။ . အပလီကေးရှင်းများသည် မကိုက်ညီမှုအနည်းငယ်ကို ကိုင်တွယ်ဖြေရှင်းနိုင်ပြီး ပရိုဂရမ်မာများသည် ၎င်းကိုကိုင်တွယ်ရန် ဒေတာဘေ့စ်အပေါ် ကြီးကြီးမားမားအားမကိုးဘဲ ကိုက်ညီမှုမရှိခြင်းကို ကိုင်တွယ်ရန် အပလီကေးရှင်းရှိ အပိုယုတ္တိယုတ္တိကို အကောင်အထည်ဖော်ရန် လုံလောက်သောပြဿနာ၏ ကွဲပြားချက်များကို ကောင်းစွာနားလည်နိုင်သည်ကိုလည်း သတိပြုသင့်သည်။
DBMS များသည် ကွဲပြားသော သီးခြားအဆင့်များကို ပေးဆောင်လေ့ရှိသည်။ အပလီကေးရှင်း developer များသည် ၎င်းတို့၏ စိတ်ကြိုက်များကို အခြေခံ၍ အထိရောက်ဆုံးကို ရွေးချယ်နိုင်သည်။ အထီးကျန်မှု နည်းပါးခြင်းသည် မြန်နှုန်း တိုးစေသော်လည်း ဒေတာ ပြိုင်ဆိုင်မှု ဖြစ်နိုင်ခြေကို တိုးစေသည်။ မြင့်မားသော insulation သည် ဤဖြစ်နိုင်ခြေကို လျော့နည်းစေသည်၊ သို့သော် အလုပ်အား နှေးကွေးစေပြီး ပြိုင်ဆိုင်မှုဆီသို့ ဦးတည်သွားနိုင်သည်၊ ၎င်းသည် ကျရှုံးမှုစတင်သည့်အခြေခံရှိ ဘရိတ်များဆီသို့ ဦးတည်သွားစေမည်ဖြစ်သည်။
လက်ရှိ တူညီသော ငွေကြေးပုံစံများနှင့် ၎င်းတို့ကြားရှိ ဆက်ဆံရေးများကို ပြန်လည်သုံးသပ်ခြင်း။
SQL စံနှုန်းသည် သီအိုရီနှင့် လက်တွေ့တွင် အခြားများစွာရှိသော်လည်း သီးခြားခွဲထုတ်ခြင်းအဆင့် လေးခုသာ သတ်မှတ်သည်။ ရှိပြီးသား concurrency မော်ဒယ်များ ၏ ကောင်းမွန်သော ခြုံငုံသုံးသပ်ချက်ကို ပေးပါသည်။ ဥပမာအားဖြင့်၊ Google Spanner သည် နာရီကိုထပ်တူပြုခြင်းဖြင့် ပြင်ပအမှတ်အသားပြုနိုင်မှုကို အာမခံပြီး ၎င်းသည် ပိုမိုတင်းကျပ်သော သီးခြားခွဲထုတ်ခြင်းအလွှာဖြစ်သော်လည်း ၎င်းကို စံအထီးကျန်အလွှာများတွင် မသတ်မှတ်ထားပေ။
SQL စံနှုန်းသည် အောက်ပါ သီးခြားအဆင့်များကို ဖော်ပြသည်-
- ။ (အတင်းကျပ်ဆုံးနှင့် စျေးအကြီးဆုံး)- Serializable execution သည် sequential transaction execution အချို့နှင့် တူညီသောအကျိုးသက်ရောက်မှုရှိပါသည်။ Sequential execution ဆိုသည်မှာ ယခင်တစ်ခုပြီးမြောက်ပြီးမှသာ နောက်ဆက်တွဲငွေပေးငွေယူတစ်ခုစီကို စတင်ခြင်းဖြစ်သည်။ အဆင့်ကို သတိပြုသင့်သည်။ ။ snapshot isolation ကိုယ်တိုင်က SQL စံနှုန်းတွင် ကိုယ်စားမပြုသော်လည်း အဓိပ္ပါယ်ဖွင့်ဆိုမှု ကွဲပြားမှုများကြောင့် snapshot isolation (ဥပမာ Oracle) ဟုခေါ်တွင်လေ့ရှိသည်။
- ထပ်ခါတလဲလဲ ဖတ်နိုင်ပါတယ်။: လက်ရှိ ငွေပေးငွေယူတွင် ခွင့်မပြုသော မှတ်တမ်းများကို လက်ရှိ ငွေပေးငွေယူတွင် ရနိုင်သော်လည်း အခြားငွေပေးငွေယူများမှ ပြုလုပ်သော အပြောင်းအလဲများ (အတန်းအသစ်များကဲ့သို့) .
- ကြူးဖတ်သည်။: ငွေလွှဲခြင်းအတွက် ခွင့်မပြုထားသောဒေတာကို မရနိုင်ပါ။ ဤကိစ္စတွင်၊ ငွေပေးငွေယူများသည် ကတိပြုထားသော ဒေတာများကိုသာ မြင်နိုင်ပြီး phantom reads များ ဖြစ်ပေါ်နိုင်သည်။ ငွေပေးငွေယူတစ်ခုသည် အတန်းအသစ်များကို ထည့်သွင်းပြီး အတန်းသစ်များလုပ်ဆောင်ပါက၊ မေးမြန်းသည့်အခါ ၎င်းတို့ကို လက်ရှိငွေပေးငွေယူမှ မြင်တွေ့နိုင်မည်ဖြစ်သည်။
- ခွင့်မပြုဘဲ ဖတ်ပါ။ (အနည်းဆုံး တင်းကျပ်ပြီး စျေးကြီးသောအဆင့်)- ညစ်ပတ်သောစာများကို ဖတ်ရှုခွင့်ပြုသည်၊ ငွေပေးငွေယူများသည် အခြားငွေပေးငွေယူများဖြင့် ပြုလုပ်ထားသော မလွတ်ကင်းသော အပြောင်းအလဲများကို မြင်တွေ့နိုင်သည်။ လက်တွေ့တွင်၊ ဤအဆင့်သည် မေးမြန်းချက်များကဲ့သို့သော အကြမ်းဖျဉ်းခန့်မှန်းချက်များအတွက် အသုံးဝင်နိုင်ပါသည်။
COUNT(*)စားပွဲပေါ်မှာ။
အဆငျ့ ။ အကောင်အထည်ဖော်ရန် စျေးအကြီးဆုံးဖြစ်ပြီး စနစ်တွင် ပြိုင်ဆိုင်မှုအများဆုံးဝန်ကို ဖြစ်ပေါ်စေပြီး ဒေတာပြိုင်ပွဲများ၏ အန္တရာယ်ကို လျှော့ချပေးသည်။ အခြားသော သီးခြားခွဲထုတ်ခြင်းအဆင့်များသည် အကောင်အထည်ဖော်ရန် ပိုမိုလွယ်ကူသော်လည်း ဒေတာပြိုင်ပွဲများ၏ ဖြစ်နိုင်ခြေကို တိုးမြင့်စေသည်။ အချို့သော DBMS များသည် သင့်အား စိတ်ကြိုက် သီးခြားခွဲထုတ်ခြင်းအဆင့်ကို သတ်မှတ်ခွင့်ပြုသည်၊ အချို့မှာ ခိုင်မာသောဦးစားပေးမှုများရှိပြီး အဆင့်အားလုံးကို ပံ့ပိုးမထားပါ။
သီးခြားခွဲထားမှုအဆင့်များအတွက် ပံ့ပိုးမှုကို ပေးထားသည့် DBMS တွင် မကြာခဏ ကြော်ငြာလေ့ရှိသော်လည်း ၎င်း၏အပြုအမူကို ဂရုတစိုက်လေ့လာမှသာ အမှန်တကယ်ဖြစ်ပျက်နေသည့်အရာကို ဖော်ပြနိုင်သည်။
မတူညီသော DBMS များအတွက် မတူညီသော သီးခြားခွဲထုတ်မှုအဆင့်တွင် တူညီသော ငွေကြေးကွဲလွဲချက်များကို ပြန်လည်သုံးသပ်ခြင်း။
Martin Kleppmann သည် သူ၏ ပရောဂျက်တွင် ဖြစ်သည်။ မတူညီသော သီးခြားခွဲထုတ်ခြင်းအဆင့်များ၊ တူညီသောကွဲလွဲချက်များအကြောင်း ဆွေးနွေးမှုများနှင့် ဒေတာဘေ့စ်သည် သီးခြား သီးခြားခွဲထုတ်ခြင်းအဆင့်ကို လိုက်နာနိုင်မှုရှိမရှိ နှိုင်းယှဉ်သည်။ Kleppmann ၏ သုတေသနပြုချက်သည် အထီးကျန်အဆင့်များနှင့်ပတ်သက်၍ ဒေတာဘေ့စ်ဆော့ဖ်ဝဲရေးသားသူများ မည်ကဲ့သို့ ကွဲပြားသည်ကို ပြသသည်။
ပုံမှန်အတိုင်းထိန်းသိမ်းရန်ခက်ခဲသောအခါတွင် အကောင်းမြင်သောပိတ်ဆို့ခြင်းသည် ကယ်တင်ခြင်းသို့ရောက်ပါသည်။
Blocking သည် ဒေတာဘေ့စ်တွင် ပြိုင်ဆိုင်မှု တိုးလာသောကြောင့်သာမက database နှင့် အမြဲချိတ်ဆက်ရန် application server များ လိုအပ်သောကြောင့်လည်း အလွန်စျေးကြီးပါသည်။ ကွန်ရက် အပိုင်းခွဲခြင်းသည် သီးသန့်သော့ခတ်မှု အခြေအနေများကို ပိုမိုဆိုးရွားစေပြီး ဖော်ထုတ်ရန်နှင့် ဖြေရှင်းရန် ခက်ခဲသော မသေမချာမှုများဆီသို့ ဦးတည်သွားစေနိုင်သည်။ သီးသန့်သော့ခတ်ခြင်းသည် မသင့်လျော်သောကိစ္စများတွင်၊ အကောင်းမြင်သောသော့ခတ်ခြင်းက ကူညီပေးသည်။
string တစ်ခုကို ဖတ်သည့်အခါ ၎င်း၏ဗားရှင်း၊ checksum သို့မဟုတ် နောက်ဆုံးမွမ်းမံမှုအချိန်ကို ထည့်သွင်းစဉ်းစားသည့် နည်းလမ်းတစ်ခုဖြစ်သည်။ ၎င်းသည် ဝင်ရောက်မှုကို မပြောင်းလဲမီ atomic version ပြောင်းလဲခြင်း မရှိကြောင်း သေချာစေရန် ခွင့်ပြုသည်-
UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1
ဤကိစ္စတွင်၊ ဇယားကိုမွမ်းမံခြင်း။ products ဤအတန်းကို ယခင်က အပြောင်းအလဲများ ပြုလုပ်ခဲ့လျှင် အခြားလုပ်ဆောင်ချက်ကို လုပ်ဆောင်မည်မဟုတ်ပါ။ ဤအတန်းတွင် အခြားလုပ်ဆောင်မှုများ မလုပ်ဆောင်ပါက၊ အတန်းတစ်ခုအတွက် အပြောင်းအလဲသည် ဖြစ်ပေါ်လာမည်ဖြစ်ပြီး အပ်ဒိတ်အောင်မြင်သည်ဟု ကျွန်ုပ်တို့ပြောနိုင်ပါသည်။
ညစ်ပတ်သောစာဖတ်ခြင်းနှင့် ဒေတာဆုံးရှုံးခြင်းအပြင် အခြားကွဲလွဲချက်များလည်း ရှိသေးသည်။
ဒေတာညီညွတ်မှုနှင့်ပတ်သက်လာလျှင် ညစ်ညမ်းသောစာဖတ်ခြင်းနှင့် ဒေတာဆုံးရှုံးခြင်းဆီသို့ ဦးတည်သွားစေနိုင်သည့် ပြိုင်ဆိုင်မှုအခြေအနေများအတွက် အလားအလာအပေါ် အာရုံစိုက်သည်။ သို့သော်၊ ဒေတာကွဲလွဲချက်များသည် ထိုနေရာတွင် ရပ်မနေပါ။
ထိုသို့သော ကွဲလွဲချက်များ၏ ဥပမာတစ်ခုမှာ ပုံပျက်ခြင်းကို မှတ်တမ်းတင်ခြင်း ဖြစ်သည်။ (စာတိုရေးပါ). ပုံပျက်ခြင်းများသည် တက်ကြွစွာရှာဖွေလေ့မရှိသောကြောင့် ရှာဖွေတွေ့ရှိရန်ခက်ခဲပါသည်။ ၎င်းတို့သည် ညစ်ပတ်သောစာဖတ်ခြင်း သို့မဟုတ် ဒေတာဆုံးရှုံးမှုကြောင့်မဟုတ်ဘဲ ဒေတာပေါ်တွင်တင်ထားသော ယုတ္တိကန့်သတ်ချက်များကို ချိုးဖောက်ခြင်းကြောင့်ဖြစ်သည်။
ဥပမာအားဖြင့်၊ အော်ပရေတာတစ်ခုသည် အချိန်တိုင်း ဖုန်းခေါ်ဆိုရန် လိုအပ်သည့် စောင့်ကြည့်ရေးအပလီကေးရှင်းကို စဉ်းစားကြည့်ကြပါစို့။
BEGIN tx1; BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0 SELECT COUNT(*)
FROM operators
WHERE oncall = TRUE;
0
UPDATE operators UPDATE operators
SET oncall = TRUE SET oncall = TRUE
WHERE userId = 4; WHERE userId = 2;
COMMIT tx1; COMMIT tx2;အထက်ပါအခြေအနေတွင် အရောင်းအဝယ်နှစ်ခုစလုံးကို အောင်မြင်စွာကျူးလွန်ပါက စံချိန်တင်လာဘ်ပေးလာဘ်ယူမှုတစ်ခု ပေါ်ပေါက်မည်ဖြစ်သည်။ ညစ်ညမ်းသောစာဖတ်ခြင်း သို့မဟုတ် ဒေတာဆုံးရှုံးမှုမရှိသော်လည်း၊ ဒေတာ၏ခိုင်မာမှုကို ထိခိုက်စေခဲ့သည်- ယခုအခါ လူနှစ်ဦးကို တစ်ချိန်တည်းတွင် ဖုန်းခေါ်ဆိုမှုအဖြစ် သတ်မှတ်ထားသည်။
Serializable isolation၊ schema design သို့မဟုတ် database ကန့်သတ်ချက်များသည် စာရေးခြင်းဆိုင်ရာ အကျင့်ပျက်ခြစားမှုကို ဖယ်ရှားရန် ကူညီပေးနိုင်သည်။ တီထွင်သူများသည် ထုတ်လုပ်မှုတွင် ၎င်းတို့ကိုရှောင်ရှားရန် ဖွံ့ဖြိုးတိုးတက်မှုကာလအတွင်း ထိုကွဲလွဲချက်များကို ဖော်ထုတ်နိုင်ရပါမည်။ တစ်ချိန်တည်းမှာပင်၊ မှတ်တမ်းတင်ပုံပျက်မှုများကို ကုဒ်အခြေခံတွင် ရှာဖွေရန် အလွန်ခက်ခဲသည်။ အထူးသဖြင့် ကြီးမားသောစနစ်များတွင်၊ မတူညီသော ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့များသည် တူညီသောဇယားများကိုအခြေခံ၍ လုပ်ဆောင်ချက်များကိုအကောင်အထည်ဖော်ရန် တာဝန်ရှိပြီး ဒေတာဝင်ရောက်ခွင့်၏ သီးခြားအချက်အလက်များအပေါ် သဘောမတူသည့်အခါ။
ဒေတာဘေ့စ်နှင့် အသုံးပြုသူသည် ဘာလုပ်ရမည်ကို အမြဲသဘောမတူပါ။
ဒေတာဘေ့စ်များ၏ အဓိကအင်္ဂါရပ်များထဲမှတစ်ခုမှာ ကွပ်မျက်ရေးအမိန့်၏ အာမခံချက်ဖြစ်သည်၊ သို့သော် ဤအမိန့်သည် ဆော့ဖ်ဝဲလ်ဆော့ဖ်ဝဲရေးသားသူအတွက် ပွင့်လင်းမြင်သာမှု မရှိနိုင်ပါ။ ဒေတာဘေ့စ်များသည် ပရိုဂရမ်မာများ ရည်ရွယ်ထားသော အမှာစာတွင်မဟုတ်ဘဲ ၎င်းတို့လက်ခံရရှိသည့် အစီအစဥ်အတိုင်း ငွေပေးငွေယူများကို လုပ်ဆောင်ပါသည်။ အထူးသဖြင့် highly loaded parallel systems များတွင် ငွေပေးငွေယူအစီအစဥ်ကို ခန့်မှန်းရန်ခက်ခဲသည်။
ဖွံ့ဖြိုးတိုးတက်မှုကာလအတွင်း၊ အထူးသဖြင့် ပိတ်ဆို့ခြင်းမပြုသည့်စာကြည့်တိုက်များနှင့် အလုပ်လုပ်သောအခါ၊ ညံ့ဖျင်းသောပုံစံနှင့် ဖတ်ရှုနိုင်မှုနည်းသောအသုံးပြုသူများသည် ဒေတာဘေ့စ်သို့ မည်သည့်အစီအစဉ်ဖြင့်မဆို ရောက်ရှိနိုင်သည့်အခါ အရောင်းအဝယ်များကို ဆက်တိုက်လုပ်ဆောင်သည်ဟု သုံးစွဲသူများက ယုံကြည်စေသည်။
ပထမတစ်ချက်တွင်၊ အောက်ဖော်ပြပါပရိုဂရမ်တွင် T1 နှင့် T2 ကို ဆင့်ကဲခေါ်သည်၊ သို့သော် ဤလုပ်ဆောင်ချက်များသည် ပိတ်ဆို့ခြင်းမဟုတ်ပါက ရလဒ်ကို ဖောင်ပုံစံသို့ ချက်ချင်းပြန်ပို့ပေးပါ။ ထို့နောက် ၎င်းတို့သည် ဒေတာဘေ့စ်ထဲသို့ ဝင်ရောက်သောအခါတွင် ခေါ်ဆိုမှုအစီအစဥ်ကို ဆုံးဖြတ်ပေးလိမ့်မည်-
result1 = T1() // စစ်မှန်သောရလဒ်များသည် ကတိများဖြစ်သည်။
ရလဒ် 2 = T2()
အကယ်၍ အနုမြူဓာတ် လိုအပ်သည် (ဆိုလိုသည်မှာ၊ လည်ပတ်မှုအားလုံးကို ပြီးမြောက်စေရမည် သို့မဟုတ် ဖျက်သိမ်းရမည်) နှင့် စီစဥ်ခြင်းကိစ္စများဖြစ်ပါက၊ လုပ်ဆောင်ချက် T1 နှင့် T2 တို့ကို အရောင်းအ၀ယ်တစ်ခုတည်းတွင် လုပ်ဆောင်ရပါမည်။
အပလီကေးရှင်းအဆင့် ခွဲဝေမှုအား အပလီကေးရှင်းပြင်ပသို့ ရွှေ့နိုင်သည်။
Sharding သည် ဒေတာဘေ့စ်တစ်ခုကို အလျားလိုက် ပိုင်းဖြတ်သည့် နည်းလမ်းတစ်ခုဖြစ်သည်။ အချို့သော ဒေတာဘေ့စ်များသည် ဒေတာကို အလျားလိုက် အလိုအလျောက် ပိုင်းခြားနိုင်သော်လည်း အချို့သော ဒေတာဘေ့စ်များသည် ကောင်းစွာ မတတ်နိုင်ကြပေ။ ဒေတာဗိသုကာပညာရှင်များ/ဆော့ဖ်ဝဲအင်ဂျင်နီယာများသည် ဒေတာမည်သို့ဝင်ရောက်မည်ကို အတိအကျခန့်မှန်းနိုင်သောအခါ၊ ၎င်းတို့သည် ဤအလုပ်ကို ဒေတာဘေ့စ်သို့လွှဲအပ်မည့်အစား အသုံးပြုသူနေရာရှိ အလျားလိုက်အပိုင်းများကို ဖန်တီးနိုင်သည်။ ဤလုပ်ငန်းစဉ်ကို "application-level sharding" ဟုခေါ်သည်။ (လျှောက်လွှာအဆင့်ခွဲဝေမှု).
ကံမကောင်းစွာပဲ၊ ဤအမည်သည် အက်ပလီကေးရှင်းဝန်ဆောင်မှုများတွင် sharding နေထိုင်သည်ဟူသော အထင်အမြင်လွဲမှားမှုကို ဖန်တီးပေးလေ့ရှိသည်။ တကယ်တော့၊ အဲဒါကို ဒေတာဘေ့စ်ရှေ့မှာ သီးခြားအလွှာတစ်ခုအနေနဲ့ အကောင်အထည်ဖော်နိုင်ပါတယ်။ ဒေတာတိုးတက်မှုနှင့် ဇယားကွက်အစီအမံများပေါ် မူတည်၍ ခွဲခြမ်းစိတ်ဖြာရန် လိုအပ်ချက်များမှာ အတော်လေး ရှုပ်ထွေးသွားနိုင်သည်။ အချို့သောနည်းဗျူဟာများသည် အပလီကေးရှင်းဆာဗာများကို ပြန်လည်အသုံးချရန်မလိုဘဲ ထပ်တလဲလဲလုပ်ဆောင်နိုင်မှုမှ အကျိုးရှိနိုင်သည်။
အပလီကေးရှင်းဆာဗာများကို sharding ဝန်ဆောင်မှုမှ ခွဲထုတ်ထားသည့် ဗိသုကာတစ်ခု၏ ဥပမာ
သီးခြားဝန်ဆောင်မှုတစ်ခုသို့ အသွင်ပြောင်းခြင်းသည် အပလီကေးရှင်းများကို ပြန်လည်အသုံးချရန်မလိုအပ်ဘဲ မတူညီသော sharding ဗျူဟာများကို အသုံးပြုနိုင်စွမ်းကို ချဲ့ထွင်စေသည်။ အက်ပလီကေးရှင်းအဆင့်တွင်ထိုကဲ့သို့သော sharding စနစ်၏ဥပမာတစ်ခုဖြစ်သည်။ Vitess သည် MySQL အတွက် အလျားလိုက် sharding ကို ပံ့ပိုးပေးပြီး သုံးစွဲသူများအား MySQL protocol မှတဆင့် ၎င်းနှင့် ချိတ်ဆက်နိုင်စေပါသည်။ စနစ်သည် ဒေတာများကို တစ်ခုနှင့်တစ်ခုအကြောင်းမသိသော မတူညီသော MySQL node များအဖြစ် အပိုင်းခွဲပေးသည်။
အလိုအလျောက်တိုးလာခြင်းသည် အန္တရာယ်ရှိနိုင်သည်။
AUTOINCREMENT သည် အဓိကသော့များကို ထုတ်လုပ်ရန် ဘုံနည်းလမ်းတစ်ခုဖြစ်သည်။ ဒေတာဘေ့စ်များကို ID ဂျင်နရေတာများအဖြစ် အသုံးပြုသောအခါတွင် မကြာခဏ ဖြစ်ရပ်များရှိပြီး ဒေတာဘေ့စ်တွင် identifier များထုတ်လုပ်ရန် ဒီဇိုင်းထုတ်ထားသော ဇယားများပါရှိသည်။ အလိုအလျောက်တိုးမြှင့်ခြင်းကို အသုံးပြု၍ အဓိကသော့များကို ဖန်တီးရခြင်းသည် စံနမူနာနှင့် ဝေးကွာသည့် အကြောင်းရင်းများစွာ ရှိပါသည်။
- ဖြန့်ဝေထားသော ဒေတာဘေ့စ်တွင် အလိုအလျောက် တိုးလာခြင်းသည် ကြီးလေးသော ပြဿနာဖြစ်သည်။ ID ကိုထုတ်လုပ်ရန်၊ ကမ္ဘာလုံးဆိုင်ရာလော့ခ်တစ်ခုလိုအပ်သည်။ ယင်းအစား၊ သင်သည် UUID တစ်ခုကို ဖန်တီးနိုင်သည်- ၎င်းသည် မတူညီသော ဒေတာဘေ့စ် ဆုံမှတ်များကြား အပြန်အလှန်တုံ့ပြန်မှု မလိုအပ်ပါ။ သော့ခလောက်များဖြင့် အလိုအလျောက် တိုးခြင်းသည် ငြင်းခုံမှုကို ဖြစ်ပေါ်စေပြီး ဖြန့်ဝေသည့် အခြေအနေများတွင် ထည့်သွင်းမှုများအပေါ် စွမ်းဆောင်ရည်ကို သိသိသာသာ လျှော့ချနိုင်သည်။ အချို့သော DBMSs (ဥပမာ၊ MySQL) သည် master-master replication ကို စနစ်တကျစီစဉ်ရန် အထူးဖွဲ့စည်းပုံနှင့် ပိုမိုဂရုပြုရန် လိုအပ်ပါသည်။ မှတ်တမ်းတင်ခြင်း ပျက်ကွက်ခြင်းဆီသို့ ဦးတည်စေမည့် configure လုပ်ရာတွင် အမှားများပြုလုပ်ရန် လွယ်ကူပါသည်။
- အချို့သောဒေတာဘေ့စ်များတွင် ပင်မသော့များကိုအခြေခံ၍ အပိုင်းခွဲခြင်းဆိုင်ရာ အယ်လဂိုရီသမ်များရှိသည်။ ဆက်တိုက် ID များသည် မှန်းလို့မရနိုင်သော hot spot များဆီသို့ ဦးတည်စေပြီး အချို့သော partitions များတွင် load တိုးလာနိုင်ပြီး အချို့ partitions များသည် idle ဖြစ်နေပါသည်။
- ပင်မသော့သည် ဒေတာဘေ့စ်တစ်ခုရှိ အတန်းတစ်ခုကို ဝင်ရောက်ရန် အမြန်ဆုံးနည်းလမ်းဖြစ်သည်။ မှတ်တမ်းများကို ခွဲခြားသတ်မှတ်ရန် ပိုမိုကောင်းမွန်သောနည်းလမ်းများဖြင့်၊ ဆက်တိုက် ID များသည် ဇယားများအတွင်းရှိ အရေးကြီးဆုံးကော်လံကို အဓိပ္ပါယ်မဲ့တန်ဖိုးများဖြင့် ပြည့်နှက်နေသော အသုံးမကျသောကော်လံအဖြစ်သို့ ပြောင်းလဲနိုင်သည်။ ထို့ကြောင့် ဖြစ်နိုင်သည့်အခါတိုင်း၊ ကျေးဇူးပြု၍ ကမ္ဘာလုံးဆိုင်ရာ ထူးခြားပြီး သဘာဝကျသော အဓိကကီး (ဥပမာ သုံးစွဲသူအမည်) ကို ရွေးချယ်ပါ။
ချဉ်းကပ်မှုတစ်ခုအပေါ် မဆုံးဖြတ်မီ၊ ညွှန်းကိန်းပြုလုပ်ခြင်း၊ ပိုင်းခြားသတ်မှတ်ခြင်းနှင့် ခွဲခြမ်းခြင်းအပေါ် အလိုအလျောက်တိုးလာနေသော ID များနှင့် UUID များ၏ အကျိုးသက်ရောက်မှုကို ထည့်သွင်းစဉ်းစားပါ။
Stale data သည် အသုံးဝင်နိုင်ပြီး လော့ခ်ချရန် မလိုအပ်ပါ။
Multiversion Concurrency Control (MVCC) သည် အထက်တွင် အကျဉ်းချုံး ဆွေးနွေးခဲ့သည့် ကိုက်ညီမှုရှိသော လိုအပ်ချက်များစွာကို အကောင်အထည်ဖော်ပါသည်။ အချို့သော ဒေတာဘေ့စ်များ (ဥပမာ၊ Postgres၊ Spanner) သည် လျှပ်တစ်ပြက်ရိုက်ချက်များ—ဒေတာဘေ့စ်၏ ဗားရှင်းအဟောင်းများနှင့်အတူ ငွေပေးငွေယူများကို “ကျွေးမွေး” ရန် MVCC ကို အသုံးပြုသည်။ လိုက်လျောညီထွေရှိစေရန် လျှပ်တစ်ပြက် ငွေပေးငွေယူများကို အတွဲလိုက် ပြုလုပ်နိုင်သည်။ လျှပ်တစ်ပြက်ဟောင်းမှ ဖတ်သည့်အခါ ခေတ်မမီသောဒေတာကို ဖတ်သည်။
ဥပမာအားဖြင့်၊ အချက်အလက်မှ ခွဲခြမ်းစိတ်ဖြာမှုများကို ဖန်တီးခြင်း သို့မဟုတ် အနီးစပ်ဆုံး စုစည်းတန်ဖိုးများကို တွက်ချက်သည့်အခါ အနည်းငယ် ဟောင်းနွမ်းနေသည့် ဒေတာကို ဖတ်ခြင်းသည် အသုံးဝင်ပါသည်။
အမွေအနှစ်ဒေတာနှင့် လုပ်ဆောင်ခြင်း၏ ပထမအားသာချက်မှာ latency နည်းပါးခြင်း (အထူးသဖြင့် ဒေတာဘေ့စ်ကို မတူညီသောနေရာဒေသများတွင် ဖြန့်ဝေပါက)။ ဒုတိယအချက်မှာ ဖတ်ရန်-သီးသန့် ငွေပေးငွေယူများသည် လော့ခ်ချခြင်းမရှိဘဲ ဖြစ်သည်။ ၎င်းသည် ဟောင်းနွမ်းနေသောဒေတာကို ကိုင်တွယ်နိုင်သရွေ့ အများအပြားဖတ်ရှုနိုင်သော အပလီကေးရှင်းများအတွက် သိသာထင်ရှားသော အားသာချက်တစ်ခုဖြစ်သည်။
နောက်ဆုံးထွက်ဗားရှင်းကို ပစိဖိတ်သမုဒ္ဒရာတစ်ဖက်ခြမ်းမှာ ရနိုင်ရင်တောင် အပလီကေးရှင်းဆာဗာက 5 စက္ကန့် နောက်ကျနေသေးတဲ့ ပြည်တွင်းပုံစံတူမှ ဒေတာကို ဖတ်ပါတယ်။
DBMS များသည် ဗားရှင်းအဟောင်းများကို အလိုအလျောက် ဖယ်ရှားပြီး အချို့ကိစ္စများတွင် သင်သည် တောင်းဆိုမှုအရ ၎င်းကို လုပ်ဆောင်ရန် ခွင့်ပြုသည်။ ဥပမာအားဖြင့်၊ Postgres သည် သုံးစွဲသူများကို လုပ်ခွင့်ပေးသည်။ VACUUM တောင်းဆိုမှုအရ၊ ဤလုပ်ဆောင်ချက်ကို အချိန်အခါအလိုက် အလိုအလျောက် လုပ်ဆောင်ပါသည်။ Spanner သည် တစ်နာရီထက်ကြီးသော လျှပ်တစ်ပြက်ရိုက်ချက်များကို ဖယ်ရှားရန် အမှိုက်စုဆောင်းသူအား လုပ်ဆောင်သည်။
အချိန်တိုင်းရင်းမြစ်များသည် ပုံပျက်သွားနိုင်သည်။
ကွန်ပျူတာသိပ္ပံတွင် အကောင်းမွန်ဆုံးသော လျှို့ဝှက်ချက်မှာ အချိန်ကိုက် API များအားလုံး လိမ်ညာခြင်းပင်ဖြစ်သည်။ တကယ်တော့ ကျွန်တော်တို့ စက်တွေက လက်ရှိအချိန်ကို အတိအကျ မသိပါဘူး။ ကွန်ပြူတာများတွင် တုန်ခါမှုများကို ထုတ်ပေးသည့် quartz crystals များ ပါ၀င်ပြီး အချိန်ကို ထိန်းသိမ်းရန် အသုံးပြုသည်။ သို့သော် ၎င်းတို့သည် လုံလောက်သောတိကျမှုမရှိသည့်အပြင် အချိန်အတိအကျထက် နောက်ကျနေနိုင်သည်။ အပြောင်းအရွှေ့သည် တစ်ရက်လျှင် စက္ကန့် 20 အထိရောက်ရှိနိုင်သည်။ ထို့ကြောင့် ကျွန်ုပ်တို့၏ကွန်ပျူတာများပေါ်ရှိအချိန်အား ကွန်ရက်တစ်ခုနှင့် အချိန်အခါအလိုက် ထပ်တူပြုရပါမည်။
NTP ဆာဗာများကို ထပ်တူပြုခြင်းအတွက် အသုံးပြုသော်လည်း ထပ်တူပြုခြင်းလုပ်ငန်းစဉ်ကိုယ်တိုင်က ကွန်ရက်နှောင့်နှေးမှုများကြောင့်ဖြစ်သည်။ တူညီသောဒေတာစင်တာရှိ NTP ဆာဗာတစ်ခုနှင့် ထပ်တူပြုခြင်းသည်ပင် အချိန်အနည်းငယ်ကြာသည်။ အများသူငှာ NTP ဆာဗာတစ်ခုနှင့် လုပ်ဆောင်ခြင်းသည် ပို၍ကြီးမားသော ပုံပျက်ခြင်းသို့ ဦးတည်သွားစေကြောင်း ရှင်းပါသည်။
အနုမြူနာရီများနှင့် ၎င်းတို့၏ GPS အတွဲများသည် လက်ရှိအချိန်ကို ဆုံးဖြတ်ရန် ပိုကောင်းသော်လည်း ၎င်းတို့သည် စျေးကြီးပြီး ရှုပ်ထွေးသော စနစ်ထည့်သွင်းမှု လိုအပ်သောကြောင့် ၎င်းတို့ကို ကားတိုင်းတွင် တပ်ဆင်၍မရပါ။ ထို့အတွက်ကြောင့် ဒေတာစင်တာများသည် အဆင့်လိုက်ချဉ်းကပ်နည်းကို အသုံးပြုသည်။ အဏုမြူနှင့်/သို့မဟုတ် GPS နာရီများသည် အချိန်အတိအကျကိုပြသပြီးနောက် ၎င်းကို ဒုတိယဆာဗာများမှတစ်ဆင့် အခြားစက်များသို့ ထုတ်လွှင့်သည်။ ဆိုလိုသည်မှာ စက်တစ်ခုစီသည် အချိန်အတိအကျမှ တိကျသော offset တစ်ခုကို တွေ့ကြုံခံစားရမည်ဖြစ်သည်။
အပလီကေးရှင်းများနှင့် ဒေတာဘေ့စ်များသည် မတူညီသော စက်များတွင် မကြာခဏ တည်ရှိနေသောကြောင့် အခြေအနေ ပိုမိုဆိုးရွားလာပါသည်။ ထို့ကြောင့်၊ မတူညီသောစက်များတွင် ဖြန့်ဝေထားသော DB node များပေါ်တွင်သာ အချိန်ကွာခြားမည်ဖြစ်သည်။ ၎င်းသည် အပလီကေးရှင်းဆာဗာတွင်လည်း ကွဲပြားလိမ့်မည်။
Google TrueTime သည် လုံးဝခြားနားသော ချဉ်းကပ်မှုကို အသုံးပြုသည်။ ဤဦးတည်ချက်တွင် Google ၏တိုးတက်မှုသည် အနုမြူနှင့် GPS နာရီများဆီသို့ banal အသွင်ကူးပြောင်းမှုဖြင့် ရှင်းပြသည်ဟု လူအများစုက ယုံကြည်ကြသည်၊ သို့သော် ၎င်းသည် ကြီးမားသောပုံ၏တစ်စိတ်တစ်ပိုင်းသာဖြစ်သည်။ TrueTime အလုပ်လုပ်ပုံက ဒီလိုပါ။
- TrueTime သည် မတူညီသော အရင်းအမြစ်နှစ်ခုဖြစ်သည့် GPS နှင့် အနုမြူနာရီများကို အသုံးပြုသည်။ ဤနာရီများတွင် ဆက်နွယ်မှုမရှိသော ချို့ယွင်းမှုမုဒ်များရှိသည်။ [အသေးစိတ်အချက်အလက်များအတွက် စာမျက်နှာ 5 ကိုကြည့်ပါ။ - ခန့်မှန်းခြေ ဘာသာပြန်။)ထို့ကြောင့် ၎င်းတို့၏ တွဲဖက်အသုံးပြုမှုသည် ယုံကြည်စိတ်ချရမှုကို တိုးစေသည်။
- TrueTime တွင် ပုံမှန်မဟုတ်သော API တစ်ခုရှိသည်။ ၎င်းတွင် တိုင်းတာမှုအမှားနှင့် မသေချာမရေရာမှုများနှင့်အတူ အချိန်ကာလတစ်ခုအဖြစ် အချိန်ကို ပြန်ပေးသည်။ အချိန်၏အမှန်တကယ်အခိုက်အတန့်သည် ကြားကာလ၏အထက်နှင့်အောက်နယ်နိမိတ်ကြားတစ်နေရာဖြစ်သည်။ Google ၏ ဖြန့်ဝေထားသော ဒေတာဘေ့စ် Spanner သည် လက်ရှိအချိန်သည် အကန့်အသတ်မရှိဟု ပြောရန် လုံခြုံသည့်အချိန်အထိ စောင့်ဆိုင်းနေပါသည်။ ဤနည်းလမ်းသည် အထူးသဖြင့် သခင်များပေါ်တွင် မသေချာမရေရာမှုများ မြင့်မားနေပါက၊ အထူးသဖြင့် ကမ္ဘာလုံးဆိုင်ရာ ဖြန့်ဝေနေသည့် အခြေအနေတွင်ပင် ဤနည်းလမ်းသည် မှန်ကန်မှုကို သေချာစေသည်။
Spanner အစိတ်အပိုင်းများသည် TT.now() ကြားကာလကို ပြန်ပေးသည့် TrueTime ကိုအသုံးပြုသည်၊ ထို့ကြောင့် Spanner သည် လက်ရှိအချိန်သည် သတ်မှတ်ထားသောအမှတ်ကိုကျော်လွန်သွားသည်ဟု ယုံကြည်နိုင်သည့်အမှတ်အထိ ရိုးရိုးအိပ်စက်နေပါသည်။
လက်ရှိအချိန်ကို ဆုံးဖြတ်ရာတွင် တိကျမှု လျော့နည်းခြင်းသည် Spanner ၏ လုပ်ဆောင်ချက်ကြာချိန် တိုးလာခြင်းနှင့် စွမ်းဆောင်ရည် ကျဆင်းခြင်းတို့ကို ဆိုလိုသည်။ ထို့ကြောင့် လုံးဝတိကျသောနာရီကို ရရှိရန် မဖြစ်နိုင်သော်လည်း ဖြစ်နိုင်ခြေအမြင့်ဆုံးတိကျမှုကို ထိန်းသိမ်းထားရန် အရေးကြီးပါသည်။
နှောင့်နှေးခြင်းသည် အဓိပ္ပါယ်များစွာရှိသည်။
နှောင့်နှေးမှုဆိုတာ ဘာလဲဆိုတာကို ကျွမ်းကျင်သူတစ်ဒါဇင်လောက် မေးရင် အမျိုးမျိုးသော အဖြေတွေ ရနိုင်ပါလိမ့်မယ်။ DBMS latency တွင် မကြာခဏ "ဒေတာဘေ့စ် latency" ဟုခေါ်ပြီး သုံးစွဲသူမှ သိမြင်သည့်အရာနှင့် ကွဲပြားသည်။ အမှန်မှာ client သည် ကွန်ရက်နှောင့်နှေးမှုနှင့် ဒေတာဘေ့စ်နှောင့်နှေးမှုပေါင်းလဒ်ကို စောင့်ကြည့်နေခြင်းဖြစ်သည်။ ကြီးထွားလာသောပြဿနာများကို အမှားရှာပြင်သည့်အခါ latency အမျိုးအစားကို ခွဲထုတ်နိုင်စွမ်းသည် အရေးကြီးပါသည်။ မက်ထရစ်များကို စုဆောင်းပြီး ပြသသည့်အခါ အမျိုးအစားနှစ်မျိုးလုံးကို အမြဲစောင့်ကြည့်ရန် ကြိုးစားပါ။
တိကျသော ငွေပေးငွေယူအတွက် စွမ်းဆောင်ရည်လိုအပ်ချက်များကို အကဲဖြတ်ရပါမည်။
တစ်ခါတစ်ရံတွင် DBMS ၏ စွမ်းဆောင်ရည် လက္ခဏာများနှင့် ၎င်း၏ ကန့်သတ်ချက်များကို ရေး/ဖတ်ခြင်း ဖြတ်သန်းမှု နှင့် latency ဆိုင်ရာ သတ်မှတ်ချက်များတွင် သတ်မှတ်ထားပါသည်။ ၎င်းသည် သော့စနစ်ပါရာမီတာများ၏ ယေဘုယျခြုံငုံသုံးသပ်ချက်ကို ပေးစွမ်းသော်လည်း DBMS အသစ်တစ်ခု၏ စွမ်းဆောင်ရည်ကို အကဲဖြတ်သည့်အခါ၊ ပိုမိုပြည့်စုံသောချဉ်းကပ်မှုမှာ အရေးကြီးသောလုပ်ဆောင်မှုများကို သီးခြားစီအကဲဖြတ်ရန်ဖြစ်သည် (မေးမြန်းမှုတစ်ခုစီနှင့်/သို့မဟုတ် အရောင်းအ၀ယ်တစ်ခုစီအတွက်)။ ဥပမာများ-
- ဆက်စပ်ဇယားများတွင် သတ်မှတ်ထားသောကန့်သတ်ချက်များ နှင့် အတန်းအကွက်များပါသော ဇယား X (အတန်း 50 သန်းပါသော) တွင် အတန်းအသစ်တစ်ခုကို ထည့်သွင်းသည့်အခါ ဖြတ်သန်းမှုနှင့် latency ကိုရေးပါ။
- ပျမ်းမျှသူငယ်ချင်းအရေအတွက် 500 ဖြစ်သောအခါ အချို့သောအသုံးပြုသူ၏ သူငယ်ချင်းများ၏ သူငယ်ချင်းများကို ပြသရာတွင် နှောင့်နှေးခြင်း။
- အသုံးပြုသူသည် တစ်နာရီလျှင် X entries များနှင့်အတူ အခြားအသုံးပြုသူ 100 ကို နောက်လိုက်သောအခါ သုံးစွဲသူ၏ မှတ်တမ်းမှ ထိပ်တန်း 500 entries များကို ပြန်လည်ရယူရာတွင် စောင့်ဆိုင်းချိန်။
အကဲဖြတ်ခြင်းနှင့် လက်တွေ့စမ်းသပ်ခြင်းတွင် ဒေတာဘေ့စ်သည် စွမ်းဆောင်ရည်လိုအပ်ချက်များနှင့် ကိုက်ညီကြောင်း သင်မယုံကြည်မချင်း ထိုကဲ့သို့သော အရေးကြီးသောကိစ္စရပ်များတွင် ပါဝင်နိုင်သည်။ အလားတူလက်မ၏စည်းမျဉ်းသည် latency metrics များစုဆောင်းခြင်းနှင့် SLO များကိုဆုံးဖြတ်သည့်အခါတွင်လည်း ဤအချက်များကို ထည့်သွင်းစဉ်းစားပါသည်။
လုပ်ဆောင်ချက်တစ်ခုစီအတွက် မက်ထရစ်များကို စုဆောင်းသည့်အခါ မြင့်မားသော cardinality ကို သတိထားပါ။ ပါဝါမြင့်သော အမှားရှာပြင်ခြင်းဒေတာကို ရယူရန် မှတ်တမ်းများ၊ ဖြစ်ရပ်စုစည်းမှု သို့မဟုတ် ဖြန့်ဝေထားသော ခြေရာခံခြင်းများကို အသုံးပြုပါ။ ဆောင်းပါးထဲမှာ "» နှောင့်နှေးမှု အမှားရှာပြင်နည်းများဖြင့် သင်ကိုယ်တိုင် ရင်းနှီးနိုင်ပါသည်။
လျှို့ဝှက်ငွေပေးချေမှုများသည် အန္တရာယ်ရှိနိုင်သည်။
DBMS တိုင်းသည် nested ငွေပေးငွေယူများကို ပံ့ပိုးသည်မဟုတ်သော်လည်း ၎င်းတို့လုပ်ဆောင်သည့်အခါတွင်၊ ထိုသို့သော လွှဲပြောင်းမှုများသည် ရှာဖွေတွေ့ရှိရန် အမြဲမလွယ်ကူသော မမျှော်လင့်ထားသော အမှားအယွင်းများ ဖြစ်ပေါ်နိုင်သည် (ဆိုလိုသည်မှာ ကွဲလွဲမှုမျိုးရှိနေကြောင်း သိသာစေသင့်သည်)။
၎င်းတို့ကို ရှာဖွေပြီး ကျော်လွှားနိုင်သည့် ကလိုင်းယင့်ဒစ်ဂျစ်ကို အသုံးပြု၍ အစုအဝေး အရောင်းအ၀ယ်များကို ရှောင်နိုင်သည်။ အသိုက်အမြုံများကို စွန့်ပစ်၍မရပါက၊ အသိုက်အမြုံကြောင့် ပြီးဆုံးသွားသော ငွေပေးငွေယူများ မတော်တဆ ပျက်သွားသည့် မမျှော်လင့်ထားသော အခြေအနေများကို ရှောင်ရှားရန် ၎င်းတို့၏ အကောင်အထည်ဖော်မှုတွင် အထူးဂရုစိုက်ပါ။
မတူညီသောအလွှာများရှိ ငွေပေးငွေယူများကို ထုပ်ပိုးခြင်းဖြင့် မမျှော်လင့်ထားသော အသိုက်အမြုံများဆီသို့ ဦးတည်သွားနိုင်ပြီး ကုဒ်ဖတ်နိုင်မှုအမြင်အရ စာရေးသူ၏ ရည်ရွယ်ချက်များကို နားလည်ရန် ခက်ခဲစေနိုင်သည်။ အောက်ပါအစီအစဉ်ကို ကြည့်ရှုပါ။
with newTransaction():
Accounts.create("609-543-222")
with newTransaction():
Accounts.create("775-988-322")
throw Rollback();အထက်ပါ code ၏ output သည် အဘယ်နည်း။ ငွေပေးငွေယူ နှစ်ခုလုံးကို ပြန်လှည့်မှာလား ဒါမှမဟုတ် အတွင်းပိုင်းတစ်ခုပဲလား။ ကျွန်ုပ်တို့အတွက် အရောင်းအ၀ယ်ပြုလုပ်ခြင်းကို ဖုံးကွယ်ထားသည့် စာကြည့်တိုက်အလွှာများစွာကို အားကိုးပါက ဘာဖြစ်နိုင်မည်နည်း။ ထိုသို့သောကိစ္စများကို ဖော်ထုတ်ပြီး ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်နိုင်ပါမည်လား။
လုပ်ဆောင်ချက်များစွာဖြင့် ဒေတာအလွှာတစ်ခုကို စိတ်ကူးကြည့်ပါ (ဥပမာ။ newAccount) ၎င်း၏ကိုယ်ပိုင် အရောင်းအ၀ယ်လုပ်ငန်းတွင် စတင်အကောင်အထည်ဖော်နေပြီဖြစ်သည်။ ၎င်းတို့ကို ၎င်း၏ကိုယ်ပိုင် အရောင်းအ၀ယ်အတွင်း လုပ်ဆောင်သည့် အဆင့်မြင့် စီးပွားရေး ယုတ္တိဗေဒ၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် ၎င်းတို့ကို လုပ်ဆောင်ပါက မည်သို့ဖြစ်မည်နည်း။ ဤကိစ္စတွင် အထီးကျန်မှုနှင့် ညီညွတ်မှုသည် အဘယ်နည်း။
function newAccount(id string) {
with newTransaction():
Accounts.create(id)
}ထိုသို့သော အဆုံးမဲ့မေးခွန်းများအတွက် အဖြေများကို ရှာဖွေမည့်အစား အသိုက်အမြုံပြုထားသော အရောင်းအဝယ်များကို ရှောင်ရှားခြင်းက ပိုကောင်းပါတယ်။ နောက်ဆုံးတွင်၊ သင်၏ဒေတာအလွှာသည် ၎င်း၏ကိုယ်ပိုင်ငွေလွှဲမှုများကို မဖန်တီးဘဲ အဆင့်မြင့်လုပ်ဆောင်မှုများကို အလွယ်တကူလုပ်ဆောင်နိုင်သည်။ ထို့အပြင်၊ စီးပွားရေးယုတ္တိဗေဒကိုယ်တိုင်က ငွေပေးငွေယူတစ်ခု စတင်ရန်၊ ၎င်းတွင် လည်ပတ်ဆောင်ရွက်မှုကို လုပ်ဆောင်ခြင်း၊ အရောင်းအ၀ယ်ပြုလုပ်ခြင်း သို့မဟုတ် ဖျက်သိမ်းခြင်းတို့ကို လုပ်ဆောင်နိုင်စွမ်းရှိသည်။
function newAccount(id string) {
Accounts.create(id)
}
// In main application:
with newTransaction():
// Read some data from database for configuration.
// Generate an ID from the ID service.
Accounts.create(id)
Uploads.create(id) // create upload queue for the user.ငွေပေးချေမှုများကို အပလီကေးရှင်းအခြေအနေနှင့် မချိတ်ဆက်သင့်ပါ။
တခါတရံတွင် အချို့သောတန်ဖိုးများကိုပြောင်းလဲရန် သို့မဟုတ် query parameters များကို ပြင်ဆင်ရန် အရောင်းအ၀ယ်အခြေအနေတွင် အပလီကေးရှင်းအခြေအနေအား အသုံးပြုရန် ဆွဲဆောင်မှုရှိသည်။ ထည့်သွင်းစဉ်းစားရန် အရေးကြီးသော ကွဲပြားချက်မှာ မှန်ကန်သော အသုံးချမှု နယ်ပယ်ဖြစ်သည်။ ဖောက်သည်များသည် ကွန်ရက်ပြဿနာများရှိသောအခါ ငွေလွှဲမှုများကို ပြန်လည်စတင်လေ့ရှိသည်။ အကယ်၍ ငွေပေးငွေယူသည် အခြားသော လုပ်ငန်းစဉ်အချို့ဖြင့် ပြောင်းလဲနေသည့် အခြေအနေပေါ်တွင် မူတည်ပါက၊ ဒေတာပြိုင်ပွဲ၏ ဖြစ်နိုင်ခြေအပေါ်မူတည်၍ မှားယွင်းသော တန်ဖိုးကို ရွေးချယ်နိုင်ပါသည်။ ငွေပေးချေမှုများသည် အပလီကေးရှင်းရှိ ဒေတာပြိုင်ပွဲအခြေအနေများ၏ အန္တရာယ်ကို ထည့်သွင်းစဉ်းစားရပါမည်။
var seq int64
with newTransaction():
newSeq := atomic.Increment(&seq)
Entries.query(newSeq)
// Other operations...အထက်ဖော်ပြပါ ငွေပေးငွေယူသည် နောက်ဆုံးရလဒ်ကို မခွဲခြားဘဲ လုပ်ဆောင်ပြီးတိုင်း ဆက်တိုက်နံပါတ်ကို တိုးပေးမည်ဖြစ်သည်။ ကွန်ရက်ပြဿနာများကြောင့် ကတိက၀တ်ပျက်ကွက်ပါက၊ သင်ထပ်ကြိုးစားသောအခါတွင် မတူညီသော sequence နံပါတ်တစ်ခုဖြင့် တောင်းဆိုမှုကို လုပ်ဆောင်ပါမည်။
Query Planner များသည် ဒေတာဘေ့စ်တစ်ခုအကြောင်း များစွာပြောပြနိုင်ပါသည်။
ဒေတာဘေ့စ်တစ်ခုတွင် မေးခွန်းတစ်ခုအား မည်သို့လုပ်ဆောင်မည်ကို စုံစမ်းရေးမှူးများက ဆုံးဖြတ်သည်။ ၎င်းတို့သည် တောင်းဆိုမှုများကို ခွဲခြမ်းစိတ်ဖြာပြီး ၎င်းတို့ကို မပေးပို့မီ ၎င်းတို့ကို ပိုမိုကောင်းမွန်အောင် ပြုလုပ်ပေးသည်။ အစီအစဥ်ရေးဆွဲသူများသည် ၎င်းတို့၏ အကောင်အထည်ဖော်မည့် အချက်ပြမှုများအပေါ် အခြေခံ၍ ဖြစ်နိုင်ခြေရှိသော ခန့်မှန်းချက်များကိုသာ ပေးနိုင်ပါသည်။ ဥပမာအားဖြင့်၊ အောက်ပါမေးခွန်းအတွက် အကောင်းဆုံးရှာဖွေမှုနည်းလမ်းမှာ အဘယ်နည်း။
SELECT * FROM articles where author = "rakyll" order by title;ရလဒ်များကို နည်းလမ်းနှစ်မျိုးဖြင့် ပြန်လည်ရယူနိုင်သည်-
- စားပွဲအပြည့်စကင်န်: ဇယားရှိ entry တစ်ခုစီကို ကြည့်ရှုနိုင်ပြီး ကိုက်ညီသော စာရေးဆရာအမည်ဖြင့် ဆောင်းပါးများကို ပြန်ပို့နိုင်ပြီး ၎င်းတို့ကို မှာယူနိုင်ပါသည်။
- အညွှန်းစကင်န်: ကိုက်ညီသော ID များကို ရှာဖွေရန်၊ ထိုအတန်းများကို ရယူပြီးနောက် ၎င်းတို့ကို အမိန့်ပေးရန်အတွက် အညွှန်းတစ်ခုကို သင်အသုံးပြုနိုင်သည်။
query planner ၏အလုပ်မှာ မည်သည့်နည်းဗျူဟာက အကောင်းဆုံးဖြစ်သည်ကို ဆုံးဖြတ်ရန်ဖြစ်သည်။ စုံစမ်းမေးမြန်းမှု အစီအစဉ်ရေးဆွဲသူများသည် ကြိုတင်ခန့်မှန်းနိုင်မှု အကန့်အသတ်သာရှိသည်ကို ထည့်သွင်းစဉ်းစားသင့်ပါသည်။ ယင်းသည် ဆိုးရွားသော ဆုံးဖြတ်ချက်များဆီသို့ ဦးတည်သွားနိုင်သည်။ DBA များ သို့မဟုတ် ဆော့ဖ်ဝဲရေးသားသူများသည် ၎င်းတို့ကို စွမ်းဆောင်ရည်နိမ့်ကျသော မေးခွန်းများကို ရှာဖွေစစ်ဆေးရန်နှင့် ကောင်းစွာချိန်ညှိရန် ၎င်းတို့ကို အသုံးပြုနိုင်သည်။ DBMS ၏ ဗားရှင်းအသစ်များသည် query planner များကို configure လုပ်နိုင်ပြီး ဗားရှင်းအသစ်သည် စွမ်းဆောင်ရည်ပြဿနာများဖြစ်ပေါ်လာပါက ဒေတာဘေ့စ်ကို အပ်ဒိတ်လုပ်ရာတွင် အထောက်အကူဖြစ်နိုင်သည် ။ နှေးကွေးသော မေးမြန်းမှုမှတ်တမ်းများ၊ တုံ့ပြန်မှုပြဿနာအစီရင်ခံစာများ သို့မဟုတ် လုပ်ဆောင်ချိန်စာရင်းဇယားများသည် ပိုမိုကောင်းမွန်အောင်လုပ်ဆောင်ရန် လိုအပ်သည့် မေးခွန်းများကို ဖော်ထုတ်ရာတွင် ကူညီပေးနိုင်ပါသည်။
စုံစမ်းမှုစီစဉ်သူမှတင်ပြသော အချို့သောမက်ထရစ်များသည် ဆူညံနေနိုင်သည် (အထူးသဖြင့် latency သို့မဟုတ် CPU အချိန်ကို ခန့်မှန်းသည့်အခါ)။ အချိန်ဇယားဆွဲသူများ၏ ကောင်းမွန်သော အပြင်အဆင်များသည် အကောင်အထည်ဖော်မှုလမ်းကြောင်းကို ခြေရာခံခြင်းနှင့် ခြေရာခံခြင်းအတွက် ကိရိယာများဖြစ်သည်။ ၎င်းတို့သည် သင့်အား ထိုကဲ့သို့သော ပြဿနာများကို ရှာဖွေဖော်ထုတ်ရန် ခွင့်ပြုပေးသည် (ဖြစ်ချင်တော့၊ DBMS များအားလုံးသည် ထိုကဲ့သို့သော ကိရိယာများကို ပေးစွမ်းသည်မဟုတ်ပါ)။
အွန်လိုင်း ရွှေ့ပြောင်းခြင်းသည် ခက်ခဲသော်လည်း ဖြစ်နိုင်သည်။
အွန်လိုင်း ရွှေ့ပြောင်းခြင်း၊ တိုက်ရိုက် ရွှေ့ပြောင်းခြင်း သို့မဟုတ် အချိန်နှင့်တပြေးညီ ရွှေ့ပြောင်းခြင်း ဆိုသည်မှာ အချိန်ဆွဲခြင်း သို့မဟုတ် ဒေတာ ပျက်စီးခြင်းမရှိဘဲ ဒေတာဘေ့စ်တစ်ခုမှ အခြားတစ်ခုသို့ ပြောင်းရွှေ့ခြင်းကို ဆိုလိုသည်။ တူညီသော DBMS/အင်ဂျင်အတွင်း အသွင်ကူးပြောင်းမှုဖြစ်ပေါ်ပါက တိုက်ရိုက်ရွှေ့ပြောင်းခြင်းသည် ပိုမိုလွယ်ကူသည်။ မတူညီသောစွမ်းဆောင်ရည်နှင့် schema လိုအပ်ချက်များဖြင့် DBMS အသစ်တစ်ခုသို့ ရွှေ့ရန် လိုအပ်သည့်အခါ အခြေအနေမှာ ပိုမိုရှုပ်ထွေးလာသည်။
ကွဲပြားခြားနားသောအွန်လိုင်းပြောင်းရွှေ့မှုမော်ဒယ်များရှိသည်။ ဤတွင် ၎င်းတို့အနက်မှ တစ်ခုဖြစ်သည်။
- ဒေတာဘေ့စ်နှစ်ခုလုံးတွင် double entry ကိုဖွင့်ပါ။ ဤအဆင့်ရှိ ဒေတာဘေ့စ်အသစ်တွင် ဒေတာအားလုံးမပါဝင်သော်လည်း နောက်ဆုံးဒေတာကိုသာ လက်ခံပါသည်။ ဒါကို သေချာသိပြီးတာနဲ့ နောက်တစ်ဆင့်ကို ဆက်သွားနိုင်ပါတယ်။
- ဒေတာဘေ့စ်နှစ်ခုလုံးမှ စာဖတ်ခြင်းကို ဖွင့်ပါ။
- ဒေတာဘေ့စ်အသစ်တွင် အဓိကအားဖြင့် စာဖတ်ခြင်းနှင့် စာရေးခြင်းများ လုပ်ဆောင်နိုင်ရန် စနစ်အား ပြင်ဆင်ပါ။
- ၎င်းမှဒေတာများကို ဆက်လက်ဖတ်ရှုနေစဉ် ဒေတာဘေ့စ်အဟောင်းသို့ စာရေးခြင်းကို ရပ်ပါ။ ဤအဆင့်တွင်၊ ဒေတာဘေ့စ်အသစ်သည် ဒေတာအချို့မပါဝင်သေးပါ။ ၎င်းတို့ကို ဒေတာဘေ့စ်ဟောင်းမှ ကူးယူသင့်သည်။
- ဒေတာဘေ့စ်အဟောင်းသည် ဖတ်ရန်သာဖြစ်သည်။ ဒေတာဘေ့စ်ဟောင်းမှ ပျောက်ဆုံးနေသောဒေတာကို အသစ်သို့ ကူးယူပါ။ ရွှေ့ပြောင်းခြင်းပြီးပါက၊ ဒေတာဘေ့စ်အသစ်သို့ လမ်းကြောင်းများကို ပြောင်းကာ အဟောင်းကို ရပ်ပြီး ၎င်းကို စနစ်မှ ဖျက်ပါ။
နောက်ထပ်အချက်အလက်များအတွက်၊ ကျွန်ုပ်ထံ ဆက်သွယ်ရန် အကြံပြုအပ်ပါသည်။ ဤမော်ဒယ်အပေါ် အခြေခံ၍ Stripe ၏ ရွှေ့ပြောင်းခြင်းဆိုင်ရာ မဟာဗျူဟာကို အသေးစိတ်ဖော်ပြသည်။
ဒေတာဘေ့စ်တွင် သိသာထင်ရှားစွာ တိုးလာခြင်းသည် မှန်းဆမရသော တိုးများလာစေသည်။
ဒေတာဘေ့စ်တိုးတက်မှုသည် ၎င်း၏စကေးနှင့်ဆက်စပ်၍ ခန့်မှန်းမရသောပြဿနာများဆီသို့ ဦးတည်စေသည်။ ဒေတာဘေ့စ်တစ်ခု၏ အတွင်းပိုင်းတည်ဆောက်ပုံအကြောင်း ကျွန်ုပ်တို့ပိုသိလေ၊ ၎င်းသည် မည်သို့မည်ပုံအတိုင်းအတာကို ခန့်မှန်းနိုင်လေလေဖြစ်သည်။ သို့သော် အချို့သော အခိုက်အတန့်များသည် ကြိုမြင်ရန် မဖြစ်နိုင်သေးပါ။
အခြေခံများ ကြီးထွားလာသည်နှင့်အမျှ ဒေတာပမာဏနှင့် ကွန်ရက် bandwidth လိုအပ်ချက်များနှင့် ပတ်သက်၍ ယခင်ယူဆချက်များနှင့် မျှော်လင့်ချက်များသည် ခေတ်နောက်ကျသွားနိုင်သည်။ ဤသည်မှာ ကြီးမားသော ဒီဇိုင်းပြန်လည်ပြင်ဆင်မှုများ၊ အကြီးစားလုပ်ငန်းလည်ပတ်တိုးတက်မှုများ၊ ပြန်လည်စဉ်းစားခြင်းများ၊ သို့မဟုတ် ဖြစ်နိုင်ချေပြဿနာများကိုရှောင်ရှားရန် အခြားသော DBMS များသို့ ပြောင်းရွှေ့ခြင်းဆိုင်ရာ မေးခွန်းများ ပေါ်ပေါက်လာပါသည်။
သို့သော် ရှိပြီးသားဒေတာဘေ့စ်၏ အတွင်းပိုင်းတည်ဆောက်ပုံဆိုင်ရာ ကောင်းမွန်သောအသိပညာသည် လိုအပ်သောတစ်ခုတည်းသောအရာဖြစ်သည်ဟု မထင်လိုက်ပါနှင့်။ စကေးအသစ်များသည် အမည်မသိအသစ်များကို ၎င်းတို့နှင့်အတူ ယူဆောင်လာမည်ဖြစ်သည်။ ကြိုတင်မှန်းမရသော နာကျင်မှုအချက်များ၊ မညီမညာသော ဒေတာဖြန့်ဝေမှု၊ မမျှော်လင့်ထားသော လှိုင်းဘန်းဝဒ်နှင့် ဟာ့ဒ်ဝဲပြဿနာများ၊ အသွားအလာများပြားလာခြင်းနှင့် ကွန်ရက်အပိုင်းအသစ်များသည် သင်၏ဒေတာဘေ့စ်ချဉ်းကပ်မှု၊ ဒေတာပုံစံ၊ အသုံးချမှုပုံစံနှင့် ဒေတာဘေ့စ်အရွယ်အစားတို့ကို ပြန်လည်စဉ်းစားရန် တွန်းအားပေးမည်ဖြစ်သည်။
...
ဒီဆောင်းပါးကို ထုတ်ဝေဖို့ စတင်စဉ်းစားချိန်မှာတော့ ကျွန်တော့်ရဲ့ မူရင်းစာရင်းမှာ နောက်ထပ် အကြောင်းအရာ ငါးခုရှိနေပါပြီ။ နောက်တော့ အရေအတွက် များလာတယ်။ အခြားမည်သည့်အရာများကို ဖုံးကွယ်နိုင်မည်နည်း။ ထို့ကြောင့်၊ ဆောင်းပါးသည် အများဆုံးအာရုံစိုက်ရန် လိုအပ်သည့် သိသာထင်ရှားသော ပြဿနာအနည်းဆုံးနှင့် ဆောင်းပါးကို ရေးထားသည်။ သို့သော်၊ ၎င်းသည် ခေါင်းစဉ် ကုန်ဆုံးသွားသည်ဟု မဆိုလိုဘဲ၊ ကျွန်ုပ်၏ အနာဂတ် ပစ္စည်းများထဲတွင် ၎င်းကို ကျွန်ုပ် ပြန်၍ မရနိုင်တော့ဘဲ လက်ရှိ အကြောင်းအရာကို ပြောင်းလဲမည် မဟုတ်ပေ။
PS
ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ
- «";
- «";
- «"။
source: www.habr.com